Vlákno názorů k článku
Vývojáři Debianu diskutují o odstranění neudržovaných balíčků od Uncaught ReferenceError: - je to největší problém debianu, instalovat nějaký balíček...

je to největší problém debianu, instalovat nějaký balíček je minové pole, jestli náhodou nechytneš nějaký, který není udržovaný a obsahuje zranitelnosti.

Alpine linux odstraňuje balíčky po půl roce neaktivnosti, stává se to, že se aspoň o chybějícím správci dozví spousta lidí a často se toho někdo ujme, u debian vlastně ani nevíš, že instaluješ balíček, který nemá svého pána nebo naopak pán sice je, ale nemá aktivitu.

Vlastně to je i důvod proč u spousty projektů jsme z debianu odešli, protože udržovat whitelist bezpečných balíčků bylo příliš náročné.

Jeste vetsi minove pole je ale stav, kdy balik z repa proste zmizi... ano, nove si ho uz nikdo nenainstaluje, ale z uz nainstalovanych systemu to nevysublimuje a pokud nema prilis slozite zavislosti, s velkou pravdepodobnosti tam bude hnit hodne dlouho. Ono i bezny dist-upgrade po sobe dost casto zanecha hromadu pohrobku, typickym favoritem zde jsou ruzne lib*, ktere kdyz maji uz od instalace manual flag (i kdyz k rucni instalaci nedoslo), tak tam zustanou... a ejhle, potencialni diry plynouci z neaktualizovanych baliku jsou na svete...

tak balík může mizet třeba pro další distro release, že jo. Ale ano, pak to rozbije dist-upgrade a v tom je asi kámen úrazu, proč se to ještě nevyřešilo.

Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou) pro spousty linuxových distribucí (tím neřikám, že jiné OS to mají lepší) je velice obtížné.

V podstatě dnes jsme ve stavu, kdy nonstop běží proces, kdy se servery přeinstalovávají na čisto, tak abychom nedrželi léta nějaký pohrobek se spoustou zapomenutých stavů, aplikací a nastavení. Zároveň se snažíme mít z OS repositáře jen minimální počty balíků, tak aby se dalo lidsky je kontrolovat a spravovat.

Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou)

Pro tohle bych použil NixOS.org ale záleží, má to samozřejmě i nevýhody.

nix je skvělý, používám, ale třeba tam ještě chybí nějaké rozumné security skeny, kontroly zranitelností, kontroly opuštěných a neaktualizovaných balíků vč. zranitelností jejich závislostí. Tohle se teprve začíná řešit, dokonce na tom i spolupracuji v nějaké malé míře.

"Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou) pro spousty linuxových distribucí (tím neřikám, že jiné OS to mají lepší) je velice obtížné."

Zas až tak obtížné to dnes už tak není. Máme tu nejrůznější externí balíčkovací systémy (Snap, Flatpak a nepodceňoval bych v tomto ani pkgsrc) a pokud chcete vyloženě "deterministický stav", tak je tu Nix (jak tu někdo zmiňoval) a GNU provozuje Guix (což - asi aby se to nepletlo - je název zároveň pro deterministický balíčkovací systém (inspirovaný právě Nixem) a zároveň pro oficiální Linuxovou distribuci od projektu GNU, která je na tomto balíčkovacím systému založená).

A nebo můžete balíčkovacím systémům zamávat a použít rovnou Appimage pro danou aplikaci (pokud je tedy k dispozici).

Takže jak vidíte, možností je dost. Úplně jednoduché to sice není, ale "velice obtížné" už taky ne.

6. 9. 2024, 00:05 editováno autorem komentáře

dříve šel zajímavou cestou třeba coreos, dnes podobně pokračuje Fedora Silverblue, Slax od Tomáše Matějíčka je přesně to stejné, vždy startuje totožný systém a jeho stav je neměnný. Jednotný obraz se používá často v embedded, řada routerů a aktivních síťových prvků na linuxu to tak má také.

Snapy, flatpaky, pkgsrc jsou skvělé, ale bohužel málo penetrované, nesou s sebou ale obrovské velikosti, příprava samotných balíků je zatím pro vývojáře (což jsou typičtí producenti požadavků na nějaké závislosti) dost obtížná. Hlavní ale problém za mě je velikost, kde nám původně stačilo 20 GB na aplikace, potřebujeme najednou 500 GB, k tomu se váže o řád vyšší nároky na repository servery, různé skenery typu qualys běží neúměrně dlouho, initializace serverů trvá pak také dlouho. Tím to celé prodražuje infrastrukturu, nix to má navržené mnohem lépe.

Ano, jde to, cesty jsou, ale za mě to je pořád v kategorii obtížné a tak pořád většinou vidím staré paradigma s OS, lokálně instalovanými balíčky a hromadou pohrobků, které jsou časem zapomenuty. Udělat to jinak něco stojí.

Nie sú na toto rôzne ansibly a podobné veci?

ansible je imperativní, dělá jen co mu řekneš, když při změně zapomeneš starý soubor smazat nebo balík odinstalovat (to ale pořád nevyřeší jeho nainstalované závislosti), tak to tam prostě nechá.

S trochou péče to lze řešit – stačí si z dpkg -l vygrepovat starší balíčky. Ale je pravda, že pokud to člověk neřeší, je to problém.

Jak se "grepují starší balíčky"? Některé mají v názvu "deb12", tj. ví se, z jaké verze Debianu jsou, ale to je menšina.

Nebo tím myslíš třeba každý měsíc si ukládat dpkg -l a pak zaměřit pozornost na balíčky, které už rok nezměnily verzi?

6. 9. 2024, 12:59 editováno autorem komentáře

no, pak to dopadne tak, že děláš dpkg -l na čistém systému a mažeš z produkce vše, co je tam je navíc.

Není vůbec snadné to samostatně rozličkovat, u řady balíků, které se instalují jako závislost máš stejně uvedeno, že jsou instalovány přímo atd.

Samozřejmě, když se snažíš, nějak se s tím popereš, ale tak trochu bych čekal, že tohle budou OS dělat daleko lépe, protože prostě dnes je problém, když na systému zůstane nějaký starý SW, nastavení balíček, nikdy nevíš, kdy tam zůstane zapomenuto něco, co umožní systém kompromitovat.