systemd, der nächste Horror für BSD?

Status
Für weitere Antworten geschlossen.
Mal schauen, ob Debian als Community das überlebt.

Ich erwarte mit Spannung die ersten Blogartikel, dass sich Debian-Maintainer dann mal lieber mit Gentoo (oder BSD...?) beschäftigen. :D

Sogar auf Phoronix, der ollen Ubuntu-Fancommunity, hagels es Kritik. Ich bin überrascht.
 
Zuletzt bearbeitet von einem Moderator:
BSD ist leichter verständlich. Für wen? Für den normalen Nutzer ist Verständlichkeit nicht von Bedeutung. Sein System muß funktionieren. Er will keinen Streß haben.
Und daher sollte es leicht verständlich sein.... ^^ 1. Damit der Entwickler/Distributor was solides anbieten kann und 2. damit der Anwender im eventuellen Problemfall dann doch noch Hand anlegen kann.

Es ist ja nicht so, daß ich von FreeBSD auf dem Desktop unbedingt weg will. Mittlerweile kann ich ganz gut (ist relativ) damit umgehen und mit fluxbox und diversen scripts kann ich auch auf Gnome und Konsorten verzichten. Wenn aber die Anwendungen langsam aber sicher den Bach runtergehen gibt es keine Alternative. Noch aber ist es nicht so weit.

Die Frage ist was man will und was man braucht, aber das wurde zu Hauf diskutiert. Solange normale Anwenderprogramme funktionieren ist das Ding durchaus "Desktop-Fähig". Wenn es natürlich keinen X oder X-Ersatz mehr gäbe der diese Programme darstellen kann wird es eng.

P.S. Man kann auch auf mehrere Posts in einem Antworten ;)
 
Warum also dafür ein neues Init-System anstatt dieser Software eine möglichst optimale Umgebung zu gönnen?

Es gibt reichlich Software, die ursprünglich mal unter einem der Unices lief, die es heute gar nicht mehr gibt.

Wenn mit dieser Software einer Millionen verdient, dann verdient der die nur deshalb weil er seine Admins und Softwareentwickler bescheiden bezahlt und zu knickerig ist seiner geliebten Software eine passende altmodische Umgebung zu gönnen.

Siehe oben - die ursprüngliche Umgebung ist nicht mehr wiederherstellbar.
Die Unternehmen, von denen ich rede, sind meist irgendwo zwischen Mittelstand und Großkonzern angesiedelt; dort mögen Admins und Softwareentwickler vieles sein, unterbezahlt sind sie nicht. :D

Was waren nochmal die grundlegenden Probleme von den bisherigen Init-Implementierungen, dass man sie unbedingt ersetzen muss (bzw. dies glaubt zu müssen)?

Die Welt hat sich weitergedreht, die Anforderungen haben sich gewandelt und das bisherige Verfahren hat sich in der Zwischenzeit als unzureichend erwiesen.
Der gleiche Grund, warum man keinen Giant Lock im Kernel mehr verwendet, obwohl der keine grundlegenden Probleme hatte. Solange man eine Single-Core-CPU hatte, gab's natürlich keinen Grund, den Giant Lock abzuschaffen.
 
Offensichtlich haben sich die Anforderungen gar nicht gewandelt, wenn mit systemd das Rad neu erfunden wird. Ich suche immer noch nach nützlichen Szenarien. Das wiederstarten von kaputten Diensten kann's ja wohl nicht sein. Das ist in einem init-Skript mit einem Befehl erledigt.
 
@Azazyel:

Als Softwareentwickler kann ich dir in so vielen Punkten zustimmen, was alte Software, etc. betrifft. Nur eines habe ich gelernt. Man neigt als Programmierer dann ziemlich bald mal die Dinge auf Grund der Erfahrungen, die man gemacht hat zu pessimistisch einzuschätzen.

Wenn du mit dem Beispiel von so einer Software kommst und die gibt es ja in etlichen Unternehmen, dann willst/musst du das Problem ohnehin gezielt angehen. Und wenn man da die fertige Lösung sieht, weil sie als solche angepriesen wird überseht man irrsinnig leicht, dass es ein Bruchteil der Maintenance/Kosten/... verursachen würde wenn man sich erlaubt hätte sich schnell mal 20 Minuten dran zusetzen man dem Ansatz das anständig zu machen.

Ich halte das mittlerweile für einen psychologischen Effekt, den man als Programmierer oder vielleicht als ITler leicht mal bekommt. Man will das Problem einfach irgendwie fertig gelöst haben, weil man mitunter weiß was die Kosten sein können. Deshalb geht man dann auf alles mögliche ein was nach eine "eins für alle mal" Lösung und nach schön klingt. Es tut aber echt weh, wenn man sich nach monatelangem "naja, eigentlich ist das doch nicht so gut und es gibt dieses eine Problem, wo wir doch noch Hand anlegen müssen, aber das kann man fixen und dann müsste es ja.." einfach mal den guten alten Weg geht und sich da seine eigene Lösung zusammenbraut, die dann anständig funktioniert.

Sieh's mal anders. Mit systemd kippst du das bewährte System über den Haufen, hast wieder deine Migrations, Integrationstests und es klingt so als würde da noch mehr dazukommen, Sachen, die du womöglich garnicht willst oder brauchst und wenn du wirklich mal über was stolperst, was nicht (deklarativ) abgedeckt ist musst du einen Bugreport machen, vielleicht einen Patch schreiben, der vielleicht Maintenenance braucht, weil in niemand integriert. Das Problem ist dann, dass wenn du dein altes Teil hast, du das nicht mehr einfach mit dem uralten, simplen RC-Skript verwalten kannst, wie immer sondern dann upgraden darfst, weil systemd anders ist, weil es am anderen Ende der Leitung, die dich eigentlich nicht interessiert etwas anders macht, aber dadurch, dass es mit dem restlichen OS zusammenhängt komplett unbeteiligte Systeme auf einmal Auswirkungen haben.

Ob du da deinen wichtigen Daemon jetzt im RC-Stil oder mit systemd verwaltest macht da wohl den kleineren Unterschied und wahrscheinlich würde es niemanden interessieren, wenn das jemand anders machen würde.

Aber systemd will ja unbedingt alles sein, ein Teil des Kernels, dein Cron, dein Logging und was sonst noch alles als ungenutzte Linuxfeatures verstanden wird. Wenn das alles ein Klumpen ist, dann überlege dir mal als Softwareentwickler ob du akzeptieren könntest. Klar, wenn die Entscheidung ist irgendein System von dem du oder deine Firma anhängig ist ist das eine Sache, aber wenn du die Wahl hast dein erprobtes RC-Skript zu verwenden oder dich auf die systemd-Reise begibst wo noch schwer abzuschätzen ist wo sie hin geht und wo die Antwort des Programmierers "it will surely be fixed when we know what's the right fix" ist, würdest du dann nicht enorme Bedenken haben? Linus hat hier vielleicht nicht den besten Ruf, aber zumindest ich kann's verstehen. Ich fänd's echt tragisch von so einem System den Erfolg und/oder weiteren Wohlergehen eines Unternehmens abhängig zu machen und nachdem systemd scheinbar wirklich alles tun will tut es das. Das kann zumindest viel Zeit und Geld kosten.

Wie sich das entwickelt wird sich noch zeigen, aber die Sache mit meinen auf und abs mit Pulseaudio gibt bei mir jetzt kein Übermaß an die Fähigkeiten der Entwickler, auch wenn sie sicherlich was drauf haben.

Giant Lock mit RC/systemd zu vergleichen halte ich für weit hergeholt. Das klingt ein wenig nach "warum sollten wir noch Tastatur und Maus verwenden? Wir haben Touchscreens und Gästensteuerung". Rc-Scripts bringen mit auf meinem sonst superaktuellen System keinen Nachteil und systemd, keinen Vorteil. Merke nur, dass es komplexer geworden ist, ich mich durch side effects kämpfe, etc. Wird nach einem Jahr oder so mit viel gutem Willen und dem hartnäckigen Versuch was wirklich positives draus zu ziehen (hatte gehofft mit Erfahrung, längerer Nutzung käme das, nachdem das die Linuxwelt so hyped) demnächst iweder rausfliegen.
 
Die Welt hat sich weitergedreht, die Anforderungen haben sich gewandelt und das bisherige Verfahren hat sich in der Zwischenzeit als unzureichend erwiesen.
Der gleiche Grund, warum man keinen Giant Lock im Kernel mehr verwendet, obwohl der keine grundlegenden Probleme hatte. Solange man eine Single-Core-CPU hatte, gab's natürlich keinen Grund, den Giant Lock abzuschaffen.

Das ist doch keine Antwort.

- Warum ist das nicht mehr adäquat?
- Weil es nicht mehr passt.
 
apart: Langsam wird das hier ja ein riesiger Thread.

Ich wuerde systemd nicht sofort verdammen nur weil es neu ist und mir nicht auf Anhieb Szenarien einfallen, bei denen die Features von systemd Sinn machen wuerden und bei denen es keine gaengige Alternative zu systemd gibt.
Was mich allerdings stoert - und das war nach meinem Verstaendnis auch der Ausloeser fuer diesen Thread - ist, dass systemd sich unersetzbar macht; es entwickelt sich immer mehr so, dass es keine Option mehr ist, sondern ein Muss (und zudem noch ein kaum portierbares). systemd hat das Potential die Portierbarkeit von anderer Opensource-Software zu beeintraechtigen - das ist die eigentliche Gefahr fuer alle Nicht-Linuxe.

pulseaudio ist ein aehnlicher Kandidat, der sich wie ein Pilz verbreitet hat und dessen Nutzen fragwuerdig ist - hier hat man zum Glueck meist noch die Wahl.
PulseAudio? Who needs it anyway!
 
apart: Langsam wird das hier ja ein riesiger Thread.

Ich wuerde systemd nicht sofort verdammen nur weil es neu ist und mir nicht auf Anhieb Szenarien einfallen, bei denen die Features von systemd Sinn machen wuerden und bei denen es keine gaengige Alternative zu systemd gibt.
Was mich allerdings stoert - und das war nach meinem Verstaendnis auch der Ausloeser fuer diesen Thread - ist, dass systemd sich unersetzbar macht; es entwickelt sich immer mehr so, dass es keine Option mehr ist, sondern ein Muss (und zudem noch ein kaum portierbares). systemd hat das Potential die Portierbarkeit von anderer Opensource-Software zu beeintraechtigen - das ist die eigentliche Gefahr fuer alle Nicht-Linuxe.

pulseaudio ist ein aehnlicher Kandidat, der sich wie ein Pilz verbreitet hat und dessen Nutzen fragwuerdig ist - hier hat man zum Glueck meist noch die Wahl.
PulseAudio? Who needs it anyway!

Die Frage ist warum verbreitet sich systemd? Es sind immer noch Personen/Gruppen die es bevorzugen. Welche Motive stehen hinter der Bevorzugung gegenüber Alternativen? Warum ist es angeblich nicht portierbar?
 
Die Frage ist warum verbreitet sich systemd? Es sind immer noch Personen/Gruppen die es bevorzugen. Welche Motive stehen hinter der Bevorzugung gegenüber Alternativen? Warum ist es angeblich nicht portierbar?

Systemd macht Gebrauch von Linuxkernelfunktionen, die natürlich in anderen Systemen nicht vorhanden sind. Sicherlich wäre mit massivem Patchaufwand eine Portierung möglich, aber die Frage ist, ob man sich den Aufwand wirklich machen will, da da andere Initsysteme bereits vorhanden sind.
 
Die Frage ist warum verbreitet sich systemd? Es sind immer noch Personen/Gruppen die es bevorzugen. Welche Motive stehen hinter der Bevorzugung gegenüber Alternativen? Warum ist es angeblich nicht portierbar?

Es nimmt dem Programmierer Arbeit ab. Er muss sich um Code und Funktionalität weniger kümmern, weil es andere leisten. Dass das den Nachteil hat, dass man sich darauf verlässt andere würden Kram schon portieren widerspricht den Gedanken von freier Software. Freie Software bedeutet ja nicht, jeder patcht sich seine Welt so zurecht wie er es braucht sondern Resourcenbündlung. Dabei ist systemd weniger das Problem sondern die Projekte die das ohne Sinn integrieren und die Alternativimplementierungen somit beschneiden.
 
Systemd macht Gebrauch von Linuxkernelfunktionen, die natürlich in anderen Systemen nicht vorhanden sind. Sicherlich wäre mit massivem Patchaufwand eine Portierung möglich, aber die Frage ist, ob man sich den Aufwand wirklich machen will, da da andere Initsysteme bereits vorhanden sind.

Was wäre der zu zahlende Preis für die BSDs wenn man gar nicht reagiert? Oder anders gefragt welche Strategie gibt es, wenn es eine gibt, um BSD als Desktopsystem zu erhalten?
 
Die Frage ist warum verbreitet sich systemd? Es sind immer noch Personen/Gruppen die es bevorzugen. Welche Motive stehen hinter der Bevorzugung gegenüber Alternativen? Warum ist es angeblich nicht portierbar?

Ja, es sind Personen und Institutionen, die es bevorzugen und verbreiten. Namentlich das Red Hat mit seinen Angestellten. Die dominieren aber GNOME und freedesktop.org usw., und drücken daher die harten Abhängigkeiten problemlos durch.
Was die Motive angeht kann ich nur spekulieren, aber auch in meiner eigenen, nicht all zu lange zurückliegenden Linux-Zeit hatte ich den Eindruck, dass es seitens GNOME eine Agenda gibt, alle Alternativen zu verdrängen. Das war u.A. bei den freedesktop.org-Standards der Fall, externe Vorschläge wurden seitens der GNOME-Entwickler immer abgeblockt, die haben nur Eigenentwicklungen akzeptiert.
Ich sehe diese Agenda noch immer, systemd est einfach die aktuellste Manifestierung davon. Es wird alles davon abhängig gemacht, da es das ganze System durchsetzt.
Nicht portierbar ist, weil es Linux-spezifische Kernelfeatures nutzt. Der Hauptentwickler sieht alle anderen Unices ohnehin als irrelevant an und legt auch nach eigenen Worten keinerlei Wert auf Portabilität zwischen unterschiedlichen Systemen.

Ach ja, noch eine Anmerkung: Lennart hat auch mal vorgeschlagen, ein GNOMEOS auf Linux-Basis zu erstellen und alle Alternativen einfach rauszuwerfen. Und da wundert sich wer, wenn ich seinen „Ich mache alles“-Daemon äußerst kritisch sehe und rein präventiv aus meinen Systemen raushalte?
 
Die Frage ist warum verbreitet sich systemd? Es sind immer noch Personen/Gruppen die es bevorzugen. Welche Motive stehen hinter der Bevorzugung gegenüber Alternativen? Warum ist es angeblich nicht portierbar?

Den "Durchbruch" hat systemd durch gutes Marketing erreicht. Durch den anfänglichen Fokus auf "schnellere Boot-Zeiten" (auf Kamikaze Art) kam man halt schnell in aller Munde, weil man mit geschönten Bedingungen eine Boot-Zeit "von 2 Sekunden" versprochen hat. Somit wollte es halt jeder haben, auch wenn es für ihr System so gar nicht umsetzbar war (kein SSD-RAID z.B.).

Mittlerweile hat man es halbwegs im Griff und die Dienste versinken nicht gegenseitig im Deadlock, was aber auch effektiv wieder auf die Boot-Zeit ging. Heutzutage startet systemd nur unwesentlich schneller als OpenRC und Konsorten. Aber das Totschlagargument "Bootzeit" bleibt.

Prinzipiell ist systemd von der Idee her nicht schlecht. Auch der aktuelle Stand ist, für Linux-Nutzer, durchaus gut und hilfreich. Was viele jedoch stört, dass alles an systemd nicht portabel erstellt wird (ebensowenig upstart). Es ist quasi "Friss oder Stirb" Prinzip. Es heißt, wenn dein System die entsprechenden Linux-Features nicht hat, dann baue sie gefälligst ein. Das kann man jetzt halten wie man will, aber es nicht unbedingt die netteste Art. Ein weiterer Punkt ist eine mangelnde Spezifikation. Das systemd Projekt baut einfach kreuz und quer Sachen ein, ohne auch nur irgendwo festzuschreiben, was sie eigentlich genau tun. Als Beispiel mal das Binärformat der Log-Dateien.

Und nun frisst sich systemd halt durch den gesamten User-Stack durch (vom Init-System bis hin zur Netzwerkverwaltung (< noch in Entwicklung)). Das Argument der systemd-Entwickler ist halt "müsst es ja nicht nutzen, wenn ihr nicht wollt", was jedoch dazu führt, dass man viel umhersynchronisieren muss.

Und nun muss man halt Entwickler anderer Systeme verstehen, wenn sie aufgefordert werden einem undokumentierten Code-Blob hinterherprogrammieren sollen, der sich alle Nase lang ändert. Das Problem haben dann auch diverse Distributionen wie Debian oder Gentoo, die auch mehr als nur den Linux-Kernel erlauben.
 
Was wäre der zu zahlende Preis für die BSDs wenn man gar nicht reagiert? Oder anders gefragt welche Strategie gibt es, wenn es eine gibt, um BSD als Desktopsystem zu erhalten?

Entweder du unternimmst diesen Aufwand oder du schießt Gnome auf den BSD's einfach in den Wind.

Was die Motive angeht kann ich nur spekulieren, aber auch in meiner eigenen, nicht all zu lange zurückliegenden Linux-Zeit hatte ich den Eindruck, dass es seitens GNOME eine Agenda gibt, alle Alternativen zu verdrängen. Das war u.A. bei den freedesktop.org-Standards der Fall, externe Vorschläge wurden seitens der GNOME-Entwickler immer abgeblockt, die haben nur Eigenentwicklungen akzeptiert.

Sind denn in anderen DEs weniger systemd Abhängigkeiten? In KDE z.B?
 
Auf GNOME kann ich locker verzichten. Aber selbst Xfce sieht sich ja als Desktop für Linux. Bleibt zu hoffen daß X nicht auch noch "verseucht" wird mit dem Zeug.
 
Was wäre der zu zahlende Preis für die BSDs wenn man gar nicht reagiert? Oder anders gefragt welche Strategie gibt es, wenn es eine gibt, um BSD als Desktopsystem zu erhalten?

Mein Problem ist, dass lesbare Skripte durch Binärkram ersetzt, der zu debuggen bescheiden ist. Shellskripte sind lesbarer und portierbar, da sie nur eine shell voraussetzen. Dazu kommt dann noch logging, cron, bootzeit (halte ich für kein gutes Argument, da die server eh länger im POST rumhängen als beim Kernel laden oder booten; ich kenn allerdings auch red hat system und weiss, wieso sie das haben wollen ;)). Dazu kommt die Verdrahtung mit allem anderen und die Modularität - ein großer Vorteil meiner Meinung nach von *ixoiden Systemen - geht verloren. Klar, soll kompatibel sein und alles andere wie bisher auch unterstützen, aber muss halt erst einkonfiguriert werden und ist nicht standardmäßig aktiv. und ich brauch auch keinen httpd im Bootprozeß.
 
Mittlerweile hat man es halbwegs im Griff und die Dienste versinken nicht gegenseitig im Deadlock, was aber auch effektiv wieder auf die Boot-Zeit ging. Heutzutage startet systemd nur unwesentlich schneller als OpenRC und Konsorten. Aber das Totschlagargument "Bootzeit" bleibt.

systemd hat noch ein paar Vorteile, welche darüber hinaus gehen z.B. kann systemd "cupsd" erst starten, wenn du einen Druckbefehl in Firefox absetzt. Nach ein paar Minuten ohne Nutzen, beendet sich "cupsd" wieder. Das spart Strom auf einem Notebook. Anderes Beispielt mit "bluetooth". Wenn du unter Ubuntu (upstart) ein Bluetooth Gerät ansteckst es aber nicht benötigst, wird trotzdem im Hintergund "blueZ" beim booten gestartet. Bei systemd erst, wenn du es benötigst.

Als Beispiel mal das Binärformat der Log-Dateien.
Das hier ist ein gutes Beispiel, welches ich einfach nicht verstehe! Was ist der Unterschied zwischen "grep","sed" und "journalctl"? Ich brauche Binärtools um eine Ausgabe zu lesen.
 
Das hier ist ein gutes Beispiel, welches ich einfach nicht verstehe! Was ist der Unterschied zwischen "grep","sed" und "journalctl"? Ich brauche Binärtools um eine Ausgabe zu lesen.

Sinn des ganzen soll wohl Speicherplatzersparnis sein. Warum man nun Angst vor ein paar MB Logfiles hat, erschließt sich mir auch nicht. systemd hätte kein Problem damit pro Dienst eine Log-Datei anzulegen. "Lustig" fand ich dann, dass ich meine Log-Dateien in einer chroot-Umgebung dann nicht lesen konnte, weil systemd die Benutzung innerhalb einer chroot unterbindet. Aber man kann ja seit jeher die Daten auch an syslog weiterleiten.

cat, grep, echo, vim etc. funktionieren aber allesamt in einer chroot und ich brauche kein systemd zum Lesen der Log-Files. Bei den Binärlogs bleibt mir _nur_ journalctl.
 
Gibt es schon Reaktionen auf den entsprechenden BSD-Mailinglisten?
Über kurz oder lang dürfte die Problematik ja auch die BSDs treffen. Vor allem wenn die Userland- Software anfängt systemd als Abhängigkeit mit einzuschleifen.
Dürfte lustig werden wenn sich Theo mal dazu äußert.

Gruß TODuke
 
Sinn des ganzen soll wohl Speicherplatzersparnis sein.
Mhhh ich habe mal gelesen, dass es auch um Manipulationen und Sicherheit geht. Mit "systemd" kannst du dir die Logfiles ja signieren. Ah ja hier gefunden [1]

"Lustig" fand ich dann, dass ich meine Log-Dateien in einer chroot-Umgebung dann nicht lesen konnte, weil systemd die Benutzung innerhalb einer chroot unterbindet.
Vielleicht zum Schutz vor Manipulation?

cat, grep, echo, vim etc. funktionieren aber allesamt in einer chroot und ich brauche kein systemd zum Lesen der Log-Files. Bei den Binärlogs bleibt mir _nur_ journalctl.
Wenn du von einer Live-CD startest, kannst du mit "journalctl -D" einen Pfad angeben.

[1] http://www.pro-linux.de/news/1/18766/systemd-schuetzt-logdateien-vor-manipulationen.html
 
Den "Durchbruch" hat systemd durch gutes Marketing erreicht. Durch den anfänglichen Fokus auf "schnellere Boot-Zeiten" (auf Kamikaze Art) kam man halt schnell in aller Munde, weil man mit geschönten Bedingungen eine Boot-Zeit "von 2 Sekunden" versprochen hat. Somit wollte es halt jeder haben, auch wenn es für ihr System so gar nicht umsetzbar war (kein SSD-RAID z.B.).
Das ärgert mich bis heute.

Systemd war anfangs aus zwei Gründen um einen Hauch (unter zwei Sekunden) schneller, weil es zum einen alle möglichen Daemons, die es nicht unterstützen nicht gestartet hat und zum Anrederen, weil viele der ersten Teile auf irgendeine Abhängigkeit vergessen haben und es race conditions gab. Das ist echt krass, wieviel User da meinten ihr System bootet schneller, wenn sie einfach die Hälfte der Services nicht mehr starten.

Das ist aber generell so eine Sache, die mittlerweile(?) extrem verbreitet ist. Software mit Macken oder auch Kinderkrankheiten (hat ja fast jede) mit alter runder, featurereicher Software zu vergleichen, dann migriert man nur um dann irgendwann festzustellen, dass das neue System Dinge entweder noch nicht oder garnicht kann. Irgendwann wird die Software alt und gilt als hoffnungslos und man wiederholt den Prozess.

Oder man tut sich das nicht an und gilt als rückständig, sobald man das Wort Stabilität nur in den Mund nimmt. ;)

Das Arge an systemd ist ja nur, dass das eine solche Kernkomponente ist. Nehmen wir mal Linux (Kernel) her. Ich bin mir ganz sicher, dass man da viele grundlegende Dinge viel schlauer lösen könnte und aus der Perspektive ein Rewrite extrem sinnvoll wäre. Die Welt hat sich weitergedreht, man weiß mehr und wenn man die Altlasten (Support für alte Architekturen, Protokolle, alte Interfaces die "nur" aus Kompatibilitätsgründen supported werden) los wird, wird die Struktur einfacher. Sowas kann man über jedes größere Projekt sagen. X.org ist da ein Beispiel. Nur das Meiste davon trifft bei RC-Scripts nichtmal zu. Das ist auch der Grund warum sie kaum verändert wurden und es nur inkrementelle Verbesserungen gab.

Okay, paralleles Starten ist cool. Kann ich verstehen, dass das Vorteile hat, ist aber auch nicht sonderlich aufwendig zu realisieren (Arch Linux hatte eine relativ simple Version) und warum man da inkompatibel sein muss verstehe ich auch nicht. Da muss man wohl (bei RC-Scripts) nichtmal das Interface ändern.

Außerdem kommt das irgendwie zu einem komischen Zeitpunkt. SSD machen vieles schneller. Mit Swapcache und Preloading ist das noch mal um einiges Schneller. Auf der anderen Seite hat bei einem Server, der sowieso selten neu startet das Timeout am Bootloader häufig mehr Einfluss. Auf Smartphones, etc. hat man das System sowieso 24/7 laufen. Da tut macht systemd so gut wie keinen Unterschied.

Klar, es ist immer ein handeln von verschiedenen Dingen: Performance, Simplicity, Features, Maintenanceaufwand, Kompatibilität, ... aber dass man Software die neuer ist grundsätzlich bevorzugt halte ich für eine extreme Fehlentwicklung. Und ich bin eindeutig niemand von denen die überall auf alte Systeme setzen, auch nicht in produktiven Systemen. Risiken gibt es überall und die muss man auch manchmal eingehen, wenn man der Zeit und seiner Konkurrenz nicht hinterherhinken will. Nur sah das weniger nach einer Abwägung aus und ich sehe den Vorteil nicht und klar bin ich nicht der Einzige, nur warum dann alle auf ein System mit den schon im vorigen Post erwähnten Nachteilen umschwenken verstehe ich nicht. Es würde mich allerdings echt interessieren. Derzeit halte ich das "RedHat will sich seine Macht sichern" noch am Realistischen, auch wenn es etwas ist das doch ziemlich traurig stimmt.
 
@foxit:Ich war zwar nur einmal auf einen BSD Vortrag aber gerade dort wurde das Feature vorgestellt. Waren aber die Chemnitzer Linuxtage. Signaturen bei Syslog sind dermaßen abgestanden, so kalt kann Kaffee nicht werden.
 
OpenBSD nutzt doch ohnehin eine eigene X-Version, da ist man auf Fremdentwicklungen nicht angewiesen... ;)
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben