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

Status
Für weitere Antworten geschlossen.
Elwood schrieb:
Aber die geplante Funktionalität Sessions zu starten (KDE, Gnome etc) lassen mir schon wieder die Nackenhaare hochstehen...
Zum Vergrößern anklicken....

Wo steht das?

In dem Artikel steht:
"Er schlägt vor, künftig auch Sessions ähnlich zu verwalten wie jetzt die Dienste"

Ähnlich bedeutet, dass sie eine ähnliche Technologie verwenden sollen (Binärdateien), nicht dass sie durch das gleiche (systemd) verwaltet werden sollen.
 
oenone schrieb:
Wo steht das?

In dem Artikel steht:
"Er schlägt vor, künftig auch Sessions ähnlich zu verwalten wie jetzt die Dienste"

Ähnlich bedeutet, dass sie eine ähnliche Technologie verwenden sollen (Binärdateien), nicht dass sie durch das gleiche (systemd) verwaltet werden sollen.
Zum Vergrößern anklicken....

Video: ab 4:45 (~5:57 "Wir möchten, daß dieser Manager systemd wird")
 
darktrym schrieb:
NIH-Problematik.
Zum Vergrößern anklicken....

Not invented Here ist sowieso das größte Probelm von FOSS, jedes Projekt meint zu wissen wie der Hase läuft, das ist bei den Linux Distries doch teilweise katastrophal wie die fragmentieren, das fängt bei so simplem Zeug wie Netzwerkkonfig an, jetzt soll dieser lauchnd Nachbau von Onkel Poettering auch noch in Konkurrenz zu upstart treten.
Im übrigen erinnert mich das Teil frappierend an das was Apple für OS X gebastelt hat.

Es spricht ja nichts dagegen SystemV Init zu modernisieren, aber wieso kucken sich die Helden dann nicht an wie es Sun seinerzeit mit SMF gemacht hat. SMF tatscht weder Projekte an, oder pappt sich als als Layer ins X rein, sondern ist ein ausgeklügeltes System.

Wobei wir da wieder beim "Not invented Here " (deswegen braucht die Welt ja wohl btrfs) Problem sind, Inkompatibilitäten werden mit solchem Quatsch wieder Tür und Tor geöffnet. Vom KISS Ansatz bleibt wenig übrig.

However, kommt gut in die neue Woche. :)
 
Ich glaub' bei einem anderen Vortrag gehört zu haben, dasse einer der Inspirationsquellen für systemd launchd war. Warum trotz brauchbarer Lizenz sich für ein Eigenbau entschieden wurde, konnte mir keiner sagen. Lustigerweise wird auf seiner Seite auch systemd nur mit System-V-Initscripte und upstart verglichen und nicht mit launchd, warum wohl?
Nebenbei existiert als Projektvorschlag bei NetBSD für GSOC dessen Portierung. Dabei wird ganz nebenbei erwähnt, das der FreeBSD-Port verwaist ist.
 
Nun, das Ganze hat halt wie immer zwei Seiten:

1. Klassische rc-Systeme haben in den letzten Jahren durch immer mehr Dienste und immer mehr Abhängigkeiten der Dienste untereinander drastisch an Komplexität gewonnen. FreeBSDs rc-Scripte (eng verwandt mit NetBSD) sind z.B. inzwischen so kompliziert, dass Committs dort hinein nur von einer Gruppe Personen und dort auch nur nach Review gewünscht sind. Das ganze Problem einmal grundlegend neu zu durchdenken ist daher durchaus sinnvoll.

2. Meiner persönlichen Meinung nach geht die Sache aber unter Linux derzeit den falschen Weg. Man versucht den Systemstart zu parallelisieren, damit das System schneller bootet. Das mag bis zu einem gewissen Punkt durchaus sinnvoll sein, über diesem Punkt wird es jedoch eklig. Die Abhängigkeiten sind zu groß, der Ablauf ist nicht mehr deterministisch. Ich sehe z.B. an meiner Ubuntu-VM, dass sie wunderprächtig schnell hochfährt, aber bei jedem vierten Start irgendwas nicht geklappt hat. Mal sind es nur Kleinigkeiten wie nicht hochgekommenes Netzwerk, aber auch nicht startende X-Server habe ich schon gesehen. FreeBSD hat aus dem Grund seine Experimente mit parallelem Systemstart leider gleich komplett beendet, Microsoft ist bei Windows wieder zurückgerudert... Jetztendlich treibt es nur das Auseinanderdriften von Distros weiter voran, denn was auf dem Desktop akzeptabel sein mag, will man auf dem Server nicht unbedingt haben.

Mein Traum wäre eigentlich, dass es ein rc-System gibt, was jeder nutzt. Nur es wird schon deshalb ein Traum bleiben, weil die Linuxer nicht auf ihre Runlevel verzichten wollen und wir BSDler wollen keine Runlevel haben. Ein solches System hätte dann auch einen Schalter "Laufe seriell ab". :)
 
Yamagi: Meinst du rc-Scripts bzw. Änderungen an diesen benötigen ein Review oder Änderungen an /etc/*subr* ?
 
Wenn ich mich richtig erinnere, dürfte Slackware und darauf basierende Distributionen noch rc Scripte verwenden. Oder bin ich nicht auf dem neuesten Stand?
 
Sind denn die Init-Scripte Teil des Kernels?
Apache Lizenz ist dann wieder mit der GPLv3 kompatibel, nebenbei selbst die BSD in alter Version ist durch die Werbeklauseln inkomp.
Aber irgendwie muss ja Red Hat zeigen, wer die Entwicklung vorantreibt, wenn schon Suse für Jahre auf Sparkurs getrimmt wird. Würde mich nicht wundern, wenn die Bremser von Xen aus dem Hause Red Hat stammen, die schließlich diese KVM-Bude gekauft hatten.
 
Crest schrieb:
Yamagi: Meinst du rc-Scripts bzw. Änderungen an diesen benötigen ein Review oder Änderungen an /etc/*subr* ?
Zum Vergrößern anklicken....
Beides. An *subr* grundsätzlich, weil man da alles zerschießen kann. Bei den eigentlichen Scripten kommt es darauf an, um welches Script es sich handelt. Es gibt auch dort einige sehr kritische...
 
Yamagi schrieb:
Nun, das Ganze hat halt wie immer zwei Seiten:

...

Mein Traum wäre eigentlich, dass es ein rc-System gibt, was jeder nutzt. Nur es wird schon deshalb ein Traum bleiben, weil die Linuxer nicht auf ihre Runlevel verzichten wollen und wir BSDler wollen keine Runlevel haben. Ein solches System hätte dann auch einen Schalter "Laufe seriell ab". :)
Zum Vergrößern anklicken....

Man muß auch nicht stur auf den alten Wegen bleiben, keine Frage. Was mich nur nervt ist, daß wieder ein experimentelles System in zig Distros Einzug hält, die zu ersetzenden Teile werden entfernt und dann wird mit Regelmäßigkeit festgestellt, daß es dann doch keine so tolle Idee war. Wenn dies nur Auswirkung auf Linux und sein jeweiliges Userland hätte, würde mich das wenig stören. Nur bleibt es ja meist nicht dabei.

Nun gut, mal schauen, wie sich die Sache entwickelt.

Den Schalter würde ich auch nehmen und bei "seriell" festlöten. Brauche keinen Startup-Benchmark, meine BSD Kisten rennen 24/7 und wenn nicht, dann stört es mich auch wenig, ob ich beim Hochfahren 2-5 Sekunden einspare.
 
ernst schrieb:
Eigentlich schade, dass es selbst bei "freier" Software soviele inkompatible Lizenzen gibt.
Zum Vergrößern anklicken....

Das ist reine Politik, die FSF, bzw. deren Hintermänner sind so GPL fixiert, das alles andere per Default "scheisse" sein muss.

Wer dem wahren Glauben nicht = GPL3 nicht folgt ist sowieso ein Ketzer.

Nur blöd das es in einigen Umgebungen auch so läuft das für Linux einen Sack voll Geld ausgegeben wird, allein für Supportkosten, das Du den Kosten von Microsoft und Oracle fast das Wasser reichen kannst.

In diesen Umgebungen interessiert sich keine Sau für die GPL und deren Segnungen, sondern für einen reibungslosen Rollout.

Aber anscheinend ist der FSF sowas dann scheissegal.

Im Endeffekt hat man dann wieder nur die Wahl zwischen Pest und Cholera.
 
Wenn der Lennart Poettering mal etwas schlaues sagen würde, dann würde es sich lohnen, den hier zu verlinken.

Sogar die Linuxer wollen den Kram nicht haben, den er entwickelt und der entwickelt ja offensichtlich primär nur für die.

Ich hab am Wochenende KDE4 zum Ausprobieren installiert. Ratet mal was das einzige war was nicht ging... RICHTIG... pulseaudio. Und ihr erkennt es leicht, dass pulseaudio läuft... der ganze Desktop hängt nämlich bei einem Sound-Event (egal ob auf Linux oder *BSD).
 
Bei meinem Quake II Client steht inzwischen in der FAQ, dass man bei Soundproblemen bitte Pulseaudio abschalten soll. Aus sehr gutem Grund, denn nachdem ich das Soundsystem grundüberarbeitet hatte, machte es sonst keine Probleme mehr und über Monate bekam ich fast ausschließlich "Bugreports" von Pulseaudio-Nutzern... Bei meinem K(r)ampf mit dem Ding habe ich auch einige sehr interessante Erkenntnisse gehabt. Egal.
 
Witzig ist ja auch die Diskussion in dem von Elwodd verlinkten Slashdot-Link. Ich könnt mich wegschmeißen.

Gruß c.
 
nakal schrieb:
Ich hab am Wochenende KDE4 zum Ausprobieren installiert. Ratet mal was das einzige war was nicht ging... RICHTIG... pulseaudio. Und ihr erkennt es leicht, dass pulseaudio läuft... der ganze Desktop hängt nämlich bei einem Sound-Event (egal ob auf Linux oder *BSD).
Zum Vergrößern anklicken....

Uff, da habe ich wohl mal wieder Glück gehabt, da ich doch KDE 4x auf FreeBSD mag:
Code: 
pkg_info -Ix pulseaudio
pkg_info: no packages match pattern(s)
Bei mir ist Xine das Backend für Phonon und KDE 4x rennt fein auf meinem untoten FreeBSD. :)
 
Ich hab' gerade von Slashdot-Kommentaren einen lustigen Link zu Lennart Poettering bekommen. Ihr könnt ja gerne sehen wie der Mensch drauf ist.

Ich will Euch nur eins sagen, ... es ist furchtbar unhöflich, den Sprecher bei einem Vortrag wiederholt zu unterbrechen. Vor allem wenn man merkt, dass der Sprecher die Software, die man selbst schreibt besser ausgetestet hat, als man selbst.

Hier der Link, viel "Spaß"... Passt auf Eure Hutschnur auf! LOL!

Ich sag nur eins: "Do you hate handicapped people?"... LOL! ;)

Nachtrag... hier noch mehr geniale Ideen von Lennart.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Zurück
Oben