Journal bude zabezpečovat logy pomocí FSS

The H informuje, že journal ze systemd bude zabezpečovat logy pomocí FSS (Forward Secure Sealing). Případný útočník tak nebude moci záznamy o své aktivitě pozměnit. Ověřovací klíč bude možné uložit pomocí QR kódu do chytrého telefonu. Dle Lennarta Poetteringa je FSS založeno na zatím nepublikované práci "Forward Secure Pseudo Random Generators" jeho bratra Bertrama Poetteringa a bude podporováno již ve Fedoře 18.

22.8.2012 13:41 | Ladislav Hagara | Zajímavý článek

Komentáře

[kralyk z abclinuxu]

Takže to je nějaký kryptografický systém, který nejenže neprošel peer-review, ale ještě ani nebyl zveřejněn? No to chci vidět tu reálnou bezpečnost To mi přijde trochu jako security through obscurity. To, že AES, SHA3 a podobné soutěže trvají roky, má svůj dobrý důvod...

Mimochodem, nevíte, jestli už nějak Linus vyjádřil svůj názor na systemd a/nebo Journal? Afaik on Fedoru použivá už docela dlouho...

No nic, přeji příjemný flamewar

[Michal Kubeček]

Nějaká forma review je běžná ještě před publikací, přinejmenším by měl článek hodnotit recenzent. Ale to se samozřejmě zdaleka nevyrovná tomu, že po publikaci se k němu může vyjádřit kdokoli.

[pc2005]

Review provedou uživatelé Fedory .

[Petr Tomášek]

Mno, vzhledem tomu, že současný stav je totálně nezabezpečený, tak nový stav nemůže být nikdy horší

Navíc se nejedná o novou šifru, ale aplikaci již ověřené šifry, takže šance něco podělat je přeci jenom o několik řádů menší

[Radek Hladik]

Jako odporník na bezpečnost nemůžu ani s jedním souhlasit. Nový stav může navodit falešný pocit bezpečí, což je leckdy horší, než když to zabezpečené není. Ve škole nám často opakovali, že "špatné zabezpečení je horší než žádné". Typický příklad: útočník z interního sítě napadne nějakou službu. Admin projede všechny F18ky a protože v journalu nic není, automaticky bude hledat na jiných strojích...

A protože špatné použití i již dlouho používané šifry může její sílu totálně oslabit (viz například nedávné problémy s RSA), je krásně možné, že útočník pronikl právě na ty stroje, které admin vyloučil... Takže ano, šance něco podělat je teoreticky možná menší, ale pořád dost veliká...

[l4m4]

Aha, takže nejlepší je nezabezpečovat nic nijak. To je totiž jediný případ, kdy vím naprosto přesně a jistě, jak jsem na tom s bezpečnosti.

[chrono]

Ak sú na výber len dve možnosti (zle a nijako), tak áno, radšej to nechať nezabezpečené (a nejaký nepublikovaný algoritmus pre mňa spadá do kategórie "zle", aj keby išlo o iných autorov).

[Radek Hladik]

Ano, ale pak s takovým systémem musím pracovat podle toho, tedy s jako nezabezpečeným systémem. Běžne se říká, že bezpečnost není stav, ale proces a já dodávám, že zabezpečení je vlastnost. Takže pokud mám zabezpečení podle FIPS, tak mám zabezpečení podle FIPS. A pokud mi to pro moje požadavký nestačí, tak nemůžu použít něco, co je zabezpečené "jen" podle FIPS...

[l4m4]

V tom případě ovšem existuje správné použití FFS. Otázka je -- a odpověď na ni zatím neznáme -- jak tedy vypadá. Nicméně ,nainstalovat to bez ptaní uživatelům Fedory` vypadá být správné použití prakticky pro cokoli ;)

[Radek Hladik]

To neznamená, že pro FFS existuje správné použití. Nainstalovat to bez ptaní uživatelům fedory může být dobré řešení pro uživatlee jiných distribucí, ale o tom to není. Ten problém je v tom, že někdo slibuje, že to udělá něco. Tedy že mi to přinese ochranu proti modifikacím logů, aniž by to seriózně podložil...

[l4m4]

Problém vůbec není, že někdo něco slibuje.

Problém je, že současně připouštíte i nepřipouštíte, že ať už FFS reálně dělá cokoli, tak lze prohlásit ,mám zabezpečené logy akorát pomocí FFS` a zařídit se podle toho. Ve chvíli, kdy bude shoda, jak dobré zabezpečení to tedy je. Tudíž jste sám se sebou ve sporu, a to se pak těžko argumentuje.

A když nepochopíte vtípek s Fedorou (dal jsem tam ksakru smajlík, to jsem tam fakt měl strčit pětiodstavcové právníkem schválené varování, že následující věta může obahovat sarkasmus?), nemusíte to speciálně zdůrazňovat nesmyslnou reakci -- stačí, když prostě rebudete reagovat.

[Radek Hladik]

Jo, to já jsem často sám se sebou ve sporu, alespoň zdánlivě... Ten sarkasmus jsem kupodivu pochopil, ale zapoměl jsem přidat smajlík za tu větu. Ale každopádně, k tomu, co kdo slibuje:

The H informuje, že journal ze systemd bude zabezpečovat logy pomocí FSS (Forward Secure Sealing). Případný útočník tak nebude moci záznamy o své aktivitě pozměnit.

To je podle mého slib, který říká "utočník nebude moci záznamy o své aktivitě pozměnit". A to je to, co mně zajímá a co potřebuju mít podložené a zaručené, že ten mechanismus otmuto slibu dostojí...

P.S. Předchozí a tyto odstavce mohou obsahovat sarkasmus, nevhodné vtípky i nejapné narážky a poznámky, kteréžto jsou jedině a pouze autorovou snahou o to být sarkastický, vtipný a/nebo nejapný. (Nejsem právník, tak dám dohromady jen jeden odstavec a ještě ne moc právně kvalitni :) )

[pavlix]

To je podle mého slib, který říká "utočník nebude moci záznamy o své aktivitě pozměnit". A to je to, co mně zajímá a co potřebuju mít podložené a zaručené, že ten mechanismus otmuto slibu dostojí...

Zatím, jestli jsem to správně pochopil, tak máš pouze zaručeno že v průměrném případě má útočník možnost získat systém a upravit logy do prvního zahození klíče (za předpokladu, že je klíč vůbec bezpečně zahozen). Pokud by navíc měl útočník možnost predikovat časy výměny klíčů, tak by nemusel být zas takový problém se mezi ně vejít (když už bude znát cestu k průniku do systému).

[Jendа]

Nevím, jak funguje toto, ale podle mě by to šlo implementovat podobně, jako blockchain v Bitcoinu - každý další záznam v logu by obsahoval hash předchozího (a pochopitelně by byl podepsaný). Když by se někdo začal rýpat v historii, bylo by to vidět.

[Bilbo]

Problém je v tom, že to, co zapisuje logy v sobě pak obsahuje klíč na podepisování, takže jakmile někdo hackne cílový stroj tak, že je schopen zapisovat do logů, asi pro něj nebude zas takový problém vytáhnout patřičný klíč z logovacího démona - a pak se znalostí klíče zbytek logu prostě přešifrovat.

[Jendа]

Hmm, co když mám klíčů sekvenci a na každý řádek použiju další a po použití ho zahodím? Sekvenci klíčů může generovat třeba nějaký PRNG, který nejde backclockovat (triviální implementace: iterovaná SHA).

[kralyk z abclinuxu]

Anebo by mohly být záznamy v logu šifrovány asimetricky s tím, že "veřejný" klíč by měl server a tím by zapisoval záznamy a soukromý klíč k rozšifrování logu by měl admin někde u sebe.

[pavlix]

Aby to bylo ještě méně užitečné, než když se tam žádná kryptografie nedělá.

[Jendа]

Tohle by právě bez externí timestampovačky nefungovalo, jak píše Bilbo.

[kralyk z abclinuxu]

Já to ale myslel jinak než Bilbo, jestli jsem to správně pochopil, v jeho příspěvku byla řeč o podepisování, já měl na mysli zašifrování logu veřejným klíčem, tzn. třeba tak, že ke každýmu novýmu příspěvku do logu by se připojil hash předchozího a zašifroval by se veřejným klíčem uloženým na serveru v konfiguraci démona. Čili útočník by log nemohl změnit prostě proto, že by si ho vůbec nemohl přečíst. Mohl by ho pouze zcela smazat a nahradit nově vytvořeným ale 1) proti tomu by se daly udělat opatření (např. admin by si do logu na začátku mohl udělat nějakou značku, podpis, etc...) a 2) i bez opatření by se to nejspíš poznalo.

Něco podobného píše Bilbo níže

[Bilbo]

To by už asi mohlo fungovat, pokud se nezmrví implementace. Otázkou ale je jak budou řešeny věci typu "spadl démon" (což se nestává) nebo pád celého počítače (u serveru asi málo pravděpodobné, ale u workstation bez UPSky se stát může) a jestli pak třeba půjde odlišit případ kdy počítač sletěl od případu kdy se někdo šťoural v logu (a potom třeba i počítač ještě navíc sletěl ...)

[Bilbo]

Možná by pak šla tahle myšlenka použít nejen k podepisování logů, ale rovnou i k jejich šifrování, kdy se pak útočník ani nedozví co tam o něm je zalogované (i když zkoumáním následného provozu v syslogu to může asi celkem dobře tipnout ... ) a nezjistí tak např. ani věci typu "z jakých IP se obvykle loguje admin", což by mu už mohlo pomoct v rozšíření útoku na další stroje.

[Mrkva]

Jasně, ale pokud to prohlížítko/ověřovátko logů modifikuješ tak, že bude za každých okolností hlásit, že "log je v pořádku" tak se admin stejně nic nedozví. :)

[Jendа]

To si myslíš, že jsem taková lama? Cítím se dotčen (touch jenda).

Samozřejmě, že při podezření na napadení se log musí prohlížet na důvěryhodném počítači.

[pavlix]

Samozřejmě, že při podezření na napadení se log musí prohlížet na důvěryhodném počítači.

Podle mě je celkem jedno, kde to prohlížíš.

[Mrkva]

Samozřejmě, že při podezření na napadení se log musí prohlížet na důvěryhodném počítači.

Tak jasně, ale není jednodušší to na ten počítač rovnou posílat?

Navíc, pokud se ten klíč nebude měnit s každým zápisem do logu (asi ne, overhead by byl značný), tak útočník bude mít šanci ten klíč vytáhnout z paměti a s tím logem si pohrát. To už bych víc věřil grsecurity a sebraný write přístup k logům (nechat jen append).

[Jendа]

Tak jasně, ale není jednodušší to na ten počítač rovnou posílat?

Ne, myšlenka je, že ten počítač, na kterém se to kontroluje, je třeba adminův notebook.

[Jendа]

(asi ne, overhead by byl značný)

Doing aes-128 cbc for 3s on 1024 size blocks: 33646 aes-128 cbc's in 2.96s

Intel Atom N270 podtaktovaný na 800 MHz.

[pavlix]

Myslím, že to není potřeba až tak komplikovat, vzhledem k tomu, že je to bezpečnostní technika, kde je podstatně pravděpodobnější, že bude prolomena než že nebude. Což je v oblasti bezpečnosti přinejmenším nezvyk.

[Jendа]

Myslím, že to není potřeba až tak komplikovat, vzhledem k tomu, že je to bezpečnostní technika, kde je podstatně pravděpodobnější, že bude prolomena než že nebude.

Proč si to myslíš?

[pavlix]

Protože k prolomení stačí včas přečíst soubor s klíčem. Pokud je systém tvůj, ta vo co go?

[Jendа]

Protože k prolomení stačí včas přečíst soubor s klíčem.

Nic takového není, klíč je v paměti a po každém zápisu se mění.

Pokud je systém tvůj, ta vo co go?

No ale co když už není? Někdo mi ho vyownoval a já se chci podívat do logů, jak se mu to podařilo.

[pavlix]

Nic takového není, klíč je v paměti a po každém zápisu se mění.

Tvé tvrzení neodpovídá tomu, co vypisoval journald na screenshotu, co jsem viděl.

No ale co když už není? Někdo mi ho vyownoval a já se chci podívat do logů, jak se mu to podařilo.

Pak záleží na tom, jestli chce, abys to viděl :). Zrovna ty bys mohl slabiny tohoto „zabezpečení“ odhalit ihned.

[Jendа]

Počkat, bavíme se ještě o tom mém návrhu (Jenda: Nevím, jak funguje FSS, ale šlo by to bezpečně implementovat třeba tak a tak.), nebo už o FSS?

[David Jaša]

Tak teoreticky by se s každým klíčem dalo zacházet podobně jako s klíči pro luks - držet ho pouze v paměti a poctivě přemazávat při každé změně. V kombinaci s nemožností backclock/replay útoku (způsobem naznačeným Jendou) by to mohlo i fungovat, tedy až do chvíle, než si útočník přečte aktuální klíč.

Pak sice nezmění minulost, ale budoucnost si už může přiohýbat k obrazu svému - a o to lepší heuristiky a častější analýzy logů na důvěryhodném stroji by musely probíhat, aby to celé divadlo k něčemu bylo.

Append-only logy dohromady se za run-time nezměnitelnou boot opšnou nebo se šikovnou MAC/RBAC politikou (kdy ani růt útočníkovi k přepsání logů nepomůže) mi zní jako bezpečnější řešení.

[pavlix]

Tak teoreticky by se s každým klíčem dalo zacházet podobně jako s klíči pro luks - držet ho pouze v paměti a poctivě přemazávat při každé změně.

Tedy chránit nějaký kus dat systémem proti neoprávněnému přečtení. Pak mi ale řekni, proč nejde místo toho se na to celé vysrat a chránit nějaký jiný kus dat rovněž systémem proti přepsání. Mám namysli ty samotné logy.

Append-only logy dohromady se za run-time nezměnitelnou boot opšnou nebo se šikovnou MAC/RBAC politikou (kdy ani růt útočníkovi k přepsání logů nepomůže) mi zní jako bezpečnější řešení.

I mně. Bratři Lennartové tím pádem vymysleli způsob, jak snížit bezpečnost oproti současným možnostem a zároveň se mohli holedbat tím, že zvýší bezpečnost oproti současnému stavu a není úplně jednoduché to vyvrátit.

[David Jaša]

Pak mi ale řekni, proč nejde místo toho se na to celé vysrat a chránit nějaký jiný kus dat rovněž systémem proti přepsání.

Protože k přepsání dat na disku má útočník větší attack surface, než k přepsání místa v RAM? Nevím, intuitivně tipuju...

Bratři Lennartové tím pádem vymysleli způsob, jak snížit bezpečnost oproti současným možnostem a zároveň se mohli holedbat tím, že zvýší bezpečnost oproti současnému stavu a není úplně jednoduché to vyvrátit.

Tak na tohle se fakt necítím dostatečně kompetentní. Třeba ta ochrana jednoho klíče v RAM jde udělat hned, zatímco append-only (ještě?) není v Linusově stromu, co já vím... A třeba by šlo jádro naučit na emergency odstavení userlandu -> remount r/o -> sync -> shutdown při neoprávněném přístupu ke klíči snáz, než na něco podobného při append-only logu. Nicméně to už jsou fakt výcucy z prstu.

[pavlix]

Protože k přepsání dat na disku má útočník větší attack surface, než k přepsání místa v RAM? Nevím, intuitivně tipuju...

Vzdáleně? V podstatě je to to samé, buď jsi systém vyownoval nebo ne.

zatímco append-only (ještě?) není v Linusově stromu, co já vím...

Jo, já jsem na každém školení při probírání oprávnění říkal, že Linuxu ještě pořád něco chybí oproti většině ostatních systémů. Teda nevím, jak je na tom selinux.

Nicméně to už jsou fakt výcucy z prstu.

Právě. Bezpečnost je jednoduchá, jen nepohodlná. A hlavně, bezpečnost se řeší porovnáváním různých řešení z hlediska jejich vlastností nebo alespoň podrobným dokumentováním dotyčného řešení a jeho vlastnostní, ne takhle. Tohle je šaškárna.

[David Jaša]

Vzdáleně? V podstatě je to to samé, buď jsi systém vyownoval nebo ne.

Myslel jsem i v samotném jádře. Správa RAM je podstatně důležitější a přímější (míň mezivrstev ala VFS, FS, ...) než správa úložných zařízení a proto tam bude IMO pravděpodobnost lokálního nefyzického (ssh) exploitu menší.

Jo, já jsem na každém školení při probírání oprávnění říkal, že Linuxu ještě pořád něco chybí oproti většině ostatních systémů. Teda nevím, jak je na tom selinux.

Pozor, já to netvrdím, jenom odhaduju z komentáře někoho výš, že je na to potřeba grsecurity.

BTW centrální sběr logů vypadá jako něco, co by se mohlo hodit zaintegrovat do oVirta. :)

[David Jaša]

Pozor, já to netvrdím, jenom odhaduju z komentáře někoho výš, že je na to potřeba grsecurity.

Prd grsecurity... Viz chattr (1):

A file with the 'a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Takže prakticky stačí dát logy pod jinýho jůzra, růtovi sebrat dotyčnou capability a útočníkovi nebude stačit ani vypwnovanej stroj.

[pavlix]

Aneb když root není root.

[Petr Tomášek]

1) to je snad základ, že člověk nebude technologii slepě věřit, zvlášť ne technologii nové a neodzkoušené. To ale pořád není argument pro to, aby se takovéto technologie zaváděly.

2) nikde jsem nepsal, že to možné není, jen že je to řádově méně pravděpodobné.

[Radek Hladik]

ad 1) Já jsem reagoval na:

Mno, vzhledem tomu, že současný stav je totálně nezabezpečený, tak nový stav nemůže být nikdy horší

Což prostě není pravda. Ale já nemám problém s tou technologií, tu zatím málo kdo zná, ale s tím způsobem zavedení.

ad 2) I pokud budu brát pojem "řádově méně pravděpodobný" v intuitivním slova smyslu a ne v matematickém (což by se u kryptografie a poč. bezpečnosti mělo), tak se pořád jedná jen o jakýsi pocit, že nová celá věc bude nějak složitější než úprava staré. A přitom jsem linkoval příklad toho, že špatné použití technologie nejenom poškodilo toho, kdo jí špatně používal, ale v principu i všechny ostantí uživatele toho kryptosystému. A chcete další příklad? Před druhou světovou válkou Němci špatně používali Enigmu a díky tomu byli poláci schopní deset let dešifrovat jejich depeše... O co šlo? Šifra používala denní kód, který se skládal ze tří písmen a posílal se na začátku zpravy (šifrovaný denním klíčem podle nějaké kódové knihy). Vlastní zpráva se pak kódovala už tím tří písmenným kódem. Aby se omezila možnost chyby operátora (pozor, teď přijde to špatné použití), opakoval se kód zprávy dvakrát. Takže například "BFLBFL....", tedy vždy prvé a čtvrté , druhé a páté a třetí a šesté písmeno bylo stejné. Polský kryptoanalytik si všiml jisté vlastnosti, která byla nezávislá na konkrétních písmenech, ale pěkně popisovala denní kód. To jim umožnilo udělat jakýsi "reverzní telefonni seznam", kde podle této vlastnosti našli kandidáty na denní kód. Naopak, kdyby Němci použili kompletně novou šifru, byli by na tom lépe, protože před válkou se engima normálně komerčně prodávala, ne moc úspěšně, ale stačilo to na to, aby Poláci znali princip jejího fungování...

[Petr Tomášek]

ad 1) Já jsem reagoval na:

Mno, vzhledem tomu, že současný stav je totálně nezabezpečený, tak nový stav nemůže být nikdy horší

Což prostě není pravda. Ale já nemám problém s tou technologií, tu zatím málo kdo zná, ale s tím způsobem zavedení.

To je blbost. Ve chvíli kdy systém reálně odhalí, že logy byly změněny, je to samo o sobě lepší stav, než nezabezpečený log, u kterého vůbec není šance se něco takového dozvědět. Takže bych Vám doporučil se přivzdělat v základech logiky, zvlášť pro kryptografii to budete opravdu potřebovat.

[pavlix]

Ve chvíli kdy systém reálně odhalí, že logy byly změněny, je to samo o sobě lepší stav, než nezabezpečený log

To je pouhá teorie. Praxe může být klidně taková, že to systém neodhalí a kvůli přehnané důvěře tomuto řešení to ani nelze detekovat, protože není k dispozici log odesílaný po síti.

Takže bych Vám doporučil se přivzdělat v základech logiky

Jak laciné :).

[Petr Tomášek]

Ve chvíli kdy systém reálně odhalí, že logy byly změněny, je to samo o sobě lepší stav, než nezabezpečený log

To je pouhá teorie. Praxe může být klidně taková, že to systém neodhalí a kvůli přehnané důvěře tomuto řešení to ani nelze detekovat, protože není k dispozici log odesílaný po síti.

Přehnaně důvěřovat takové neověřené novince může jen blbec, to ale není důvod proč ji nezavádět...

[kralyk z abclinuxu]

Přehnaně důvěřovat takové neověřené novince může jen blbec, to ale není důvod proč ji nezavádět...

Právě že je. Dokud to schéma není pořádně prověřené, analyzované, otestované, nedá se o něm s dostatečnou spolehlivostí prohlásit, že zaručuje cokoli navíc oproti běžným logům. A tudíž celkem není důvod něco takovýho zavádět.

[pavlix]

Přehnaně důvěřovat takové neověřené novince může jen blbec

Při takto přísných měřítkách se ti může lehce stát, že zjistíš, že jsou blbci skoro všichni :).

[Radek Hladik]

K té impertinenci bych si dovolil snad jen toto.

Resp. ještě poznámku, ano někdo může za lepší stav považovat to, že ho systém upozorní, že mohlo dojít k úpravě logu...

[kralyk z abclinuxu]

Navíc se nejedná o novou šifru, ale aplikaci již ověřené šifry, takže šance něco podělat je přeci jenom o několik řádů menší

Hehe... Doporučuju zkusit si ověřenou symetrickou šifru v ecb módu

[Petr Tomášek]

No, ta to jsou snad dětské nemoci kryptografie, které, kdyby je někdo udělal dnes, budou považovány za školácou chybu...

[kralyk z abclinuxu]

Jistěže to je školácká chyba, mně šlo o to demonstrovat, že použití lety prověřených algoritmů ještě samo o sobě nic nezaručuje.

[pavlix]

Mno, vzhledem tomu, že současný stav je totálně nezabezpečený, tak nový stav nemůže být nikdy horší

Omyl.

Navíc se nejedná o novou šifru, ale aplikaci již ověřené šifry, takže šance něco podělat je přeci jenom o několik řádů menší

Bezpečnost stavěná na domněnkách končí zpravidla vždy podobně.

[Petr Tomášek]

Mno, vzhledem tomu, že současný stav je totálně nezabezpečený, tak nový stav nemůže být nikdy horší

Omyl.

Mýlýš se ty

Navíc se nejedná o novou šifru, ale aplikaci již ověřené šifry, takže šance něco podělat je přeci jenom o několik řádů menší

Bezpečnost stavěná na domněnkách končí zpravidla vždy podobně.

Každá bezpečnost v reálném světě je založena na domněnkách

[pavlix]

Tedy s/domněnkách/nekvalifikovaných domněnkách/.

[Rezza]

Rodina nedocenenych geniu :)

[Sešívaný]

To bylo první, co mě napadlo: A sakra, oni už jsou dva

[little.owl]

U mne to bylo: Proboha, kolik jich je?

[Lol Phirae]

[little.owl]

Me jen fascinuje, ze nikdo nevi co to je, ale uz se vi, ze to bude v F18. Poeterringove nesmeji byt nechani bez dozoru!

[Lol Phirae]

Poeterringove nesmeji byt nechani bez dozoru!

Jen aby nebylo pozdě... už se začali nekontrolovatelně množit.

[TM]

Škody, které napáchali przněním Unixového, pardon - Linuxového - světa jsou již bohužel asi nevratné. Distribuce začínají být, za zpěvu pokrokových budovatelských písní, zaplaveny jejich "zlepšováky" do té míry, že si říkám, co nám z toho krásného Unixu vlastně zbyde.
Takže jestli jsou jeden, dva nebo jich je třeba deset je vlastně úplně jedno.

[Jinan Dvoulalocny]

+1

Nejdřív to byl Miguel de Icaza, teď je to Lennart Poettering. Nemůžu si pomoct, ale nemám tyhle lidi rád (poněkud mírně řečeno - nechci být zcenzurován).

Co nám zbývá? Konzervativní distribuce? BSD?

[TM]

Rád bych zůstal u Linuxu, jehož jádro mně vcelku vyhovuje mimo jiné pro dobrou podporu nejrůznějšího hardwaru. Ale nemohu už skoro najít distribuci, kde by se neexperimentovalo s těmi zmiňovanými pitomostmi a přitom byla aspoň trochu s perspektivou dalšího vývoje. Někdy mám až skoro strach, že Unix ze světa mizí a je nahrazován podivnými mutanty.
Pořád dobře vypadá CentOS(RHEL) - hlavně verze 5, ale jen do té doby než se do něj dostanou ty hrůzy, které se teď odehrávají ve Fedoře. Na laptopu mám pořád OpenSUSE - jediná, která seriózně staví na dnes již zase použitelném KDE a kde se lze některých "zlepšováků" i v poslední verzi 12.1 pořád ještě zbavit. Ale co dál?

[pavlix]

Ale nemohu už skoro najít distribuci, kde by se neexperimentovalo s těmi zmiňovanými pitomostmi a přitom byla aspoň trochu s perspektivou dalšího vývoje.

Vždyť je vás tolik, co v dizkuzích proklamujete zájem o takovou distribuci. Já se divím, že jste dosud nespojili síly a nevytvořili ji nebo nedali nějaké existující perspektivu dalšího vývoje.

Mám skoro pocit, že zájem o takovou distribuci jsou jen hospodské řeči.

[TM]

Možná to bude tím, že ti kteří by ji uvítali nemají moc času, protože jim ke všemu ještě jejich práci znepříjemňují právě distribuce s těmi "zlepšováky".
A ti, kteří mají času spoustu si mohou dovolit hrát si s hrnečkem s uchem dovnitř, který jim připadá děsně cool.
Ti první by v mnoha případech dodavateli takové distribuce klidně i zaplatili. Zatím mají k dispozici RHEL, ale co bude až současným verzím vyprší životnost...

[pavlix]

Možná to bude tím, že ti kteří by ji uvítali nemají moc času, protože jim ke všemu ještě jejich práci znepříjemňují právě distribuce s těmi "zlepšováky".

Pak by to byla výborná investice do jejich času.

Ti první by v mnoha případech dodavateli takové distribuce klidně i zaplatili.

V tom případě by opět bylo možné, aby se podíleli méně časem a více penězi. Existuje spousta modelů, jakými se dá údržba takové linuxové distribuce financovat, od klasického vztahu zákazník-dodavatel, až po nějakou formu spolufinancování.

[Lol Phirae]

Vždyť je vás tolik, co v dizkuzích proklamujete zájem o takovou distribuci. Já se divím, že jste dosud nespojili síly a nevytvořili ji

Co mi to jen připomíná...

[kavol]

hm, zajímavé, můj komentář je prý vulgární, ale tvůj, kde je kompletní citace oné jadrné horalské mluvy, cenzurován není ... to už je fakt jak ve školce, my s ním nekamarádíme, on se nám nelíbí

[pavlix]

No ne, mně to upřímně zajímá a nemyslím to vůbec jízlivě. Jo dobře, ta provokativní věta na konci :), ale ta je tam jenom k probuzení spoludiskutujících, abych měl větší šanci dostat smysluplnou odpověď.

[okko]

Jednu chvíli z Redmontu vyhlásili, že Linux je největší hrozba pro jejich produkt. Chvíli se mračili, pak se zasmáli, jak je něco napadlo a od té doby si vesele pohvizdují. Čím to? ... Krátce po té události začaly linuxové distribuce zaplavovat "pokrokové" novinky, které postupně mění "linuxy" k nepoužitelnosti. Do té doby fungující prinip, že kdo chtěl nějakou funkcionalitu, tak ji naprogramoval a nabídl ostatním do "volné soutěže" se změnil - podivní "Osvícení" (kde se tu náhle sakra vzali) protlačují do samotných základů systému všelijaké šílenosti a z reálné možnosti volby se stal vyčpělý slogan (podobný slogan jako třeba "komunitní distribuce").

Jsem sám, komu poslední dění na linuxové scéně připomíná Syrský scénář?

[kralyk z abclinuxu]

Jednu chvíli z Redmontu vyhlásili, že Linux je největší hrozba pro jejich produkt. Chvíli se mračili, pak se zasmáli, jak je něco napadlo a od té doby si vesele pohvizdují. Čím to? ... Krátce po té události začaly linuxové distribuce zaplavovat "pokrokové" novinky, které postupně mění "linuxy" k nepoužitelnosti.

Tím v podstatě nazančuješ, že věřejný názor MS na linux je kompetentním hodnocením situace. Za to bych osobně teda moc nedal.

Do té doby fungující prinip, že kdo chtěl nějakou funkcionalitu, tak ji naprogramoval a nabídl ostatním do "volné soutěže" se změnil - podivní "Osvícení" (kde se tu náhle sakra vzali) protlačují do samotných základů systému všelijaké šílenosti

Souhlasím, že Journal vypadá jako slušná krávovina a osobně mě štve, že autoři nenabízejí možnost používat systemd bez Journal. Na druhou stranu - všichni tady mluví o jakémsi donucování vývojářl k něčemu, Syrských scénářích a podobná melodramatická přirovnání. Mohl by někdo nějak doložit, kterým lidem teda vlastně Lennart držel pistoli u hlavy, koho násilím donutil používat jeho SW?

Mimochodem, už je to sice dávno a nevzpomínám si na to moc, ale iirc při přechodu devfs → udev vzbuzoval udev podobný kontroverze jako systemd.

[pavlix]

autoři nenabízejí možnost používat systemd bez Journal.

Citation needed.

Mimochodem, už je to sice dávno a nevzpomínám si na to moc, ale iirc při přechodu devfs → udev vzbuzoval udev podobný kontroverze jako systemd.

+1

[Lol Phirae]

Mimochodem, už je to sice dávno a nevzpomínám si na to moc, ale iirc při přechodu devfs → udev vzbuzoval udev podobný kontroverze jako systemd.

+1

No, a nyní se zase brzo vrátíme zpět k devtmpfs, jen co zvládne Poettering family ten samostatný udev kompletně dorazit (předpokládám, že to bude nejpozději do konce roku). Takže, opět měli pravdu.

[kralyk z abclinuxu]

No, a nyní se zase brzo vrátíme zpět k devtmpfs, jen co zvládne Poettering family ten samostatný udev kompletně dorazit (předpokládám, že to bude nejpozději do konce roku). Takže, opět měli pravdu.

Ty něčemu takovýmu fakt věříš? Vždyť to je naprostej nesmysl.

[little.owl]

+1

[Lol Phirae]

Viz Lennart:

Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.

[kralyk z abclinuxu]

Jasně a hned potom 21.12. skončí svět.

[belisarivs]

Ani bych nerekl. V OpenSUSE 12.2 mi bez systemd nejel zvuk. A hle, pokurveny udev. Dekuju pekne. Sup tam s Gentoo.

[kralyk z abclinuxu]

autoři nenabízejí možnost používat systemd bez Journal.

Citation needed.

Q: I am using systemd on an embedded system and am not interested in persistent logging, can I opt out of the journal?
A: No you can’t really. However, what you can do is tell systemd that you don’t want persistent logging, by removing (or not creating in the first place) the /var/log/journal directory, in which case journald will log only to /run/log/journal (which it does in any case during early boot). /run is volatile and lost on reboots, in contrast to /var. On top of that you can configure the maximum disk space the journal may consume to a low value.

Citováno odtud, FAQ ke konci dokumentu. Celý je to takový vtipný...

[little.owl]

Citováno odtud, FAQ ke konci dokumentu. Celý je to takový vtipný...

Co je to za dokument? Kdo je autor? A navic, podle soucasneho stavu kodu, je to i trochu zastarale.

[kralyk z abclinuxu]

Nevím. Pokud to není pravda, budu jedině rád.

[JoHnY2]

Tenhle text si mapatuju z Lennartova blogu nekdy z doby kdy jsem instaloval F17 a nejak vic jsem si hral se systemd.

[little.owl]

Ten text ma skutecne Lennartuv rukopis, Kay Sievers ma jiny styl.

Q: I am using systemd on an embedded system and am not interested in persistent logging, can I opt out of the journal?

A: No you can’t really. However, what you can do is tell systemd that you don’t want persistent logging, by removing (or not creating in the first place) the /var/log/journal directory, in which case journald will log only to /run/log/journal (which it does in any case during early boot). /run is volatile and lost on reboots, in contrast to /var. On top of that you can configure the maximum disk space the journal may consume to a low value.

S tim jako SW/HW Embedded Engineer nemam problem, naopak binarni log je zde spise plus.

[Cody]

Kdo Linux tvoří? Komunita? Z části. Malé části (méně než 20%). Většinu vývojářských aktivit financují firmy, které do Linuxu protlačují, co potřebují. Red Hat, pro který pracuje Lennart, je největším přispěvovatelem. Není divu, že systemd a další "vymoženosti" se do Linuxu úspěšně protlačují.

Pro ostatní (zejména pak nekomerční) distribuce je jednodušší jít "po proudu", než si zadělávat na kvanta problémů s údržbou. Zejména, mají-li další projekty typu GNOME ony novinky časem vyžadovat a již bez nich nefungovat. Mimochodem, kdopak nám to přispívá do těchto dalších projektů? V případě GNOME je to zase z většiny Red Hat.

Dovedu si představit, že táhne-li se vývoj dostatečně rychle, pak zachovávat zpětnou kompatiblitu nebo udržovat možnost používat daný software bez "novinek" se stává extrémně náročné, a tudíž se do toho komunitě nechce. Nehledě na to, že je to otrava a mnohem zajímavější je implementovat novou funkčnost než udržovat tu stávající.

Soutěž sice je svým způsobem volná, ale firmy zaměstnávající kvanta vývojářů pracujících na plný uvazek mají šanci přebít komunitu, která se programování věnuje ve volném čase.

Neřekl bych, že se Linux mění k nepoužitelnosti. Mění se tak, aby maximalizoval zisk firmám, které do něj přispívají (což je mimochodem i MS). A mění se tak, jak se nám to třeba nelíbí. Jenomže nás, kterým se to nelíbí, je zoufale málo a nemůžeme firmám s armádou placených vývojářů konkurovat.

[pavlix]

Kdo Linux tvoří? Komunita? Z části. Malé části (méně než 20%). Většinu vývojářských aktivit financují firmy, které do Linuxu protlačují, co potřebují.

Znamená to, že firmy nejsou součástí komunity?

Není divu, že systemd a další "vymoženosti" se do Linuxu úspěšně protlačují.

Na druhou stranu závislost na systemd je relativně slabá, tudíž žádný distributor není nucen systemd do distribuce vůbec zařazovat, natož do výchozí instalace. Samozřejmě to mnozí dělají například proto, že jim to šetří práci se správou initskriptů.

Pro ostatní (zejména pak nekomerční) distribuce je jednodušší jít "po proudu", než si zadělávat na kvanta problémů s údržbou.

Jo, to je víceméně to samé, co jsem napsal výše než jsem si přečetl další část příspěvku :).

Nehledě na to, že je to otrava a mnohem zajímavější je implementovat novou funkčnost než udržovat tu stávající.

Ono jak pro koho, lidé jsou různí. Mně třeba teď nejvíc bavilo implementovat či opravovat funkčnost, o které se už roky tvrdí, že ji máme :). A testování a opravování věcí taky není až taková nuda, alespoň pro mě.

Soutěž sice je svým způsobem volná, ale firmy zaměstnávající kvanta vývojářů pracujících na plný uvazek mají šanci přebít komunitu, která se programování věnuje ve volném čase.

Takhle to nefunguje. Jednotlivé komunity distribucí si vybírají, kolik práce za sebe nechají udělat komerční firmy a kolik věcí si udělají po svém. Volba je čistě na jednotlivcích, kteří jsou schopni se spojit do skupin a udržovat nějaký software.

Mění se tak, aby maximalizoval zisk firmám, které do něj přispívají (což je mimochodem i MS).

To, že MS přispěl někdy nějakým kódem neznamená, že je to aktivní přispěvatel.

Jenomže nás, kterým se to nelíbí, je zoufale málo a nemůžeme firmám s armádou placených vývojářů konkurovat.

Proč konkurovat? Když Linux vznikal, tak taky nikomu nekonkuroval, přesto se vyvíjel. Stačí si systém vyladit podle svých potřeb a klidně při tom lze vycházet z nějaké distribuce, kde je už spousta práce hotová.

[okko]

Komerční firma je komunita a pravda je lež. (Eric Arthur Blair).

[little.owl]

Ne, symbiosa je mozna.

[little.owl]

Soutěž sice je svým způsobem volná, ale firmy zaměstnávající kvanta vývojářů pracujících na plný uvazek mají šanci přebít komunitu, která se programování věnuje ve volném čase.

Ano, to ale dava smysl, oni investici do Linuxu sleduji sve zajmy a je dulezite ze vysledky jejich prace muzeme diky licenci vyuzit. Linux ma diky tomu plno fungujicich technologii, ktere by se obtizne davali do kupy bez specializovanych full time vyvojaru a to vyzaduje je platit. Staci srovnat stav treba NetBSD a Linux a hned je to videt.

[little.owl]

Do té doby fungující prinip, že kdo chtěl nějakou funkcionalitu, tak ji naprogramoval a nabídl ostatním do "volné soutěže" se změnil

Je tu stale. Lide kolem Fedory treba napsali systemd, naintegrovali do sve distribuce a dali ostatnim k dispozici zdrojove kody pod otevrenou licenci. Udelali tedy vse co se u slusneho OSS ocekava.

podivní "Osvícení" (kde se tu náhle sakra vzali) protlačují do samotných základů systému všelijaké šílenosti a z reálné možnosti volby se stal vyčpělý slogan (podobný slogan jako třeba "komunitní distribuce").

Problem je jinde. Fedora pouziva systemd a tudiz prestava podporovat alternativni reseni a to i v samotnych zakladech. Pokud nejaka skupina chce alternativni reseni, musi si to zacit podporovat a vyvijet sama, doby kdy za ne delal tuto praci Red Hat je proste pryc. Vemte to na vedomi a v tom je jadro problemu. Je tu nemala skupina lidi, ktera na jedne strane nechce nove reseni a strane druhe se nechteji zacit aktivne podilet na podpore alternativniho reseni, ktere jim vyhovuje a pak jen hlasite breci jak jim nekdo neco vnucuje.

Jsem sám, komu poslední dění na linuxové scéně připomíná Syrský scénář?

Nesmyslne z mnoha smeru.

[okko]

V původním příspěvku byl zmíněn systemd? Asi jsem omylem potrefil husu...

[little.owl]

Za prve, uvadel jsem to jako vhodny ilustrativni priklad v kontextu vasich tvrzeni a pak je naprosto irelevantni ze jste to nezminil, za druhe, pamatuji si vase predchozi pripevky a vyjadreni ohledne systemd, ktere vykazuji vsechny znaky zmineneho pristupu.

[okko]

naintegrovali do sve distribuce

To je právě ono. Kdosi odkudsi přišel a náhle je distribuce "jeho". A on je zároveň celá ta tzv. komunita. Nejsou to ty mraky přispěvatelů, uživatelů a bugreporterů, jak by si jeden mohl myslet. A pár přicmrndávačů na abclinuxu přesvědčuje ostatní, že to je tak správné.

[little.owl]

Kdosi odkudsi přišel a náhle je distribuce "jeho".

Systemd byl v ramci Fedory odsouhlasen standardni cestou a pokud vam nevyhovuje komunitni usporadani Fedory a organizace jejiho rozhodovaciho procesu, nepouzivejte ji, distribuci mate dost.

[Lol Phirae]

goto ...

[little.owl]

Za podstatnou casti OSS stoji svoboda vyvojare implementovat veci, tak jak uzna za vhodne. Nikdo neni povinen psat SW, tak aby vyhovoval vam, podle vasich pozadavku. Respektujte to. Prave nespokojenost byla hnaci silou startu cele rady dobrych OSS projektu.

[Lol Phirae]

Víte, co mi ten váš styl argumentace připomíná? Bydlíte v nájmu, domácí je nesnesitelný kretén. Odstěhujete se jinam, leč co čert nechtěl, po chvíli barák koupí ten samý kretén. Opět vám "poradí", že když se vám to nelíbí, ať táhnete jinam nebo si nejlépe máte postavit vlastní barák. No, a když to teda konečně uděláte, tak přijde ten samý kretén potřetí a pod barák vám svede žumpy z širokého okolí, aby podmáčel základy a pořádně vám to tam zasmradil.

[little.owl]

Dala by se napsat obdobna alegorie pojata z druhe strany, ale neminim to delat a placat se ve vagnich obraznych vykladech.

[Lol Phirae]

Ano, na pochvalné reakce na adresu kreténa ze strany zbylých nájemníků, kterým centrální žumpa pod mým barákem smrdí méně, jsem úplně zapomněl. Vybudované stoka sice zamořila zdroje vody široko daleko, ale to nájemníci neřeší, není to vidět.

[little.owl]

Go fly a kite.

[kralyk z abclinuxu]

Bydlíte v nájmu, domácí je nesnesitelný kretén. Odstěhujete se jinam, leč co čert nechtěl, po chvíli barák koupí ten samý kretén. Opět vám "poradí", že když se vám to nelíbí, ať táhnete jinam nebo si nejlépe máte postavit vlastní barák. No, a když to teda konečně uděláte (...)

Nevěřim, že něco takovýho uděláš... Ty budeš celou dobu sedět v tom prvním bráku a večer v hospodě s kámoši nadávat na toho domácího, jakej je to strašnej kretén Po čase to přejde a už to nadávání na něj nebude mít tu šťávu, jako za starých časů, a proto bude potřeba najít nějakýho jinýho nesnesitelného nepřítele státu, ale to jistě nebude žádný problém, takže cyklus bude moct pokračovat...