1. Foren
  2. Kommentare
  3. Internet-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux im Ehrenamt: NixOS muss…

Ich schnalls nicht...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Ich schnalls nicht...

    Autor: Barnabas 04.07.22 - 10:43

    Nachdem das jetzt schon der zweite "Jubelartikel" auf NixOS ist und ich denn Sinn dieses ganzen Systems immernoch nicht verstehe - kann mir irgendjemand bitte mit verständlichen Worten erklären, was an diesem System so toll ist? Und welche Anwendungszwecke man damit abbildet?

  2. Re: Ich schnalls nicht...

    Autor: Dai 04.07.22 - 10:48

    So wie ich das sehe ist das einfach Docker mit ein paar extra steps.

  3. Re: Ich schnalls nicht...

    Autor: Dakkaron 04.07.22 - 11:11

    Die grobe Idee scheint zu sein, dass man sein System gescripted installieren kann. Scheint allerdings nicht wirklichein Problem zu sein, welches eine neue Lösung braucht.

    Einerseits kriegt man sowas auch mit Setup-Scripts auf ner normalen Distro hin.

    Andererseits ist Docker auch genau für diesen Anwendungsfall entwickelt worden.

    Bin mir nicht sicher, was genau das bringen soll.

  4. Re: Ich schnalls nicht...

    Autor: tomatentee 04.07.22 - 11:25

    Das komplette System ist deklarativ. Du hast nicht einen Container, den du per Dockerfile deklarativ (und im Besten Fall reproduzierbar) beschreibst sondern das komplette OS.

    Eine Installation eines Pakets ist nur eine Zeile in der konfig und entsprechend leicht z.B. rückstandsfrei rückgängig zu machen.

    Du startest jeden Morgen (bzw nach jedem reboot) in einer frischen, sauberen Umgebung und kannst diese quasi unbegrenzt und on-demand zerstören, neu aufbauen und skalieren.

  5. Re: Ich schnalls nicht...

    Autor: VanCoding2 04.07.22 - 11:29

    Nicht wirklich nein. Es gibt sicher überschneidungspunkte, ja, aber das Ziel ist ein anderes.

    Das Ziel von Docker ist es, eine einmal gebuildete Software genau gleich an Zielsysteme auszuliefern und dort zu betreiben.

    Das Ziel von Nix ist es eine Software mit gleichem Input immer genau gleich zu builden und zum selben Ergebnis zu kommen.

    Genau das gleiche? Nein!

    Bei Docker werden Images normalerweise mit Dockerfiles gebuildet. Diese sind NICHT reproduzierbar. D.h. je nach dem WANN du den build ausführst, kriegst du ein unterschiedliches Ergebnis. Es ist dir also in der Regel nicht möglich genau das selbe Image, das dein Kollege hat, auch selbst zu generieren. Stattdessen kriegst du von deinem Kollegen einfach sein Image.

    Das Problem ist aber, dass wenn du mal Änderungen am Image machen musst, dies u.U. gar nicht mehr funktioniert oder sich das Image anders verhält, weil eben gar nicht mehr die Selben Dependency-Versionen zum Einsatz kommen. So kann es sein, dass deine Build-Pipeline einfach plötzlich nicht mehr funktioniert, wenn sich irgend ein Alpine-Paket ändert.

    Es mag ein kleiner, aber eben ziemlich entscheidender unterschied sein.



    1 mal bearbeitet, zuletzt am 04.07.22 11:35 durch VanCoding2.

  6. Re: Ich schnalls nicht...

    Autor: nubar 04.07.22 - 12:05

    NixOS ist the Administrator's Dream, sozusagen. Das praktische Problem, dass es löst, siehst du, wenn du 20 Maschinen zu verwalten hast:
    - von denen sind vielleicht 3 oder 4 identisch
    - 5 sind spezielle Server die alle unterschiedlich konfiguriert sind
    - es gibt immer Überschneidungen zwischen irgendwelchen Maschinen (5 brauchen Spezial-Software A, 7 brauchen Zugriff auf VLAN Y, 10 machen Hardware-Development usw.)

    Images ausspielen bringt nichts, löst nicht das Update-Problem, außerdem sind ja nicht alle Maschinen identisch.

    NixOS erlaubt dir, die Aspekte der Konfiguration in einzelne Module abzutrennen (die dürfen voneinander abhängen oder sich auch sonst gegenseitig beeinflussen) und die Module je nach individuellem Bedürfnis an- oder abzuschalten.

    Jetzt kommt der Clou: Aus meiner Praxiserfahrung ist NixOS das erste Betriebssystem, in dem ich davon ausgehen kann, dass wenn ich ein Modul auf 2 Maschinen aktiviere, die sonst sehr unterschiedlich konfiguriert sind, dass das einfach funktioniert, ohne dass ich da genauer hingucken muss. If it works, it works! Das(!) ist in meiner täglichen Arbeit die mit Abstand größte Arbeitsersparnis. Ansible und fette Docker-Setups sind Kinderkram dagegen.

    Das 2. schöne Give-Away an NixOS ist, aufgrund der Architektur kann ich Anwendern erlauben ihre eigene Software zu installieren ohne andere Anwender oder das System zu gefährden. Kein sudo- oder root-Zugriff notwendig. Das erspart mir nochmals unheimlich viel Zeit.

    Das 3. schöne Feature ist, noch nie waren OS Major Upgrades so problemlos wie mit NixOS. Ich sage nicht, dass alles auf Anhieb klappt. Aber ich kann die notwendigen Anpassungen auf einer Modell-Maschine machen und testen, bis es geht. Maschinen-Konfigurationen kann ich auch einfach als QEMU VMs bauen und ausprobieren. Da muss ich also nicht mal 'ne Maschine booten. Und when it works, it works!

    Das 4. Feature, sollte ich beim Major Upgrade (oder irgendeinem Update) mal was übersehen haben und eine Maschine läuft nicht mehr richtig, kann der Anwender selbstständig die funktionierende ältere Version booten und weiterarbeiten, während ich im Hintergrund die Analyse mache und Lösung vorbereite. Auch das Risiko von Server-Downtimes nach verbockten Upgrades ist sehr viel kleiner.

    Das 5. Feature, ich muss mich nicht mehr entscheiden: Verschiebe ich ein Update weil Software A dabei kaputtgeht oder nicht? Ich kann das Update machen und trotzdem die alte Version von Software A (samt aller Libraries etc.) weiterlaufen lassen.

    Das sind die praktischen Auswirkungen von der Architektur von NixOS, der Rest sind technische Details. Und ja, es gibt auch Nachteile: Developer o. Admins müssen da voll mit drauf einsteigen und Nix lernen. Es gibt da hohes Frustpotential. Stackoverflow oder Google wird über Nacht quasi wertlos. Das ist eine ganz-oder-gar-nicht-Geschichte. Einziger Ausweg sind Linux-Container auf den Kisten für die Developer. Damit kreiert man dann 'ne unüberwachte, unbekannte, ungesteuerte Parallel-Infrastruktur.

  7. Re: Ich schnalls nicht...

    Autor: nomorenoless 04.07.22 - 13:34

    1. Reproduzierbar
    2. Deklarativ
    3. Atomar

  8. Re: Ich schnalls nicht...

    Autor: nomorenoless 04.07.22 - 13:37

    nubar schrieb:
    --------------------------------------------------------------------------------
    > Das sind die praktischen Auswirkungen von der Architektur von NixOS, der
    > Rest sind technische Details. Und ja, es gibt auch Nachteile: Developer o.
    > Admins müssen da voll mit drauf einsteigen und Nix lernen. Es gibt da hohes
    > Frustpotential. Stackoverflow oder Google wird über Nacht quasi wertlos.

    Ich benutze Nixos schon seit einigen Jahren... seit 2018. Mit nix schlage ich mich auch immer mal wieder rum. Es ist halt einfach vieles anders und ich habe hier auch nicht wirklich die Zeit, mir das im Detail mal anzueignen. Zum Glück ist #nixos auf libera.chat doch sehr hilfreich.

  9. Re: Ich schnalls nicht...

    Autor: gdh 04.07.22 - 16:36

    nubar schrieb:
    --------------------------------------------------------------------------------
    > NixOS ist the Administrator's Dream, sozusagen. Das praktische Problem,
    > dass es löst, siehst du, wenn du 20 Maschinen zu verwalten hast:
    > - von denen sind vielleicht 3 oder 4 identisch
    > - 5 sind spezielle Server die alle unterschiedlich konfiguriert sind
    > - es gibt immer Überschneidungen zwischen irgendwelchen Maschinen (5
    > brauchen Spezial-Software A, 7 brauchen Zugriff auf VLAN Y, 10 machen
    > Hardware-Development usw.)
    >
    > Images ausspielen bringt nichts, löst nicht das Update-Problem, außerdem
    > sind ja nicht alle Maschinen identisch.
    >
    > NixOS erlaubt dir, die Aspekte der Konfiguration in einzelne Module
    > abzutrennen (die dürfen voneinander abhängen oder sich auch sonst
    > gegenseitig beeinflussen) und die Module je nach individuellem Bedürfnis
    > an- oder abzuschalten.
    >
    > Jetzt kommt der Clou: Aus meiner Praxiserfahrung ist NixOS das erste
    > Betriebssystem, in dem ich davon ausgehen kann, dass wenn ich ein Modul auf
    > 2 Maschinen aktiviere, die sonst sehr unterschiedlich konfiguriert sind,
    > dass das einfach funktioniert, ohne dass ich da genauer hingucken muss. If
    > it works, it works! Das(!) ist in meiner täglichen Arbeit die mit Abstand
    > größte Arbeitsersparnis. Ansible und fette Docker-Setups sind Kinderkram
    > dagegen.
    >
    > Das 2. schöne Give-Away an NixOS ist, aufgrund der Architektur kann ich
    > Anwendern erlauben ihre eigene Software zu installieren ohne andere
    > Anwender oder das System zu gefährden. Kein sudo- oder root-Zugriff
    > notwendig. Das erspart mir nochmals unheimlich viel Zeit.
    >
    > Das 3. schöne Feature ist, noch nie waren OS Major Upgrades so problemlos
    > wie mit NixOS. Ich sage nicht, dass alles auf Anhieb klappt. Aber ich kann
    > die notwendigen Anpassungen auf einer Modell-Maschine machen und testen,
    > bis es geht. Maschinen-Konfigurationen kann ich auch einfach als QEMU VMs
    > bauen und ausprobieren. Da muss ich also nicht mal 'ne Maschine booten. Und
    > when it works, it works!
    >
    > Das 4. Feature, sollte ich beim Major Upgrade (oder irgendeinem Update) mal
    > was übersehen haben und eine Maschine läuft nicht mehr richtig, kann der
    > Anwender selbstständig die funktionierende ältere Version booten und
    > weiterarbeiten, während ich im Hintergrund die Analyse mache und Lösung
    > vorbereite. Auch das Risiko von Server-Downtimes nach verbockten Upgrades
    > ist sehr viel kleiner.
    >
    > Das 5. Feature, ich muss mich nicht mehr entscheiden: Verschiebe ich ein
    > Update weil Software A dabei kaputtgeht oder nicht? Ich kann das Update
    > machen und trotzdem die alte Version von Software A (samt aller Libraries
    > etc.) weiterlaufen lassen.
    >
    > Das sind die praktischen Auswirkungen von der Architektur von NixOS, der
    > Rest sind technische Details. Und ja, es gibt auch Nachteile: Developer o.
    > Admins müssen da voll mit drauf einsteigen und Nix lernen. Es gibt da hohes
    > Frustpotential. Stackoverflow oder Google wird über Nacht quasi wertlos.
    > Das ist eine ganz-oder-gar-nicht-Geschichte. Einziger Ausweg sind
    > Linux-Container auf den Kisten für die Developer. Damit kreiert man dann
    > 'ne unüberwachte, unbekannte, ungesteuerte Parallel-Infrastruktur.

    Danke!
    Beste Zusammenfassung, die ich gesehen hab.

  10. Da oben steht's. Wer es danach nicht schnallt...

    Autor: Kein Kostverächter 04.07.22 - 16:51

    ....braucht vermutlich auch kein NixOS. Danke, das war mal ein schöner Überblick.

    Bis die Tage,

    KK

    ----------------------------------------------------------
    Mach dir deine eigenen Götter, und unterlasse es, dich mit einer schnöden Religion zu beflecken.
    (Epikur, griech. Phil., 341-270 v.Chr.)
    ----------------------------------------------------------
    We provide AI Blockchain Cloud (ABC) enabled applications bringing Enterprise level synergies to vertically integrated business processes.



    1 mal bearbeitet, zuletzt am 04.07.22 16:51 durch Kein Kostverächter.

  11. Re: Da oben steht's. Wer es danach nicht schnallt...

    Autor: Yonderboy 04.07.22 - 17:27

    Kleiner Einwand meinerseits.

    Docker Images sind vielleicht nicht reproduzierbar, das liegt aber vor allem an "docker build". Daran wird jedoch gearbeitet um eben das zu ändern.

    Außerdem implementiert docker auch nur das OCI Format und interessanterweise sind andere Container build platformen wie zum Beispiel Google's bazel oder ko, reproduzierbar.

    Das bedeutet es lassen sich durchaus Container bauen die 100% reproduzierbar sind und sogar auf docker ausgeführt werden können.

    Und genau hier komme ich zu meinem wichtigsten Punkt.

    Nixos hat folgt einer tollen Idee und ich mag den Deklarationen Ansatz und die nix config sehr gerne, es wird sich aber leider nie im Enterprise Bereich durch setzen mit ein paar wenigen Ausnahmen.

    Denn, wieso sollte ich nixos verwenden und eine komplett neue Sprache (Nix) lernen nur um dann ein Linux system damit aufzubauen was nicht Mal OCI kompatibel ist.

    Deshalb wird im Enterprise Bereich, zumindest bei den großen FAANG, zunehmend auf immutable Linux Distributionen wie Microsoft's/Kinvolk's Flatcar Linux oder Red Hats CoreOS.

    Beide Linux Distributionen sind immutable und einzig dafür gedacht Container laufen zu lassen.

    NixOS deklariert ein system oder mehrere Systeme und baut diese dann auf.

    Container platformen wie die oben genannten Linux Distributionen verfolgen aber meiner Meinung nach den besseren Ansatz, weil man sie zu tausend ausrollen kann und dann einfach eine Container Orchestration Engine wie Kubernetes darüber legt.

    Am Ende ist es also völlig egal auf welchem Knoten der workload läuft und Kubernetes bringt noch dazu zig Features die NixOS nicht hat (wieso auch? Löst ja ein ganz anderes Problem).

    NixOS's Lieblingsargument is "Reproducibility", aber genau das gleiche erreiche ich mit Containern und immutables operating systems genauso.

  12. Re: Da oben steht's. Wer es danach nicht schnallt...

    Autor: nubar 04.07.22 - 17:50

    Den Beitrag verstehe ich nicht. Natürlich kann ich NixOS Images als OCI-kompatible Container bauen und dann von einem Kubernetes oder sonst was hochziehen lassen. Container arbeiten auf der Abstraktionsebene von komplette Dateisystemen, da baue ich halt ein Image zusammen und dann tut das. Das Tool, dass das dann zusammenbaut heißt halt nicht mehr "docker build" und die config files sind nicht mehr YAML, aber das war dann auch schon der Unterschied.

    Wenn ich tausende von denen ausrollen will, dann macht Kubernetes das halt. Ob er dazu NixOS-Container oder sonstwas ausrollen soll, ist doch komplett egal. Das weiß der Container-Manager ja nicht mal, was er da genau für ein Linux hochzieht.

    Ja, "reproducibility" erreiche ich auch mit Linux from Scratch, ist aber aufwendig und unpraktisch. Genauso ist es auch mit Flatcar oder CoreOS. Die machen aus der Sache einfach eine übelste Materialschlacht, indem, wie unter Windows, jede Anwendung komplett mit ihrem Dependency-Stack ausgeliefert wird. Da sind dann die Core-Libraries 1000x mit drin. Kann man machen. Und wenn nicht, dann bauen die in ihren Container-Build-Prozessen halt Nix nach und versuchen die Dependencies nur einmal im Image liegen zu haben. Und das wäre ja auch schön.

    Nix liefert halt auch gleich eine Sprache mit, mit der sich das ganze auf beliebiger Granularität komponieren lässt. Flatcar und co. brauchen dann noch 5 oder 10 verschiedene Tools und Sprachen.

    Langer Rede kurzer Sinn: Wenn man keine Zeit hat ernsthaft Nix zu lernen, dann ist NixOS nicht das richtige Mittel. Es löst (für meinen Alltag) jedoch Probleme, die kein anderes Tool auch nur im Ansatz beherrscht.

  13. Re: Da oben steht's. Wer es danach nicht schnallt...

    Autor: Yonderboy 04.07.22 - 20:22

    nubar schrieb:
    --------------------------------------------------------------------------------
    > Den Beitrag verstehe ich nicht. Natürlich kann ich NixOS Images als
    > OCI-kompatible Container bauen und dann von einem Kubernetes oder sonst was
    > hochziehen lassen. Container arbeiten auf der Abstraktionsebene von
    > komplette Dateisystemen, da baue ich halt ein Image zusammen und dann tut
    > das.

    Klar kannst du das. Aber wieso den extremen Aufwand betreiben und nixos dafür nehmen wenn man genauso gut etwas benutzen kann was mehr als 1 von 1000 ITlern kennen?

    Ich meine damit, der Vorteil geht flöten. Nixos hatte für mich Mal eine Daseinsberechtigung als man damals noch server provisionierte. Die Zeit ist aber vorbei.


    > Ja, "reproducibility" erreiche ich auch mit Linux from Scratch, ist aber
    > aufwendig und unpraktisch. Genauso ist es auch mit Flatcar oder CoreOS. Die
    > machen aus der Sache einfach eine übelste Materialschlacht, indem, wie
    > unter Windows, jede Anwendung komplett mit ihrem Dependency-Stack
    > ausgeliefert wird.

    Das macht NixOS doch auch nicht anders wenn du mehrere Pakete hast die auf unterschiedliche Versionen der gleichen Software zeigen. Ich erinnere mich da an tolle glibc fummeleien mit NixOS wenn man Mal etwas installieren wollte was nicht in den repos war.


    > Nix liefert halt auch gleich eine Sprache mit, mit der sich das ganze auf
    > beliebiger Granularität komponieren lässt. Flatcar und co. brauchen dann
    > noch 5 oder 10 verschiedene Tools und Sprachen.

    Ja nur mit dem Unterschied das flatcar und co nichts esoterisches sind sondern quasi Industrie Standard im Cloud Bereich.
    Das gleiche mir den 5-10 verschiedenen Tools.

    Nixos ist ein Exot und wird es leider immer bleiben. So sehr ich 1-2 Ideen von nixos auch mag :)


    > Langer Rede kurzer Sinn: Wenn man keine Zeit hat ernsthaft Nix zu lernen,
    > dann ist NixOS nicht das richtige Mittel. Es löst (für meinen Alltag)
    > jedoch Probleme, die kein anderes Tool auch nur im Ansatz beherrscht.

    Gebe ich dir Recht! :)

    Dann haben wir anscheinend einfach völlig andere Probleme.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Java Anwendungsentwickler (w/m/d) Backend
    ING Deutschland, Frankfurt am Main
  2. C# / .NET Softwareentwickler / Programmierer (m/w/d)
    PM-International AG', Speyer
  3. Projektleiterin / Projektleiter für die Bauwerkserneuerung der Ingenieurbauwerke U-Bahn (w/m/d)
    Berliner Verkehrsbetriebe (BVG), Berlin
  4. IT-Systemadministrator (m/w/d) Projekte
    Bayerischer Jugendring, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 429€ (Vergleichspreis 489€)
  2. 33,90€ (Best -und Tiefstpreis!)
  3. 1.699€ (1.798€ im Vergleich)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Solarenergiespeicher Bluetti EP500 Pro: Wie ich versuchte, autark zu werden
Solarenergiespeicher Bluetti EP500 Pro
Wie ich versuchte, autark zu werden

Ich vermesse per Drohne, schleppe Solarpanels und eine 83-kg-Powerstation, drucke Abstandshalter im 3D-Drucker - und spare Stromkosten. Zudem berechne ich, ob und wann sich die Ausgaben für die Anlage amortisieren.
Ein Erfahrungsbericht von Thomas Ell

  1. Fotovoltaik Solarzellen werden billiger und grüner
  2. Umweltschutz Swiss tankt bald klimaneutrales Kerosin
  3. Saubere Energie Strom aus dem Gewächshaus

Datenschutz: GPS-Ortung in Firmenwagen meist unzulässig
Datenschutz
GPS-Ortung in Firmenwagen meist unzulässig

Manche Firmen statten ihre Dienstwagen mit GPS-Sendern aus, einige machen das sogar mit Diensthandys. Solcherlei Überwachung ist meist nicht rechtens.
Von Harald Büring

  1. Schweiz Alles andere als ein Datenschutzparadies
  2. Alternativen zu Google Analytics Tools für Reichweitenanalyse datenschutzkonform nutzen
  3. Anonyme Kritik Glassdoor muss Nutzerdaten an Arbeitgeber herausgeben

IAA Transportation: Akku schlägt Brennstoffzelle
IAA Transportation
Akku schlägt Brennstoffzelle

Auf der IAA Transportation in Hannover wird deutlich: Wasserstoff und Brennstoffzelle spielen eine untergeordnete Rolle beim Gütertransport.
Ein Bericht von Dirk Kunde

  1. Zero DSR/X im Test Die andere Art der großen Tour
  2. Elektroautos Tesla erhöht Supercharger-Preise massiv
  3. Elektromobilität Reichweite und Nachhaltigkeit zählen bei Elektroautos