>>78957>Alles ist eine Datei, es gibt nur einen Root, ein Prozeß ist ein Prozeß, Dateiberechtigungen sind einfach gestrickt usw.
Das klingt alles ganz toll, aber in der Praxis gibt es dann:
- Synchrone E/A mit "Get a byte, get a byte, get a byte byte byte", ein wirklich gutes Modell gab es erst mit io_uring
- So etwas wie
fork() will wirklich niemand haben, nach dem Forken erst mal alles schließen? Man wollte doch nur einen neuen Faden anlegen, und nicht gleich den ganzen Küchensiphon dazu. Gab es dann mit
clone().
- Dateiberechtigungen sind schön und gut, aber was ist mit Berechtigungen bzgl. Nicht-Dateien? Koffer im Punkt: Man will in den iptables nur bestimmte Ports für bestimmte Prozesse erlauben. Da wurde es erst mit cgroups besser.
>Registry Keys
Was ist der Linux-Weg, um Konfigurationsdaten hierarchisch abzulegen, und dabei
- Binärdaten
- atomare Änderungen
- starke Typisierung
- unterschiedliche Berechtigungen pro Konfigurationseintrag
- uniforme API für Änderungen, egal welche Konfigurationsdatei
erlaubt? Die Registry wurde gerade erschaffen, weil Microsoft keinen Bock mehr auf INI-Dateien hatte. Problem ist halt, dass es in der Regel nur einen Registry-Hive gibt, in den alle Programme alles zumüllen. Hätte jedes Programm seinen eigenen Hive, könnte man ihn einfach löschen, und der Müll des einen Programms wäre weg.
>Group Policies
Sind halt "systemweite Konfiguration", wie man es auch unter Linux hat, dort nur mit Textdateien in /etc oder Dotfiles oder sysctl.
Problem ist eher, dass die Group Policies in Domänen im Netzwerk verbreitet und auf den Rechern forciert werden. Wenn der Domänen-Kontrolleur Schlechtware ausliefert, hat jeder Rechner die Schlechtware. Das gleiche gilt unter Linux, wenn der Ansible-Servierer hackiert wurde.
t. Linux-Nutzer seit 15 Jahren, kein Winzigweich-Lüfter