Vlákno názorů k článku Která distribuce je nejlepší na server a proč právě NixOS? od Krtek Prcá Ježka - Proč používat něco standardního, za čím stojí rozsáhlá...

Proč používat něco standardního, za čím stojí rozsáhlá komunita, když můžu používat něco exotického že ? Za mě ne, raději zůstanu dalších dvacet let u Debianu.

Komunita kolem Nixosu není zrovna malá :) (btw, Nix se dá používat i v Debianu, třeba na reprodukovatelné vývojové prostředí je fakt super)

A nevznikl přesně takhle Debian? :)

NixOS tady je 20 let. Ve skupině na githubu nás je skoro tisíc (debian má stejný počet členů), jen za poslední týden do projektům kolem nixu přispělo skoro 500 lidí bezmála 2 tisíce commitů, což je více než u balíčků do debianu.

A proč to používat? Proč debian posledních 10 let pracuje na reproducible builds? Proč tady lidi z debianu udělali FAI? Není náhodou celá open source komunita založena na tom, že si každý dělá co chce a občas něco se uchytí a občas něco prostě ne?

Třeba protože až budete instalovat a konfigurovat 20. balíček na debianu, já budu už instalovat 20. server na Nixu... Jednou si "deklaruju" jak takový server má vypadat a pak už jen dělám nixos-install ;-) ... Nemám to zaplevelený různýma pokusama atd.
Samozřejmně, můžete použít puppet, ansible. Ale proč nepoužít něco co je v systému a na čem je takový systém postavený? Navíc třeba takový puppet(ansible whatever) má nevýhodu že ačkoli se tváří deklarativně, moc deklarativní nakonec při vývojových iteracích není a vede to k zaplevelenému systému. Tj. např. při instalaci balíku puppetem ho (až ho přestanete používat) musíte deklarovat jako ensure => absent. Nicméně osobně bych si představoval že pokud "deklaruju" nějaký systém tak na něm nebude nic krom toho co jsem deklaroval (a ne že pak půlka puppet file kvůli tomu bude časem zaplevelená ensure => absent a stejně se nikdy pravděpodobně nedostanu ke stejné instalaci jako na čistém stroji).

to je ale problém všech těch imperativních nástrojů, prostě jen automatizují změny a jsou nedetermistické. Pokud chci s chef/ansible/puppet nějakou kontrolu, musím je vždy spouštět ze stejného bodu (generovat nový image, generovat overlay nad prázdný fs atd.).

U nixu je za mě občas složité vědět, kdy mám přestat nixovat a kdy z toho udělat samostatnou aplikaci, při složitých deploymentech to umí rekurze a miliony nixpkgs instancí celé zabít.

"Tj. např. při instalaci balíku puppetem ho (až ho přestanete používat) musíte deklarovat jako ensure => absent."

To je dané tím, že Ansible ani Puppet nemají state file, jako třeba TerraForm. Sice to neodstraní vytvořený soubor, ale taky to pak je mnohem menší peklo to používat.

podobně to má i chef, ale pořád mi to třeba nevyřeší, když tam soubor/změna vznikla jiným zásahem nebo třeba jako side effect při spuštění služby.

To nepochybně. Na druhou stranu je to problém? Já používám Ansible na serverech skoro 10 let a problém to pro mě nikdy nebyl. Většinou mi systém nepřežije déle jak pět let, protože je nahrazen novým s tím, jak se vyvíjí infrastruktura a nebo kvůli migraci na nový hardware.

Yo... jenonze pak resite kde ten statefile ulozit a s kym ho sdilet a jak resit kolize.

Pro mě je tohle i úžasná vlastnost u desktopu, a Ansible fakt nedovede to co NixOS moduly a home manager. Instalace nového PC se vším co potřebuju pro práci včetně kompletní konfigurace desktopu za pár minut.