oreissig's Unix-Rant

[thosch97]

Im Übrigen schafft Gentoo das recht gut mit den Paketsubversionen, wenn die parallel installierbar sind ists meistens geslottet, z.B. sys-boot/grub:0 und sys-boot/grub:2 – wobei letzteres mit USE="-multislot" dann auch DEPEND="!sys-boot/grub:0" hat (d.h. wenn das Useflag multislot nicht gesetzt ist, heißen die Binaries grub-* anstatt grub2-* und GRUB Legacy kann nicht mehr installiert werden).
Gentoo ist aber nicht direkt ein Kackboon-Desktop-System.
Und durch die ganzen eclasses sind die ebuilds bei einfachen Paketen auch einfach, z.B. für einfaches CMake, Autotools, setup.py gibts dann inherit autotools und wie das heißt und damit hat mans im Prinzip schon.

[gandro]

Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht. Steht sehr viel ähnliches drin wie in diesem Thread. Er meint ebenfalls, dass der "Toolbox"-Ansatz, also Paket-Repositories, wo sich die User selber einen Werkzeugkkasten für ihre Verwendung zusammenstellen, der Realität nicht gerecht wird.

Grundthesen:

• Auf vielen Linux-Installationen in der Realität werden selten einzelne Pakete aktualisiert/installiert, sondern direkt gleiche ganze Builds ausgerollt (Workstation in Unternehmen/Schulen, Server, Embedded-Kisten).
• Benutzer wollen ein App-Model mit schnellen Releases, und nicht erst auf den nächsten Build/Release warten.
• Aktuelle Lösungsansätze (Ubuntu Apps, Docker, ChromeOS) lösen nur einzelne Teilprobleme.
  

Der Lösungsansatz der präsentiert wird ist dann relativ umfangreich und detailliert. Kern-Idee ist es aber das Dateisystem in Dateisystem-Images aufzuteilen, die dann einzeln kombiniert werden können.

Nebst Low-Level Dateisystem-Images von Distributionen soll es dann Framework-Images z.B. für GNOME geben. Und Vendors wie Mozilla können dann App-Images z.B. für Firefox bauen, die auf der GNOME-Runtime aufbauen, anstatt auf einer spezifischen Distribution.

Home-Verzeichnisse sollen auch so verwaltet werden. Es ist ein ziemlich umfangreicher Vorschlag, aber klingt definitiv interessant. Soll technisch auf btrfs aufbauen, benötigt also Mounting/Snapshotting/Subvoluming um den Sandbox-Ansatz umzusetzen. Und halt ordentliches IPC via kdbus, da das Dateisystem nicht mehr so einfach als Kommunikationsmittel missbraucht werden kann.

Trotzdem soll da ganze Legacy-kompatibel bleiben.

[s4ndwichMakeR]

Auja, ich liebe solche Threads (den inkorrekten Apostroph im Thread-Titel hingegen nicht).

Ich beurteile das ganze aus der Sicht eines gewissen Liebhabers der Unix-Philosophie und zugegebenermaßen auch leicht bis mittelstark religiös anmutender Abneigung gegenüber Windows, das muss ich eingestehen.

Insbesondere möchte ich auf das Config-Chaos eingehen. Ansich finde ich es ja nett, dass man unter Unix (Begriff hier allgemein stellvertretend für unixoide Systeme oder Linux-Distributionen) jede Software auch jenseits ihrer selbst mit einem Editor konfigurieren kann. Das schafft eine gewisse Einheitlichkeit. Diese hört aber bereits dann auf, wenn man feststellt, dass Software A ihre Konfiguration als ~/.foo ablegt, Software B als ~/.foorc, Software C ein eigenes Directory erstellt und Software D lieber irgendwo unter ~/.config/… geht. Aber das ist ja noch nicht das Schlimste. Software A verwendet XML (z.B. Pidgin), Software B verwendet ein Variable=Wert-Paar und Software C benutzt C-ähnliche Syntax mit geschweiften Klammern (z.B. nginx). Als vierte Variante seien noch doppelpunktgetrennte Werte à la /etc/passwd oder /etc/group genannt.

Diese Uneinheitlichkeit setzt sich auch als Nebenwirkung der Unix-Philosophie innerhalb der Software selbst fort. An sich ist es ja löblich, dass jede Software einen eigenen Zweck hat und ausschließlich diesen verfolgt. Oftmals ist man dadurch aber gezwungen, Software mit unterschiedlicher, also uneinheitlicher Bedienung zu benutzen – von unterschiedlicher Handhabung von Kommandoparametern bis hin zu uneinheitlichen Keyboard-Shortcuts in curses-Anwendungen. Manchmal gibt es --parameter mit einer zusätzlichen Abkürzung -p, manchmal aber auch -parameter oder in Anlehnung an tar einfach nur einen einzigen Buchstaben. Manche curses-Anwendungen mögen einen Buchstabentastendruck, manche möchten über F-Tasten gesteuert werden und wieder andere wollen eine Strg-Kombination.

Zum Softwareverwaltungsproblem: Wer ist modularer? Windows speichert eine Software mit ihren Bestandteilen an einem zentralen Punkt unter C:\Program Files. Unix flechtet die Software ins System ein. Tatsächlich hat die Windows-Lösung einen gewissen Reiz: Gehe ich in ein Unterverzeichnis unter C:\Program Files, weiß ich ganz genau ›Ich bin genau dort, wo alles ist, was mit der Software zu tun hat‹ und sehe die einzelnen Bestandteile und kann auch die Größe der Software beurteilen. Der Unix-Ansatz macht einen Paketmanager (insbesondere in Zeiten von Shared Libraries) unabdingbar. Man kann ihn als Hilfsmittel zur Softwareverwaltung sehen, aber auch als Versuch, irgendwie den Überblick über die Bestandteile des Systems nicht zu verlieren, also genau das nachzubilden, was im Design eines Windows-Systems von Haus aus im Dateisystem implementiert ist. Ich weiß nicht, ob mein Paketmanager seinen Job so erledigt, wie ich das möchte. Ich hoffe einfach drauf. Genauso wie ich bei einer Deinstallation einer Software unter Windows darauf hoffe, dass wirklich alle Spuren an allen Stellen beseitigt sind, denn dort wiederum entstehen mitunter Hinterlassenschaften in der Registry, im Startmenü und vielleicht noch an anderen Orten. Also eigentlich nimmt sich da nicht viel, oder?

[gandro]

(01.09.2014 09:13)gandro schrieb:  Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht.

Zusammenfassung von Golem ist jetzt Online: http://www.golem.de/news/lennart-poetter...08941.html

[mrshadowtux]

(01.09.2014 15:43)gandro schrieb:  

(01.09.2014 09:13)gandro schrieb:  Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht.

Zusammenfassung von Golem ist jetzt Online: http://www.golem.de/news/lennart-poetter...08941.html

Und noch mehr Unix-Grundprinzipien verhauen. Wenns so weitergeht, wechsle ich auf OpenBSD auf dem Desktop. Das hat ja inzwischen auch aktuelle Desktopumgebungen und macht son Scheiß nicht.

[oreissig]

(01.09.2014 15:47)mrshadowtux schrieb:  Und noch mehr Unix-Grundprinzipien verhauen.

warum sollten die gut sein?

[oreissig]

(01.09.2014 09:13)gandro schrieb:  Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht.

Interessant auch, dass er RPM/dpkg als build-tools bezeichnet, die man zum initialen Erstellen der images verwendet. Das erscheint mir auch etwas zu sein, was sich von der Komplexität von klassischen Paketmanagern lösen lässt.

[oreissig]

ich hab immer mal noch über das thema nachgedacht und komme an einem punkt nicht ganz weiter: ein kernpunkt meiner argumentation war das dynamische linken. was passiert, wenn man das einfach nicht macht? klick wenn man ein ganz normales linux-system mit unaufgeräumtem FS und wilden dependencies hat, die vom paketmanager verwaltet werden. reicht statisches linken aus, um blöde nebeneffekte zu vermeiden, die das system mit der zeit immer kaputter machen?

das problem dass jede distro ihre pakete selbst verwaltet und es keine portabilität zwischen den distros gibt wird dadurch auch nicht gelöst, aber wenn ich einfach ohne nachzudenken updaten kann und das system damit über jahre weiterläuft, wär das schonmal nett

[oreissig]

wow ich hab schoela heraufbeschworen

(05.09.2014 20:26)oreissig schrieb:  ein kernpunkt meiner argumentation war das dynamische linken. was passiert, wenn man das einfach nicht macht?

hab inzwischen mal noch die position von einem redhat-mitarbeiter gefunden:
Static Linking Considered Harmful

• "fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked." das ist wiederum genau der punkt, der dazu führt, dass man niemals was anderes als minor fixes ausrollen kann.
  "By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library." halte ich für unfug, dafür gibts repo-basierte paketmanager. wer nur das updatet, wo er selbst mitbekommt, dass es dort eine offene lücke gibt, ist eh grob fahrlässig...
• "Security measures like load address randomization cannot be used. [...] Fixed addresses (or even only fixed offsets) are the dreams of attackers." Das ist meiner Einschätzung nach ein valider Punkt, oder gibts da im Kernel inzwischen voodoo magic, die das trotzdem randomisiert? Prinzipiell hab ich ja nix gegen dynamisches linken, nur sollen sich Apps halt nicht gegenseitig in die quere kommen, wenn sie die selbe lib teilen.
• "more efficient use of physical memory" mag sein, da wärs mal interessant zu sehen wie viel das wirklich ausmacht. wenns jetzt irgendwie 50mb spart kann ich da auch drauf verzichten.
  kernel same page merging könnte ggf. abhilfe schaffen, aber das ist standardmäßig sicher nicht aktiv, oder?
• der Rest ist irgendwie zeugs, was mich als Nutzer nicht so richtig kümmert...
  

[gandro]

(Drepper und Poettering in einem Thread. Ich warte nur noch auf Ad Hominem )

ASLR und das limitiertere Tooling finde ich schon signifikante Nachteile. Die static linux Leute haben da natürlich ne andere Meinung zu: http://sta.li/faq

Die ganzen Steam-Spiele unter Linux machen ja eh den Kompromiss dass sie zwar dynamischen Linken, aber wie unter Windows einfach alle Bibliotheken selber mitbringen (gut, bei Spielen ist da eh häufig ein gepatchtes SDL mit dabei, von daher ist das nicht immer freiwillig).

Ich glaube auch nicht dass statisches Linken alle besprochenen Probleme löst, glaube da braucht es schon noch mehr Abkapselung.

Nachtrag: Same-Frame-Merging ist nicht standardmässig aktiv. Gibt da da auch Security-Bedenken, da es Sidechannel-Attacken erlaubt (man kann durch Timing-Attacken ziemlich zuverlässig rausfinden, ob bestimmte andere Binaries im RAM sind).