Názory k článku Neměnný operační systém: odolný útokům nebo uživatelům?

Díky za článek.

Nebylo zmíněno, že jsou zde příbuzné snahy o bezpečnost a stabilitu, v podobě LTS distribucí, které by měly podporu v řádech desítek let. Povětšinou tyto snahy míří do míst, kde takový OS obsluhuje průmyslové celky, nezřídka v ostrovním režimu.

A rozmohl se nám tady na Rootu takový nešvar. Pokusy mystifikovat lidi pojmem "předvídatelný"
Cite z článku: "...protože při běhu nedochází k nějakým změnám v jádře nebo ovladačích a vše je předvídatelné."

Tak se nenechte zmást. A až se někomu podaří mít skutečně předvídatelný OS, tak ho beru plnou nádrž, a dvakrát.

Tak ono "predvidatelny" muze mit vic kontextovych vyznamu a i vy ho vyuzivate pravdepodobne ve vyznamu, proti kteremu by nekdo jiny protestoval. Pravdepodobne ve smyslu schedulingu uloh?
V clanku je mysleno "predvidatelne verze SW" nebo neco jineho (nevim co). Je to line psani? Asi no. Mohlo to byt vysvetleno. Odhalil/a jste zasadni iluminatskou konspiraci na rootu? Myslim, ze ne.

Se slovem "předvídatelný" jsem narážel na to, že jsme tu o něm diskutovali včera u zprávičky o začlenění podpory pro RTOS, která měla z Linuxu také dělat "předvídatelný OS".

Možná mám skutečně ujetý význam slova "předvídatelné", ale vyjádření typu: "a vše je předvídatelné", bych rozhodně nepoužil. Vám to nepřijde matoucí, téměř v jakémkoliv kontextu?

Na druhou stranu, není to žádné drama, zvládnu s tím žít.

Mozno "predvidatelny" nie je celkom dobry preklad pre "deterministicky".

Pěkný článek, krátké doplnění.

Immutable systémy přesouvají veškeré konfigurační a administrační věci do fáze, kdy se systémový obraz vytváří. Je to daleko méně pohodlné, každý software nebo změnu je nutné relativně dlouze testovat v cyklu: vytvořit nový obraz, nainstalovat nebo spustit a otestovat. Proč by tedy někdo podstupoval takové peklo když je v tomto lepší tradiční systém?

Hlavním typem zákazníka pro tento postup je organizace s flotilou stejných strojů. Typicky jsou to servery na pobočkách, nebo pokladny v jednotlivých prodejnách. Prostě místa kde nemáte IT technika, protože jich je moc a bylo by to drahé. Pak tato vyšší vstupní investice do vytvoření a otestování takového systému smysl má, navíc aktualizace jsou pak robustnější a některé technologie umí A/B partitioning s možností rollbacku, například ostree.

Ve článku není zmíněn asi nejnadějnější projekt Fedory s názvem bootc (bootable containers), který řeší zmíněný problém s dlouhým cyklem testování před nasazením. Místo speciálního způsobu instalace immutable systému, který má každá technologie jiný, se používají kontejnery.

Jinými slovy, vytvoříte Dockerfile z bootable kontejneru, odladíte si aplikace a nastavení pomocí dockeru nebo podmanu a jakmile jste spokojeni, vytvoříte si immutable image pro cloud, VMWare nebo holé železo. Celý cyklus se tak výrazně zkrátí protože spustit kontejner trvá méně než vteřinu. Pohodlně se do systému kopírují vlastní binárky a hlavně můžete využít veškeré nástroje, které byly vytvořené pro kontejnery (např. CI/CD). Software, který se používá k vytváření obrazů z bootovatelných kontejnerů, se jmenuje osbuild (image builder).

Kolega má na to téma přednášku na letošním LinuxDays 2024 tak hlasujte a poznačte si to do kalendáře, jestli máte o to téma zájem. Já na tom projektu dělám a myslím si, že je to jedna z nejzajímavějších věcí od Fedory / Red Hatu. Kdyby snad měl někdo zájem o článek na toto téma, ozvěte se a s redakcí něco domluvím :-D

Immutable systémy přesouvají veškeré konfigurační a administrační věci do fáze, kdy se systémový obraz vytváří. Je to daleko méně pohodlné, každý software nebo změnu je nutné relativně dlouze testovat v cyklu: vytvořit nový obraz, nainstalovat nebo spustit a otestovat. Proč by tedy někdo podstupoval takové peklo když je v tomto lepší tradiční systém?

To není vlastnost immutable systémů obecně ale pouze konkrétních implementací. Např. NixOS nebo GNU Guix žádným takovým problémem netrpí: požadovaný stav deklarujete v konfiguraci, systém provede vyhodnocení změny a běžící systém na tu novou verzi přejde okamžitě.

23. 9. 2024, 11:13 editováno autorem komentáře

Jenze tu vec v ty kase chces kazdy 3 dny aktualizovat, protoze si nejakej chuj usmyslel ze mas tisknout nejaky eet. Ta kasa pak musi byt nekam napojena, pouzivat nejaly to tls ... a to znamena kazdou chvili aktualizovat nejakou tu deravou knihovnu.

Testovat to nikdo nebude, protoze na to nema ani cas, natoz penize. Nez by dotestoval, najde se dalsi dira.

U ty kasy beztak chcete, aby nekam komunikovala. Doba izolovanych mechanickych pocitacich stroju, kde vrcholem zaznamu byla rolicka papiru je davna minulost. Takze tem aktualizacim se nevyhnete, at se vam to libi nebo ne.

Přesně, jeden z největších hobbymarketů v ČR nedávno nasadil kasy co jsou pouze on-line kiosky. V podstatě je to prohlížeč, vše běží v cloudu. To už je extrém, ale je to realita.

Asi nemá cenu moc reagovat na ten komentář, je plný nesmyslů. Naši zákazníci jsou hodně z této oblasti a aktualizují řekl bych v normálním režimu a samozřejmě že se aplikace testuje, dokonce i na samotných zařízeních ostree má na to funkci. Zrovna taková kasa běží izolovaně bez přístupu na internet (a to i on-line kasa, tam je pouze VPN do datacentra), tam není potřeba dělat aktualizace na denní bázi.

V článku se neustále zmiňuje bezpečnost, ale přijde mi že se tím myslí hlavně stabilita a nerozbitnost - slovo útok je poprvé a naposledy v titulku.
Jak se koncepčně řeší u těch flatpacků a pod když nějaká low-level knihovna najde závažnou zranitelnost? Postaru updatuju tu jednu knihovnu, ponovu čekám až si toho všimnou všechny aplikace a průběžně updatuju všechny, jednu po druhé? Trochu mi přijde že se tím vrací do doby statických knihoven před ELFem.

Nebo se spoléhá na Pokud by jakýkoliv škodlivý program, proces či útočník chtěl na vašem systému provést změny, které by váš počítač přinutily chovat se nestandardně, tak by se mu to buď nepovedlo nebo jen do chvíle, než počítač restartujete.?

Jinak pamatuju v první polovině nultých let pravý immutable systém u jedné pseudostátní organizace - boot z CD, první krok smazání většiny disku. Aktualizace znamenala vypálení nových CD. Instrukce pro nonstop dohled - když to nefunguje rebootujte.

20. 9. 2024, 08:39 editováno autorem komentáře

Flatpaky maji runtime. Takže není potřeba aktualizovat každou aplikaci zvlášť, je tam dost sdíleného obsahu.

Tiez ma to irituje, ako sa jednym slovkom "bezpecnost" autor dookola snazi vyvazit vsetky nevyhody okolo :) a pritom jeden odstavec, co je tou bezpecnostou naozaj myslene by clanku dost pomohol.

Nevyhody:

1. treba sa ucit nove postupy,
2. treba cakat na aktualizaciu upstreamu + kym to niekto zabali do prave modneho kontajnera + extra cas navyse na stiahnutie + extra cas na reboot + opakuj pre vsetko co nie je zdielane.

1. uzivatel/utocnik nevie omylom zmazat OS (resp. jednoduche rm -rf nestaci),
2. aplikacia v kontajneri sa nevie "zazrat" do systemu tak, ze je tazke ju odstranit.

20. 9. 2024, 10:46 editováno autorem komentáře

Zkousel jsem immutable Fedoru a usoudil jsem, ze pro me to neni - k mym zazitym postupum uzivani prehistorickych nastroju typu mc, vim je to prilis odolne, jak je trefne uvedeno v nadpisu clanku :)

Ale! Kdyz se nad tim zamyslim, tak pro zakladni pouziti treba u rodicu odpada vetsina nevyhod a jednoduchost zachranit system je pro me jako potencialniho spravcu rodicovskeho/det­skeho systemu docela fajn.

20. 9. 2024, 15:11 editováno autorem komentáře

ak se koncepčně řeší u těch flatpacků a pod když nějaká low-level knihovna najde závažnou zranitelnost?

Ty low-level knihovny, obzvláště ty bezpečnostní, jsou zpravidla součástí runtimu, protože to je něco, co si jako autor aplikace nechcete spravovat.

Na Flathubu je základem všech runtimů FreeDesktop Runtime, který obsahuje opravdu ty nejzákladnější věci, na něm staví GNOME a KDE runtimy. Když tedy objeví chyba třeba v OpenSSL, opraví se ve FreeDesktop Runtimu a díky tomu také ve všech ostatních runtimech, které na něm staví, a všech aplikacích, které je používají.

Nicméně pokud je chyba v tom, co obsahuje samotná aplikace, musíte se spoléhat na jejího autora, že to opraví. Flathub nezakazuje bundlování. Autor aplikace si může klidně přibundlovat vlastní OpenSSL a pak je to na něm, aby si to opravil. Ultimátně je to tedy o důvěře v autora aplikace. Ale to platí u distribučních repozitářů. Bundlování je sice zpravidla zakázané, ale běžně se děje a opět je to o důvěře ve správce balíčku, že to má pod kontrolou.

Jediná distribuce, u které jsem viděl, že se šlo opravdu balíček po balíčku, odstraňovalo se vlastní krypto a vynucovalo se používání vybraných systémových knihoven, byl RHEL.

To je easy, viz nedavno tady kolem tokeny Yubi, proste to vemes, rozslapnes a vymenis.

A pokud bys nekdy videl aspon z rychliku libovolnej korporat, tak odpoved je velice snadna. Neaktualizuje se nic. A to ani v tom pripade, ze bys hypoteticky moh. Proc? Protoze dodavatel ti garantuje ze X bude funkcni prave s verzi a revizi Y. S zadnou jinou. Jakakoli aktualizace = kdyz se to podela, at uz to s tim neco spolecnyho ma nebo ne, je to na tobe.

Jak se to teda resi? Mno vkladaji se mezi to vsemozny proxy, ktery to dost casto vsemozne rozbijej samy o sobe, ale je tu proste nejaka snaha ten primarni system pokud mozno maximalne odstinit od cehokoli.

Diky za clanok, nedavno som hladal informacie o "immutable" a tu je to pekne zhrnute.

"Ve zkratce jde o to, že Flatpak může nabízet sdílení knihoven v rámci lokálního flatpakového repozitáře. Nemusíte je pak přibalovat k programu. Jde o klasický koncept distribuovaných aplikací, jen se to děje v rámci vašeho lokálního repozitáře. "

Clovek by povedal, ze skoro ako doterajsie existujuce nie-flatpak riesenie, co?

Uz sa tesim na moment, ked niekto pride s tym, ze toto zdielanie je problematicke ("aktualizacia zdielanej kniznice vo flatpaku nieco rozbila") a zacne budovat flatpak vo flatpaku, aby si clovek instaloval vsetky zavislosti lokalne... v uz lokalnom adresari. :-)

No, určité podstatné rozdíly tam jsou:
- Flatpak umožňuje pouze jednu závislost: na konkrétním runtimu. Nevytváří se tam komplikované vazby závislostí jako u balíčkovacích systémů, kdy jeden balíček může záviset na libovolné množině jiných balíčků.
- Je to celé nezávislé na samotném systému. Je fajn, že tradiční neflatpak řešení to mají taky pošéfované, ale balíček z Debianu vám nebude kvůli neuspokojeným závislostem fungovat na Fedoře a naopak.

Ne, že by v tom byl Flatpak nějak unikátní. Je to v podstatně kontejnerová technologie určená pro desktopové aplikace. Runtimy jsou obdobou základních obrazů u klasických kontejnerů.

Mne zaklad te myslenky neprijde spatny.

V podstate v soucasne dobe operacni system obstarava dve z velke casti disjunktni veci: 1) nastartovani zakladniho systemu, jadra a ovladacu zarizeni, 2) beh uzivatelskych aplikaci.

Soucasne standardni distribuce jsou vsechny delane tak, ze uzivatelske aplikace musi sdilet verze knihoven se zakladem systemu. Ale jelikoz ty aplikace komunikuji se systemem skrz jadro, tak neni moc duvodu, proc je s temi verzemi svazovat.

Ja si klidne umim predstavit, ze si nainstaluju Ubuntu 20.04, a ono nekde krom /{bin,lib} apod., bude mit jeste podslozky /ubuntu22.04/{bin,lib} a podobne (ale taky treba /ubuntu18.04/{bin,lib­}). V podstate takove runtimy. A pak si aplikace muzou svobodne vybrat zakladni runtime, vuci kteremu se kompiluji. Tj. bude existovat minimalne jedna verze OS, kde ta aplikace pujde zbuildit na "zakladnim" systemu. To je dobre pro udrzovatelnost. A na systemech jinych verzi se proste jenom zpristupni ten spravny runtime a aplikace na nich pobezi bez problemu. Nevim, proc by fakt, ze systemovy runtime potrebuje glibc 1.30, musel znamenat, ze aplikace nemuzou pouzivat glibc 1.40.

Technicky je to samozrejme malicko slozitejsi, ale kdyby si treba zakladni system (rekneme Ubuntu 20.04) pri buildeni balicku udelal symlink /ubuntu20.04->/, tak by to mohlo tu technickou cast vyznamne zjednodusit.

A spravce "zakladnich" distribuci by to nijak nad ramec nezatezovalo, proste by si dal piplali svoje Ubuntu 20.04 a vubec by je nezajimaly aplikace, ktere potrebuji novejsi knihovny (ty by proste presly na novejsi runtime). Jediny problem pak samozrejme muze byt, kdyz se vyvojarum mezi runtimy nepodari najit zadny, ktery by nabizel knihovny ve spravne kombinaci verzi, kterou potrebuji. Ale to bude dost malo pripadu.

Ano, bylo by to trochu plytvani mistem na disku, protoze najednou by tam clovek misto jednoho Ubuntu mel 3, ale zase ty nesystemove runtimy s sebou nemusi nest kernel, firmwary a podobne, takze by to snad nemuselo byt az tak zle (ostatne, flatpak runtimy jsou podle me neco dost podobneho).

> Clovek by povedal, ze skoro ako doterajsie existujuce nie-flatpak riesenie, co?

To je skoro ako otazka na radio jerevan: ano, presne, ale je to uplne inak :-)

V prvom rade runtime su verzionovane. Toto ma obrovsky dopad na vyvojarov aj pouzivatelov. Vyvojari mozu cielit na stabilny set API (presne z tohto dovodu su verzionovane SDK na konkurencnych systemoch) a pouzivatelia mozu sucasne pouzivat aplikacie vyuzivajuce rozlicne verzie runtime.

V pripade klasickych distribucii mali pouzivatelia k dispozicii jednu verziu runtime (danu verziu distribucie) a aplikacie sa museli prisposobit. To zase malo za nasledok, ze pouzivatelia mali k dispozicii zvycajne starsie verzie aplikacii, ktore fungovlali s danou verziou runtime, resp. distribuciou. Nehovoriac o tom, aku zataz zostavit distribuciu to predstavuje pre tvorcov -- je to ako nahananie hordy maciek, aby vsetky aplikacie fungovali s vybranymi verziami kniznic (presne spominany problem: v novej verzii distribucie sme updatli kniznicu libX na aktualny release a polka veci nefunguje).

Tak si to predstavte ako ze mozete mat nainstalovane debian 10, 11, 12 a redhat 7, 8, 9 sucasne a kazda aplikacia si moze vybrat , co bude pouzivat, sucasne vsetky naraz, bez rebootov a zmeny desktopovych prostredi.

Tahle odpověď mi přijde trochu devalvuje to se security patchováním pomocí updatu runtime (musím updatovat všechny runtime? Co když je nějaký už opuštěný?)

Jinak sdílené knihovny jsou taky verzované, aspoň takový byl design - IIRC stejné první číslo za .so je stabilní/zpětně kompatibilní API, a může být v systémy víc verzí. Teda ne že by se to až tak chytlo, ale občas je víc verzí i v jedné distribuci.

Otázka jak moc má aplikace sledovat updaty a vývoj závislostí a knihoven (runtimu, chcete-li) má asi v různých situacích různé nejlepší odpovědi, a tomu bude odpovídat jaké je vhodné technické řešení.

Pořád se musí autor starat o jednu závislost pro jednu runtime, prostě zvedne snadno verzi. Flatpak samotný upozorňuje když něco používá deprecated runtime. A hlavně je díky tomu mnohem snazší cílit na nové verze závislostí a runtimes, takže ta deprecation přijde pomaleji. Pokud chci vyvíjet pro Debian bez flatpaku, musím držet závislosti dost konzervativně, případně staticky linkovat.

Clovek by povedal, ze skoro ako doterajsie existujuce nie-flatpak riesenie, co?

Ano, ale tohle je další z mnoha nekonečných diskusí v IT. :-)

Uz sa tesim na moment, ked niekto pride s tym, ze toto zdielanie je problematicke ("aktualizacia zdielanej kniznice vo flatpaku nieco rozbila") a zacne budovat flatpak vo flatpaku, aby si clovek instaloval vsetky zavislosti lokalne... v uz lokalnom adresari. :-)

Tohle je také komické. Vždy tady byly k disposici staticky kompilované jazyky, takže pokud má někdo problém s nevyhovujícími verzemi knihoven (proč vlastně? - velmi vážně míněná otázka) v OS, tak si klidně mohl ten svůj program zkompilovat staticky a měl by po problému.

Ne, místo již existujících řešení se zavede jiné, které je určené pouze k zakrytí nepořádku v těch programech a jejich vývoje a místo toho, abychom se zaměřili na způsob vývoje v linuxu tak se to jen hodí do kontejneru a zavře se víko, aby na ten ... ehm nepořádek, nebylo příliš vidět.

Vedle toho na FreeBSD od roku 2015 jsem nezažil jediný problém při kompilaci portů. Vše je z distribuce, každý port si určuje co všechno potřebuje k běhu a vedle toho i ke kompilaci, nikdy žádný problém. Za těch skoro 10 let se nikdy nestala hádka o knihovny, kdy jeden program vyžadoval verzi 1 a druhý 5. Toto je velmi častý argument proponentů flatpaků apod, ale tak chtěl bych to vidět v praxi a taky bych chtěl vidět důvod, proč to tak je.

Jestli to nebude tím, že BSD bylo vždycky spíš katedrála a Linux spíš tržiště. A hlavně na Linux cílí násobně více softwaru než na BSD, takže udržet nějakou štábní kulturu je prakticky nemožné.

abychom se zaměřili na způsob vývoje v linuxu

Co přesně to je způsob vývoje v Linuxu? Způsob vývoje toho, co se zpravidla považuje za samotný OS? To by asi nějak ovlivnit šlo, ale ovlivnit způsob vývoje softwaru, který cílí na Linux? Good luck. Tu autoritu nikdo nemá. Dřív ji z části měly distribuce, ale už ji dávno ztratily. Dnes je většině autorů softwaru ukradené, jestli je jejich software v repozitářích linuxových distribucí. Dnes člověk přijde na jejich stránky a u instalace pro Linux najde:
curl -fsSL instalacni-skript.sh | sh a podobné věci.

Buď před tímto zavřeme oči a budeme si na svém písečku vytvářet ideální svět, zatímco ten reálný je někde úplně jinde, nebo tu realitu akceptujeme a přijdeme s řešeními, která její negativa aspoň zmírňují.

Jestli to nebude tím, že BSD bylo vždycky spíš katedrála a Linux spíš tržiště. A hlavně na Linux cílí násobně více softwaru než na BSD, takže udržet nějakou štábní kulturu je prakticky nemožné.

Chápu narážku, ale katedrála je jen base (+kernel). Ten není v portech, ten se kompiluje zcela zvlášť a zcela nezávisle na portech.

Na freebsd serverech mám tentýž software jako na linuxových serverech. Tady porovnávám stejné věci.

Dnes je většině autorů softwaru ukradené, jestli je jejich software v repozitářích linuxových distribucí.

V tom případě mě je zcela ukradený ten software. Já mám prostě mnohem větší nároky na software a pokud autor není schopný software napsat tak, aby šel snadno nainstalovat, tak já jako admin (i jako uživatel) o tento soft vůbec nestojím.

Buď před tímto zavřeme oči a budeme si na svém písečku vytvářet ideální svět, zatímco ten reálný je někde úplně jinde

A kde je ten reálný svět a na čem běží?

Když to zjednoduším, proč bychom měli měnit linux jen proto, že někteří autoři dělají problémy a současně chtějí, aby jejich soft běžel na linuxu? A proč před nimi ustupovat? A když se ustoupí, bude opravdu ten výsledek lepší? Opravdu bude lepší "svět", kde se umožní instalovat každá kravina s libovolnou verzí knihoven, libovolně složitě a jen se to zavře do kontejneru? Opravdu to bude lepší pro ty programy samotné, které jsou napsané tak blbě, že jednak není možné vytvořit klasický balíček a ještě navíc vyžadují speciální verze?

Když to zjednoduším, proč bychom měli měnit linux jen proto, že někteří autoři dělají problémy a současně chtějí, aby jejich soft běžel na linuxu? A proč před nimi ustupovat? A když se ustoupí, bude opravdu ten výsledek lepší? Opravdu bude lepší "svět", kde se umožní instalovat každá kravina s libovolnou verzí knihoven, libovolně složitě a jen se to zavře do kontejneru? Opravdu to bude lepší pro ty programy samotné, které jsou napsané tak blbě, že jednak není možné vytvořit klasický balíček a ještě navíc vyžadují speciální verze?

Ústup by to byl, kdyby bylo z čeho. Distribuční repozitáře ve svých nárocích příliš neustupují, ale výsledkem je, že jsou méně a měně relevantní. Před 20 lety byl pro open-source projekt problém, když nebyl v repozitářích, dnes už to je skoro jedno. Je to dané i tím, že vymáhání těch požadavků stojí usilí a to prostě neškáluje. Škálovalo to, když existovaly tisíce projektů, které cílily na Linux, dnes jsou jich stovky tisíc. Nebýt v distribucích je dnes normál a byl by, i kdyby o to měli tvůrci pořád zájem, protože distribuční repozitáře a jejich pravidla prostě do takových čísel neškálují.

Ve výsledku rozhoduje uživatel. A většina z nich bude vždy preferovat prasácky napsaný software, který ale má ty funkce, které potřebuje, před softwarem, který je správně napsaný, ale neumí to, co potřebuje. Člověk by si mohl říct, proč nemít oboje, jenže to druhé taky vyžaduje úsilí a prostředky, kterých je omezené množství, a pokud zákazník preferuje první, budou autoři softwaru také tíhnout k prvnímu. Bez ohledu na to, co si o tom myslí platforma, pro kterou se ten software píše.

Myslíte, že se dnes distribucí někdo ptá? To by musely distribuce nějaký typ instalací úplně zakázat, jenže pak budou volit uživatelé nohama a půjdou tam, kde jim to půjde. A ani nemusí opustit Linux. Mezi distribucemi je taková konkurence, že distribuce víc potřebují ten software než naopak.

Stačí se podívat na software kolem AI. To jsou naprosto nerozpletitelné molochy závisející a bundlující konkrétní verze knihoven v kombinacích, kterým distribuce nemůže nikdy vyhovět. Neběží to na tvém OS? Nevadí, budeme to provozovat na jiném.

Reálně tak dnes distribuce nemají na tvůrce softwaru skoro žádné páky, takže není z čeho ustupovat. Jak už jsem psal, na výběr mají mezi tím to ignorovat a budovat svůj malý dokonalý svět bez valných šancí jej prosadit v reálném světě, nebo akceptovat realitu a mít řešení, které ty trendy reálného světa aspoň nějak mírní.

Osobně za tím vidím lenost/neschopnost vývojářů. Jak na straně použité knihovny, tak aplikace.

Vidím v tom problém s držením kompatibility jednotlivých verzí - u aplikací striktní vyžadování nejnovější verze knihovny nebo naopak setrvávání na historické. U knihovny je to zase neschopnost/ne­ochota držet kompatibilní rozhraní té knihovny (neschopnost muže být i ve formě malého počtu zdrojů na držení více verzí).

Setkal jsem se s aplikací, která striktně vyžadovala nejnovější verzi interpretu. Při zkoumání proč a co reálně z té nejnovější verze potřebují, tak nic. Prostě proto. Že vyžadovaná verze interpretu nebyla součástí žádné distribuce, to vývojáře nezajímalo, dokonce s tím přišli u minoritního update (X.Y.Z -> X.Y+1.W), krása. Takže řešením byl kontejner přímo od vývojářů. Mimochodem, dost prasácky udělaný a i s tím bylo dost problémů.

Opačný problém, setrvávání na historické verzi knihovny, je asi častější. Nikdo nechce jít do portace na novější, vývojáře nezajímá, že nikdo jiný danou verzi už nepoužívá... Tak zase, šup s tím do kontejneru a sere pes.

Ale ani jedno není dobré. Řešení to ale nemá, pokud vývojáři nechtějí s tím něco udělat... Jen mi přijde, že cca 15 let zpět to byl celkem standard. Nehnal se vývoj tolik dopředu, dbalo se na zpětnou kompatibilitu a podobně.

Ad setrvávání na starých knihovnách : krásný příklad je GIMP. Před rokem a něco přišla verze, která z GTK2 (protože GTK už byla EOL) upgradovala na GTK3 a v podstatě s dnem vydání mohli začít pracovat na portaci GTK4.
Tohle je příklad aplikace, která je robustní a kde dělat upgrade zásadní knihovny "protože nikdo jiný tu starou už nepoužívá," je prostě veliký problém. Zvláště, pokud aplikace se starou verzí knihovny funguje a upgrade se dělá vlastně jen proto, protože EOL. Vím, vím, co mi chcete říct...

Jen, že to prostě není tak jednoduché a u projektů tohoto typu jako GIMP se vlastně může jednat o kontinuální portaci...

Hele, zrovna ten GIMP jsem měl na mysli už v okamžiku psaní toho příspěvku a podle mne je to někde na hranici té mé myšlené neschopnosti*) a výjimky potvrzující pravidlo.

U toho GIMP-u je to takový dvojitý problém, GTK původně byla zkratka Gimp Tool Kit - vznikl právě kvůli GIMP-u. Jenže někde ujel vlak a GTK jede prostě rychleji... Taky to může být prostě to, že si v GIMP-u ukousli větší sousto koláče, než dokážou sníst. Nový GIMP má přinést tolik novinek, že až oči přecházejí - a některé potřebují opravdu veliké přepsání vnitřní logiky. Nebylo by tedy lepší rozdělit práci na dva kroky? Portaci na aktuální/aktu­álnější GTK a pak přepsat jádro aplikace? Nevím, nedokážu posoudit... Možná ne... Jen nahlas přemýšlím...

Na druhou stranu, ono to možná ukazuje i na problém v té GTK knihovně - pokud portace aplikace na novou verzi vyžaduje tak hluboké zásahy, že to autoři nedokážou stíhat, je s tou knihovnou něco špatně, protože nedokážou dostatečně držet zpětnou kompatibilitu/model vývoje toto umožňující. Trošku tím zabřednu do GTK vs. QT války. Portace celého prostředí KDE na QT6 trvala kratší dobu. Proč? Je to lepším návrhem QT? Lepším návrhem KDE? Lepším zaměřením dostupných zdrojů? Nebo jen a pouze většími dostupnými zdroji? Nechci otevírat válku GTK/QT/Gnome/KDE. Opět jen nahlas přemýšlím.

*) nemyšleno jen jako „blbí vývojáři“! Ale právě kvůli té komplexnosti, nedostatku zdrojů a možná i zastarání kódu, takže ten přepis se prostě táhne, protože potřebují komplexní refaktoring, který trvá a trvá...

U knihovny je to zase neschopnost/ne­ochota držet kompatibilní rozhraní té knihovny (neschopnost muže být i ve formě malého počtu zdrojů na držení více verzí).

Jenže potom je otázka, proč ten vývojář používá takto problematickou knihovnu.

Na tohle v těchto svých komentářích narážím. Autor použije něco, co je špatně. Proto se to nedá zabalit, proto použije kontejner. A právě z tohoto důvodu tady (a už dávno na svém webu) kritizuju tu poslední technologii, v tomto případě kontejnerizaci, která pro všechny zúčastněné jen zakrývá ten pravý stav věcí. Kontejner se dá snadno vyrobit a nainstalovat, takže se nikdo nemorduje s balíčkem a tedy to nevidí. Autor je spokojen a to že má v programu zcela špatnou knihovnu ho vlastně vůbec netankuje. Takže je to další vrstva na zakrývání problémů.

Opačný problém, setrvávání na historické verzi knihovny, je asi častější.

Jenže tohle by ve skutečnosti nemělo vůbec vadit. Knihovna v5 by měla obsahovat všechno z v1. Pokud je některá věc deprecated, tak se to ohlašuje tak cca 10 let a ta funkce je tam další 5 let (ale třeba už ne v dokumentaci).

Já prostě nikde nevidím problém a ani v praxi nepozoruju.

Hele, v tomto s Tebou souhlasím. Jen v běžné praxi toto vidím jako problém - ten problém je přesně to, co popisuješ - neudržitelný vývoj.

> tak si klidně mohl ten svůj program zkompilovat staticky a měl by po problému

Není potřeba kompilovat staticky (což jednak znamená, že pokud tvůj software je z více binárek, tak je v každé ta knihovna znova, jednak s některými věcmi (glibc) je to opruz a nefunguje to), typický komerční software (různé CADy apod.) to dělá tak, že jsou to normálně dynamické binárky, ale nastavené tak, aby se knihovny prioritně hledaly v /opt/jméno_výrobce.

Ono bohate staci, kdyz autor aplikace deklaruje jake knihovny v jakych verzich aplikace ocekava, a normalni distro si je proste v tech verzich dotahne k prislusne aplikaci. Klidne muzes mit 10 verzi teze knihovny.

Jenze to by fikulini nesmeli vymejslet ze verze <X neni dost khull a oni ji z repa vyhodej.

Stejne tak by samozrejme bylo fajn, kdyby autori knihoven drzeli kompatabilitu = starsi aplikace by videla to na co je zvykla a nove veci by videla jen aplikace nova.

bez prezdivky ...
Jenze to by fikulini nesmeli vymejslet ze verze <X neni dost khull a oni ji z repa vyhodej.

a ty se frikuline budes o balicek s tou starou verzi starat? nebo zaplatis nekoho kdo bude? a pokud jde o tve ciste soukrome potreby, muzes si preci udelat vlastni soukromy ci primo lokalni repositar, kam si muzes kdyz uz ne zkompilovat/pri­pravit vlastni balicky, pouzit ty odstranene i kdyby jen s upraveou jejich depends, kdyz by to stacilo.... cokoliv z toho je lepsi nez blbe kecy ;-)

23. 9. 2024, 23:51 editováno autorem komentáře

Tak nekteri jsou gramotni, jini jako ty nikoli ...

Distro ten balicek ma, staci na nej nehhrabat ze? NIKDO se o NIC starat nemusi.

Kdyz si ten tenhle post napisu treba ve foxovi verze 0.7, je ti do toho taky uplny kulovy.

Takze te radim presne k tem frikulinum, kvuli kterym veci prestavaji fungovat, aniz by k tomu byl jakykoli relevantni duvod krome blabolu. A presne proto NIKDY nikdo tuxe pouzivat realne na desktopu nebude. Protoze na tedch widli aspon vi, ze kdyz mu to na nich fungovalo pri instalaci bude to na nich fungiovat i za 10, 15 nebo 20 let.

No já jenom abysme tu příliš nehýkali nad těma aplikačníma packama - zrovna teď po přechodu na nové LTS ubuntu mě trestál snap, ve spojení s apparmor. Plnil mi dmesg log hláškama o nemožnosti zapisování do nějakého adresáře firefoxu. Nainstaloval jsem apparmoří profiles, nepomohlo. Odinstaloval jsem snapí firefox a hle v systému zůstal normální firefox. V tom novym gnome je trochu těžký zjistit co ikonka na panelu zrovna spouští. Odinstaloval jsem normální firefox, hlášky apparmoru v dmesg jsou pořád, odinstaloval jsem snap a hádej co. Pořád je to rozjebaný. Ještě tam jsou další hlášky něco s acpi a pod... tenhle apparmor byl čert dlužen...Přeh­lídnout to nemůžu a už se s tim drbu tejden, páč to nejde dobře vypnout... :-(

Porad nikde neni receno, jak tedy probiha update toho immutable systemu. Doufam, ze nekolik let bez updatu nebezi. Tam, kde je a/b partitioning, je to jasne. A tam, kde neni? Prijde muminek s flaskou, nabootuje z ni a dd? To doufam, ze ne =)

Ale i u toho a/b, jak zajistim, ze mi do druhe partitiony nezapise nejaky hacker? Takze bych se po rebootu mohl tesit akorat na adresu btc penezenky?

A taky pochybuju, ze beh aplikaci z uni balicku zlepsuje bezpecnost. Jak uz psal kolega vyse, po hotfixu jednoho balicku musim cekat, nez si toho vsimnou vsechny aplikace. Ok, runtimy to trochu resi, ale treba takovy docker potrebuje, aby se prebuildily vsechny zavisle image. To taky muze trvat (nekdy to ani nedotrva).

Proste mi prijde, ze v takovem systemu misto abych dal duveru jedinemu tymu distro maintaineru, tak najednou musim davat duveru desitkam az stovkam tymu... To rozhodne k bezpecnosti neprispiva (tohle samozrejme plati jen kdyz na tom immutable systemu provozuju i jine aplikace, nez jsou v image).

A jasne, je hezke, ze mi zadny utocnik neprepise /usr/bin/ls, ale treba k .ssh/authorized_ke­ys ma porad bez problemu pristup. Takze argumentovat tim, ze derave aplikace na immutable systemu nevadi, je blbost.

A jako posledni vec - kdyz se tedy nektere updaty (treba v a/b) updatuji restartem, tak jak zaridim, ze restart vyresi vsechny problemy? Kdyz senpak vlastne startuje jinej, pozmenenej, system?

Jak Silverblue, tak Flatpak a vlastně i bootable kontejnery používají libostree. V dokumentaci je detailně popsáno, jak to celé funguje, včetně integrity, aktualizací, rebootů, možnosti vytvořit si test který aplikaci po upgradu ověří a pokud neprojde tak se automaticky udělá rollback. Na některé otázky to odpovídá.

Souhlasím s tím, že článek vyznívá trošku jako "immutable = bezpečnější" což samozřejmě není. Troufám si tvrdit, že je tomu naopak - immutable systémy jsou daleko náročnější na správu, aktualizace probíhají spíše méně často než u tradičních deploymentů

Díky za pěkný shrnující článek. Silverblue používám už sedm let a dnes na prakticky všech svých počítačích, udělalo to z Fedory bezúdržbový systém. Nejvíc se mi na tom líbí ta flexibilita přesouvání se mezi verzemi. Včera jsem na pracovním počítači přešel na Fedoru 41, která vyšla teprve v betě, a zcela bez stresu, protože když by něco nefungovalo, jedním rebootem bych byl zpátky ve Fedoře 40. Funguje to i v rámci jednoho vydání a je to super na bisektování regresí.

Dávám to i na počítače běžným uživatelům, protože ugprade systému s tím zvládnou sami a hlavně jsou schopní i beze mě se vrátit k předchozí verzi, když by se něco pokazilo.

Jinak v článku je drobná chyba: toolbox není nástroj na package layering, na to je v neměnných variantách Fedory rpm-ostree. Toolbox slouží k vytvoření pracovního prostředí nad neměnným systémem, kde si můžete instalovat balíčky, zapisovat atd. Je to tenká vrstva nad podmanem, která kontejner upravuje pro použití na desktopu: připojení domovského adresáře, display serveru, dbusu atd.

Bisektovani regresi. Zarazuji jako vrazedne kombo do seznamu vypatlanych ceskych IT vyrazu.

Když ono to hezký překlad nemá. "Hledání nového výskytu starých chyb pomocí binárního dělení (historie)" je poněkud dlouhé.

Dlouhé to je, ale alespoň je tomu rozumět.

Mně tedy bisektování regresí přijde podstatně srozumitelnější, protože obě slova mají přesný význam a nemusím luštit dvouřádkový opis.

Silverblue je super, má to tchýně akorát už se mi 3x stalo, že se zasekly aktualizace. Naposledy to byl nějaký problém s grubem, musel se provést ruční zásah. A před tím zase program Updates neviděl žádný updaty.

Zřejmě je to jen problém lidské síly - Silverblue se nedostává takové pozornosti, jako tradiční Fedoře.

Ovšem pro prarodiče je to ideální, nerozbitný systém. Zaselký aktualizace zase nejsou až takový problém, systém jel normálně. Lepší než cokoli jiného.

U běžných uživatelů to dělám tak, že jim v ostree nastavím pravidelný staging na pozadí a jen řeknu, ať to čas od času restartují. Nevyřeší to zaseknuté aktualizace kvůli GRUBu, ale vyloučí to aspoň tu grafickou nadstavbu a nutnost, aby s ní nějak pracovali.

Premyslim jak si prarodice rozbijou system, kdyz jim clovek neda prava roota? Pokud si pokazi nastaveni Chrome/Firefoxu, tak to stejne zustane v home adresari a nacte se i po restartu, ne?

Nerozbijí si ho rodiče, ale ten systém se může rozbít sám. Neděje se to už tak často, ale třeba regrese u podpory hardwaru se stávají. A když máti po aktualizaci na novou verzi kernelu začne vypadávat wifina, je to na dálku těžké řešit. Takto jí stačí říct, aby po bootu vybrala druhou položku v menu a je v tom systému, který jí před tím fungoval.

Hm, asi necemu nerozumim ale predchozi verzi kernelu si muzu zvolit i v ubuntu, a to neni nemenny OS.

Ty si myslis, ze treba takovy buntu se bez roota neaktualizuje? Mno a chcipne to prave po ty aktualizaci.

A pokud rozjebnes profil browseru, tak chci videt, jak stim BFU cokoli udela, protoze ten browser pak uz nikdy nenastartuje.

Ech. Tak znova.
Jo, aktualizuje.
Ja se snazim pochopit, v cem je ten nemenny system lepsi v tomhle pouziti: "pro prarodiče je to ideální, nerozbitný systém".
Ubuntu se aktualizuje. Pokud nastane chyba jadra, tak v ubuntu i nemennem systemu poradim po telefonu at pri startu zvoli ten druhy radek (predchozi kernel/system). Tady je to stejne pro oba typy systemu.

Pak je problem s programy typu Chrome (zasadni pro BFU). Dle Eischmann "jsou standardně oddělené od systému a běží ve flatpacích. Žijí si nezávisle na systému". Takze tady nemennem systemu nedokaze BFU nejak snadno vratit verzi, stejne jako to nedokaze v ubuntu.

Zatim jsem pochopil, ze nemenny system oproti standardnimu resi snadno systemove balicky. Takze nemenny system navic oproti standardnimu pomaha se systemovymi balicky, ale jak jsem psal vyse, techto problemu v souvislosti s aktualizacemi potkavam minimum (=jsem nepotkal).

Jo, muzu to chapat blbe, ale z diskuze ani clanku jsem to lip nepochopil.

To zacina byt nejakym zvykem necist predchozi diskuzi a napalit tu komentar?

26. 9. 2024, 09:00 editováno autorem komentáře

Mě přijde, že přesně na tohle je dobrý Tálos OS: https://www.talos.dev/

Jenom doplním, že ve Windows není potřeba po každé aktualizaci restartovat. Po spoustě ano, protože je dost obtížné aktualizovat runtime nad kterým něco běží, sdílené knihovny které jsou právě používané, atd. I kdyby šlo soubory aktualizovat na FS, což Windows by default zakazují, tak to neopatchuje běžící procesy. Dá se použít hot patching, ale ten Microsoft zatím umožňuje jen pro vybrané edice Windows (a například MSVC runtime, za jistých okolností).
https://techcommunity.microsoft.com/t5/azure-sql-blog/hot-patching-sql-server-engine-in-azure-sql-database/ba-p/849700
A je třeba říci celou pravdu. MS většinou uvolňuje patche ve větším množství během patch Tuesday. Je super pokud restart vyžaduje třeba jeden patch z pěti, ale pokud je skoro vždy nějaký takový součástí dávky z patch Tuesday, tak nakonec restartovat stejně musíte.
Chápu, že článek neměl rozebírat aktualizace ve Windows. Berte to čistě jako doplnění.

To sice může být pravda, ale třeba některé korporace vyžadují restart, a to jakože skutečný restart, minimálně jednou za 14 dnů. Je jedno jestli nějaké aktualizace proběhly nebo ne, restartovat se muší, i kdyby na chleba nebylo...

Dovedu to pochopit. Ona spousta aplikací má větší či menší resource leaky, a často je to vidět i u OS a driverů. Když máte leak v DB engine, driveru pro připojení k příslušné DB, na web serveru, v TCP stacku, antiviru a v nějaké aplikaci v Javě která vám míchá data dlouhým bidlem, tak dříve či později něco přestane fungovat. Pokud má korporace pracovní dobu, tak může být snazší jednou za čas v noci nebo o víkendu rebootovat. U desktopů je situace ještě horší, protože na nich běží dlouhá řada aplikací které jsou postavené z mnoha úrovní abstrakce postavených nad sebou, mají obrovský stavový prostor, jsou event-driven, a po celou dobu užívání vytvářejí a/nebo modifikují objekty.

Tak hlavně dneska v době distribuovaných systémů by pravidelné restarty měly být samozřejmostí a aplikace by s tím měla počítat. Když někde potkam server s uptime víc než pár týdnů (měsíců, ano, i roků), ježí se mi z toho chlupy až na pytlíku.

Problém to může být na desktopu, když je to vynucené.

Vedle toho existují i immutable systémy typu NixOS, kde se nic jako in-place aktualizace knihoven neděje a každá aplikace si svoje závislosti umí používat nezávisle. Na serverech je pak nutný reboot prakticky jen když se aktualizuje jádro.

Jen připomenu, že už před >20 lety se dělaly cross compilace OS + drivery + sada programů do statického souboru. Prostě malý monolit, klidně bez podpory konzole, nebo vtipně, bez driverů k HID, nasazovaný v všelijakých krabičkách, například v routerech. Říkali jsme tomu firmware, i když je to trochu sporný název.

A co se týče aplikací, takový starý dobrý pes chroot taky umí pěkné kousky, až si říkám, zda mnozí dockeriské, flatpakisté, snapisté, appimagisté a další izolatisté mají dostatečně dobré důvody ho nepoužít.

Nebylo by to dost khull ... to je ten duvod vis?

Tux se pred temi lety vesel na disketu a jeste si na ni mel i dost mista na vlastni data. Cely dos mel v poslednich verzich mozna 300kB.

Mnoho těchto distribucí se používá pro běh kontejnerů a Kubernetes clusterů. A veškerá konfiguce se odehrává ve vyšších vrstvách.