Příspěvky

3721

Software / Re:Hledám prohlížeč který podporuje Java aplety

« kdy: 14. 10. 2017, 16:18:49 »

Vážně nikdo neví? 

Na tom, co napsal Jenda, se vám nelíbí co?

3722

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 14. 10. 2017, 12:09:46 »

Kompletne zabranit poruse nejde, ale poruchu je treba nejak detekovat. Treba tim, ze soubor bude zabalen jako 7z archiv a bude pravidelne testovan.

Přestaňte trvat na tomhle nesmyslu, už vám tu psali jiní, že tohle je k ničemu a navíc zbytečně komplikované. Komprese souborů do archivu slouží ke zmenšení objemu dat, ne k zajištění neporušitelnosti. Když se ten archiv poškodí, klidně ho rozbalíte, akorát získáte jiná data. Což je přesně to, čemu chcete zabránit. Jediný případ, kdy byste poškození poznal, by byly některé typy poškození metadat.

Pro kontrolu toho, že nedošlo ke změně souboru, se používají otisky souborů, nebo-li hashe. Spočítejte si SHA-512 hash toho ukládaného souboru a hash si někam uložte. (Soubor máte na více místech, hash uložte také na více míst – ideálně ke každému uloženému souboru uložte i jeho hash. Tím máte ošetřené neúmyslné poškození souboru. Pokud se chcete bránit i před úmyslným poškozením, tj. útočník by změnil soubor a také přepočítal hash, uložte si hash ještě někde jinde, offline do trezoru, aby se k němu útočník nedostal.) Až budete chtít zkontrolovat, že se obsah souboru nezměnil, spočítáte znovu jeho hash a porovnáte s tím, co máte uložené. Pokud v tom souboru máte uložený recept na výrobu elixíru mládí, mapu Atlantidy a Peroutkův článek „Hitler je gentleman“, mlžete těch hashů spočítat i víc různými algoritmy, třeba SHA-3,  SHA-512 a třeba ještě BLAKE2.

Ale hlavně, pokud je to opravdu tak důležité, jak tvrdíte, nechte ten proces ukládání, kontroly a obnovy navrhnout někoho, kdo bezpečnosti rozumí. Ta vaše validace pomocí 7z je zásadní chyba, je tudíž dost pravděpodobné, že podobné kiksy máte i v jiných částech procesu, které jste tu nepopsal – třeba práce s tím TC archivem nebo s klíči.

3723

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 14. 10. 2017, 09:54:43 »

Dela to kazdy prohlizec, rika se tomu "pametova cache" ;-)

Hm, kampak se asi ztrati veskera ta pamet, kdyz pustim browser a chvili lezu po webu?

To ale není cache souborů – opravdu nedává smysl cachovat v paměti to, co už jednou cachuje operační systém, a akorát tím zbytečně zabírat paměť. Zkuste si to představit, pokud byste měli paměť jen na dva soubory. Buď se vám tam vejde soubor A nacachovaný v OS a ten samý soubor A podruhé nacachovaný v prohlížeči, nebo se vám tam vejdou soubory A a B nacachované v OS. Lepší je samozřejmě druhá varianta, protože když budete chtít načíst soubor A, v obou případech ho načtete z paměti, ale když budete chtít načíst soubor B, v prvním případě ho musíte načíst z disku a v druhém případě z paměti. Což je samozřejmě rychlejší, proto se to cachování souborů v paměti dělá. Navíc v tom prvním případě by se pro načtení souboru B nejdříve musela nějaká paměť uvolnit, např. zapsat do swapu. Takže by se klidně mohlo stát, že soubor A, který už máte na disku a dokonce ještě v jiném místě paměti, by se úplně zbytečně zapisoval do swapu. A až by ho ten proces chtěl zase číst, musel by se zase načíst ze swapu na disku – přestože vedle by byl ten samý obsah v paměti v cache OS.

To, co cachují prohlížeče v paměti, je DOM (rozparsované a načtené stránky), rozparsovaný a případně zkompilovaný JavaScript, případně jiné už předzpracované objekty.

Cache je obecný pojem, existuje spousta různých druhů cache, takže když máte dva různé cachovací mechanismy, neznamená to, že by cachovaly to samé – naopak by to bylo neefektivní. Už tady byly zmíněné tři různé cache – prohlížeč si lokálně cachuje soubory, aby je nemusel stahovat z internetu; OS cachuje data načtená z disku do paměti, aby je nemusel načítat znovu z disku, když je bude chtít nějaký proces číst; prohlížeč cachuje předzpracované objekty (webové stránky, skripty), aby je nemusel znovu parsovat a překládat nebo interpretovat, když bude chtít uživatel zobrazit danou stránku. Dál prohlížeč cachuje třeba výsledky DNS dotazů – to ale vůbec neznamená, že by to mělo něco společného se souborovou cache OS.

3724

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 13. 10. 2017, 21:22:55 »

A proc cachuji browsery? Ze by proto, ze cache OS pro dane pouziti nevyhovuje?

To je ale úplně jiná cache. Browsery lokálně cachují data, která by jinak musely znovu stahovat ze sítě. Ta data uloží do souboru na disk. Nevím o to, že by nějaký prohlížeč data, která má na disku, ještě duplicitně držel v paměti.

Disková cache OS funguje tak, že když nějaký proces čte data ze souboru, OS je načte do paměti, a nechá je tam i po té, kdy je proces přečetl – dokud není paměť potřeba pro něco důležitějšího. Stahovat soubory přes HTTPS OS opravdu neumí.

3725

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 13. 10. 2017, 20:04:11 »

pripadne si ho jeste navrch ulozi do cache

Proč by takovou hloupost dělal, když to může mít v cache operační systém? Aby se pokud možno zaplnila paměť, přeteklo to do swapu a ta data, která jsou už jednou na disku, se pro jistotu zapsala na disk ještě podruhé a příště by se četla z disku?

ale rozhodne ho nedrzi otevrenej

To nepište mně, to běžte napsat autorům Apache – zjevně totiž nevědí, co dělají.

Kdybyste aspoň tušil, o čem je řeč, věděl byste, jak triviální je ověřit si to, co tady píšu. Mohl byste mi prozradit, kde se podle vás ve výpisu deskriptorů souborů Apache vzal ten deskriptor č. 5?

Kód: [Vybrat]

root@desktop:~# a2enmod file_cache
Considering dependency cache for file_cache:
Enabling module cache.
Enabling module file_cache.
To activate the new configuration, you need to run:
  service apache2 restart

root@desktop:~# echo 'CacheFile /var/www/html/index.html' >> /etc/apache2/apache2.conf

root@desktop:~# service apache2 restart
 * Restarting Apache httpd web server apache2    

root@desktop:~# ls -l /proc/25129/exe
lrwxrwxrwx 1 root root 0 říj 13 19:57 /proc/25129/exe -> /usr/sbin/apache2

root@desktop:~# ls -l /proc/25129/fd/
celkem 0
lr-x------ 1 root root 0 říj 13 19:58 0 -> /dev/null
l-wx------ 1 root root 0 říj 13 19:58 1 -> /dev/null
l-wx------ 1 root root 0 říj 13 19:58 2 -> /var/log/apache2/error.log
lrwx------ 1 root root 0 říj 13 19:58 3 -> /unknown
lrwx------ 1 root root 0 říj 13 19:58 4 -> /unknown
lr-x------ 1 root root 0 říj 13 19:58 5 -> /var/www/html/index.html
lr-x------ 1 root root 0 říj 13 19:58 6 -> pipe:[21343]
l-wx------ 1 root root 0 říj 13 19:58 7 -> pipe:[21343]
l-wx------ 1 root root 0 říj 13 19:58 8 -> /var/log/apache2/other_vhosts_access.log
l-wx------ 1 root root 0 říj 13 19:58 9 -> /var/log/apache2/access.log

protoze pro to neexistuje naprosto zadnej duvod

Existuje, a to zrychlení přístupu k souboru.

3726

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 23:21:16 »

Vzhledem k tomu, ze je to bastl od MS, tak bych si radsi nebyl nicim jisty.

Já jsem to zkoušel na Ubuntu pod Windows 10 s vimem – ve vimu jsem otevřel soubor s NTFS svazku (/mnt/c/…), vim si vytvoří pracovní soubor .nazev.swp. Podíval jsem se do /proc/<vim-pid>/fd/, tam je vidět otevřený deskriptor souboru, v průzkumníkovi ve Windows se v příslušném adresáři objevil soubor .nazev.swp. Z průzkumníka jsem ho smazal, v Ubuntu už ten název souboru také neexistoval (ověřeno výpisem ls -la), ale link v /proc/<vim-pid>/fd/ stále existoval – a cat /proc/<vim-pid>/fd/ vypsal očekávaný obsah pracovního souboru vimu. Chovalo se to tedy přesně podle očekávání a úplně stejně, jako na čistokrevném Linuxu běžícím přímo na železe. mmap jsem nezkoušel, ale nemám žádný důvod myslet si, že by to mělo fungovat jinak.

S dovolením budu tedy raději věřit tomu, co jsem si sám vyzkoušel, než vašim pochybám, které nemáte podložené žádným experimentem nebo dokumentací.

To by nešlo, Jirsák postupuje podle těchto bodů:

Chápu vaši frustraci z toho, že jsem si vám dovolil oponovat, vám, který si o sobě myslíte, že jste mistr světa. Nicméně to, že si někdo dovolí oponovat vám, opravdu neznamená, že si dotyčný myslí, že má vždy pravdu. Ostatně pokud si myslíte, že pravdu nemám, napište konkrétně, v čem se mýlím, jak je to podle vás – a ideálně také něco, čím svůj názor podpoříte. Zatím tady na tazatelův dotaz padly dvě relevantní odpovědi – že soubor cachuje prohlížeč, což tazatel následně vyvrátil, a druhá odpověď byla, že z nějakého důvodu starý obsah posílá server. Já jsem vysvětlil, v jakém případě a proč server může posílat starý odkaz, JardaP. to doplnil citací o mod_file_cache a Majkl to doplnil odkazem na MSDN, v obou případech jsou popisovány stejné principy, o kterých jsem psal já. Nikdo tahle tvrzení nevyvrátil ani nenapsal nebo neodkázal nic, co by s nimi bylo v rozporu.

Takže pokud jste přesvědčen, že se mýlím, protože ten geniální jste tu přece vy ne nemůže být nikdo, kdo by se vám alespoň přiblížil, dokažte to. Dokažte, že se mýlím, a neztrapňujte se tu podsouváním věcí, které jsem nikdy netvrdil. Ten váš předpoklad, že Jirsák nikdy nemůže mít pravdu, totiž nevypovídá nic o mně, jenom o vás.

3727

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 16:41:31 »

@Filip Jirsák: A vy vite s jistotou, ze v linuxovem subsystemu na Widlich to funguje take tak?

Jistě. Není tak těžké si to vyzkoušet. A navíc by to těžko mohlo fungovat jinak.

3728

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 15:48:09 »

No, jede to na NTFS a pres widlofy ovladac FS, takze bych si neroufal tvrdit, ze to takto funguje, protoze nemam tuseni, jak to na tech Widlich v tomto pripade je.

To počítání odkazů není vlastností jednotlivých souborových systémů (btrfs, ext4 apod.), ale přímo součástí VFS. Třeba když je spuštěný program, který drží otevřený soubor, na souborovém systému na disku se to nijak neprojeví – je to informace, kterou si udržuje VFS v paměti.

3729

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 15:44:34 »

Nebylo  by lepší si místo těch bludů přečíst ten odkaz na MS? 

Bylo, netuším, proč to neuděláte. Můžu vám tu i jeden odstavec vypíchnout:

Further, as in Linux, some Windows tools implement unusual filesystem access patterns to handle file updating and don't actually edit files in-place: When apps/tools save changes to a file, the original files are often deleted and re-created, etc. During such operations, NT file extended properties (i.e. Linux file permissions) are often not copied and are "lost".

Už to tu máte vysvětlené potřetí, tak třeba to vezmete na vědomí…

3730

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 15:20:29 »

Tenhle nesmysl vznikl tak, že tady napsal svou spekulaci či hypotézu (nebo co to bylo) Filip Jirsák, bez toho, že by to podpořil nějakými reálnými podklady. A napsat ji takto mohl jen proto, že tazatel nedal k dispozici moc informací, což pak nahrává tomu, že si kde kdo může napsat kde co, bez toho, že by se to opíralo o něco opravdu reálného.

V dalších komentářích tazatel informace doplnil:

Za prvé, starou verzi souboru zobrazují i jiné prohlížeče, kde stránka předtím nebyla zobrazena – takže nemůže jít o cache v prohlížeči. Mohla by to ještě dělat nějaká cache mezi prohlížečem a serverem, ale dá se předpokládat, že to tazatel zkouší přímo. Nebo-li je vysoce pravděpodobné, že starou verzi souboru servíruje přímo server.

Za druhé, když tazatel zkusí zobrazit soubor příkazem cat přímo z Linuxu, zobrazí se nová verze. Takže to není žádný problém v té emulační vrstvě mezi Windows a Linuxem (leda že by různým programům poskytovala různé verze souborů, ale to by byl fakt úlet). No a případ, kdy v Linuxu vidí dva programy různá data v jednom souboru, nastává právě tehdy, když program drží soubor otevřený, jiný program ten soubor smaže a na jeho místě vytvoří nový, se stejným názvem (což je u Windowsovských editorů typický postup). Původní program pak stále vidí ten soubor, který původně otevřel (a který už nemusí mít žádné jméno), nově spuštěný program použije cestu k souboru pro získání ukazatele, ale cesta už vede na nový soubor.

Takže zbývá vyřešit, proč Apache drží ten soubor otevřený – jednu z možných odpovědí citoval JardaP.

Pokud nějaký program drží otevřený soubor přes souborový deskriptor, je vidět v adresáři /proc/<PID>/fd/. mmap ale má v Linuxu svůj vlastní odkaz na soubor a původní souborový descriptor je po volání mmap možné zavřít, takže pokud Apache soubor drží přes mmap, v /proc/<PID>/fd to vidět nebude – je ale možné to najít v souboru /proc/<PID>/maps.

3731

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 14:58:12 »

Protoze apache urcite nedrzi soubor otevreny

V komentáři výše od JardyP. máte popsán jeden z případů, kdy Apache drží otevřený soubor.

urcite neblokuje fyzicke smazani souboru...

Souborové systémy na Linuxu (a na Unixem obecně) fungují tak, že je někde na disku uložený soubor (tj. samotná data souboru, jeho obsah), a na ten soubor existuje jeden nebo více odkazů. Odkazy jsou například jména souborů v adresářích – nebo-li když máte nějak pojmenovaný soubor na disku, je to právě odkaz na ta data soubor. Když vytvoříte hardlink na soubor, není to nic jiného, než že do nějakého adresáře přidáte další odkaz na ten soubor (tj. na jeden obsah souboru vedou dva různé odkazy). A také každý program, který má otevřený nějaký soubor, má odkaz na ten soubor. Souborový systém pak funguje tak, že se soubor (tj. jeho obsah) fyzicky smaže teprve tehdy, když počet odkazů na soubor klesne na nulu. Takže když smažete nějaký soubor (např. pomocí příkazu rm), smaže se ten odkaz z adresáře – ale pokud na soubor vede nějaký další odkaz, třeba ze spuštěného programu, soubor dál na disku zůstává. Nebo-li můžete mít na disku soubor, ke kterému nevede žádná cesta ze souborového systému (myšleno teď přímo ze souborového systému na diskovém oddílu, ponechme stranou speciální souborové systémy jako /proc).  Takže například pokud vám nějaký program bude chrlit spoustu dat do logu a bude docházet místo na disku, vy soubor s logem smažete, ale žádné místo na disku se neuvolní, protože na soubor s logem stále vede odkaz z toho programu a ten do logu vesele dál zapisuje. Nebo-li dokud jakýkoli program v Linuxu má otevřený nějaký soubor, brání fyzickému smazání toho souboru, protože počet odkazů na soubor nemůže klesnout na nulu.

3732

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 12. 10. 2017, 06:58:15 »

@Filip Jirsák:
A co treba:
…

To je přesně to, co jsem napsal. Soubor není nijak explicitně cachovaný Apachem, ale Apache ho drží otevřený. A pokud dojde ke smazání souboru a vytvoření nového souboru se stejným jménem, Apache to kvůli implementaci souborových systémů na Linuxu nezjistí, protože má stále odkaz na ten původní soubor (který už po smazání není dostupný pod žádným jménem, ale protože na něj ještě existuje v Apachi odkaz, nedojde k jeho fyzickému smazání).

3733

Windows a jiné systémy / Re:Bash Ubuntu ve Windows 10 a změny souborů z Windows

« kdy: 11. 10. 2017, 22:53:52 »

Cache Apache se mi moc nezdá, není k tomu důvod, aby to držel někde explicitně nacacheované. Ale je možné, že drží otevřený soubor, a že ten editor ve Windows ve skutečnosti udělá to, že původní soubor smaže a zapíše nový se stejným názvem. Mělo by to být vidět v adresáři /proc příslušného procesu Apache – v podadresáři fd je seznam otevřených souborů, uvidíte, zda tam bude odkaz na ten váš soubor a případně zda bude označený jako deleted.

3734

Vývoj / Re:Jak vlastně vypadá diskový oddíl?

« kdy: 02. 10. 2017, 08:52:13 »

Pokud se nepoužívá GPT, je na začátku disku Master boot record (MBR). Jeho součástí je i tabulka rozdělení disku, ale před ní je ještě kód zavaděče (kód, který je načten BIOSem při startu počítače a následně mu předá řízení – např. LILO nebo GRUB).

3735

Sítě / Re:smejdsky router od o2?

« kdy: 01. 10. 2017, 10:27:15 »

Nebylo by daleko jednodušší za 300 Kč si koupit nějaký normální low-end switch? To, že ten router používáte jen jako switch, ještě neznamená, že se jako switch chová. Navíc pokud těch 40 – 60 Mbit/s měříte na aplikační úrovni, na linkové vrstvě to bude podstatně víc, zrovna Torrent má velkou režii. A jak píšou ostatní, pro switche je důležitý hlavně počet paketů, spoustou malých paketů můžete kapacitu vyčerpat dřív, než se dostanete k limitu šířky pásma.