Portál AbcLinuxu, 19. dubna 2024 03:26
Diskuse byla administrátory uzamčena.
Instalátor dokáže nainstalovat systém i do šifrovaného BTRFS oddílu, ale je to komplikovanější. Je třeba vytvořit nešifrovaný malý oddíl /boot formátovaný jako EXT4 stejně jako v prvním případě, ale potom vytvořit to, co v instalátoru se jmenuje jako „fyzický svazek pro šifrování“ což je oddíl šifrovaný pomocí LUKS. Co instalátor v tuto chvíli po zadání šifrovacího hesla udělá je ale, že vnitřek tohoto šifrovaného oddílu rovnou naformátuje jako ext4, aniž by se zeptal. Lze ale v druhém kroku tento odemčený oddíl (pokud je ten šifrovaný sda2, tak instalátor ten odemčený připojí jako sda2_crypt) přeformátovat na jiný souborový systém, tj. i BTRFS, říct, že na něm má být přípojný bod / a instalátor si s tím poradí a nainstaluje se i na šifrovaný BTRFS.Cool. Tohle mě ve starších verzích trochu štvalo. Ne že by to asi nešlo, ale je to neintuitivní a pokud člověk neví, že to tak má udělat, tak na to jen tak nepřijde.
No ono to porad JE velmi neintuitivni, respektive kdyz jsi poweruser co vi presne co chce docilit a pochopi pojmy instalatoru a nespokoji se s ext4 a rozhodne se odemcene LUKS zarizeni rucne zvolit a znovu preformatovat, tak to nejak instalator zkousne. Ale to ze je treba mit ten /boot oddil bokem atd. se ten instalator samozrejme nezepta...
Dovedu si predstavit i jinou moznost jak provest tou instalaci a vyberem oddilu. Momentalne takove to "preinstalovat cely disk Ubuntu/Mintem" a nebo "Rucni vyber" jsou dva extremy. Ta jednodussi volba "nainstalovat" by jeste mohla obsahovat nejake "pokrocile nastaveni" ale ne zas az tak moc pokrocile, typu vyber "chci lety provereny system ext4 (a strucne info o vyhodach takoveho reseni i limitech), nebo "chci pokrocily btrfs" (a zase nejake vyhody treba ty rychle snapshoty, a nevyhody treba nejaka vyssi rizika ztraty dat,experimentalni filesystem a janevimco),a vedle toho zaskrtavatko "chci cely disk sifrovat" ano/ne. JIne filesystemy nez ext4 a btrfs jsou IMHO vhodne jen do te expertni instalace, sifrovani bych mozna v roce 2018 dokonce nabizel jako default a spis volit "opt out".
No ono to porad JE velmi neintuitivni, respektive kdyz jsi poweruser co vi presne co chce docilit a pochopi pojmy instalatoru a nespokoji se s ext4 a rozhodne se odemcene LUKS zarizeni rucne zvolit a znovu preformatovat, tak to nejak instalator zkousne. Ale to ze je treba mit ten /boot oddil bokem atd. se ten instalator samozrejme nezepta...Jo, já vím, kdysi jsem tu o tom psal blog, když to ještě neuměl vůbec: Mint 12 na šifrovaném disku (návod) + pár dojmů
Dovedu si predstavit i jinou moznost jak provest tou instalaci a vyberem oddilu.Já mám zrovna na disku právě ext4 a uvažuji, že si koupím větší SSD (to chci už delší dobu) a při té příležitosti bych tam právě hodil btrfs na LUKSu. V tomhle mě tedy ten tvůj blog docela navnadil.
Uf, tak to teda byly dřevní doby to takhle šíleně hackovat. Já začínal na Mint 13, nicméně namísto nějakého LUKSu jsem tam už tehdy používal HW šifrování umožněné rozumným BIOSem a self-encrypting SSD, takže nevím už ani jestli u 13ky (12.04) už bylo šifrování podporované instalátorem nativně. U 17 (14.04) už určitě ano.
Celkem mě překvapilo, že systém je celkem reagující i na těch nejpomalejších počítačích, na které jsem ho zkusil nainstalovat.Zkoušel jsi, jak se chová při kopírování větších dat na flashdisk? Zatím jsem ještě neviděl distribuci, která by se celá nesekala v defaultu.
Nezkousel, nenapadlo me to vubec jako nejaky test co bych mel delat. Jako je jasny ze zapis na ntfs nebo exfat je v linuxu relativne vic CPU-intensive nez nativni zapis do ext4 coz u pomalych procesoru bude citit, ale priznam se ze me to nikdy nepaadlo tohle konkretne nejak resit. Pokud budu chtit neco delat na tom Athlonu XP (a zkousel jsem na tom par hodin brouzdat po netu atd) tak mi musi byt jasne ze kdyz mam pusteny browser tak si muzu dovolit otevrit tak tri az pet zalozek maximalne a s nejakymi zurivymi alt-taby a prepinani do x dalsich aplikaci a delani nejakych I/O intenzivnich veci je potreba hodne omezovat. Kdyz ono dneska jedno okno Facebooku, druhe Gmailu, treti Google Drivu uz dost zatopi jak te RAMce tak CPU, LibreOffice6 taky neni tak usporne jako MS Office 2000 na Windows 98 ci XP a o prasackych "aplikacich" kdy jde o zaobaleny prohlizec se zavislostma v samostatnym okne (Slack apod.) co samy spolknou skoro 1 GB RAM nemluve :)
Ostatne velkou obezretnost co a kolik toho pustim soucasne jsem zvyklej delat i na tabletu (Dell Venue 11) s nejakym Atomem, 2 GB RAM, 64GB SSD a Win10Pro, tam zejmena ta RAMka je taky obrovsky limit a je treba zasadne hlidat aby to nezacalo moc swapovat, pak se na tom uz neda vubec pracovat.
Takže jednak některé prohlížeče se už ani nedělají pro 32bitové systémy, a pokud dělají, tak se nepíšou tak, aby se obešly bez procesorových instrukcí SSE2.Jak se tohle stane? Jako že je buildsystém Firefoxu tak zprasený, že když zjistí, že ho kompiluješ na x86_32, tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (
-march=686)? Bohužel to nemám kde vyzkoušet, ale disassembloval jsem binárku Firefoxu pro i386 Debian a není v ní žádná instrukce pracující s xmm registry. V libxul.so jsou, ale dost málo, takže bych řekl, že to budou speciální verze některých funkcí s runtime detekcí CPU featur.
Jak se tohle stane? Jako že je buildsystém Firefoxu tak zprasený, že když zjistí, že ho kompiluješ na x86_32, tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (-march=686)?Vyhozeni procesoru bez SSE2 se resilo uz pred osmi lety. Kdy se to vyhodilo realne nevim. Osobne bych tipl, ze to maji kvuli implementaci JavaScriptu, kdy se JIT dela mnohem lip, kdyz aritmetiku s plovouci radovou carku delas pres SSE2 (jako vsechno ostatni a vsude jinde) nez kdyz musis resit x87-based FPU s naprosto odlisnym pristupem...
Vyhozeni procesoru bez SSE2 se resilo uz pred osmi lety.To jsou oficiální buildy od Mozilly, ne distribuční.
Osobne bych tipl, ze to maji kvuli implementaci JavaScriptu, kdy se JIT dela mnohem lip, kdyz aritmetiku s plovouci radovou carku delas pres SSE2Samozřejmě, ale stejně tam musí být generický kód, když to jede i na ARMu i jinde.
Pokud Debian jeste dela buildy kde odstranuje pozadavek na SSE2 tak Ubuntu to uz rozhodne nedela, dokonce i samotne Ubiquity kde jsou takove ty lakadla co system bude umet je ve skutecnosti nejaky Webkit v tom okynku a ani to na tom Athlonu nefungovalo a bylo tam prazdny okno. Zajimavy je ze nepodpora SSE2 je fakt domenou predevsim webovych prohlizecu,jinak snad vsechny ostatni normalni balicky v distribuci porad funguji i bez toho.
Nova Fedora ale i v x86 buildu bude vse kompilovat s podporou SSE2 a IMHO se dalsi distra budou pridavat. Fedora je vic bleeding edge,ale Ubuntu muze byt klidne dalsi. Nicmene jelikoz 18.04 jeste vicemene funguje non-SSE a podpora byy mela byt 5 let tak to uz asi tyhle stroje nejak dozijou, byt teda otazka je jestli se postupne nebude zvysovat mnozstvi balicku co po nejake aktualizaci prestanou nahle fungovat tak jako se to uz stalo u tech prohlizecu :)
"it seems like Firefox staring with version 49.0 (released yesterday), drops supports for non SSE2 CPUs as well, like Chrome did in 2014 since 2014 (Chrome 35 was the first version to drop non SSE2 CPUs support), Firefox 48.0.2 is now the last version to work in non SSE2 CPUs" (9/2016 - https://www.vogons.org/viewtopic.php?t=50032)
tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (-march=686)?Taková kombinace voleb není validní:
# gcc -march=i686 -msse2 z59.c cc1: error: CPU you selected does not support x86-64 instruction setAle nevím co by udělal inline assembler přímo ve zdrojáku. Jestli tedy konfigurační systém buildu nepřeparsuje uživatelské volby (byla by to prasárna, ale třeba buildroot to dělá), tak by to mělo jít zkompilovat s -march=i686 a -mno-sse2 a fungovat.
když nefunguje swap kvůli přesouvání bloků sem a tamJá bych řekl, že problém bude spíš v tom, že při zápisu hrozí, že bude potřeba alokovat paměť - která při swapování došla.
funguje na btrfs vůbec mmap() na souborProč by nemělo? Kernelu je při obsluze pagefaultu jedno, odkud tu stránku vyčaruje.
Já bych řekl, že problém bude spíš v tom, že při zápisu hrozí, že bude potřeba alokovat paměť - která při swapování došla.Ale to bude potřeba i při swapu na loopbacku.
Kernelu je při obsluze pagefaultu jedno, odkud tu stránku vyčaruje.Aha myslel jsem si že swap bude na nižší úrovni než mmap.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
