News Debian: Devuan veröffentlicht erste Beta ohne Systemd

[blackiwid]

@raph

Ein Tool für eine Aufgabe - diese Unix-Regel wird durch Systemd mit Füßen getreten - aber jede Regel ist irgendwann einmal überholt.

falsch, es gibt nen video oder ne Seite wo das genau erklaert wird und es ist selten daemlich, emacs ist auch uralt, ist eben auch nicht nur ein Editor, der Kernel ist auch monotisch und macht daher extrem viel, der Xserver macht ganz viel, wayland ist viel minimalistischer, Libreoffice, Firefox... Unix philosophy ist was nettes, aber da irgendwie ne Religion draus zu machen ist absurd.

Durch Systemd wird Linux aber auch inkompatibel zu BSD - das kann Fluch und Segen zugleich sein.

Absolut irrelevant, zumal das nicht mal stimmt, was meinst du ueberhaupt mit inkompatibel? Ein Ubuntu deb fille wird so oder so inkompatibel mit linux sein, ob der bsd kernel dieses ELF binary format unterstuetzt oder wie das heisst weiss ich nicht, nehms an?

Davor wurde auch Upstart benuutzt, das ist genauso kompatibel/inkompatibel wie systemd, auch kann es sogar alte startscripte irgendwie noch starten wenns drauf an kommt.

@Eis-T

Unfug. s.o.

Ich denke das war eher ironisch gemeint.

Ergänzung (3. Mai 2016)

(Vermutlich sind die Zeiten vorbei, wo man global WLAN-Settings vergeben konnte, und die vom Start bis zum Shutdown der Maschine auch ohne per GUI angemeldete User aktiv waren...)

Das dann entweder ein Problem von deiner Distribution oder von deinem Wissen, in Archlinux z.B. aber auch in Fedora kann man sich zwischen verschiedenen Netzwerkdeamons entscheiden und diese bieten jeweils unterschiedliche vor und nachteile.

Heute ist Netzwerkmanager populaer aber es gibt noch etliche andere die auch mit systemd wunderbar zusammenarbeiten, btw kann man netzwerkmanager auch ueber cli configurieren.

Mir scheint das du Probleme die du unabhaengig von Systemd noch nicht geloest hast, nun versuchst kuenstlich auf Systemd zu schieben.

2) Auf dem Server ist SystemD ein Graus. Alle Server, die ich bei Debian von 7 auf 8 nachziehen durfte, waren gruselig. Netzwerk-Einstellungen in Xen? Root-Dateisysteme per Netzwerk einbinden? Die Lösung war letztlich, das Upgrade auf dem Produktivsystem ohne SystemD-Komponenten zu machen. Nur in dieser Konfiguration lief es.

Hier scheinst du auch die Schuldzuschreibung falsch zu machen, es ist bekannt das Hersteller von Proprietaerer Software immer extrem lange Hinterher hinken wenn sie ihre Software anpassen, dir muss das bekannt gewesen sein sofern du kein Linuxanfaenger bist, als beispiel wars schon einige male der Fall das nach nem Xserverupdate die freien Treiber Wunderbar liefen quasi sofort, die unfreien dann oft Monate auf nen Update warten.

So deine Entscheidung diese Nachteile in Kauf zu nehmen ist deine Entscheidung, dann die Unfaehigkeit voellige Unfaehigkeit dieser Firma hinter Xen, die ja jede Menge Geld bekommt und damit Systemd ordentlich supporten koennte auf die Systemd entwickler zu schieben halte ich fuer abenteuerlich.

Sofern du nicht irgendwelche Korrospondenz hast das die Systemd entwickler irgendwelche Patches von Xen Bezahlten Leuten abgelehnt haben, wuerde ich mit solchen Schuldzuweisuungen zurueck halten.

Ergänzung (3. Mai 2016)

Es geht allerdings nicht allein darum wie die Nutzererfahrung am Desktop ist. Viele Linuxer schauen eben auch darauf wie sie entsteht, auf das, was unter der Haube passiert.

Wer selbst programmiert etwa, weiß sofort wie unterschiedlich der Code von zwei Programmen aussehen kann, die dem absolut gleichen Zweck dienen. Wenn man es gut machen will, folgt man am besten einem konsistenten Regelwerk und kann auch eine dementsprechende Arbeit abgeben.

Wählt man schon eine im Ansatz bedenkliche Basis, kann man immernoch ein sehr schönes, komfortables, großzügig dimensioniertes und bis ins letzte Detail durchdachtes Haus erbauen - und dann setzt man das halbe Fundament in den Treibsand.

Ja und das was so gaengig war Spegethicode-scripte war genau der Treibsand.

Ergänzung (3. Mai 2016)

Die Beweggründe und Bedürfnisse anderer Nutzer nicht ernstzunehmen und letztlich als unlogisch, ängstlich und unwillig abzutun, ist halt keine vernünftige Basis für eine konstruktive Diskussion.

Das ist ja genau das Problem aber primaer von der anderen Seite als sich Systemd nach und nach ueberall durchsetzte gab es einen riesen Shitstorm dagegen, wenn die alle die Fresse gehalten haetten, oder zivilisiert bisschen argumentiert haetten, und dann eben ganz ruhig und unaufgeregt 1 2 forks wo raus gebracht haetten, haette sich doch niemand aufgeregt.

Stattdessen lief nicht nur ein Shitstorm gegen diese Technologie es gab Regelrechte Hatestorms gegen bestimmte Entwickler.

Ergänzung (3. Mai 2016)

Und es würde keine Massentierhaltung, Atom-Waffen und Überbevölkerung geben.

Es gibt keine Ueberbevoelkerung, wir koennen alle heuute lebenden 2x mit Nahrung versorgen, unser Lebensstandart ist zu hoch das stimmt, aber nur weil man den nicht senken will (vorallem die reichen) zu sagen dann sollen weniger leben, damit wir pro kopf die Umwelt mehr vergewaltigen koennen ist bisschen pervers.

Ergänzung (3. Mai 2016)

Hm..... gibt es denn keine Möglichkeit für Interessierte, die aber keine Profis sind, auf nüchterne Weise zu erfahren, wo die Vor- und Nachteile exakt liegen und wo genau die Unix-Philisophie unterwandert wird und wo nicht? Möglichst ohne solche doch eher emotionalen Begriffe wie "Krebsgeschwür" oder was auch immer?

Ich versuchs mal Punkt 10 geht um die UNIX geschichte, aber auuch alle anderen Kritiken die hier aufgefuehrt wurden werden beschrieben:

http://0pointer.de/blog/projects/the-biggest-myths.html

Ich bin btw kein religioeser verfechter von Systemd, aber es ist EIN gutes System fuer viele Sachen und auch ein Fortschritt, schon alleine das ich die sehr gute Archlinux Wiki lesen kann und fast alles 1:1 fuer meine fedora Systeme benutzen kann ist sehr schhoen, das ich fuer dienste nicht 10 verschiedene startscripte habe sondern eines das in fast allen distries laeuft.

und wenn ich mal selber eines schreiben muss ist das viel einfacher:

ich kanns mal damit sagen, ich habe in den 15 bis 20 Jahren in denen ich Linux nutze niemals ein eigenes Servicefile geschrieben, seit ich auf Fedora gewechselt bin mit Systemd, habe ich damit angefangen. hab 2 das eine startet nen Xserver (nuur aleine) das andere startet kodi standalone.

das format ist recht simpel man muss nicht immer eine grundstruktur hin schreiben, normale startscripte sind extrem redundant, oft steht ziemlich genau das gleiche da, aber eben sehr ausfuehrlich, mir ist es auch egal wie der pc das macht was ich will, systemd service files erlauben einem zu sagen, was der pc machen soll, um das wie kuemmert sich systemd selber, dagegen musste man sich um das wie daver selber kuemmern.

Standartmaesig nimmt einem systemd also arbeit ab, und man muss nur noch das wesentliche hin schreiben, das den dienst oder was man will aus macht. Nicht mehr das was bei 99% der dienste immer das selbe ist.

Das seher ich als fortschritt. Auch die vereinheiltlichung, das auf allen major distries die gleichen tools vorhanden sind ist gut, auch das Logging System ist zugaenglicher, man muss nicht irgendwelche 10 km langen grep kommandos eintippen um aus seinen logs was raus zu lesen. Sondern es gibt einfache kommandos die einem sehr uebliche tasks sehr einfach bereit stellen.

Hoffe das hat die Fragen ein wenig erhel

Mich würde beispielsweise interessieren, ob Systemd nicht auch so mit all seinen Vorteilen hätte funktionieren können, ohne das o.g. Dogma zu untergraben...

Nein ausser das schnell booten das andere Systeme auch haben bis zu nem bestimmten grad, das aber das unwichtigste an Systemd ist, haette es die meisten Ziele nicht erreichen koennen.

das die log files binaer gespeichert sind (wobei ein ascii output auch z.b. mit nem cronjob generieren laesst) wird von vielen kritisiert, aber nuur das laesst es schnell und gut parsen) ascii ist halt von computern nicht soo gut zu verarbeiten. d

Ergänzung (3. Mai 2016)

Hm..... gibt es denn keine Möglichkeit für Interessierte, die aber keine Profis sind, auf nüchterne Weise zu erfahren, wo die Vor- und Nachteile exakt liegen und wo genau die Unix-Philisophie unterwandert wird und wo nicht? Möglichst ohne solche doch eher emotionalen Begriffe wie "Krebsgeschwür" oder was auch immer?

Ich versuchs mal Punkt 10 geht um die UNIX geschichte, aber auuch alle anderen Kritiken die hier aufgefuehrt wurden werden beschrieben:

http://0pointer.de/blog/projects/the-biggest-myths.html

Ich bin btw kein religioeser verfechter von Systemd, aber es ist EIN gutes System fuer viele Sachen und auch ein Fortschritt, schon alleine das ich die sehr gute Archlinux Wiki lesen kann und fast alles 1:1 fuer meine fedora Systeme benutzen kann ist sehr schhoen, das ich fuer dienste nicht 10 verschiedene startscripte habe sondern eines das in fast allen distries laeuft.

und wenn ich mal selber eines schreiben muss ist das viel einfacher:

ich kanns mal damit sagen, ich habe in den 15 bis 20 Jahren in denen ich Linux nutze niemals ein eigenes Servicefile geschrieben, seit ich auf Fedora gewechselt bin mit Systemd, habe ich damit angefangen. hab 2 das eine startet nen Xserver (nuur aleine) das andere startet kodi standalone.

das format ist recht simpel man muss nicht immer eine grundstruktur hin schreiben, normale startscripte sind extrem redundant, oft steht ziemlich genau das gleiche da, aber eben sehr ausfuehrlich, mir ist es auch egal wie der pc das macht was ich will, systemd service files erlauben einem zu sagen, was der pc machen soll, um das wie kuemmert sich systemd selber, dagegen musste man sich um das wie daver selber kuemmern.

Standartmaesig nimmt einem systemd also arbeit ab, und man muss nur noch das wesentliche hin schreiben, das den dienst oder was man will aus macht. Nicht mehr das was bei 99% der dienste immer das selbe ist.

Das seher ich als fortschritt. Auch die vereinheiltlichung, das auf allen major distries die gleichen tools vorhanden sind ist gut, auch das Logging System ist zugaenglicher, man muss nicht irgendwelche 10 km langen grep kommandos eintippen um aus seinen logs was raus zu lesen. Sondern es gibt einfache kommandos die einem sehr uebliche tasks sehr einfach bereit stellen.

Hoffe das hat die Fragen ein wenig erhel

Mich würde beispielsweise interessieren, ob Systemd nicht auch so mit all seinen Vorteilen hätte funktionieren können, ohne das o.g. Dogma zu untergraben...

Nein ausser das schnell booten das andere Systeme auch haben bis zu nem bestimmten grad, das aber das unwichtigste an Systemd ist, haette es die meisten Ziele nicht erreichen koennen.

das die log files binaer gespeichert sind (wobei ein ascii output auch z.b. mit nem cronjob generieren laesst) wird von vielen kritisiert, aber nuur das laesst es schnell und gut parsen) ascii ist halt von computern nicht soo gut zu verarbeiten. die kommen mit binaeren files besser klar.

Ausser sehr abstraktem unkonkreten zeug, gits aber keine echten Nachteile, von daher besteht ja kein grund es anders zu machen, ausser das irgendwelche Religioesen Leute sagen, hei es ist anders wie es war, wir wollen aber nicht das sich irgendwas aendert.

Es mag sicher spezielle Ziele geben wo das nicht so gut ist, ich bin z.B. ein grosser Fan von Guix(SD) einer sehr speziellen Linuxdistribution, leider unterstuetzt diese noch kein lvm warum ich sie noch nicht benutze, aber diese hat ein anderes System, soweit ich das ueberblicke eher was altmodischeres.

Stoert mich das gross? Da ich nicht jeden tag 50 service files schreibe eher nicht.

Leider wird unter Linux acuh oft die Schuldzuweisung falsch vor genommen, sieht man ja auch bei Linux vs Windows diskussionen, da sagen Leute Linux ist schlecht weil die proprietaeren AMD Grafikkarten schlechter sind und es kein Photoshop gibt oder keinen Treiber fuer XY, statt zu sagen, diese Firmen sind schlecht weil sie Llinux nicht unterstuetzen, wird Gesagt linux ist schlecht, voellig hirnrissig, niemand wuerde sagen windows ist schlecht weil irgend ein Hersteller fuer seine Hardware kein Windowstreiber liefern.

Also finde das alles schwierig, aktzeptiere auch andere Meinungen, mich nervt nur dieses verbissene und hoch emotionale Ablehnen von Systemd, niemand zwingt einen es zu benutzen, aber man kann halt auch Distributionshersteller nicht zwingen es nicht in ihre Distries einbauen, das doch recht einfach und simpel.

Und es gibt deutlich schlimmere Probleme die Linux und Datensicherheit bedrohen, Rootkits mit offiziellen Backdoors in Intel hardware (mme oder wie der mist heist) aehnliches auch bei amd.

das sind wirklich punkte die massiv die Freiheit und Sicherheit von Leuten gefaerdet, etwas so unwichtiges wie ein bootloader der komplett quelloffen ist und einen niemand zwingt ihhn zu benutzen macht mir dagegen in keinerweise angst, egal was ich davon technisch halte.

 

[fuyuhasugu]

emacs ist auch uralt, ist eben auch nicht nur ein Editor, der Kernel ist auch monotisch und macht daher extrem viel, der Xserver macht ganz viel, wayland ist viel minimalistischer, Libreoffice, Firefox...

Das ist fast alles Anwendungssoftware, was Du hier aufzählst und damit vollkommen irrelevant im Zusammenhang mit Adminstrationstools. Beim einzig halbwegs relevanten Beispiel "Kernel" (wobei der ja auch nur bedingt als Admintool zu bezeichnen ist) versuchte man ja gerade mit den ladbaren Kernel-Modulen einigen Nachteilen eines monolithischen Kernels zu begegnen.

p.s. Standart －＞ Standard

 

[mensch183]

@fuyuhasugu Du hast Recht, dass dein Vorredner sinnlose Vergleiche zog. Aber das da von dir stimmt jedenfalls nicht:

l "Kernel" (wobei der ja auch nur bedingt als Admintool zu bezeichnen ist) versuchte man ja gerade mit den ladbaren Kernel-Modulen einigen Nachteilen eines monolithischen Kernels zu begegnen.

__DER__ entscheidende und namensgebende Nachteil monotlithischer Kernel besteht darin, dass jedes beliebige Stück ausgeführter Kernelcode im gesamten Kernel tun und lassen kann was es will. Egal wo im Kernel ein Fehler steckt, durch den ein Angreifer eigenen Code einschmuggeln kann: Ergebnis ist immer der Super-GAU, also der komplette Fall des Rechners. Der ganze Kernel ist hinsichtlich der Berechtigungen des ausgeführten Codes eine große Suppe oder ein(=mono) großer Block(=lith), d.h. es gibt keinerlei Unterteilungen und Absicherungen dieser Teile gegeneinander. Dabei spielt keine Rolle, ob der Kernelcode aus einem File oder dank Modulen aus mehrere Files gelesen wird. Linux ist trotz dieser Module ein rein monolitischer Kernel.

 

[fuyuhasugu]

@mensch183: Wo widersprechen denn Deine Aussagen dem von mir geschriebenen? Der Kernel fällt natürlich trotzdem weiterhin unter die Kategorie "monotlithisch" (was im übrigen nur eine Definitionsfrage ist). Und um den aus den von Dir aufgeführten Eigenschaften eines solchen Kernelmodells folgenden Nachteilen zu begegnen, wurden LKM eingeführt, wodurch zumindest nur noch die zum jeweiligen Zeitpunkt notwendigen Treiber etc. im Kernelspace Unsinn machen können.

 

[Zedar]

Ich als User, der tatsächlich nur Linux als Desktopsystem nutzt, merkt natürlich nicht viel dass systemd in irgendeiner Form Dinge verkompliziert. Bei Arch Linux werden Dinge meines Erachtens vereinfacht. Ich habe mir auch schon viele links über systemd durchgelesen, konnte aber nicht nachvollziehen wo das Problem wirklich liegt. Wahrscheinlich fehlt mir der Background.

Allerdings werden die Leute schon ihre Gründe haben und die Zeit wird es zeigen ob Platz ist für eine Distribution welche so ausgelegt ist.

[...]Da stimme ich Dir zu - Fortschrittsverweigerung enthält uns nur gute Sachen vor.

[...]Ganz recht. Die angeblichen "Fortschritte" haben eben soviel zur Seite schaffen müssen.

Was hält euch ab? Zieht in eine Hütte im Wald ohne Strom und fließendes Wasser, verzichtet auf Medikamente wie Schmerzmittel oder Antibiotika und ernährt euch von dem was Gott euch schenkt.

 

[blackiwid]

Das ist fast alles Anwendungssoftware, was Du hier aufzählst und damit vollkommen irrelevant im Zusammenhang mit Adminstrationstools. Beim einzig halbwegs relevanten Beispiel "Kernel" (wobei der ja auch nur bedingt als Admintool zu bezeichnen ist) versuchte man ja gerade mit den ladbaren Kernel-Modulen einigen Nachteilen eines monolithischen Kernels zu begegnen.

p.s. Standart －＞ Standard

Naja wenn ich heute irgend ein Softwareentwickllungsbuch mir schnappe und drin lese, dann lese ich von decoupling und von DRY Prinzipien, und der alte Mist mit diesen beschissenen init-scripten, war so ziemlich der schlimmste verstoss gegen DRY den ich kenne.

irgend so eine doofe Empfehlung aus ner Zeit wo Computer noch Schraenke fuelllten und 1mb Arbeitsspeicher hatten, nhem ich dagegen nicht zu ernst. Klar MUSSTEN damals programme sehr klein und simpel sein, weil sonst der Arbeitsspeicher beim ausfuehren direkt voll gewesen waere.

Btw ist das eh absurd, letztlich ist systemd eben auch nur eine sammlung von einigen sehr primitiven kleinen programmen. Und nun ein interface das einem erspart erzwungenermasen mit grep und co nen logging was sinnvolles zu entlocken nun als super komplexes programm dar zu stellen halte ich absurd.

ich verstehe auch den aufstand nicht, das alte System war kaputt das war gut genug fuer die 80er zur not auch noch die 90er aber danach outdated, niemand anderer konnte etwas besseres liefern wie systemd, das ist ne klare extrme verbesserung zu dem was davor da war (wenn man mal so esoterischhe unix-ideologien ausser acht laesst, ausser ne widerholung welche das angeblich sind ohne irgeendwelche begruendungen WARUM das gut sein sollte die ueberzeugen) wenn jemnad was besseres macht das angeblich mehr unixish ist, bitte gerne, aber der scheiss davor war mal der reinste muell.

 

[fuyuhasugu]

aber der scheiss davor war mal der reinste muell.

Das ist doch wirklich mal eine gute Begründung.

das alte System war kaputt

Dann ist systemd wohl kaputter:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd
https://github.com/systemd/systemd/issues
Hut ab, wenn das das zentrale Programm zur Systemsteuerung sein soll!
p.s. Dank an Sven für die Links.

 

[Cool Master]

@fuyuhasugu

Bugs hat jede Software... Schau dir aber mal das an:

https://github.com/systemd/systemd/labels/release-critical
https://github.com/systemd/systemd/labels/security

Und das ist wichtig. Alles andere wird im laufe der Zeit bereinigt und gefixed. Zudem der Stand auf Github nicht dem von Debian entspricht.

 

[fuyuhasugu]

Gut das es nur funktionale Probleme mit systemd gibt, jedoch keine die offensichtlich sicherheitskritisch sind. Man könnte natürlich auch der unter Entwicklern dieses Matière recht verbreiteten Auffassung folgen, dass nahezu jeder Bug auch für einen Bruch der Sicherheit genutzt werden kann. Bei der Anzahl Bugs ist aber eher zu vermuten, dass die fehlerhafte Funktionalität viel zu sehr im Vordergrund steht und sicherheitsrelevante Bugs, wie auch bei anderen SW-Projekten üblich, erst an Wichtigkeit gewinnen, wenn die gröbsten funktionalen Bugs ausgemerzt sind und sich systemd auch über ein paar Jahre funktionsfähig im Einsatz bewährt hat.

 

[chithanh]

Libreoffice, Firefox... Unix philosophy ist was nettes, aber da irgendwie ne Religion draus zu machen ist absurd.

Gut das es nur funktionale Probleme mit systemd gibt, jedoch keine die offensichtlich sicherheitskritisch sind.

Wie heißt es so schön, "complexity is the worst enemy of security". Wenn systemd soviele Sicherheitsprobleme hätte wie Firefox oder LibreOffice, dann gute Nacht. sysvinit ist ein extrem simples Stück Software während bei systemd manchmal anscheinend die Featureritis grassiert. Aber immerhin sind die weniger essenziellen Teile in eigene Prozesse ausgelagert und die Zahl der Sicherheitsprobleme ist für eine Codebasis dieser Größe gering.

 

[fuyuhasugu]

"complexity is the worst enemy of security"

Nicht nur das, eine erhöhte Fehlerhäufigkeit ist eine inherente Eigenschaft von Komplexität. D.h. die Fehlerwahrscheinlichkeit nimmt nicht nur mit dem Codeumfang zu sondern darüber hinaus auch mit der Komplexität des Codes.

 

[Miuwa]

Ist doch immer wieder schön, wenn man so mit Allgemeinplätzen um sich werfen kann. Natürlich führt komplexerer Code zu mehr Fehlern, aber man muss eben auch Äpfel mit Äpfel, d.h. Software mit ähnlichem Funktionsumfang vergleichen. Wenn die Systemd SW-Kollektion mehrere Verschiedenen Programme ersetzt, dann muss man die Fehler eben auch mit der Summe der Fehler in diesen Programme vergleichen.
Und was das Thema Funktionsumfang angeht: Komplexität an einer Stelle kann durchaus sinnvoll sein, wenn sie Komplexität an anderer Stelle verringert. Wenn also die Startscripte von zig Distributionen oder das Auswerten der Logs vereinfacht werden, dann KANN es durchaus sinnvoll sein dafür an einer Stelle mehr Komplexität zu erlauben.

Ich selbst habe nicht die geringste Ahnung, ob Systemd technisch besser als die Alternativen ist, aber ich glaube ehrlich gesagt nicht, dass auf Stabilität ausgerichtete Distributionen wie Debian trotz massiven Widerstands auf Systemd gewechselt wären, wenn es funktional und von der Stabilität her nicht überzeugen würde. Jedenfalls schien es mir (zumindest oberflächlich) so, als ob die (durchaus berechtigten) Kritikpunkte mehr philosophischer, denn technischer Natur waren.

 

[matadoerle]

Hallo,
habe lange geschwiegen, aber möchte jetzt doch meinen Senf dazu geben. Bisschen zu meinem Hintergrund: habe unter CP/M meine ersten Computerschritte getätigt, auf einem Commdore 128 (wüßte gerne, wo der abgeblieben ist). Arbeite seit ca. 30 Jahren beruflich mit allerhand Systemen, MS-DOS, DR/DOS, OS/2, und natürlich Windows (kenne noch das alte vor 3.0), Novell NetWare (ab 2.1x), Linux Debian über SuSE und Mint bis hin zu Arch und Manjaro (neuerdings), natürlich beruflich RedHat und CentOS, HP-UX und andere BSD sowie System V UNIX Derivate. Mein Lieblings-Betriebssystem ist nach wie vor Solaris, wenn es um "rockstable" und Skalierbarkeit für den Produktionseinsatz geht - dagegen ist alles andere (!) billige Hühnerkacke.

Ich begrüße die Distribution devuan auf jeden Fall und hoffe, dass genug Unterstützung das System am Leben erhält.

Systemd (nur groß am Anfang, weil am Anfang des Satzes ) ist ein Init- und Startsystem für Linux, was meistens ja noch eine gewisse Kompatibilität zu Sysinit (System V) gewährt, aber leider dem Komfortgedanken und der Komfort-Automatisierung"like" Windows zu viel Raum schenkt. Es ist, und das ist der große Nachteil daran, grundsätzlich viel zu eng ins System verflochten, als dass es einfach "auszublenden" wäre. Da sind andere Systeme wie Runit wesentlich pflegeleichter und würden annähernd gleiche Funktionalität bieten.
Den Hatestorm der "Elder Admins" hat systemd sich zugezogen, weil ein paar Programmierer Götter spielen wollen und die Bedürfnisse derjenigen, die für Infrastruktur und große Anwendungen entsprechende Systeme betreiben, mit Füßen getreten haben. Um das ganz klar zu sagen: wenn ich einen wirklich großen Host fahre und dort Verfügbarkeiten jenseits der 98% über 365 Tage und 24 Stunden zu gewährleisten habe, gehen mir "Boot"-Zeiten aber sowas von am Allerwertesten vorbei .. aber ein systemd, was mir in die Suppe spucken kann, weil ein Entwickler eines kleinen Systembestandteils - der ebenfalls keine Ahnung vom Betrieb großer Systeme hat - mit "kleinen" Konfigurationseinstellungen selbstständige "Korrekturen" vornimmt, das kann einem dann schonmal schlaflose Nächte bereiten. Viel schlimmer noch: es kommt immer dann zu unerklärlichen und unerwünschten Seiteneffekten, wenn ich es überhaupt nicht gebrauchen kann.

Auf einem Desktop empfinde ich es als angenehm, wenn mein System den eingesteckten USB-Stick mountet und zugänglich macht; auf einem Server ist das ein komplettes Unding! (wenn ich da nicht weiß, wie ich den zu mounten habe, dann sollte ich gefälligst die Griffel von der Tastatur fernhalten).

Systemd wäre vollkommen problemlos und hätte keine Feinde, wenn es bei einer optionalen und damit jederzeit vollumfänglich vom Admin kontrollierbaren Umgebung geblieben wäre. Das ist es aber nicht und ich muss auf JEDEM System jetzt manuell hinterher sein, unerwünschte "Selbstständigkeiten" von Treibern und Tools zu kontrollieren. Das kostet Zeit und Kraft, von der ich in Zeiten immer höheren Kosten- und Leistungsdrucks aber leider zu wenig habe.
Alleine der immense Aufwand, der für devuan erkennbar ist, verdeutlicht aber das Problem: mittlerweile steckt systemd schon überall tief drinnen. Und was dem einen gefällt, kann einem anderen erhebliche Probleme bereiten - die gerade im Falle großer Systeme VIEL MEHR Nachteile als Vorteile bringen.

Ich habe überhaupt nichts dagegen, wenn jemand systemd auf seinen Systemen einsetzt und halte das im übrigen für den Desktop durchaus als denkbaren Ansatz, aber auf einem Produktivsystem, was gefälligst tun soll was ich und meine Kollegen wollen, hat es NICHTS zu suchen.
Wenn dann irgendwelche Nerds, die in ihrem Leben schon dreimal ein Linux vom USB-Stick auf eine Platte geschoben und auch schon mal eine Config editiert haben, glauben sie könnten mir und meinen Kollegen "Fortschrittsverweigerung" vorwerfen, nur weil wir auf unseren Systemen UNSERE Bedürfnisse verteidigen, dann geht auch schonmal die Emotion hoch. WIR haben schließlich die Infrastruktur aufgebaut, die ihr täglich nutzt wie die Klosettspülung - und im Ernstfall wüßtet ihr nichtmal, wie man die Sche.ße aus dem Haus bekommt, wenn es nicht einen Fortschrittsverweigerer gäbe, der sich noch erinnern kann, wie man das in der Steinzeit geruchlos bewerkstelligen konnte ..

devuan steht für die Freiheit der Wahl! Auch und vor allem des zentralen Init-Systems. Und wenn irgendwer diese Freiheit angreift, dann hat er den ersten Grundgedanken von Linux schon verraten. Ich bin für stetigen Fortschritt und durchaus auch für neue Systeme immer zu haben, aber der gewachsene Bestand sichert die Basis, auf die ich aufbauen kann. Und die sollte man nicht leichtfertig instabiler machen. Genau das macht aber systemd. Wenn ich auf meinen Desktops Probleme haben, dann hängt systemd immer mittendrin - beim Desktop bringt es mir enigstens ein paar Vorteile, auf dem Server NUR Nachteile.

 

[fuyuhasugu]

Wenn die Systemd SW-Kollektion mehrere Verschiedenen Programme ersetzt, dann muss man die Fehler eben auch mit der Summe der Fehler in diesen Programme vergleichen.

Falsch. Die Summe der Einzelteile wäre es nur im Idealfall, in dem wir die Komplexität nicht zu höhereren Fehlerwahrscheinlichkeit führt. Wenn wir den erreichen könnten, bräuchten AKWs auch nicht ein Dutzend Sicherungssysteme und größere Unfälle würden gleich gar nicht auftreten. Fehlertolerante Systeme, d.h. solche mit mehreren Sicherungen, sind deshalb auf lange Sicht die einzige Möglichkeit, Komplexität zu begegnen.

Und was das Thema Funktionsumfang angeht: Komplexität an einer Stelle kann durchaus sinnvoll sein, wenn sie Komplexität an anderer Stelle verringert.

Mit dem bisherigen System kann man sehr simple, leicht überschau- und leicht kontrollierbare Systeme schaffen. Abhängigkeiten zwischen Diensten verchwinden ja nicht durch die Einführung eines Tools wie systemd, ebensowenig wie die Notwendigkeit, Dienste in einer bestimmten Reihenfolge zu starten. Wenn es also um Vereinheitlichung ginge, wäre das auch damit zu realisieren. Ob es mit systemd gelingt, langfristig eine Vereinheitlichung zu schaffen, die eine Verringerung der Komplexität auf der Seite eines mit verschiedenen Systemen arbeitenden Admins entspricht, muss sich erst noch zeigen. Bisher waren solche Bestrebungen noch nie von langfristigem Erfolg gekrönt.
Prinzipiell stimmt es natärlich, dass die gleiche Funktionalität bisher durch mehrere "kleine Bausteine" erricht werden musste, was auch oft genug zu komplexen Startscripten führte. Debugging und auch Anpassung an die Notwendigkeiten ist durch das Bausteinprinzip aber rect einfach und es gibt keinen SPOF wie systemd.

Wenn also die Startscripte von zig Distributionen oder das Auswerten der Logs vereinfacht werden...

Warum Logs nun gerade kein gutes Beispiel _für_ systemd sind, wurde u.a. in disem Thread schon geschildert...

Ist doch immer wieder schön, wenn man so mit Allgemeinplätzen um sich werfen kann. ... Jedenfalls schien es mir (zumindest oberflächlich) so, als ob die (durchaus berechtigten) Kritikpunkte mehr philosophischer, denn technischer Natur waren.

Das gehört nun mal zu den Grundeigenschaften. Schau Dir mal ein paar Vorlesungen zu höherer Mathematik oder Physik an, die hören sich ab einem bestimmten Abstraktionsgrad auch mehr nach Philosophie denn nach einer angewandten Wissenschaft an. Studierte Philosophen werden hier (mit Recht) widersprechen.

 

[Miuwa]

Warum Logs nun gerade kein gutes Beispiel _für_ systemd sind, wurde u.a. in disem Thread schon geschildert...

Wenn du dir die Posts hier und auf den Mailinglisten mal durchliest, dann sind die Meinungen dazu sehr gemischt. Und Textlogs lassen sich bei bedarf ohnehin automatisch generieren.

Das gehört nun mal zu den Grundeigenschaften. Schau Dir mal ein paar Vorlesungen zu höherer Mathematik oder Physik an, die hören sich ab einem bestimmten Abstraktionsgrad auch mehr nach Philosophie denn nach einer angewandten Wissenschaft an. Studierte Philosophen werden hier (mit Recht) widersprechen.

Das bezog sich auf unterschiedliche Designphilosophie bzw. die hier immer wieder wiederholte UNIX Philosophie.

 

[fuyuhasugu]

Wenn du dir die Posts hier und auf den Mailinglisten mal durchliest, dann sind die Meinungen dazu sehr gemischt. Und Textlogs lassen sich bei bedarf ohnehin automatisch generieren.

Das ist normal, aber der Logik nach ist ein System auch dann nicht als fehlerfrei zu bezeichnen, wenn auf 100 Erfolgsmeldungen nur eine Fehlermeldung kommt. Wenn das Verhältnis umgekehrt wäre, würde die Nutzung wohl niemand auch nur in Erwägung ziehen.

Das bezog sich auf unterschiedliche Designphilosophie bzw. die hier immer wieder wiederholte UNIX Philosophie.

Richtig. Diese fußt aber auf genau diesen Erkenntnissen aus der Komplexitätstheorie, deren moderne Grundlagen nämlich aus der gleichen Zeit stammen, in der auch Unix entstand. Die Argumente hören sich vielleicht für Fachfremde "nur" nach Philosophie an, sie basieren aber auf naturwissenschaftlichen Erkenntnissen.

Mein Lieblings-Betriebssystem ist nach wie vor Solaris, wenn es um "rockstable" und Skalierbarkeit für den Produktionseinsatz geht - dagegen ist alles andere (!) billige Hühnerkacke.

Solaris hat seine Berechtigung und ist dort, wo passend eingesetzt, auch wirklich extrem stabil und gut skalierbar. Das Anwendungsspektrum anderer Systeme sieht nicht nur anders aus, die anderen Systeme haben da auch ihre Vorzüge gegenüber Solaris. Auch hier ist Vielfalt gut und notwendig für den Anwender.

 

[mensch183]

Wenn die Systemd SW-Kollektion mehrere Verschiedenen Programme ersetzt, dann muss man die Fehler eben auch mit der Summe der Fehler in diesen Programme vergleichen.

Eben. Der typische Troll verklärt zuerst systemd lediglich zu einem init-Ersatz, was seit Jahren grober Unfug ist, um sich danach über die zu große Komplexität aufzuregen. Mit dieser Art "Logik" muss man sich nicht wirklich auseinandersetzen.

spassig finde ich das da: (von mir arg zusammengekürzt)

...
Mein Lieblings-Betriebssystem ist nach wie vor Solaris, wenn es um "rockstable" und Skalierbarkeit für den Produktionseinsatz geht - dagegen ist alles andere (!) billige Hühnerkacke.
...
Systemd (nur groß am Anfang, weil am Anfang des Satzes ) ist ein Init- und Startsystem für Linux, was meistens ja noch eine gewisse Kompatibilität zu Sysinit (System V) gewährt, aber leider dem Komfortgedanken und der Komfort-Automatisierung"like" Windows zu viel Raum schenkt.
...
Wenn ich auf meinen Desktops Probleme haben, dann hängt systemd immer mittendrin - beim Desktop bringt es mir enigstens ein paar Vorteile, auf dem Server NUR Nachteile.

Wie kann man sowas schreiben, wenn man von Solaris kommt (von einer nicht antiken Version) und damit Server betreibt, also mit smf vertraut sein dürfte, was hinsichtlich Diensteverwaltung für Server doch gerade _DAS_ Vorbild für systemd ist? Sind die XML-freien Konfigfiles bei systemd zu komfortabel?


BTW:
Mein Eindruck insgesamt ist ja, dass die meisten Nutzer eher wenig Probleme mit den Programmen von systemd haben. Ärger machen vor allem die durch mitgelieferte Unitfiles konfigurierten Automatismen, die gern übers Ziel hinausschießen.

 

[matadoerle]

spassig finde ich das da: (von mir arg zusammengekürzt)

Wie kann man sowas schreiben, wenn man von Solaris kommt (von einer nicht antiken Version) und damit Server betreibt, also mit smf vertraut sein dürfte, was hinsichtlich Diensteverwaltung für Server doch gerade _DAS_ Vorbild für systemd ist? Sind die XML-freien Konfigfiles bei systemd zu komfortabel?

Richtig erkannt, wenn Du meinen Beitrag gelesen hast, dann dürfte Dir auch aufgefallen sein, dass ich nichts gegen sinnvolle Veränderungen und Ergänzungen habe.
Solaris hat lange gebraucht und hart daran gearbeitet, smf stabil und leistungsfähig hinzubekommen; ein paar Solaris-spezifische Vorteile gibt es obendrein. Und dass systemd dem Vorbild nacheifert, bestreite ich nicht. Aber die Entscheider und diejenigen, die ihren ganzen Kram auf systemd umgestellt haben, haben leider von Administration und Produktion nicht den Hauch einer Ahnung. Es reicht nicht, ein sehr gutes Vorbild zu haben; man muss dann auch etwas davon verstehen, welche Bedürfnisse und Risiken je nach Anwendung gegeneionander abzuwägen sind.

Ich selber war übrigens von den ersten Ankündigungen bezüglich systemd durchaus angetan; der Streit eskalierte erst, als die Softwareentwickler sich als Allwissenden wähnten und auf Kritik nicht sachlich und problemorientiert, sondern hämisch, polemisch und einfach nur frech reagiert haben. Smf wurde von Server-Admins für ein Server-Betriebssystem entwickelt und getestet, systemd wurde von Kernelentwicklern für eine erleichterte Kernelintegration entwickelt. Das eine ist ein Traktor, das andere ein Rennwagen - was für letzteren gut sein könnte, kann für ersteren eine empfindliche Einschränkung sein.

Devuan verlangt ja nicht, dass Debian oder systemd abgeschafft werden - es wird nur eine Alternative etabliert, die dringend erforderlich ist.

Nur mal ein ganz blödes Beispiel: wir werden in einer Anwendung jetzt EINE Konfigurationszeile ändern; das habe ich in Testsystemen mit entsprechenden Diensten, die neu initialisiert werden müssen, in weniger als fünf Minuten erledigt und geändert. Aber bevor wir das in Produktion einsetzen können, werden einige Manntage und Abstimmung und Tests und Querchecks erforderlich sein - die Umsetzung von der Idee und der nachgewiesenen Machbarkeit bis zum Einsatz ist steinig, lang und manchmal ermüdend. Da sind auch mehr als eine handvoll Leute und einige hundert Server beteiligt .. und bitte, es sollten mehr als zwei oder drei Leute verstehen, WAS und mit welchen Konsequenzen da gemacht wird.

Meine Kollegen und ich haben aber bald keine Zeit mehr für diese Vorsorge, weil mittlerweile jedes Sicherheitsupdate zu einem heiklen Drahtseilakt wird. Ich muss Sicherheitspatches so schnell wie möglich in Produktion bringen, aber der Aufwand, da um diverse "selbstverständliche" Annahmen und Reaktionen von systemd herumzulavieren und zu skripten, wird immer größer. Dazu kommt etwas fatales: auf minimale Abeichungen reagieren manche Komponenten jetzt unvorhersehbar. Es zunehmend unmöglich, das Gesamtsystem wirklich zu verstehen und vorherzusehen - genau das benötige ich aber, wenn ich ein Stabilitätsziel habe was sich den hundert Prozent wenigstens asymptotisch annähern soll.

 

[fuyuhasugu]

Mein Eindruck insgesamt ist ja, dass die meisten Nutzer eher wenig Probleme mit den Programmen von systemd haben. Ärger machen vor allem die durch mitgelieferte Unitfiles konfigurierten Automatismen, die gern übers Ziel hinausschießen.

Das nennt man "blame game" und ist auch keine Entschuldigung sondern sollte eher ein Grund zum Überdenken des Konzepts sein. Solche "Automatismen" werden im Laufe der Zeit auch nicht weniger werden, die Probleme damit also eher größer.

 

[mensch183]

Und um den aus den von Dir aufgeführten Eigenschaften eines solchen Kernelmodells folgenden Nachteilen zu begegnen, wurden LKM eingeführt, wodurch zumindest nur noch die zum jeweiligen Zeitpunkt notwendigen Treiber etc. im Kernelspace Unsinn machen können.

Nein, nicht deshalb. Solange die Programmteile nicht verwendet werden, machen sie keinen Unsinn (sie machen gar nichts) sondern verschwenden nur Platz (DAS ist der tatsächliche Grund für die Module). Wenn die Programmteile verwendet werden und somit potentiell Unsinn machen können, werden sie auch in Modulform vorliegend geladen. In Sachen "weniger potentiell kaputter Code" bringen die Module nichts. Ganz im Gegenteil: Der Mechanismus, Kernelcode aus Files nachladen zu können, vergrößert sogar die Angriffsfläche.

Die Module kamen auf, als nicht mehr jeder Endnutzer einen für seinen Rechner angepassten Kernel selbst baute und Distro-Kernel, in die wirklich alles eingebaut wurde, schlicht zu groß wurden, da insb. die Zahl der Gerätetreiber explodierte. Das ist kein Punkt, der nur monolithische Kernel trifft. Anders strukturierte Kernel müssen(sollten) ebenfalls irgendwie dafür sorgen, nur die Teile zu laden, die benötigt werden. Später, als man Module auch wieder entfernen konnte, kam die bequemere Austauschbarkeit von Kernelcode zur Laufzeit als Pluspunkt hinzu, was vor allem beim Entwickeln hilft. Auch das ist kein Feature, was speziell monolithische Kernel trifft.

Aber egal. Hier ist der Platz um über systemd zu ranten, nicht über Kernelkram.

Apropos Kernel ....

systemd wurde von Kernelentwicklern für eine erleichterte Kernelintegration entwickelt.

Von Kernelentwicklern? *hust* Dann sähe systemd ganz anders aus. Du musst auf die Freedesktop-Gnome-Bloat-Chaos-Ecke zeigen.