Bericht Updates unter Linux: Paketmanager NIX aktualisiert (fast) alles

[nille02]

Jop, und versuche mal von so etwas wie glibc ein Downgrade zu machen, da braucht dann fast das ganze System ein Downgrade.

Wo wir wieder beim Dilemma sind was den GNU/Desktop so plagt. Im Userspace werden einfach zu gerne ABIs geändert. Man verweist gerne auf den Kernel bei solchen Diskussionen, aber da ist die Schnittstelle zum Kernel mehr oder weniger in Stein gemeißelt und man braucht schon extrem gute Gründe warum man zum Userspace hin was ändern möchte.

Wenn ich die ABI schon ändere kann darauf auch gleich ein major release kommen mit einem neuen .so Filename damit beide im System liegen können ohne das es migrationsschmerzen gibt.

 

[MaxDaten]

Nix nutze ich im professionell aber auch als Hobby tool, die grenze lässt sich da so oder so nicht immer scharf ziehen.

Gerade mit nix eigene Umgebungungen deklarativ (entweder als Profil, nix-shell oder flake + direnv) reproduzierbar (!) definieren zu können ist ein großer Gewinn.

So habe ich hier im aktuellen Projekt jetzt eine flake Umgebung eingeführt, die für alle Entwickler alle nötigen Tools und binaries bereitstellt. Alle benutzen die gleiche openssl, kubectl, java & python Version.

Parallel habe ich aber noch diverse andere private und professionelle Projekte die alle ihre eigene Umgebung bekommen haben, so kann ich easy zwischen den Projekten wechseln und direnv läd automatisch alles nötige. Keine VM benötigt, alles nativ. Keine Konflikte zwischen den Projekten.

Vereinfacht kann man das setup vllt mit npm/pnpm/yarn package.json + lock File verstehen, nur eben für "alle" Ökosysteme.

Nächster Schritt wird sein, dass wir unsere Build-Pipeline & Service Images für Kubernetes genau auf nix umstellen. Nix bietet hierbei noch den Vorteil, dass man die Binaries sehr einfach aus öffentlichen Caches (cryptosafe hashes sind bei nix buildin) oder eben custom Caches aufsetzen kann. Eine Build-Pipeline, die diese Caches aktuell hält sorgt auch automatisch dafür, dass Entwickler sich nur noch binaries ziehen müssen, auch von custom tools.

Parallel habe ich noch einen raspberry pi mit nixOS aufgesetzt. Vorteil hierbei ist die leichte Desaster Recovery. Ich kann mir jeder Zeit reproduzierbar ein sdImage mit meiner letzten aktuellen System Konfiguration bauen. kein neues Einrichten.

Zudem share ich die gleiche home Konfiguration über ein nix community Projekt namens home-manager, mit shell konfigurationen, alias und packages die ich alltäglich und projektübergreifend benutze (z.B. ripgrep).

 

[N3r1x]

Ich finde es schon beeindruckend, wie man es als Redaktion schafft, durch Vereinfachung und Weglassung, völlig am Kern und Vorteil einer vorgestellten Software vorbei zu quatschen.

Nix ist halt deutlich mehr als "ein plattformübergreifender Paketmanager".
Die deklarative Konfiguration macht so viel mehr als "Pakete installieren", dass es schon fast eine Beleidigung ist, Nix auf einen "Paketmanager" zu reduzieren.

Ich hab mir den Artikel durchgelesen und war am Ende überrascht, dass das Ende da war, weil einfach völlig fehlt, auf die Besonderheiten und sich daraus ergebenden Vorteile einzugehen. Der Bericht ist damit insgesamt ziemlich enttäuschend. 🤷‍♂️

 

[Kaito Kariheddo]

Man kann es am Ende eben nicht allen Recht machen. Daher muss irgendwann die Linie gezogen werden: Wer bereits weiß, dass NIX mehr als ein einfacher Paketmanager ist, der braucht auch keinen Bericht darüber zu lesen. Alle Anderen, vom Einsteiger bis zum Fortgeschrittenen, haben zumindest genug Vorlage um sich näher mit dem Thema zu befassen, falls denn gewünscht. Das wesentliche ist doch, dass zumindest mal darüber berichtet wurde. Natürlich steht es dir jederzeit offen einen ausführlichen Bericht im Forum über NIX zu verfassen.

 

[4nanai]

Wenn Windows: nutze winget in der powershell, mit z.B. upgrade --all. Die gängigen Anwendungen (Steam, Discord, Office, OBS etc etc) sind da alle drin.

Naja und unter Windows wäre anzuraten den AppStore zu nutzen bzw. als Paketmanager winget (auch wenn winget mitunter ganzschön müllig ist..).

Andersrum drückt Microsoft krampfhaft den Microsoft Store in die Welt und das durchaus überzeugende Winget.

Ja Moment. Ich war schon hocherfreut erfahren zu haben, dass sowas scheinbar mit Bordmitteln möglich ist.

Umso ernüchternder der Versuch Chromium zu installieren:

Multiple packages found matching input criteria. Please refine the input.
Name Id Source
------------------------------------------
Chromium Hibbiki.Chromium winget
Chromium eloston.ungoogled-chromium winget

Als Option gibt es also 2x irgendwelche Github Repos, bei denen zunächst überhaupt nicht nachvollziehbar ist, auf welchem Stand die sind.
Das fand ich schon bei Chocolatey äußerst unprofessional. Vor allem nach einer Erfahrung mit einem Softwarepaket, das extrem viele Kontextmenü-Einträge erstellt hat, die auch nach der Deinstallation noch vorhanden waren.

Da besteht seitens MS noch ganz schön viel Nachholbedarf.

 

[Piktogramm]

Da besteht seitens MS noch ganz schön viel Nachholbedarf.

Ich schrieb ja, winget ist mitunter müllig. Das Projekt rennt in alle Probleme, für die es offensichtliche Lösungen gibt, wenn man sich die Paketmanager der div. Distributionen der BSD/Linux Welt anschaut.

Und das wird auf absehbare Zeit alles nicht besser werden. Ms tut sich viel zu schwer alte Zöpfe abzuschneiden. Allein die Windows Updates sind Satire im Vergleich zu allen anderen, produktiven OS für Desktops.

 

[ReactivateMe347]

Da besteht seitens MS noch ganz schön viel Nachholbedarf.

Also ich finde Winget bisher erstaunlich gut. Ich nehme an, das meinst du mit den 2 Repos, da ist das eine der Client und das andere das Repo. Aufbauen tut das ganze auf den setup-Dateien der Hersteller, keiner muss sie manuell "umpacken" wie bei Linux.

Wenn Software im Repo fehlt, dann kann man die melden, wenn mal eine Version nicht ganz aktuell ist ebenso. Blöd ist nur, dass man teilweise die alten Versionen nicht installieren kann, weil er dann den neuen Installer lädt und mit dem alten Hashwert abgleicht.

 

[4nanai]

ch nehme an, das meinst du mit den 2 Repos, da ist das eine der Client und das andere das Repo.

Nee. Das sind die beiden angeboten Quellen:

https://github.com/ungoogled-software/ungoogled-chromium
https://github.com/Hibbiki/chromium-win64

Keins von Beiden ist "offiziell", sprich weder von Google noch von Microsoft. Das Eine ist zudem von allen Google-Diensten befreit, das muss man nicht zwangsläufig wollen (zwecks Synchronisierung z.B.).

Das entspricht ungefähr dem, was das AUR unter Arch ist. Von Usern selbst gestellte Repos. Dafür, dass das ein Windows Bordmittel sein soll, ist das ziemlich schwach.

 

[Piktogramm]

@ReactivateMe347
Das was @4nanai ist ne Namenskollission. Als "Chromium" sind da zwei Pakete bekannt, die die PaketIDs "Hibbiki.Chromium" als auch "eloston.ungoogled-chromium" tragen, beide Liegen im Repo "winget". Wer Namenskollissionen umgehen will, muss die genauen IDs nutzen. Wobei es da immer noch Kollisionen geben kann, wenn die exakt selben IDs in verschiedenen Repos auftauchen (ab Werk ist winget und der AppStore hinterlegt).
Ganz besonders witzig ist auch, wenn sich die IDs ändern, dafür hat Microsoft selbst ein gutes Händchen..
Edit: Und wer den Spaß automatisieren will hatte zumindest noch vor einem Jahr keine Chance Prioritäten zu einzelnen Repos zu setzen. -.-

Naja und das die Installer der Hersteller genutzt werden. Es sind viele Installerformate unterstützt, aber nicht alle. Zudem befeuert das auch nur die DLL-Hölle, dass jeder Installer die meisten Bibliotheken selber mitbringen (muss) und eigentlich jeden Sicherheitspatch der Bibliotheken sofort selbst updaten müsste. Was natürlich nicht passiert, da die ganzen Softwareschmieden weder auf ständige Updates Bock, noch ihre Abhängigkeiten wirklich unter Kontrolle haben.
Naja und Dependencies mit unter winget sind noch recht schmerzhaft. Laut Github issue sind Dependencies noch nicht aus "experimental Feature" hinaus. Verschiedene Architekturen lassen sich auch nicht definieren (Aarch64, X86_64 zum Beispiel) und als ich das Letztemal geschaut habe, war das Hinterlegen von Dependencies beim Einreichen von winget Rezepten keine Pflicht (und entsprechend kaputt).

 

[Snakeeater]

Ich habe NIX jetzt mal kurz installiert. So pralle finde ich es nicht.

Die Aussagekraft von so einem Post...

 

[mytosh]

Das gebe ich gerne zurück
Dein Post glänzt nahezu von Aussagekraft.

Was soll ich groß dazu sagen, an einem Einzelplatzsystem macht NIX für mich keinen Sinn. Wenn man viele Clients betreuen und oder ausliefern muss, gerne.
Aber auf dem heimischen Desktop sehe ich keine Vorteile für mich.
Die Syntax ist auch eine Qual.

 

[MordragT]

Wie sorgt Nix jetzt eigentlich für die Isolation der verschiedenen Programmversionen gegeneinander bzw. sorgt dafür, das zu jedem Programm die richtigen Abhängigkeiten in der Richtigen Version geladen werden.
Und wer maintained die ganzen Pakete?

In den elf Dateien (executables oder shared objects) gibt es Pfade die man angeben kann wo dann der dynamische linker nach den Paketen sucht (rpath) . Diese Pfade sind in normalen distros meist auf /usr/lib oder so. In nix zeigen sie aber auf die Abhängigkeiten im nix Store direkt. Und da die Pakete in einem gehashten Ordner liegen können so auch bibs mit unterschiedlichen Versionen koexistieren

Ergänzung (21. Juni 2023)

Das gebe ich gerne zurück
Dein Post glänzt nahezu von Aussagekraft.

Was soll ich groß dazu sagen, an einem Einzelplatzsystem macht NIX für mich keinen Sinn. Wenn man viele Clients betreuen und oder ausliefern muss, gerne.
Aber auf dem heimischen Desktop sehe ich keine Vorteile für mich.
Die Syntax ist auch eine Qual.

Es gibt auch für hemische Desktops enorme Vorteile. Als Entwickler kann ich die genauen Abhängigkeiten meiner Projekte in so genannten nix shells definieren (oder nix flake devshell) und andere Entwickler haben somit auch mit einem einzigen Kommando genau die gleiche Umgebung (wie Docker nur besser, gerade in Verbindung mit direnv). Und durch die Verwendung von nix kann ich mir auch sicher sein, dass wenn mein Programm auf meinem PC läuft, ich keine Abhängigkeiten vergessen habe und alles auch auf anderen PCs läuft. Meine gesamte Konfiguration für z.B. Vscode mit allen Extensions und modifikationen, meine Firefox Config mit allen Addons usw. kann sehr einfach mit wenigen Kommandos zwischen verschiedenen PCs geteilt werden (siehe home-manager). Wenn ein Paket mein System zerschiesst oder ich ausversehen eine falsche Konfiguration für mein System geschrieben habe, kann ich sehr einfach beim booten zu der vorherigen Version zurück rollen und tada alles klappt wie bevor (wie btrfs snapshots der system dateien nur besser). Wenn ich schnell die Konfiguration von anderen PCs testen will kann ich diese mit einem Kommando innerhalb einer virtuellen Maschine, oder mit wenigen Änderungen direkt auf meinem PC testen und bei nicht gefallen wie bereits gesagt zurückrollen. Die Syntax ist natürlich am Anfang etwas gewöhnungsbedürftig, aber man kommt da eigentlich recht schnell rein wenn man sich etwas einliest. Das größte Problem was ich mit Nix sehe sind:
1. Software wird nicht mit Nixos im Hinterkopf geschrieben: So ist Software mit bestimmtem Verhalten gerade in Bezug auf das FHS manchmal echt ein Krampf auf Nixos zu portieren.
2. Die Dokumentation ist leider etwas dürftig. Aber schon deutlich besser als wenige Jahre zuvor.

Ergänzung (21. Juni 2023)

Nix kompiliert auch? D. h. NixOS ist eine Alternative zu Gentoo?

Jein, also by default, sucht Nix in einem Binary Server nach den Paketen und downloaded sie ohne sie zu bauen. Wenn du aber z.B. die neusten avx512 nutzen willst und den standard cc überschreibst wirst du alle deine Pakete höchstwahrscheinlich auf deinem eigenen PC bauen. Vielleicht gibt es aber auch irgendwo eine Config wodurch alles auf deinem lokalen PC baut.

 

[ReactivateMe347]

Edit: Und wer den Spaß automatisieren will hatte zumindest noch vor einem Jahr keine Chance Prioritäten zu einzelnen Repos zu setzen. -.-

Prios weiß ich nicht, aber ich habe den Windows Store ausgestellt in winget, weil ich diese gammeligen Web-Apps eh nicht haben will

Naja und das die Installer der Hersteller genutzt werden. Es sind viele Installerformate unterstützt, aber nicht alle. Zudem befeuert das auch nur die DLL-Hölle, dass jeder Installer die meisten Bibliotheken selber mitbringen (muss) und eigentlich jeden Sicherheitspatch der Bibliotheken sofort selbst updaten müsste.

Das zeichnet eben Windows und auch z.B. Flatpack aus. Einen Tod musst du sterben. Entweder werden Libraries mit im Programmpfad installiert und sind dann ggf. veraltet, oder sie sind aktuell aber ggf inkompatibel. Würden alle konsequent breaking changes nur bei Major-Updates machen, dann wäre an der Stelle schonmal viel gewonnen. Leider macht heute jeder Versionen wie er will. Browser haben dreistellige pseudo-Major erreicht, bei Cyberpunkt ist 1.12 eigentlich 1.1.2 (und es folgt darauf 1.2), andere machen nur ein neues Major, weil sie inkompatibilität zu einer neuen Windows-Version erzwingen und Nutzer nochmal abkassieren wollen (z.B. O&O, ahead Nero).

Bei Windows gibt es solche Abhängigkeiten meiner Wahrnehmung nach auch kaum. .Net und C++ wird über Windows Update aktualisiert, Java wird spätestens seit der Lizenzänderung nun idR mitgeliefert (was echt einiges an Platz frisst) - was gäbe es da noch?

 

[Deinorius]

Es reizt mich schon länger, NIX auf dem Steam Deck auszuprobieren.
Auch wenn NIX viel mehr Vorteile bringt, würde ich erst mal nur sehen wollen, wie viel Speicherplatz ich dadurch einsparen könnte. Flatpak ist eine schöne Lösung, sofern man den Speicherplatz außer Acht lässt. Diese ganzen unterschiedlich versionierten KDE/Gnome Platform packages sind nervig.

 

[Piktogramm]

Das zeichnet eben Windows und auch z.B. Flatpack aus.

Das ist dann genauso wie bei Docker, wo die ganzen Bibliotheken vergammeln.

[...]Würden alle konsequent breaking changes nur bei Major-Updates machen, dann wäre an der Stelle schonmal viel gewonnen. Leider macht heute jeder Versionen wie er will. Browser haben dreistellige pseudo-Major erreicht, bei Cyberpunkt ist 1.12 eigentlich 1.1.2 (und es folgt darauf 1.2)[...]

Abhänigkeiten zu Spielen oder ganzen Browsern wären untypisch und ein wirklich schlechtes Zeichen. Was jedoch in die Richtung geht wäre u.a. Electron. Da würde es eigentlich ausreichen, wenn das einmal auf dem Rechner ist, und jedes Programm nur diese (aktuell gehaltene Version) referenziert. Weiter geht es dann bei den üblichen Verdächtigen wie OpenSSL und sonstigen Standardlibs. Die haben sich in Sachen Versionsverwaltung in der Regel unter Kontrolle und die APIs bleiben langfristig stabil. Zumindest bis der Kram sich derart überlebt hat, dass man wirklich an die Bibliothek und aller davon abhäniger Software ran muss.
In der Realität habe ich aber auch schon OpenSSL libs gefunden von 2002 und frisch gepanschter[1] Software.

[1]Kein Vertipper

Bei Windows gibt es solche Abhängigkeiten meiner Wahrnehmung nach auch kaum.

Ja wie auch, es liefert jedes Drecksprogramm ja auch fast alles mit und exponiert keine Abhänigkeiten. WhatsApp Desktop? Electron! Discord? Electron! GUI vom GPU Treiber (bei Intel?) Electron! Visual Studio Code? Electron!
Praktisch ist da viermal der selben Browser samt seiner Abhänigkeiten Installiert, wobei der technische Unterbau in etwa der Selbe ist wie beim Edge bzw. Chromebrowser. Daher, die Meisten haben noch mehr Iterationen davon aufm Rechner. Nur eben mit unterschiedlichen Patchständen, entsprechend ausgebliebenen Security Fixes und entsprechendem Bedarf an Fest- und Arbeitsspeicher.

.Net und C++ wird über Windows Update aktualisiert, Java wird spätestens seit der Lizenzänderung nun idR mitgeliefert (was echt einiges an Platz frisst) - was gäbe es da noch?

Ist das ein Witz? Schnapp dir WinDirStat und schau dir mal die größten Programme an. Die bringen teils ihr ganzes Betriebssystem mit (looking at you git for Windows).
Oder die Suche.. mit ein bisschem 0815 Software auf meiner nahezu ungenutzten VM komme ich auf:
2Electron (+Edge, + Chromium)
20 SQLite.dll
2 Phyton Umgebungen neben dem bewusst installiertem Phyton
2x mingw
10 Stellen die wie OpenSSL aussehen

 

[ReactivateMe347]

Abhänigkeiten zu Spielen oder ganzen Browsern wären untypisch und ein wirklich schlechtes Zeichen

Browsererweiterungen und Mods?!

Was jedoch in die Richtung geht wäre u.a. Electron. Da würde es eigentlich ausreichen, wenn das einmal auf dem Rechner ist, und jedes Programm nur diese (aktuell gehaltene Version) referenziert.

Theoretisch ja. Bis die WebUi irgendein Element erfordert, dass das neue Electron nicht mehr unterstützt. Oder vergleiche mal Balena Etcher mit Rufus.

Weiter geht es dann bei den üblichen Verdächtigen wie OpenSSL und sonstigen Standardlibs. Die haben sich in Sachen Versionsverwaltung in der Regel unter Kontrolle und die APIs bleiben langfristig stabil.

OpenSSL ist ein gutes Beispiel. Beim Fedora Update ging deswegen mein VPN-Client kaputt, weil der private Schlüssel in einem alten Format gespeichert ist, das jetzt als unsicher gilt und in OpenSSL 3 deaktiviert wurde. Gewarnt wurde ich davor nicht, es hat nach dem Upgrade einfach nicht mehr geklappt. Aber ja, grundlegend ist OpenSSL da ganz gut mit der Versionierung - bringt nur nichts, wenn die Anwendung, die es nützt, dann nichts sagt.

Ja wie auch, es liefert jedes Drecksprogramm ja auch fast alles mit und exponiert keine Abhänigkeiten.

Jein. Die Dateien sind ja da, Programm A könnte die Lib von Programm B benutzen. Windows hindert daran nicht, es ist nur eben nicht das Übliche.

WhatsApp Desktop? Electron! Discord? Electron! GUI vom GPU Treiber (bei Intel?) Electron! Visual Studio Code? Electron!

Electron ist sowieso der größte Mist, den es gibt. Ressourcenfressend und trotzdem miese Leistung. Spotify kann weniger als Winamp vor 20 Jahren... (Jaja, CEF nicht Elektron, aber derselbe Mist)

Ist das ein Witz? Schnapp dir WinDirStat und schau dir mal die größten Programme an.

Du verstehst das falsch. Die sind halt mitgeliefert und greifen nicht auf eine zentrale Instanz zu, genau das meine ich ja. Das ist unter Windows einfach nicht üblich. Ohne Paketmanager ist das auch schwer zu pflegen in dieser Konstellation - naja und mit hast du ggf. Probleme, dass es nach einem Update nicht mehr (ganz) korrekt funktioniert.

 

[Whistl0r]

Ich verwende Guix seit drei Jahren als Distribution ("Guix System" analog zu NixOS) auf meinem Hauptrechner. Sowie auf zwei Servern. Gerade dort macht das richtig Spaß, wenn man mal die initiale Konfiguration hinter sich hat

Sei ehrlich: Ziehst du das mit der deklarativen Konfiguration konsequent durch?
Ich nutze bspw. verschiedene Configuration-Management-Tools (Ansible, Salt, Puppet...) aber wenn es da Probleme gibt verbinde ich mit SSH und behebe in der Regel das Problem "vor Ort". Nicht immer aktualisiere ich dann die Konfiguration in entsprechenden Tools. Sei es aus Faulheit oder weil ich es manchmal zu umständlich finde: Es ist eine Sache eine Konfigurationsdatei komplett durch eine andere auszutauschen, gerne auch mit Templates etc, aber wenn man wirklich nur einen etwas komplizierten sudoers-Eintrag ergänzen muss und hierfür erst einmal verstehen muss, wie das in der jeweiligen YAML/Whatever Lösung umgesetzt wird, damit das entsprechende Abstraktionslayer das richtig umsetzt (und am Ende schlägt man sich noch mit Escaping etc. herum)...

Ziehst du das wirklich konsequent durch und konfigurierst dein System ausschließlich via zentraler Konfiguration?

Vor allem am Desktop... bedeutet dies, dass du dein Hintergrundbild nicht via Gnome/KDE/whatever-Lösung setzt sondern auch via deklarativer Konfigurationsdatei? Du willst ja schließlich irgendwann einmal dein System exakt so wie es gerade ist nachbauen können, nicht wahr? ;-)

 

[N3r1x]

Das wesentliche ist doch, dass zumindest mal darüber berichtet wurde.

Wenn man die Verknappung von Informationen genau da ansetzt, wo erst die Vorteile beginnen, wie soll jemand Interesse dafür bekommen?
Wenn NIX allein als "ein neuer Paketmanager" verkauft wird, wer sollte gesteigertes Interesse daran entwickeln?
Die Argumentation ist in meinen Augen noch schwächer als der Beitrag selbst.

Und ich werde keinen Artikel dazu verfassen, weil ich dazu zu wenig im Thema NIX bin. Ich bin soweit drin, dass ich weiß, dass es eben deutlich MEHR ist, als ein Paketmanager, danach hört es aber auf, weil es mir momentan an Zeit und Gelegenheit mangelt, das zu ändern.

 

[Kuristina]

@N3r1x Statt zu meckern, hättest du die weiteren Vorteile hier auch einfach mal aufzählen können. Wär die gleiche Zeit gewesen und alle hätten davon was gehabt.

 

[N3r1x]

Das ist hier im Thread schon mehrfach passiert.
Ich fand es nicht zielführend, die 5. Erklärung zu liefern.