Portál AbcLinuxu, 5. května 2025 03:09
K tomu se dá říct všeho všudy toto.
Kritická chyba v poslední verzi nějaké knihovny byla objevená a opravená už mnohokrát. Ovšem těch 32768 klíčů, které tam byly kdovíjak dlouho jenom kvůli správci balíčků a kvůli nesmyslnému backportování údajných oprav bez kontroly ze strany vývojářů OpenSSL — to byl asi tak vrchol všeho.
Nevidím ovšem důvod omezovat celou diskusi pouze na zabezpečení. Kromě bezpečnostních děr existují ve fosilních systémech i mnohé další problémy, které se uživatelů dotknou mnohem dřív a mnohem citelněji. Copak nikdo nikdy nezkusil naklonovat nějaký aktivně udržovaný projekt z GitHubu a přeložit ho na fosilním Debilanu nebo Blbuntu? Kdo něco takového zkusil a kdo těch projektů potřeboval třeba pět, kvůli benchmarkování a podobně, ten velmi rychle zijstil, že na fosilních systémech se nedá zprovoznit v podstatě nic, co někdo vyvíjí na normálním aktuálním systému. U jednoho projektu nesedí verze CMake. U jiného zase vadí, že není podporovaná asi tak polovina C++11. Pro další zase není k dispozici Java 1.8, Ruby 2 nebo Python 3. To je jen pár příkladů z mnoha.
Zajímavý je jeden zásadní rozdíl mezi domovskými adresáři uživatelů na normálních systémech a na fosilních sračkách. Zejména při zálohování dat si toho nelze nevšimnout. Na normálním systému tam uživatelé mají zkrátka svá data a nic jiného. Na fosilním systému tam mají pár gigabytů zdrojáků a binárek a něco na způsob vlastního malého UNIXového adresářového stromu, což je doklad o zoufalé snaze získat aspoň trochu aktuální software, většinou po manuálních zásazích do zdrojáků a po vynaložení obrovského nesmyslného úsilí. Výsledkem je něco, co funguje „náhodou tady a teď“ a co se rozhodně nikdy nebude dát spustit jinde.
Člověk by ale přece měl mít možnost spustit něco, co na „experimentálním“ stroji nastaví a zprovozní, na nějakém „produkčním“ stroji! Jinak to může rovnou zabalit a jít raději chlastat. Tento jednoduchý požadavek má ovšem dvě překážky v podobě omylů, mýtů a polopravd, podle kterých někteří „jezdí“. Fáma číslo jedna říká, že fosilní systémy jsou nějakým způsobem stabilnější a spolehlivější a měly by se preferovat. Jenže opak je pravdou a navíc výše popsané extrémní úsilí vedoucí k nepřenositelným projektům není nic jiného než mrhání lidským časem, což je trestuhodné, když jsou k dispozici nesrovnatelně lepší a aktuální systémy. Fáma číslo dvě zase říká, že by měl být jiný systém na serverech a jiný na desktopech, které administrátoři serverů používají. Jenže opak je pravdou, protože odlišnost „experimentálního“ a „produkčního“ systému je zase jen další zdroj problémů a zdržení, další hloupé mrhání časem lidí, který by se dal ušetřit.
Kritická chyba v poslední verzi nějaké knihovny byla objevená a opravená už mnohokrát. Ovšem těch 32768 klíčů, které tam byly kdovíjak dlouho jenom kvůli správci balíčků a kvůli nesmyslnému backportování údajných oprav bez kontroly ze strany vývojářů OpenSSL — to byl asi tak vrchol všeho.
Kritické chyby sa vyskytujú vždy či je to stable alebo bleeding edge softvér. Podľa mňa odmietaš sw alebo čokoľvek iné čo je staršie a ty to považuješ za odpad ?Koľkokrát bola chyba v najnovšom sw. Robil si niekedy diff verzii ? Prečo je to asi opensource asi preto, že každí si môže upraviť systém podľa seba.
Nevidím ovšem důvod omezovat celou diskusi pouze na zabezpečení. Kromě bezpečnostních děr existují ve fosilních systémech i mnohé další problémy, které se uživatelů dotknou mnohem dřív a mnohem citelněji. Copak nikdo nikdy nezkusil naklonovat nějaký aktivně udržovaný projekt z GitHubu a přeložit ho na fosilním Debilanu nebo Blbuntu? Kdo něco takového zkusil a kdo těch projektů potřeboval třeba pět, kvůli benchmarkování a podobně, ten velmi rychle zijstil, že na fosilních systémech se nedá zprovoznit v podstatě nic, co někdo vyvíjí na normálním aktuálním systému. U jednoho projektu nesedí verze CMake. U jiného zase vadí, že není podporovaná asi tak polovina C++11. Pro další zase není k dispozici Java 1.8, Ruby 2 nebo Python 3. To je jen pár příkladů z mnoha.
Načo zbytočná náročnosť sw s funkciami, ktorých efektivita je otázna. Ja keď kompilujem niečo tak zásadne to ide do /usr/src a keď je to niečo inštalačného typu tak to ide /usr/local. Chýbajuce závislosti som väčšinou vyriešil pomocou repozitára a hlavne sa vždy pozriem čo daný sw potrebuje. Požiadavky na sw by mali byť nasledovné. V prvom rade musí byť bezpečný. To znamená ošetrené potencialne nebezpečné situície. Maximálna efektivita. Mňa nezaujíma, že je dostupný hw s neviem akým výkonom. Ďalší dôvod je aj šetrenie prírodných zdrojov. Výroba stále novšieho hw spôsobuje zbytočné hromadenie odpadu. Keď bude efektívny recyklačný cyklus pre tento typ spotrebičov, tak môže byť- Nesúhlasím s výrobou zariadení len preto, že sú suroviny.
Zajímavý je jeden zásadní rozdíl mezi domovskými adresáři uživatelů na normálních systémech a na fosilních sračkách. Zejména při zálohování dat si toho nelze nevšimnout. Na normálním systému tam uživatelé mají zkrátka svá data a nic jiného. Na fosilním systému tam mají pár gigabytů zdrojáků a binárek a něco na způsob vlastního malého UNIXového adresářového stromu, což je doklad o zoufalé snaze získat aspoň trochu aktuální software, většinou po manuálních zásazích do zdrojáků a po vynaložení obrovského nesmyslného úsilí. Výsledkem je něco, co funguje „náhodou tady a teď“ a co se rozhodně nikdy nebude dát spustit jinde.
Na mojom PC mám poriadok v datach. Mám to elegantne vyriešené. Na oddieloch kde nie je dôvod mať povolené mount príznaky určitého typu nemám žiadne zdrojaky. Z dôvodu ochrany systému nebudem špecifikovať detaily. A ďalší dôvod je, že nie som zvedavý na komentáre typu zbytočne usilie a zastaraný prístup.
Člověk by ale přece měl mít možnost spustit něco, co na „experimentálním“ stroji nastaví a zprovozní, na nějakém „produkčním“ stroji! Jinak to může rovnou zabalit a jít raději chlastat. Tento jednoduchý požadavek má ovšem dvě překážky v podobě omylů, mýtů a polopravd, podle kterých někteří „jezdí“.
Ako by si sa zachoval keby máš uviesť produkt na trh a neriešil by testovanie, veď načo strata času. Nie každý je ochotný podstupovať riziko, že vplyvom nejakej chyby dôjde k poškodeniu. Načo je testovací nástroj chroot, virtualizácia atď. Podľa mňa je väčši problém prístup nainštaluj a zabudni. Je jedno o akú distribúciu sa jedna. Táto situácia sa často vyskytuje na hostingoch.
Co je normalny aktualny system? To, ze to nejde prelozit na starsich verziach je problem vyvojarov daneho projektu, nie starsej distribucie. Na vyvovjaroch zalezi ake nastroje pouziju a aka bude kompatibilita. Places na zlom hrobe.Copak nikdo nikdy nezkusil naklonovat nějaký aktivně udržovaný projekt z GitHubu a přeložit ho na fosilním Debilanu nebo Blbuntu? Kdo něco takového zkusil a kdo těch projektů potřeboval třeba pět, kvůli benchmarkování a podobně, ten velmi rychle zijstil, že na fosilních systémech se nedá zprovoznit v podstatě nic, co někdo vyvíjí na normálním aktuálním systému.
To je staleo tom istom a zaroven problem danych uzivatelov, ze si nevedia urobit poriadok.Zajímavý je jeden zásadní rozdíl mezi domovskými adresáři uživatelů na normálních systémech a na fosilních sračkách. Zejména při zálohování dat si toho nelze nevšimnout. Na normálním systému tam uživatelé mají zkrátka svá data a nic jiného...
Ak nieco vyvijam, tak pri vyvoji musim mysliet na com to chcem v reale pouzivat. To je zase problem vyvojara a administratora. Stare systemy byvaju stabilnejsie, vecsina chyb odhalena ale hlavne za ten cas ich pouzivania je miera poznania daneho systemu ovela vyssia(poznania jeho prednosti a nedokonalosti, dokumentacia,..). Preco si myslis, ze kritickejsie systemy nebezia na najaktualnejsej verzii daneho systemu alebo verziach? Scenar vo vecsine pripadov je, ze je potrebne otestovat prechod, opravit pripadne chyby, zoznamit sa s novinkami a pripravit migraciu. Kym to pripravia a otestuju, tak uz je novsia verzia. Ine pripady zase nove verzie nepotrebuju alebo migracia sa neoplati. Preco myslis, ze napr. Debian je uz v dobe vydania novej stable verzie neaktulany? No, ale vdaka tomu to cele aj funguje. Ak by to malo fungovat podla teba, tak to vecsina casu by sa spotrebovala na neustalu migraciu a upgrade. Neviem ako ty ale ja neptorebujem neustale najnovsie programy a operacne sytemy. Dnes to ani nestoji za vela, lebo casto je vecsina zmien dizajnovych a krokom spät.Člověk by ale přece měl mít možnost spustit něco, co na „experimentálním“ stroji nastaví a zprovozní, na nějakém „produkčním“ stroji! Tento jednoduchý požadavek má ovšem dvě překážky v podobě omylů, mýtů a polopravd, podle kterých někteří „jezdí“.
To, ze to nejde prelozit na starsich verziach je problem vyvojarov daneho projektuJako vývojář projektu prostě píšu v Pythonu 3 (je to pohodlnější) a není můj problém, že má uživatel prehistorický systém, na kterém si nedokáže opatřit pythoní3 moduly.
Na vyvovjaroch zalezi ake nastroje pouziju a aka bude kompatibilita.Pokud dělám něco třeba ve volném čase, nemíním trávit zbytečný čas tím, abych řešil, proč se můj kód nepřekládá na pět let starém systému.
bez kontroly ze strany vývojářů OpenSSL... protože zeptat se na mailing listu vývojářů OpenSSL, kteří řeknou, že je to OK, není kontrola...
Fáma číslo jedna říká, že fosilní systémy jsou nějakým způsobem stabilnější a spolehlivější a měly by se preferovat. Jenže opak je pravdouZajímavý argument. Nebo spíš jeho absence. A není to "nějakým způsobem". Je to prací vývojářů těch systémů, kteří ví, že jejich cílovou skupinou nejsou lidi, kteří chtějí mít každou hovadinu 5 minut poté, co ji někdo vložil do -tip větve. Jsou to lidi, kteří si na některé věci rádi počkají do doby, než budou stabilní a odladěné a bude je možné nasadit bez rizika výpadků. Protože zákazníci mají tendence se naštvat, když jim nejede služba, za kterou si platí. Pro takové případy jsou stabilní distra mnohem vhodnější, protože se někdo stará o to, aby software v dané verzi fungoval.
Fáma číslo dvě zase říká, že by měl být jiný systém na serverech a jiný na desktopech, které administrátoři serverů používají. Jenže opak je pravdou, protože odlišnost „experimentálního“ a „produkčního“ systémuNesouvisející věci. Experimetnální a produkční systém je ten samý systém, ale na tom experimentálním neběží žádná kritická služba. A můj desktop s tím nesouvisí už vůbec - když vím, že na něm nemůžu vyvíjet, protože by to na produkčním systému nefungovalo (a to se mi teda ještě nestalo), tak mám výojový stroj.
Vývojáři OpenSSL pokud vím neřekli, že je to OK. Oni neřekli nic.No na tom mailing listu AFAIK někdo řekl, že OK. Zpětně se ukázalo, že to není vývojář a že ten mailing list vlastně není konference vývojářů, ale jak to máš vědět, když na webu openssl je napsáno (nebo tenkrát bylo), že vývojáře je možné kontaktovat na tom a tom mailing listu.
K hlubšímu prozkoumání, jak moc velký zprasek OpenSSL je, tak tehdy ke škodě věci bohužel nedošlo.Nedávno jsem narazil na pěkné povídání - Proč Varnish nemá SSL - https://www.varnish-cache.org/docs/trunk/phk/ssl.html
Pro mě to znamená, že by se mělo víc energie věnovat do backportů. Pak to někdo jednou zprovozní a ostatní si to už jenom stáhnou a všichni jsou spokojení, takže your argument is invalid.Copak nikdo nikdy nezkusil naklonovat nějaký aktivně udržovaný projekt z GitHubu a přeložit ho na fosilním Debilanu nebo Blbuntu?
Jasně, takhle jednou někdo zprovoznil OpenSSL s 32768 klíči a ostatní si to už jenom stáhli a byli spokojení. Tohle je ta spokojenost, o kterou jde? Tomuhle že se má věnovat víc energie? 
To přece nemůže být míněno vážně. Zkrátka a dobře, je zbytečné přesvědčovat mě neplatným argumentem o údajné neplatnosti mého argumentu.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
17.4.2014 14:30
17.4.2014 08:24
17.4.2014 22:16
25.4.2014 09:42
20.4.2014 08:36