GNU Guix a GuixSD 0.12.0

Byla vydána verze 0.12.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 76 vývojářů. Přibylo 853 nových balíčků. Jejich aktuální počet je 4 599. Aktualizována byla také dokumentace.

22.12.2016 22:55 | Ladislav Hagara | Nová verze

Komentáře

[xkucf03]

Hodně zajímavá distribuce. A i ty konfiguráky.

[lertimir]

Distibuce s novým package managerem je pochopitelná, ale The release comes with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries. nerozumím co to s původním distrem udělá. Ten nový package manager je metamanager, který se bude nad puvodním natívním dkpg nebo rpm nebo jiným, nebo ho nahradí? (ale tím by musel nahradit i repozitáře.)

[dumblob]

Package manager GNU Guix se nainstaluje jako jakýkoliv jiný program a vše co s jeho pomocí nainstalujete je "neviditelné" pro nativní package manager (dpkg, dnf/yum, pacman, ...) a instaluje se paralelně ke stávajícímu systému, aniž by ho jakkoliv ovlivňoval.

Vzdálená analogie by mohly být balíčkovací manažery pro CPAN, npm, RubyGems, PyPI, Maven Central Repository, Docker Hub, PkgBase, atd., které taktéž jedou "nezávisle" na nativním package manager (ačkoliv mnohé distribuce se snaží nejpoužívanější balíčky/moduly balit do nativních balíčků pro jednodušší správu a řešení závislostí a bezpečnosti apod.).

Jinak GNU Guix je kromě mnoha dalších vysoce atraktivních vlastností poměrně výjimečný mj. i tím, že umožňuje jakýkoliv balíček nainstalovat v různých verzích paralelně a pro každé spuštění (či obecně použití daných dat, protože nemusí jít pouze o spustitelné aplikace) lze zvolit verze, ze kterých se má sestavit prostředí běhu. Tohle neuvěřitelným způsobem zjednodušuje ohromné množství práce IT člověka (testování, systémově nezávislá kompilace, debugování, porovnávání několika běžících verzí naráz, atd. - dále ve spojení s bit-perfect sestaveními podepsanými klíči lze instalovat tisíce balíků v podstatě v rámci sekund a ne hodin čekání na různá sestavení apod.) a mnohdy i koncového uživatele (transakční update, zkoušení starých/nových verzí, preview/"nakouknutí" do budoucnosti, jednorázové překlenutí nějakého problému užitím jiné verze, atd.).

Prostě paráda, každému doporučuji. Tohle mít v ruce před 10 lety, tak blbiny jako Docker buď nevzniknou a nebo budou okrajovou záležitostí. <rejp>Ju, ale to bychom zde nesměli mít plebs vychvalující balíčkovací systémy vedoucích Linuxových a BSD distribucí, které jsou IMHO již minimálně 15 let zářnou ukázkou, jak se balíčkování nemá dělat.</rejp>

[xkucf03]

Jinak GNU Guix je kromě mnoha dalších vysoce atraktivních vlastností poměrně výjimečný mj. i tím, že umožňuje jakýkoliv balíček nainstalovat v různých verzích paralelně a pro každé spuštění (či obecně použití daných dat, protože nemusí jít pouze o spustitelné aplikace) lze zvolit verze, ze kterých se má sestavit prostředí běhu. Tohle neuvěřitelným způsobem zjednodušuje ohromné množství práce IT člověka (testování, systémově nezávislá kompilace, debugování, porovnávání několika běžících verzí naráz, atd. - dále ve spojení s bit-perfect sestaveními podepsanými klíči lze instalovat tisíce balíků v podstatě v rámci sekund a ne hodin čekání na různá sestavení apod.) a mnohdy i koncového uživatele (transakční update, zkoušení starých/nových verzí, preview/"nakouknutí" do budoucnosti, jednorázové překlenutí nějakého problému užitím jiné verze, atd.).

+1

Tohle mít v ruce před 10 lety, tak blbiny jako Docker buď nevzniknou a nebo budou okrajovou záležitostí.

Částečně to souvisí, ale víc za rozšíření Dockeru IMHO může neschopnost/neochota autorů/výrobců softwaru dodat standardní balíčky (byť třeba jen pro jednu vybranou distribuci) a použitelnou dokumentaci. Což je podle mého věc, která by měla být dostupná i v případě, že se software distribuuje přes Docker nebo třeba binární obraz disku VM (QEMU-KVM, VirtualBox, Xen atd.). A taky za to může marketing – když řekneš průměrnému manažerovi, že bychom měli dělat RPM nebo DEB, tak nebude vědět, o čem mluvíš – kdežto když řekneš, že bychom měli jít do Dockeru, tak sice taky reálně neví, o čem mluvíš, ale už o tom někdy slyšel nebo četl.

Ju, ale to bychom zde nesměli mít plebs vychvalující balíčkovací systémy vedoucích Linuxových a BSD distribucí, které jsou IMHO již minimálně 15 let zářnou ukázkou, jak se balíčkování nemá dělat.

Hodně přeháníš. Balíčkovací systémy jako RPM a DEB vznikaly v době, kdy většina lidí neměla internet, alternativou balíčku bylo ./configure && make && make install a (o dost později) windowsáři si stahovali zavirované exáče z pochybných webů (což většina dělá dodnes). Klasický balíčkovací systém byl oproti tomu až mimozemsky vyspělá technologie, o mnoho řádů výš než cokoli jiného. Tyhle systémy se udržely dodnes a stále jsou velmi užitečné.

Je ale pravda, že možnost instalace více verzí jednoho balíčku a uživatelské instalace by to posunuly ještě o kus dál. To je evoluce. Otázka je, co s tím, jestli by Debian, Ubuntu, Fedora, Suse… měli přejít na nový formát balíčků nebo vylepšit ten svůj. Pokud by existoval nějaký nástroj na automatizovanou konverzi zdrojových DEB a RPM tak by to nemuselo být tak hrozné, ale bylo by potřeba upravit i všechny ty procesy kolem. Nebo nechat klasické distribuce žít jejich vlastním životem a „kanibalizovat“ jejich balíčky – převést je do nového formátu a začlenit do GuixSD.

[dumblob]

Pokud by existoval nějaký nástroj na automatizovanou konverzi zdrojových DEB a RPM tak by to nemuselo být tak hrozné,

Tak tohle už 5 let máme např. ve formě Effing package management.

Jinak co se změny týče, tak prvním (zřejmě nejbolestivějším) krokem bude celosvětové sjednocení verzování - ale i na tom se urputně pracuje. Až pak se opatrně můžeme začít ptát distribučních kanálů, zdali by nechtěli v horizontu 5-10 let pomaloučku přejít na smysluplné (a libovolně rozšiřitelné pro jakékoliv potřeby) verzování při změně jejich release/build/distribution řetězce.

Docker a vůbec "kontejnerizace" právě tento problém vyřešili poměrně radikálním způsobem - přeskočíme kompletně všechno a prohlásíme se za krále, který vše obalí do jednotlivých "panství" a řekne, že pak všechno funguje. Ale ouha, ono to není tak jednoduché, a tak se neobaluje do panství, nýbrž každá chaloupka zvlášť a jsme znovu tam, kde jsme byli, avšak s další částečně zbytečnou abstrakční vrstou navíc a tedy zvýšenou komplexitou, náklady, rizikem atd. Naštěstí některá "panství" (kontejnery použité na správných místech) skutečně existují, takže alespoň částečný úspěch se rozhodně nezapře.

[xkucf03]

Ale ouha, ono to není tak jednoduché, a tak se neobaluje do panství, nýbrž každá chaloupka zvlášť a jsme znovu tam, kde jsme byli, avšak s další částečně zbytečnou abstrakční vrstou navíc a tedy zvýšenou komplexitou, náklady, rizikem atd.

To mi připomíná svět Windows, kde se servery vytváří naprosto prasecky a živelně, protože aplikace nejsou dostatečně oddělené, běží většinou pod uživatelem system a různě si přepisují data a knihovny. Provozovat víc aplikací je peklo a nikdo do toho rizika nechce jít (co kdyby se to rozbilo?), tak se radši pro každou aplikaci nainstaluje nový server (což náramně vyhovuje Microsoftu, protože inkasuje za každou licenci). O tohle ve svém operačním systému a světě zrovna nestojím.

Naštěstí některá "panství" (kontejnery použité na správných místech) skutečně existují, takže alespoň částečný úspěch se rozhodně nezapře.

Za důležité považuji důslednější oddělení aplikací na desktopu. Zatímco serverové služby běží každá pod svým uživatelem a nemůžou si jen tak navzájem požírat data (i když i tam je co vylepšovat, ale není to tak akutní). Na desktopu běží všechny aplikace pod daným uživatelem, se stejnými právy a přístupem ke všem zdrojům daného uživatele. Tohle je potřeba oddělit – aby aplikace, které ke své činnosti nepotřebují síť nemohly po síti komunikovat, aby většina aplikací nemohla číst soukromé klíče uživatele, aby hudební přehrávač nemohl číst fotky a poštu uživatele, aby grafický editor nemohl do e-mailu, hudby, konfigurace www prohlížeče, aby uživatel mohl mít víc spolehlivě oddělených profilů prohlížeče (např. jeden pro internetové bankovnictví, jeden na běžnou činnost, jeden vývojářský/testovací s všemožnými doplňky)… zároveň spolu aplikace musí umět komunikovat přes nějaká API/sběrnici (např. když chci poslat obrázek e-mailem), musí to být pod kontrolou uživatele (správce nebo distributor zvolí nějaké výchozí nastavení, ale uživatel musí mít možnost si určit např. přísnější pravidla pro některé aplikace nebo naopak něco povolit – někdo chce, aby mu hudební přehrávač stahoval obaly CD z internetu, někdo chce mít radši přehrávač zcela offline bez jakékoli interakce s okolím) a celé to musí být podporované grafickým subsystémem, ať už nějaký firewall na úrovni X serveru nebo něco modernějšího jako Wayland.

[Dirka]

Firejail?

[xkucf03]

Koukám, že už je v Ubuntu, to je fajn – kdysi jsem o něm četl a to ještě v distribucích nebyl.

Já zatím používám vlastní řešení – Xephyr + další uživatelský účet, na který se připojuji přes SSH (díky čemuž tam aplikace může běžet i na jiném stroji). Pokud je potřeba omezit síť, tak to jde přes iptables.

Na Firejailu mi trochu vadí, že je to suid binárka – lepší by mi přišlo, kdyby to bylo přes bezpečnostní modul v jádře (AppArmod/SELinux), kterému by uživatel mohl podstrčit konfigurák s pravidly, s jakými chce danou aplikaci spustit.

K ideálu pak chybí ještě „bezešvý“ režim – okna z různých kontextů budou normálně vedle sebe, akorát budou třeba barevně odlišená, jako to má QubesOS (tzn. není tam okno Xephyru a uvnitř něj okna aplikací).

[Dirka]

Tak jasny firejail neni neprustrelny reseni v kontextu absolutni bezpecnosti, nicmene je trivialni pro nej napsat profil pro novou aplikaci, napriklad prave komunikace s netem nebo pristup na disk a to z nej dela imo velice zajimavy reseni.