Boycott Systemd

Status
Für weitere Antworten geschlossen.
Niemand bestreitet, dass es problemlos ist, wenn alles funktioniert. Der Wert misst sich daran, wie gut man damit zurechtkommt, wenn etwas _nicht_ funktioniert.
Sicherlich, aber es gibt immer etwas was funktionieren muss. Und wenn etwas nicht funktioniert ist frühzeitiges logging und networking von Vorteil. Wir werden sehen wie sich das in der Praxis bewährt und was da tatsächlich an evtl. Problemen entsteht...
 
Solange logind, journald und weiß der Geier nicht ohne Systemd lauffähig sind, sind das nicht Teilprojekte sondern Systemd-Bestandteile. Und seit wann gehört zum Dienstmanagement die Neugenerierierung der Config-Files, udev, dbus-Client, Webserver...?
 
Solange logind, journald und weiß der Geier nicht ohne Systemd lauffähig sind, sind das nicht Teilprojekte sondern Systemd-Bestandteile

Äh, falsche Richtung? Die Teilprojekte laufen nicht ohne systemd, ja, aber systemd läuft ohne die Teilprojekte, mal von journald abgesehen.

Projekte hängen am Init-Dienst ja, aber der Init-Dienst hängt nicht an ihnen. Und es kann einem doch herzlich egal sein, ob jemand einen Zeitserver schreibt der systemd benötigt. Das nimmt dir weder ntpd noch openntpd weg.
 
Mal abgesehen davon dass die Dienste alle mitausgeliefert werden, es gibt keine Pakete. Optional ist hier nur die Möglichkeit der Nutzung, man nur hoffen dass da keine impliziten Abhängigkeiten existieren.
 
Das sind so Banale Dinge, wie das man sich nicht mal darauf einigen konnte, in welcher Datei der Hostname gespeichert wird.
Muß man sich da einigen?
Es gibt ein Binary mit dem namen hostname im Pfad, das den Hostnamen ausspuckt, seit 4.2BSD. Und in der C-libary gibt es die Funktion gethostname (Teil von IEEE Std 1003.1-2001 (``POSIX.1'')).

So gesehen besteht keinerlei Grund eine bestimmte Datei parsen zu wollen, nur weil man oder ein Programm den Hostname herausfinden will. Sicher, es gibt bestimmt Programmierer die das lieber selber Programmieren, anstatt eine definierte Schnittstelle oder vorhandene Lib zu verwenden. Aber da wären wir wieder bei systemd und dem dort um sich greifenden nih-Syndrom
 
Teilprojekte, Module anderer Ordner im Source-Tree... alles nur Namen und leicht andere Struktur. Sie hängen zur Laufzeit nicht zusammen und das ist was zählt. Der Rest ist Alu-Hut-Denken und nicht zielführend. systemd ist keine Verschwörung...

Man kann auch Sachen die man nicht mag objektiv betrachten und sich an die Fakten halten statt sich irgendwas auszudenken. Man sollte sich meiner Meinung nach nicht hinter einer Wand verstecken und sämtliche Entwicklungen der anderen Systeme ignorieren oder beschimpfen, sondern nachgucken was man davon lernen kann.

Mir ist klar, dass gerade die ältere Generation ihre Systeme nicht geändert haben wollen "weil das ja schon X Jahre so läuft", aber dann braucht man sich nicht wundern wenn man irgendwann überholt wird. Das ist dann wie mit den Assembler Leuten die sich über C aufgeregt haben die wiederum sich über C++ aufgeregt haben, die wiederum sich über Java aufregen...
 
Es gibt ein Binary mit dem namen hostname im Pfad, das den Hostnamen ausspuckt, seit 4.2BSD. Und in der C-libary gibt es die Funktion gethostname (Teil von IEEE Std 1003.1-2001 (``POSIX.1'')).
Gibt es auch ein "sethostname"? Wie willst du den Hostnamen auf 100 Distributionen setzen? Das gehört auch dazu und wird von systemd übernommen. Weiter ist es auch möglich eine "LOCATION" zu definieren. Ganz praktisch, wenn man wissen will, wo sich der Server eigentlich im Rack/Standord befindet.
 
Meinst Du so etwas?

Code:
$ man hostname
HOSTNAME(1)  General Commands Manual  HOSTNAME(1)

NAME
  hostname - set or print name of current host system

SYNOPSIS
  hostname [-s] [name-of-host]

DESCRIPTION
  The hostname utility is used to set or print the name of the current
  host.  If no argument is given, the name of the current host is printed.

  The host name can be set by the superuser either by specifying
  name-of-host, or by supplying a myname(5) file, which is used at system
  boot time by netstart(8) to initialize the hostname.

  The options are as follows:

  -s  Trims off any domain information from the printed name.

SEE ALSO
  domainname(1), gethostname(3), myname(5), hostname(7), netstart(8)

HISTORY
  The hostname utility appeared in 4.2BSD.

OpenBSD 5.8  January 24, 2011  OpenBSD 5.8

oder diese hier:

http://www.gnu.org/software/libc/manual/html_node/Host-Identification.html
 
Mich interessiert nicht, ob der Lennart höflich oder unhöflich ist. Das ist doch irrelevant, wenn jemand gute Arbeit macht. Ihr seid doch nicht alle plötzlich auf dem PC-Trip, wie die Bekloppten im Netz zur Zeit?

Was wichtig ist, dass Software einen gewissen Grad an Portabilität anbietet, insbesondere wenn sie zentraler Natur ist. Lennart hat aber eindeutig durchscheinen lassen, dass er absichtlich alles so gestalten will, dass es nur auf Linux läuft (und noch nicht einmal das... sogar einige Linux-Distributionen haben bereits systemd aufgegeben). Das ist ein konkretes Ziel und das wird von mir kritisiert. Es ist kein Metagespräch, es ist kein persönlicher Angriff. Es ist einfach Kritik an seiner Arbeitsweise, die Kompatibilität zwischen Systemen zerstört, die ich für eine sehr gute Idee halte.

Dass das allerdings auch dumm ist, was er gemacht hat, ist auch die Konsequenz daraus. Aus Nichtportabilität ergeben sich Fehler, die nur schwer auszumerzen sind und mit der Zeit erst in der Software entdeckt werden. Es gibt deswegen konzeptionelle Probleme, schwere Bugs und eine Masse von kleinen Problemen. All das würde schon alleine durch Portabilität (wegen der Techniken, die dabei in Gebrauch sind) gemildert werden. Konzeptionelle Probleme kann man leider nur durch offene Diskussion angehen. Das machen sie aber auch nicht.

Alles in einem: es ist einfach ein Ärgernis für alle.
 
Es ist nur halt schwierig etwas portabel zu gestalten, wenn nur ein System die nötigen Features hat, um dein Konzept umzusetzen.

Es fußt nunmal alles auf cgroups vom Linux Kernel und wenn ich das richtig sehe, dann hat kein anderes System etwas äquivalentes.

Und die Aussage "Software so schreiben, dass sie nur Linux läuft" ist eher missverständlich. Seine Aussage war eher, dass er es satt hat sich mit Systemen rumzuschlagen die Linux meilenweit hinterherhinken und sich lieber darauf konzentriert das weiterentwickelte System zu verbessern. Wie schon gesagt... hat Xorg auch gemacht und die *BSDs haben nachgezogen. Das werden sie bei cgroups wohl dann auch müssen.

Das die allgemeine Code-Qualität zu wünschen übrig lässt, gut, da ist systemd nicht das einzige Projekt.
 
Ein neuer CRE ist da. Knappe 3 Stunden mit Lennart Poettering.
Ich habe noch nicht reingehört, ist aber bestimmt interessant.
http://cre.fm/cre209-das-linux-system

Vielen Dank für den Hinweis. :cool:

Ich kann die Episode allen systemd-Befürwortern und -Gegnern nur wärmstens ans Herz legen. Wer in Anbetracht der knapp 3 Stunden das Vorgeplänkel (mit u.a. pulseaudio und ahavi) überspringen und direkt beim systemd-Teil einsteigen möchte, der sollte zur 50. Minute der Folge vorspulen.
 
Ich kann die Episode allen systemd-Befürwortern und -Gegnern nur wärmstens ans Herz legen.

Wozu? Wenn ich Befürworter bin, dann braucht mich niemand mehr zu überzeugen - zumindest nicht, wenn ich nicht auch noch missionarisch tätig werden soll. Was mich persönlich angeht, sagt der Source schon genug über das Projekt aus.

Seien wir doch alle mal ehrlich: Ist es nicht enttäuschend, dass die selben Mechanismen, welche das Grundübel aus Redmond zum "Erfolg" verholfen haben, auch mit Open Source funktionieren? Ist es nicht erstaunlich, wieviel Mist man zu schlucken bereit ist, weil man die Bequemlichkeit von Distributionen oder graphischen Benutzeroberflächen nicht aufgeben möchte?

Aber der Käs' ist gefressen. Alternativen gibt es wenige und nur im semiprofessionellen Bereich - zumindest für Linuxer. Beruflich werden viele lernen müssen, mit dem Unfug umzugehen. Da unterscheidet sich Linux nicht mehr von Windows. Aber wer hat denn schon den Anspruch, dass die Arbeit Spaß machen muss?
 
Ist es nicht enttäuschend, dass die selben Mechanismen, welche das Grundübel aus Redmond zum "Erfolg" verholfen haben, auch mit Open Source funktionieren?
Tja, noch vor 10 Jahren hat man in der Linux-Community laut geschrien, dass Microsoft die "Standards" einfach festlegt und nicht mal dokumentiert. Alle anderen hatten sie einfach zu fressen, was gar nicht so einfach war. Erkennt man da etwa Parallelen? :)
 
Zuletzt bearbeitet:
Vor 10 Jahren hat man sich auch noch als root angemeldet, um sich zu einem neuen WLAN zu verbinden und das unter dem Deckmantel "das ist viel viel sicherer" hingenommen/befürwortet. :D

Aber lustigerweise haben es die Meisten dieser undokumentierten "non-Standards" dazu gebracht die portabelsten Sachen überhaupt zu werden. Also mal so Kram wie FAT, NTFS oder SMB. Ist halt die Frage wie viel Innovation in reinem Open Source steckt. Ich mein, ist ja auch klar. Die meisten Leute mit guten Ideen machen lieber ein StartUp auf und hoffen auf die Millionen. Der reine Open Source Innovator kriegt eines in die Fresse, weil er XYZ nicht beachtet hat. ;)

Ich will damit jetzt nicht Poettering nicht als großen Innovator hinstellen (schon alleine wegen Pulseaudio nicht xD), aber ich bin auch kein Fan davon wenn Jahre nichts passiert "weil ja alles geht". Am Meisten aufgefallen ist mir das damals beim Ports-System von FreeBSD... man kommt von Linux oder OS X/macports zu FreeBSD und hört überall was vom tollen Ports System und es sei super gut pi pa po und dann guckt man sich das an und denkt sich: "WTF? Wurde ich verarscht?" Mittlerweile gibt es ja einen halbwegs vernünftigen Paket-Manager, aber die Pakete sind weiter noch recht suboptimal in ihren Default-Einstellungen. Mal als ein Beispiel unter Vielen: Blender, welches wegen "ab und zu baut es nicht" ohne Cycles Renderengine ausgeliefert wird. Oder auch, dass der Wechsel von Major-Versionen, z.B. PHP, recht umständlich ist bzw. werden kann. Oder auch der teilweise problematische Mix von Base-Version und Port-Version.

Gerade für Anfänger kann sowas sehr schnell den Frust soweit anheben, dass er dann doch wieder geht. Und darum kriege ich immer einen ziemlichen beiß-reflex, wenn ich so Sachen höre wie: "Geht doch alles", "das brauche ich nicht", etc. Ich würde FreeBSD auch gerne mehr Verbreitung wünschen, aber man betritt hier auch sehr innovationsfeindliches Territorium.
 
Am Meisten aufgefallen ist mir das damals beim Ports-System von FreeBSD... man kommt von Linux oder OS X/macports zu FreeBSD und hört überall was vom tollen Ports System und es sei super gut pi pa po und dann guckt man sich das an und denkt sich: "WTF? Wurde ich verarscht?" Mittlerweile gibt es ja einen halbwegs vernünftigen Paket-Manager, aber die Pakete sind weiter noch recht suboptimal in ihren Default-Einstellungen. Mal als ein Beispiel unter Vielen: Blender, welches wegen "ab und zu baut es nicht" ohne Cycles Renderengine ausgeliefert wird. Oder auch, dass der Wechsel von Major-Versionen, z.B. PHP, recht umständlich ist bzw. werden kann. Oder auch der teilweise problematische Mix von Base-Version und Port-Version.

Gerade für Anfänger kann sowas sehr schnell den Frust soweit anheben, dass er dann doch wieder geht. Und darum kriege ich immer einen ziemlichen beiß-reflex, wenn ich so Sachen höre wie: "Geht doch alles", "das brauche ich nicht", etc. Ich würde FreeBSD auch gerne mehr Verbreitung wünschen, aber man betritt hier auch sehr innovationsfeindliches Territorium.

Das liegt aber in erster Linie an den Anfängern von Heute.
Ich erinnere mich durchaus an die Zeit des MSDOS Gefrickels mit Treibern und Speicher und was weiß ich nicht noch alles, was man damals machen mußte, damit man seine Kiste überhaupt mit allem starten konnte. Da waren die ersten Schritte zu BSD relativ einfach. Es war sehr gut dokumentiert und lief auf SCSI-Platten "rock solid" und ich konnte Dinge damit machen, die ich unter MS* nicht so ihne weiteres machen konnte.

Heutzutage schaut mich mein Sohn immer an, als wäre ich plötzlich aus irgendeiner Zeitreise bei ihm notgelandet, wenn ich einen X-Terminal aufmache und da irgendwas reintppen muß. Dann verdreht er die Augen und geht ...
Ein anderer junger Teenager, der sehr pfiffig war und immer was "mit Computer" machen wollte, war schon mit einem Standardubuntu völlig überfordert und angenervt. Vorherige Versuche mit FreeBSD oder anderen Linux-Distributionen waren "zu kompliziert" ...

"Innovationsfeindlich" würde ich unsere BSDs nun auch nicht nennen wollen. Allerdings liegen die Innovationen weniger in bunten Oberflächen und Magie, worüber man streiten kann, aber nicht muß. IMHO
 
Heutzutage schaut mich mein Sohn immer an, als wäre ich plötzlich aus irgendeiner Zeitreise bei ihm notgelandet, wenn ich einen X-Terminal aufmache und da irgendwas reintppen muß. Dann verdreht er die Augen und geht ...
Ein anderer junger Teenager, der sehr pfiffig war und immer was "mit Computer" machen wollte, war schon mit einem Standardubuntu völlig überfordert und angenervt. Vorherige Versuche mit FreeBSD oder anderen Linux-Distributionen waren "zu kompliziert" ...

Sowas begegnet man aber nicht dadurch, dass man alles noch einfacher macht. Der Schlüssel ist, dass alles _konsistent_ ist, dann ist es auch einfach erlernbar. Wenn alles vollautomatisch läuft und man nur hier und da klicken muss, lernt man nichts. Dann ist man User und kein Admin.
 
Ich würde FreeBSD auch gerne mehr Verbreitung wünschen, aber man betritt hier auch sehr innovationsfeindliches Territorium.
Auf der anderen Seite muss man fragen, was uns die sogenannten Innovationen gebracht haben. Zwischen 2000 und 2005 lagen die 5 dunklen Jahre, in denen FreeBSD das System technisch grundlegend umgebaut hat. In Rahmen dessen wurde FreeBSD deutlich näher in Richtung Linux gerückt, hart gesagt wollte man damals wie Linux sein. Mit dem Ergebnis, dass die eigene Zielgruppe stinksauer war und man von den Linuxern nur mitleidig angeschaut wurde. Die hatten ja ihr Linux und kein Interesse zu einem Linux-Klon zu wechseln. FreeBSD ging es von dem Punkt an wieder deutlich besser, als man Linux einfach Linux sein ließ und seinen Weg ging.

Das soll nun nicht heißen, dass man gar nichts verändern sollte. Im Gegenteil. Wir haben für FreeBSD 11.0 einige hochinteressante Neuerungen. Aber wir sind nun einmal ein konservatives System für eine konservative Zielgruppe und verhalten uns so. Änderungen werden gemacht, wenn sie sinnvoll erscheinen und man achtet sehr auf POLA. Warum auch nicht? Das tolle System mit einem beständigen Fluss an Neuerungen gibt es bereits. Linux halt. Neuerdings ist nun noch NextBSD hinzugekommen, die eine ganz andere Vision eines modernen Unix umsetzen möchten. Man wird sehen, wie weit sie damit kommen und ob sie Erfolg haben werden.

Im Übrigen frage ich mich seit mindestens 15 Jahren, wieso FreeBSDler eigentlich immer Minderwertigkeitskomplexe haben. Wieso es immer heißt "man müsste" oder "Linux hat". Mir gefällt die Weltanschauung der OpenBSDler da wesentlich besser. Sie gehen ihren Weg, ohne ständig zu lamentieren, dass das Gras woanders grüner sein könnte. Wem OpenBSD gefällt, der kann es nutzen. Wem es nicht gefällt, kann ja woanders hingehen. Punkt. Die Weltherrschaft haben sie damit ebenso wenig wie wir FreeBSD errungen, aber wesentlich schlechter als uns geht es ihnen auch nicht.
 
Naja, meiner Meinung nach krankt FreeBSD gerade ziemlich stark an seinen vielen Möglichkeiten das Gleiche zu tun, nur damit sich für andere nichts ändert. Mal als Beispiel ein Paket aus den Ports zu installieren. Genauso auch die zig Varianten eine Jail anzulegen. Oder auch das Basissystem zu aktualisieren.

Da hat man dann den großen hochkonservativen Bereich, der alles so macht "wie das schon immer war"... das ist meist der komplizierte und oft langsamste Weg. Als Ergebnis dessen hat auch dann kein Interesse daran bzw. kein Auge darauf, dass sich die schnellen einfachen Wege verbessern. Also statt an den, ich sag mal, modernen Wegen zu arbeiten und diese zu verbessern, klammert man sich an die alten Wege. Die Weiterentwicklung der modernen Wege lahmt dann und schläft ggf. ein.

Als Beispiel mal das Tool "freebsd-update", welches eher stiefmütterlich behandelt wird und bei Benutzung ein Seiltanz ist. Ich sehe dort eher wenig Interesse der Entwickler und auch Nutzer das zu verbessern, sondern es wird auf das Source-Update verwiesen. Das heißt man muss gar nicht über den Tellerrand hinweg schauen, um Innovationsfeindlichkeit zu erkennen. Selbst beim Tooling im eigenen System stößt man auf Widerstand bzw. Desinteresse.

Dann erkennt man auch ganz leicht, dass der große Unterschied zwischen FreeBSDs Jails und das gerade boomende Linux Docker einzig und allein das Tooling ist.
 
Muß man sich da einigen?
Es gibt ein Binary mit dem namen hostname im Pfad, das den Hostnamen ausspuckt, seit 4.2BSD. Und in der C-libary gibt es die Funktion gethostname (Teil von IEEE Std 1003.1-2001 (``POSIX.1'')).

ich habe befürchtet, dass jemand das hostname binary auspackt. Das sollte auch nur ein Beispiel sein - wir können auch die Netzwerkkonfiguration als Beispiel nehmen. /etc/sysconfig/network vs. /etc/network/interfaces und was es da sonst noch an Pfaden gibt. Von der Syntax der Datei mal ganz zu schweigen.

Will damit nur sagen: nicht mal auf die einfachsten Dinge kann man sich im Unix Lager einigen - und hier würde sich nun wirklich niemand einen Zacken aus der Krone brechen, das einfach mal einheitlich zu machen. Solche Sachen würden es vielen Entwicklern einfacher machen und wirkliche Portabilität schaffen. Da will SystemD hin: Einen definierten Ort an dem Dinge in einem definiertem Format gespeichert werden. Entweder du implementiert das oder du bist raus. Finde ich aber ganz in Ordnung. Was passiert, wenn man darüber Diskutieren will anstatt einfach Regeln vorzugeben, sieht man ja in diesem Thread. Die Diskussion ist absolut legitim, aber zu einem Ergebnis kommen wir da nicht :-)
 
Sowas begegnet man aber nicht dadurch, dass man alles noch einfacher macht. Der Schlüssel ist, dass alles _konsistent_ ist, dann ist es auch einfach erlernbar. Wenn alles vollautomatisch läuft und man nur hier und da klicken muss, lernt man nichts. Dann ist man User und kein Admin.

Das ist zwar völlig offtopic, aber was ich damit beispielhaft sagen wollte, ist daß es die meisten jungen Menschen heute nicht zum admin treibt, sondern zum DAU. Es besteht bei vielen scheinbar noch nicht mal der Ansatz dazu etwas anderes als DAU sein zu wollen und wenn die Flachpfeife von Admin das nicht hinkriegt, dann ist der halt ein DAA (dümmster anzunehmender Admin).
Alles andere ist zu anstrengend, da müssen die chillen und twittern und ins Gesichtsbuch gucken.
 
..., ist daß es die meisten jungen Menschen heute nicht zum admin treibt, sondern zum DAU.
Diese Klagen hört man seit man über das Generationenverhältnis nachgedacht hat, - von Griechen, Römern und was da noch folgte. Seltsamerweise ging es mit der Zivilisation dennoch weiter. ;) Im übrigen ist das falsch was du sagst, das trifft bestenfalls auf einen Teil - vielleicht keinen kleinen - der Kohorte zu. End of OT.
 
Und trotz allem schreiben wir unsere Software nicht mehr in Assembler, wie soll man dann da noch die Arbeitsweise eines Prozessors verstehen...
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben