Boycott Systemd

Status
Für weitere Antworten geschlossen.
Was mich an systemd stört ist, dass
  • das KISS-Prinzip fundamental verletzt wird,
  • das Unix-Paradigma one-job-one-tool ignoriert wird (any-job-systemd)
  • und schließlich ein komplexer Daemon alle Aufgaben übernimmt, und so ein geschlossenes System auf Opensource basis gebaut wird
Das stört mich auch gewaltig und ich frage mich manchmal, warum sie systemd nicht gleich in den Kernel klatschen und KDE/Gnome + Libreoffice auch gleich dazu.
Außerdem stört mich die Überheblichkeit. Ich kann mich gibt daran erinnern, wie sie vor Jahren zu Recht auf MS eingedroschen haben, weil die ihre eigenen 'Standards' implementiert haben und offene Standards mehr o. weniger sabotiert haben. In meinen Augen tun sie jetzt nichts anderes mit systemd. Viele Projekte wollen systemd voraussetzen und durch seine enge Verbindung zu Linux wird das Portieren schwierig wenn nicht unmöglich. Nichts mehr davon übrig, was Unix ausmacht.
 
Wird denn seitens BSD schon so etwas wie ein systemd äquivalent geschaffen?

Project: Provide bsd-licenced, os-agnostic, dbus-api compatible systemd-{hostnamed,timedated,localed,logind} replacements.
Brief explanation: More and more desktop-level applications now depend on apis provided by linux's systemd. We need to have an equivalent to keep up with them.

Expected results: Working & seamless integration of those components as ports.

Knowledge prerequisite: C, D-BUS, perl.

Mentor: Landry Breuil landry@openbsd.org, Antoine Jacoutot ajacoutot@openbsd.org
 
Ist aber kein Superdienst der alles ansichreißt wie Systemd. Vor allem interessant ist logind, würden einigen Linuxer gerne verwenden wollen.
 
Logind Funktionalität ohne herausoperieren, was jetzt ohnehin keiner mehr machen wird, aus Systemd, weil's nun ein Defacto Standard ist.
 
Ich kann mich gibt daran erinnern, wie sie vor Jahren zu Recht auf MS eingedroschen haben, weil die ihre eigenen 'Standards' implementiert haben und offene Standards mehr o. weniger sabotiert haben. In meinen Augen tun sie jetzt nichts anderes mit systemd.

Auf welchen Standards hätte systemd denn aufsetzen sollen? :confused:
Die rasante Verbreitung von systemd liegt doch darin begründet, dass es für viele Problemfelder vor systemd gar keine Lösungen gab.

Viele Projekte wollen systemd voraussetzen und durch seine enge Verbindung zu Linux wird das Portieren schwierig wenn nicht unmöglich.

Sollte systemd ein so schlechtes Stück Software sein, müsste es ja kein Problem sein, vergleichbare oder bessere Funktionalität POSIX-kompatibel und leicht portierbar auf Basis von SysVinit (bzw. BSDinit) auf die Beine zu stellen?

Ansonsten sind die APIs von systemd portabel. Nichts hindert andere Betriebssysteme daran, die entsprechenden APIs zu implementieren oder - the Unix way - eine bessere Lösung auf die Beine zu stellen, auf die andere Projekte dann umschwenken.
 
Ich weiß nicht, ob ich das genauer wissen will.

Wissen ist immer besser als raten:

A new "systemd-timesyncd" daemon has been added for synchronizing the system clock across the network. It implements an SNTP client.

In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations.

The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd.
Quelle: [systemd-devel] [ANNOUNCE] systemd 213
 
Wissen ist immer besser als raten:

In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it.
Quelle: [systemd-devel] [ANNOUNCE] systemd 213
Ich bin von Anfang an davon ausgegangen, dass da nur ein Client implementiert ist, denn es stand ja ntp da und nicht ntpd.

Kann man nicht auch bei der Referenzimplementierung nur den client ntpdate (/usr/src/contrib/ntp/ntpdate) bauen?
Hier (freeBSD 10) kann ich zumindestens per ntp eine aktuelle Zeit holen, ohne den ntpd-Server zu starten.

Ich sehe keinen Grund dafür bei ntp(-client) die Prinzipien kiss und one-job-one-tool zugunsten von any-job-systemd zu verletzen.
 
Ich muss zugeben, dass ich es für sinnvoll halte auf den clients keine Server NTP Komponente laufen zu haben. Insbesondere nach der Geschichte mit den NTP Query Amplifcation Dings.

Aber ich bezweifele mal dass der systemd mist ordentliche Clock discipline macht. In dem Fall kann ich auch per Cron sntp/ntpdate aufrufen.
 
Nach dieser DHCP-Sache (man implementierte DHCP "schneller", aber leider auch ein wenig standardinkonform), ist zumindest ein wenig Skepzis angebracht. Und fefe soll sich mit dem Mailserver man nicht zu weit aus dem Fenster lehnen. Ein kleiner MTA würde dem Poettering-Oktopus wirklich gut stehen und wird garantiert irgendwann aus der schleimigen Software-Ursuppe steigen.
 
Als kleiner Anwender verstehe ich die Aufregung nicht. Es ist ein Linux-Ding und gut ist. Und wenn DEs davon betroffen sind, dann meide ich sie und gut ist, amen.
Ich denke die BSDs wissen es anders zu machen....und wenn sie es nachmachen bzw unbedingt implementieren wollen, na dann ist es so.
Zuviel KopfGedanken, genau wie xorg und wayland/weston, etc etc..... es sind Entwickler und die machen halt was sie wollen. War schon immer so.... also warum so viel Aufregung? Dinge gehen und Dinge kommen.... Und gerade die alten Hasen sollten das wissen, ne.

Chu
 
Ich frag' mich wie weltfremd diese Leute sind. Ihnen scheinen die existierende Systeme noch nicht komplex genug zu sein, als dass man nicht noch ein komplexe(re)s dazu erfindet. Und die Konsequenzen sind beliebig aetzend. OpenSSL laesst gruessen ...
Der naive und gutglaeubige Rechnernutzer mag denken, dass die Systeme mit der Zeit immer sicherer werden. Aber anstatt bestehende Software zu reviewen und zu debuggen, wird immer neuer Kram hingecodet und in die freie Wildbahn entlassen, obwohl er eigentlich 10 bis 20 Jahre abhaengen muesste, um einigermassen zu reifen. Wozu gibt es Entwicklerversionen, -distributionen? Aber wir sind doch nicht alle Alpha-Tester. Nein, danke!
Es ist einfach gruselig. Man kann nur hoffen, dass man nicht direkt neben dem Atomkraftwerk wohnt, welches gerade in die Luft geht, weil ein Bug in irgendwelchen Steuerungsanlagen von Blackhats ausgenutzt wurde. Softwareentwicklung ist kein Sandkastenspiel!
 
NUnd fefe soll sich mit dem Mailserver man nicht zu weit aus dem Fenster lehnen. Ein kleiner MTA würde dem Poettering-Oktopus wirklich gut stehen und wird garantiert irgendwann aus der schleimigen Software-Ursuppe steigen.
Sicher, jede Software wird solange weiterentwickelt, bis sie E-Mail "kann".
Aber vielleicht kann das ja auch erst der systemd-Nachfolger. *SCNR*

Als kleiner Anwender verstehe ich die Aufregung nicht. Es ist ein Linux-Ding und gut ist.
Nächste Frage: Wirrd es irgendwann problematisch, wenn Linuxsoftware wie Gnome, KDE, Apache, Samba, xfce und {X11|wayland|weston} systemd zwingend voraussetzt?
 
Die Frage, was systemd noch nicht kann, wird bald schneller zu beantworten sein ...
Schoen waer noch 'ne Datenbank (MySQL, PostgreSQL, MariaDB, LDAP, ...), die Problem-Reports, die der Webserver ausliefert, koennten mit Flash aufgepimpt werden, und dann will ich mein systemd auch anrufen koennen, damit es mir am Telefon seinen Status mitteilen kann und vielleicht noch die Lottozahlen der kommenden Ziehung ...


OK, OK, ich nehme gleich mein Beruhigungsmedikament ...
 
chaos, bitte komplette Nachricht lesen und zitieren.
DEs sollten egal sein. Da hat Upstream bzw BSD gute Sachen.
Bei Samba und Apache kann ich nicht mitreden, jedoch denke ich, dass zumindest Apache da seine Sache machen wird.

Der Chu
 
chaos, bitte komplette Nachricht lesen und zitieren.
Ich hatte sie durchaus ganz gelesen.

DEs sollten egal sein.
Irgendwann wird die Systemd-Macht die DEs in die Abhängigkeit zwingen. Auch einfachere Windowmanager werden folgen.

Da hat Upstream bzw BSD gute Sachen.
Ja, PCBSD hat wohl eine eigene DE angefangen. Wielange andere bestehende DEs/Windowmanager von systemd unabhängig bleiben, werden wir sehen. Systemd besteht aus eigner sicht ja auf einem Alleinvertretungsanspruch. Und genau dieser ist das Hauptproblem. Es darf keine Initsysteme außer Systemd mehr geben, aus systemd-sicht.
 
chaos, ich verstehe deine Meinung, aber im Ernst es gibt genug andere WMs, wobei ich dir Recht gebe, dass sie nachziehen. Deshalb bleibe ich bei TWM(1), zum Beispiel.
Unix-Philosophie - Einfach und gut. Schön bei der Kommandozeile bleiben. DAS ist der WEG.
Ich will nicht predigen. Aber so ist es.
Wenn GUI, dann schmal. Und da gibt es auch Sachen. Ohne systemd und dbus und HAL. Nicht umsonst haben wir in den BSDs makefiles und OPTIONS.
oder?

Gruß
Chu
 
Kann man nicht auch bei der Referenzimplementierung nur den client ntpdate (/usr/src/contrib/ntp/ntpdate) bauen?
Hier (freeBSD 10) kann ich zumindestens per ntp eine aktuelle Zeit holen, ohne den ntpd-Server zu starten.
Noch ja. Ein Blick in die man page von ntpdate sagt:
Note: The functionality of this program is now available in the ntpd(8)
program. See the -q command line option in the ntpd(8) page. After a
suitable period of mourning, the ntpdate utility is to be retired from
this distribution.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben