NixOS 14.12 (diskuse)

[chrono]

Mierne mi uniká zmysel distribúcie, ktorá zostavuje všetko zo zdrojových kódov a zároveň majú jednotlivé balíky (aspoň tie čo som pozeral) nulovú možnosť konfigurácie.

[papouch]

Fuj !!! Je tam systemd !!!

[Eda]

No já jsem rád, že to tam uvádí... a můžu se tomu případně vyhnout tako moru. Na druhou stranu, systemd není vůbec bez vlivu: U nás ve firmě díky němu a jeho průse.ům, vedení z konečnou platností zakázalo nahrazovat Windows systémem GNU/Linux :(. Ale na serverch je naštěstí zpravuji dál (samo na server nedám systemd). Windows moc nemusím ale systémd - to opravdu nešlo. Každou aktualizaci se něco opravilo a rozbilo něco jiného. Ještě dnes tam máme celkem šikovné uživatele kteří při slově Linux zbrunátní v obličeji . Samo, že se najde dost lidí kteří budou vysvětlovat jak na tom běží už 50let, mají to na ještě větších serverech než mi, a udržují víc stanic než mi a za celou dobu se nestala žádná chyba a žádný problém. A já byh jim mohl vyjmenovávat co se dělo u nás a, že tohle se nám bez systému toho neděje . A tak stále dokola Takže souhlas: Fuj systemd!

http://www.muylinux.com/wp-content/uploads/2014/08/funny-systemd.gif

[Stevko]

Čo sa dialo u vás?

[daemon]

Ta animace je dobrá. Směju se ještě teď.

[HonzaRez]

Bacha, systemd má vliv i na duševní schopnosti, během krátkého času udělá z člověka úplného hlupce...

[chrono]

Vlastná skúsenosť?

[Franta Hanzlík]

+∞
Odpovídá to i mým zkušenostem. Včetně toho odlivu, i když hlavně od Fedory (kterou jsem já idiot doporučoval ;)

[novy rok]

Odliv od Fedory je tak velký, že už ani nestojí zato ji dál vyvíjet.

Zprasili tam všechno, od tý hnusný Anakondy až po ten šílený nový gnome-shell.

[petr_p]

Jejich balíčkovací systém prý pro identifikaci nainstalovaných balíčků používá otisky, takže veškerý celý operační systém pak lze vyjádřit jedním reprodukovatelným kontrolním součtem. Od toho odvíjejí binární kompatibilitu, ověření integrity a zároveň možnost přečíst si související zdrojáky.

Slyšel jsem ale, že v praxi na to rezignovali. Když zjistili, že instalací bezpečnostní aktualizace se jim změní kontrolní součet, tak začali součty falšovat (původní součet je uložen v aktualizujícím balíčku), jinak by nikomu nešly nainstalovat reverzní závislosti.

[chrono]

To by ale fungovalo aj v prípade, že by boli použité binárne balíčky.

[Vladimír Čunát]

To "falšování kontrolních součtů" je poněkud silná dezinterpretace. Stav: nix normálně donutí znovu zkompilovat balíček kdykoliv ho chceme s nějakou změněnou závislostí (tranzitivně). Pokud tedy ozáplatujeme třeba glibc, "musíme" všechno překompilovat, což trvá a u bezpečnostních aktualizací to může být pro někoho problém. Proto je přidána možnost, že se ta závislost "prostě jen vymění", jako to dělá většina distribucí.

Obecně nelze říct zda třeba configure skripty kontrolují verze nebo nastavení svých závislostí a podle toho mění své chování (to není hypotetická situace)...

Navíc, ty /nix/store/hashe se (zatím) nepočítají z obsahu binárního balíčku, ale z jeho kanonizovaného zdrojového popisu (*.drv derivace). V případě výměny závislostí prostě zdrojový popis obsahuje instrukce k této výměně, a z nich se ten hash dělá. Je tedy těžké to nazývat "falšování".

[petr_p]

Já chápu, proč jste to udělali, ale podle mě to bortí celý koncept a očekávání uživatelů: Pokud hash je definován jako a unique identifier for the package that captures all its dependencies, tak čekám, že po změně jediné závislosti se hash změní.

Pokud tomu tak není, tak očividně hash nepostihuje celý stav. Navíc to znamená, že někdo subjektivně musí rozhodnout, která změna je dost důležitá, aby se hash změnil, a která není. Pak se už ale kvalitativní rozdíl mezi Nixem a jinými balíčkovacími systémy ztrácí. To už třeba Docker nebo OSTree je v tomto směru ortodoxnější.

Je třeba ale přiznat, že Nix nabízí univerzální způsob hlídání build-time konfigurace včetně flexibility rozhodnout, která „proměnná“ je z hlediska konfigurace význačná.

[Vladimír Čunát]

Ale ten hash se změní. Jen se nekompiluje znova, ale vytvoří se kopie (včetně všech závislostí) s přepsanými hashi. Hashe tedy stále postihují celý stav, ať už došlo k výměně závislostí nebo ne.

Navíc, výměnu závislostí skoro nikdo nepoužívá (pokud vím). Ta možnost byla naimplementováno hlavně proto, že pár lidí občas křičelo, že máme "problém s bezpečnostními updaty".

Obecně se snažíme co nejvíc automatizovat. Ono to ani jinak nejde, protože ještě nedávno bylo jen ~10-20 aktivnějších přispěvatelů (>100 committů/rok), což se nedá srovnávat s tisíci u Debianu a jiných velkých distribucí.

[tacoberu]

V původních verzích tam mělo být init systém GNU dmd. Ten byl nahrazen systemd? Nebo se s tím poprali nějak jinak?

[Sleep_Walker]

nepletete si to s GNU Guix?

[tacoberu]

Pletu. Dík.

[Petr Ježek]

Jako obvykle, většina "mudrců" si spletla téma a věnuje se komponentě, nikoli celé distribuci. Problémy se systemd mají pouze ti, kteří vytrvale preferují nechuť se s konfigurací popasovat a hlavně ji pochopit. NixOS je rozhodně zajímavý již pro své unikátní vlastnosti. Zkoušel jsem, funguje, ale nevyhovuje pro zdaleka každému...

[chrono]

To naozaj musí niekto, vždy keď sa objaví názov systemd, prísť a napísať, že všetci, čo majú niečo proti systemd sú neschopní? Možno že systemd vyskúšali, zistili že funguje ale im z nejakého dôvodu nevyhovuje. ;)

[pavlix]

Tak musí přijít mudrc největší...

[mankind_boost]

"Problémy se systemd mají pouze ti, kteří vytrvale preferují nechuť se s konfigurací popasovat"
Naprosto mě fascinuje, že toto dokáže napsat "vysokoškolský pedagog s doktorátem". Neočekával bych, že takovému člověku budou chybět intelektuální schopnosti nebo že se nechá takto snadno ovládnout svými emocemi. V obou případech je to pozoruhodné.

[pavlix]

a miltidisciplinárním znalostním zázemím