Boycott Systemd

Status
Für weitere Antworten geschlossen.
Ich denke, dass darktrym schon Recht hat. 1993 war NetBSDs Ziel die alte 4.4BSD-Codebasis so portabel wie möglich zu machen und alle denkbaren CPU- und Rechnerarchitekturen zu unterstützen. Das sicherlich auch vor dem Hintergrund, dass es damals völlig unklar war, welche der existierenden Architekturen sich schlussendlich durchsetzen würden. FreeBSD konzentrierte sich hingegen vollständig auf Intels i386-Architektur, entfernte die vorhandenen Portierungen und ihre Schnittstellen, richtete neuen Code hart auf i386 aus. Seine erste Portierung erhielt FreeBSD erst Jahre später mit Version 3.0 auf den DEC / Compaq / HP Alpha. Das waren schon sehr gegensätzliche Ziele, die es durchaus wert waren, in unterschiedlichen Projekten verfolgt zu werden.

Allerdings hat das Alles nicht mehr viel mit systemd zu tun. :)
 
Um noch mal kurz auf die "Choleriker" zurückzukommen - wenn etwas bewegt werden soll oder muß, dann braucht es solche Persönlichkeitsstrukturen, wie Lennart, Theo, Linus und auch z.B. Steve Balmer. Die sehen ihr Ziel und tun alles, um da hin zu kommen und lassen sich auch nur selten ablenken oder gar umleiten.
 
Ich kann mir halt schon vorstellen, dass es eine gewisse Charismatik bedingt, um in grösseren EDV/IT-Projekten Neuerungen durchzusetzen.
Man denke da nur schon an die Herren Watson & Aiken bei IBM in den 40er Jahren (Mark I.; Dezimalsystem, satt binär).
Wer's geschafft hat, hintelässt halt mehr als eine Fussnote.

Und vielleicht auch weil sich Software (& die entsprechenden HardwareProdukte) immer in Entwicklung benfinden, schwebt stets ein Hauch von Pioniergeist darin, zumindest scheint er ab und zu aufzublitzen.
Bis hin dazu, dass sich Menschen ja auch mit Technik identifizieren.

Doch nur der Wille neue Software zu implementieren reicht halt nicht. Da entstehen insbesondere in grösseren Projekten auch schnell mal Konkurrenzen - oder auch unter ihnen. Neue Software kann sich schliesslich nicht etablieren, sondern braucht sich zuerst schon mal innerhalb des Projekts durchzusetzen bzw - die beteiligten Protagonisten.
Typsich schneint mir auch dass Anwendersoftware nicht demassen polarisiert wie systemspezifische/systemnahe.
vi & emacs waren diesbezüglich wohl eher eine Ausnahmeerescheinung.

Aber was ärgert euch an systemd am meisten? Die Qualität, die grundsätzliche Idee (Optimierung der StartProzesse) dahinter oder die Entscheidung sich vom unixklasischem SysVinit zu entfernen inkl der Linux-Bindung, die Lizenzierung?
Die Person/en dahinter alleine kann's ja nicht sein.

Oder würde man solcher Art Software tatsächlich auch aus ethischen Gründen ablehnen?
 
Mich ärgert nichts daran, es betrifft mich ja nicht. Täte es das, würden mich v.a. "Qualität" (cf. CVE) und Verzahnung mit sämtlichen Systemteilen stören.
 
Mich stört die Mentalität dahinter! Was systemd funktioniert nicht bei euch? Euer Problem! Hinter mir die Sinnflut! Friss oder stirb! Und jetzt muss der liebe Lenny noch die Gentoo Com. indirekt angreifen, nur weil diese sich gegen systemd stellen und halt doch zeigen, dass es ohne geht.
 
Ich weiß nicht, welches Problem damit eigentlich gelöst werden soll. Ich habe noch nie - weder unter GNU/Linux noch unter FreeBSD - Probleme mit irgendeinem init-System gehabt. Und wenn, dann ist es sicherlich nicht förderlich, daraus so einen Monolithen zu machen, statt wie bisher ganz einfache Shellskripte die Arbeit machen zu lassen. Der Typ hat meines Erachtens eine Neurose.

Rob
 
KobRheTilla schrieb:
Ich weiß nicht, welches Problem damit eigentlich gelöst werden soll. Ich habe noch nie - weder unter GNU/Linux noch unter FreeBSD - Probleme mit irgendeinem init-System gehabt
Zum Vergrößern anklicken....
foxit schrieb:
Was systemd funktioniert nicht bei euch? Euer Problem! Hinter mir die Sinnflut! Friss oder stirb! Und jetzt muss der liebe Lenny noch die Gentoo Com. indirekt angreifen, nur weil diese sich gegen systemd stellen und halt doch zeigen, dass es ohne geht.
Zum Vergrößern anklicken....
Die Betroffenen werben ja u.A. damit, dass auch die Konfiguration leichter werden sollte. Ist das also abstrus?

Wie sieht's bei Slackware aus? Bei Gentoo soll's ja immerhin optional sein. Arch soll es auch schon drin haben. Vermute, wenn dann die letzten "konservativen" Distributionen umgestiegen sind, dann . . . na ja.

CrimsonKing schrieb:
Mich ärgert nichts daran, es betrifft mich ja nicht. Täte es das, würden mich v.a. "Qualität" (cf. CVE) und Verzahnung mit sämtlichen Systemteilen stören.
Zum Vergrößern anklicken....

Dünkt mich verständlich. Und dahin soll die Reise wohl auch gehen.

War wohl launchd Vorbild? Steht ja unter Apache.
 
KobRheTilla schrieb:
Ich weiß nicht, welches Problem damit eigentlich gelöst werden soll.
Zum Vergrößern anklicken....

SysVinit hat einige Probleme, die einem je nach Anwendungsfall ganz schön beißen können (siehe auch unten):
The good and bad of the System V init system
Want to start a service during boot-up?

Was systemd richtig macht (was nicht heißt, dass es alles richtig machen würde):
Things that systemd gets right

KobRheTilla schrieb:
Ich habe noch nie - weder unter GNU/Linux noch unter FreeBSD - Probleme mit irgendeinem init-System gehabt.
Zum Vergrößern anklicken....

Ich wünschte, das könnte ich auch behaupten. Mit SysVinit ist auch im Jahre 2014 immer noch kein zuverlässiges Überwachen und Beenden von Diensten möglich, ohne üble Bastellösungen zu betreiben.
Wenn hinter der PID in der PID-Datei inzwischen ein anderer Prozess steckt, weil der ursprüngliche Dienst abgestürzt ist und die PID neu vergeben wurde, wird halt der unbeteiligte Prozess fröhlich beim Dienst-Neustart abgeschossen. :eek:
Ich kann natürlich Horden von 3rd-Party-Software installieren, habe damit aber die Büchse der Pandora geöffnet.

KobRheTilla schrieb:
Und wenn, dann ist es sicherlich nicht förderlich, daraus so einen Monolithen zu machen, statt wie bisher ganz einfache Shellskripte die Arbeit machen zu lassen.
Zum Vergrößern anklicken....

Das Problem ist: einfache Shellskripte machen die Arbeit eines Init-Systems nur unzureichend. Dadurch entsteht viel Komplexität an anderer Stelle.

Wenn mein Init-System nicht einmal den Status eines Dienstes zuverlässig bestimmen kann, muss ich das an anderer Stelle mit wesentlich mehr Aufwand, Fehleranfälligkeit und Wartungsaufwand machen. Sobald ich essentielle Dinge wie Monitoring, (automatischer) Neustart von Diensten oder Abhängigkeiten zwischen Diensten betrachte, sieht es mit SysVinit zappenduster aus. Aus vermeintlich einfachen Shellskripten werden dann ganz schnell Monster.
 
Slackware nutzt BSD Init, ich vermute die Slackware-Macher und -Nutzer verstehen den Nutzen von systemd genauso wenig wie die meisten BSDler.
 
Jammerei über systemd schafft keine Alternativen. Ist vielleicht auch gar nicht mehr erforderlich.
Es geht problemlos auch ohne BSDs im "Bereich Desktop".
 
CrimsonKing schrieb:
Nö.
Zum Vergrößern anklicken....

Man sieht ein paar Patch-Releases in den letzten 3 Monaten und vorher 3,5 Jahre Funkstille. Ist runit schon so rund, dass es schon das nächste Init-System sein sollte (und irgendwie hat's keiner gemerkt) oder was geht dort tatsächlich vor? Ich konnte kein aktuelles Source-Code-Repository finden, in dem man die Aktivität bei runit verfolgen könnte (freecode ist tot, letztes Release von 2009).
 
runit hat halt kein so fettes (ich schreibe bewusst nicht "gutes") Marketing. ;)
 
grogolz schrieb:
Jammerei über systemd schafft keine Alternativen. Ist vielleicht auch gar nicht mehr erforderlich.
Es geht problemlos auch ohne BSDs im "Bereich Desktop".
Zum Vergrößern anklicken....

Wie meinen?
Es geht doch auch problemlos ohne systemd und/oder Linux im Desktopbereich.

Dieses Gehampel, daß Linux super für den Desktop wäre ... 1,6% gegenüber ca. 90% Microsoft und immerhin 6,38% OS X. Systemd wird das nicht ändern.
 
Eben. Linux ist im Desktopmarkt eine Nieschenerscheinung. Wer kein Windows nutzt und produktive Desktops will der setzt auf Macs. Der Linux-Sektor ist zu zersplittert und eben zu volatil um sich im Desktopbereich wirklich durchsetzen zu können. Systemd hier als Lösung vorzubringen ist ein Schrauben an der völlig falschen Stelle.

Die 3 Sekunden schneller booten machen Linux für den Desktop nicht interessanter, aber die weitere Versplitterung in den Distributionen und die Probleme die diese Grundlegend Umstellung mit sich bringen machen es im Gegenzug deutlich unattraktiver als Produktivsystem. Das ist zumindest meine Meinung.
 
Nein. systemd sieht eindeutig nach Desktop-Ideen aus. Wer um Gottes Willen hat Lust auf Uhrzeit-Änderungsdaemon? Oder Locale-Änderungsdaemon? Damit sowas sichergestellt wird, dass Applikationen auch mitkriegen, dass eine Änderung passiert ist. Das ist doch zu nichts nutze außer dafür dass es scheinbar konsistent auf dem Desktop ist.

Niemand, der heil im Kopf ist würde so etwas abstruses auf dem Server machen. Einen anderen Daemon/Dienst interessiert es nicht, dass ein Nutzer sein Locale gewechselt hat. Auf dem Server hat man auch kein Interesse ein systemd-Feature zu nutzen, bei dem Dienste im Kreis neugestartet werden, falls sie ausfallen. Wenn ein Dienst ausfällt hat das nämlich einen Grund, der untersucht werden muss. Beim Desktop ist das für DAUs, die nichts vom System verstehen schon ok, so ein Windows-like Verhalten zu emulieren (kennt jeder: nach dem Explorer-Crash verschwindet kurz die Leiste unten und dann erscheint sie wieder nachdem der Explorer nochmal gestartet wird).
 
Guten Morgen!

Ich folge dieser Diskussion mit großem Interesse und würde gerne 2 kleine Fragen einwerfen..
Zum einen würde mich interessieren, ob Theo tatsächlich plant systemd zu implementieren und dann, falls dem so wäre, ob daraus nicht auch eine erhöhte Gefahr besteht, dass es auch FreeBSD treffen könnte?
 
Theo möchte sicherlich nicht systemd in OpenBSD einführen. Sie sehen dort aber die Notwendigkeit eine "Anschlußstelle" zu bieten, an die sich systemd-verlangende Programme andocken können.
Wenn das auf OpenBSd funktioniert, wird das IMHO auch auf FreeBSD portiert werden, wenn es da denn einer braucht.
 
Schnittstellen implementieren heißt ja nicht Systemd nachbauen.

Edit: Peterle war schneller.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben