> proc potrebujes rozkopat tlamu nekomu za to, ze neco vylepsil
Tuhle konkrétní změnu jsem ještě nezkoumal, ale předchozí „vylepšení“ v tomto smyslu mi rozhodně jako vylepšení nepřišla. Příklady:
- Na některých grafických kartách černo, protože to blbě detekovalo rozlišení
- Plymouth nějak podivně deadlockne čekání na odemčení šifrovaného disku
Výsledek tedy je že jako admin řeším problémy věcí u kterých nevidím žádný přínos.
Ale tak jasne. priklady se daji najit na vsechno. Jenze timhle stylem je nejlepsi zustat u cernobilych monitoru.
Ty vlastne resis nejakou rovnovahu mezi vyvojem/pokrokem, a stabilitou. Bez vyvoje to nebude nikdo chtit, nestabilni taky ne. No a hladky start, bez jakychkoliv POST zprav apod. zvysuje atraktivnost pro BFU.
Takze, jestli to autor vylepseni udelal dobre, pak hura. Jestli to udelal spatne, a protlacilo se to do Fedory a Ubuntu, pak bych chapal rozhorceni autora prvniho prispevku. Jenze ten autor prispevku to jeste ani nezkusil, a to je to co tu resime. Nadava, aniz by zkusil a vedel.
1) nema nic spolocne s flicker-free bootom. Pointa flicker free je, ze boot loader ani jadro pri inicializacii kms modulu **nemeni** aktualny graficky mod. Az login manager zmeni, ak je treba, pretoze v idealnom pripade uz firmware nastavil nativny mod panelu.
2) predstavujem klaves "ESC". Jeho stlacenim je mozne zrusit plymouth a zobrazit kernelove hlasky. Pokial je to uz neskoro, lebo zatuhnutie uz zacalo, odstrante `quiet` z command line kernelu pri dalsom boote.
3) kedze vyriesenie tohto bugu trvalo 6 rokov, tak zjavne to mnoho ludi nepostretlo. Odomykanie sifrovaneho disku pri boote **vzdialene** (dolezity bod ktory vam vypadol) asi vela ludi nepraktikuje, a ked ano, tak trocha inak.
ad 2) krome odebrani "quiet", odebrat i "splash", tim se primo vypne Plymouth a veskere jeho pripadne (v dane situace) problemy jsou pak irelevantni (btw: tohle ale Jan Hrach samozrejme vi, casto dava lidem co nevedi proc jim nestartuje GNU/Linux odkaz na svoji wiki kde tyhle a dalsi boot parametry ma ;-)
ad 3) kdyz sem pred casem pouzival vzdalene(SSH) odemceni sifroaneho rootfs(LUKS), tak sem problem nemel, resp. pripojil sem se pres ssh, odemknul sem LUKS a zabil sem proces co cekal na zadani LUKS hesla na obrazovce, ten bug asi je o tom ze se ten proces neukonci sam pri dostupnosti odemceneho target...
nicmene je vhodne podotknout ze tohle vzdalene odemknuti funguje pouze pokud NEni sifrovanej /boot, tedy kdokoliv s fyzickym pristupem s minumum znalostma muze podvrhnout svuj initramdisk kterej pri pristim lokalni/vzdalenem odemknuti vlastnikem odesle utocnikovi LUKS heslo mailem/ftp/ssh/www/jakkoliv...)
Nemůžeme, abys byl správný tvrďák, musí ti to při bootu aspoň třikrát probliknout, ideálně pokaždé s jiným rozlišením a jiným fontem výpisu startu systému. Když to ještě okořeníš nějakým obskurním WM a barevnou paletou, po které ti za půl hodiny shoří oči, můžeš poučovat ostatní, jak má vypadat moderní linux.
bez přezdívky 48 17.7.2019 5:07
bezte do haje! rozkopal bych vam tlamy...
jestli nerestartujes rok desktop, ocividne mas problem i pres vyuziti (nejake implementace)livepatching desktop preci jen obcas v ramci bezpecnosti restartovat potreba je... pokud nejde o desktop a/nebo jde o zarizeni nepripojene do internetu a/nebo jinak omezenej pristup tak si zkus rozkopat tlamu sam, jednak mozna prijdes na to ze to ze to neni tva potreba neznamene ze to nikdo neuvita, druhak ti mozna dojde ze chtit rozkopat tlapu opensource vyvojaru software kterej pro tebe tvori zadarmo je jednoduse ubohe... aneb sve mindraky si zkus lecit jinak.