"sondern Debian 6 mit allen oder jedenfalls fast allen Updates."
Das "fast" muss hier leider rot unterstrichen werden. Man startet dazu einfach die Gnewsense 3.0-Live DVD und schaut dann nach, wieviele Sicherheitsupdates zur Verfügung stehen. Dann trägt man einen Sicherheitsupdate-Server für Debian Squeeze ein und schaut dann, was da aktualisiert werden muss. Tja, q.e.d.
Und bitte keinesfalls die in Gnewsense integrierten Webbrowser wie Epiphany oder Iceweasel 3.5.16 benutzen, wegen der ungepatchten Sicherheitslücken. Debian hat hier den Support mit Sicherheitsupdates schon längst eingestellt. Eine gangbare Alternative ist hierbei das Noch-Squeeze-Mozillaprodukte-Angebot von mozilla.debian.net. Zudem ist Squeeze sehr bald EOL.
Man muss sich auch fragen, wie sinnvoll es eigentlich ist, das freie Debian noch ein bisschen mehr "befreien" zu wollen. IMO wäre ein RHEL6 hierfür der weitaus geeignetere Kandidat.
Debians alter Gnome 2.30/2.32-Mix ist aber in Gnewsense schön anzuschauen. Ein Jammer, was da mittlerweile der Linuxgemeinschaft verlorengegangen ist.
Von kamome umidori am Mo, 10. Februar 2014 um 15:37 #
> Debians alter Gnome 2.30/2.32-Mix ist aber in Gnewsense schön anzuschauen. Ein Jammer, was da mittlerweile der Linuxgemeinschaft verlorengegangen ist.
Auch das wird doch nicht mehr richtig gepflegt - es gibt aber einen Nachfolger ... teilweise schon in testing, aktuell noch von http://repo.mate-desktop.org
Debians alter Gnome 2.30/2.32-Mix ist aber in Gnewsense schön anzuschauen. Ein Jammer, was da mittlerweile der Linuxgemeinschaft verlorengegangen ist.
Bedanke dich bei Red Hat dafür. Red Hat und seine Entwickler töten gerade Gnu/Linux (systemd, Restricted Boot, uvm.). Auch deshalb ist es klug, Red Hat zu meiden. Der jämmerliche Zustand von gNewSense, Trisquel & Co untermauert das nur.
Gnewsense und Trisquel verwenden ebenso wie Ubuntu kein Systemd als Default.
Ich empfinde Systemd für Unixsysteme als kompletten Overkill, genauso over-engineered wie z.B. Grub2. Es ist aber zur Zeit das "Init-System", das in Zukunft wohl am besten supportet sein wird. Upstream hat eine Shuttleworthsche "Mist-Lizenz", so dass Debian hier automatisch zum Upstream werden müsste, wenn es sich für Upstart entscheidet. Und wenn man z.B. Sysvinit auswählen würde, dann steht sofort die Frage im Raum, wer das dann weiterentwickeln und supporten soll.
Auf der openSUSE-Mailingliste gab es auch einmal eine diesbezügliche Streiterei. OpenSUSE hätte auch Sysvinit gerne weiterhin unterstützt, doch auf die Frage, wer in der Community die Maintainerschaft hierfür übernehmen möchte, gab es leider keine entsprechenden Einlassungen.
Man kann nicht mehrere Init-Systeme dauerhaft supporten.
Man überlegt sich anscheinend hierbei, wie man die Konfiguration im Nachhinein möglichst kompliziert gestaltet, damit man als gemeiner Nutzer nicht einfach alles gemäß dem eigenen Geschmack ruck-zuck anpassen kann. Für ein Init-System mischt sich Systemd in zuviele andere Angelegenheiten ein und möchte anscheinend verhindern, dass normale Nutzer möglichst einfach an Systemd herumschrauben können.
Mit Systemd verliert Linux einen Teil seines ursprünglichen Unixcharakters (ein Tool, eine Aufgabe).
Der Vergleich mit Grub2 hinkt zwar etwas, nur hat man bei Grub2 genau diejenigen Vorteile aufgegeben, die einstmals Grub1 gegenüber Lilo als vorteilhaft erscheinen ließen. /Sbin/lilo heißt jetzt plötzlich gewissermaßen z.B. update-grub, Grub1 benötigte dieses Unfeature nicht, um bloße textliche, dauerhafte Änderungen zu übernehmen.
Ähnlich ist es von der Philosophie her bei Systemd. Einfach ist anders, nämlich etwa so wie bei Sysvinit.
Ein Teil des folgenden Gedichtes (nämlich der rationale, nicht beleidigende Teil) drückt etwa das aus, was ich auch denke (natürlich nicht das, was im dortigen Text Lennart Pöttering mit der NS-Zeit und dem Zweiten Weltkrieg i Zusammenhang bringen soll): https://lists.debian.org/debian-ctte/2014/02/msg00376.html
Ich zitiere aus dem obigen Link:
------------------ Zitat Anfang "Fuck systemd from the bottom of my heart. Fuck it. Fuck it.
FUCK SYSTEMD.
I do not want to learn systemd. I do not want to deal with systemd. I hate the way it does things. I hate the way their community works.
I hate that it does so much. I hate that it changes the system. I hate what it is: system Daemon.
I want an init that does few things. An init that doesn't crash (not systemd!) An init that doesn't care that I have encrypted hdd, and _never_ did care. An init that's small and doesn't contain security errors (the larger the code the more there are, and nope C is not run directly on the iron, so whatever you think you're coding, guess again because you don't have as much control as you think once the real code is running on the machine)
SystemD isn't it. I hate the attitude of it's fuck faced devs and fans. It's either them or us. They make that clear.
Fuck them, Fuck their system. Fuck SystemD Fuck SystemD.
We are "obsolete" and must obey their way. Our beliefs are superceded, says them. Fuck Systemd.
Viva unix (please!). Fuck Systemd." ------------------ Zitat Ende
[..] dass normale Nutzer möglichst einfach an Systemd herumschrauben können.
Der "normale" Benutzer will gar nicht am System rumschrauben. Er will einfach, dass es funktioniert. Rumschrauben tun nur die Benutzer, die meinen sie sprechen für alle.
Mit Systemd verliert Linux einen Teil seines ursprünglichen Unixcharakters (ein Tool, eine Aufgabe).
Dumm nur, dass dieser Charakter kein, in Stein gemeiseltes, Dogma war und ist, sondern einfach aus der Historie raus entstanden ist. Speicherplatz und RAM war damals nämlich sehr kostbar.
Zudem sind die Unix-Tools mitnichten alle nach der Philosophie "Ein Tool für eine Aufgabe" aufgebaut. "ls" übernimmt z.B. auch die Formatierung der Darstellung, dabei könnte man das auch per Pipe mit einem anderen Tool realisieren.
Mit Systemd verliert Linux einen Teil seines ursprünglichen Unixcharakters (ein Tool, eine Aufgabe).
Das Gegenteil ist der Fall. Bei SysVInit z.B ist es so, das Funktionalitäten redundant in verschiedenen Shell-Skripten implementiert ist. Das ist nicht nur fürchterlich unübersichtlich, sondern auch wenig performant.
In systemd hast du pro Dienst eine kleine Konfigurationsdatei, in dem du das Verhalten festlegst. Du muss nicht alles noch mal neu implementieren, weil systemd das schon gemacht hat.
Man überlegt sich anscheinend hierbei, wie man die Konfiguration im Nachhinein möglichst kompliziert gestaltet, damit man als gemeiner Nutzer nicht einfach alles gemäß dem eigenen Geschmack ruck-zuck anpassen kann.
Auch hier sehe ich das völlig anders. Ein normaler Nutzer kann keine Shell-Skripte bearbeiten, die Syntax eines systemd-Unitfiles ist aber leicht zu erlernen. In der Regel kommt der Nutzer mit systemd gar nicht in Berührung.
Dieses "Gedicht" war wohl eher ein Eigentor, nicht wahr?
"Man überlegt sich anscheinend hierbei, wie man die Konfiguration im Nachhinein möglichst kompliziert gestaltet, damit man als gemeiner Nutzer nicht einfach alles gemäß dem eigenen Geschmack ruck-zuck anpassen kann."
Inwiefern empfindest du den den typischen Init-Script als einfach? Abgesehen davon, das die meisten immer und immer wieder ein identisches Verhalten implementieren, sind sie weder sonderlich übersichtlich - wenn sie komplexere Dienste steuern - noch wirklich immer sauber nach Konfiguration und Steuerung getrennt.
Bezüglich des "Liedes": Es enthält keine wirklich greifbaren Argumente. Was willst du damit aussagen? Nebenher, wessen Sockenpuppe ist das eigentlich?
Es sei zudem angemerkt, das Systemd der Unix-Philosophie sogar eher folgt als dies bei SysVinit der Fall ist. Seine Teile sind besser wiederverwendbar, zudem folgt eine Sammlung von klar definierten Programmen mit definierten Schnittstellen dem Prinzip eher als eine Sammlung von Shellscripten, die gerne mal tun und lassen was sie wollen
Wenn Du den Level betrachtest, auf welchem man z.B. einfach angibt, ob man einen Dienst stoppen oder starten möchte, dann ist gegen Systemd nichts zu sagen. Für Desktopnutzer ergibt sich zu Sysvinit kein wirklicher Unterschied, es ist vielleicht sogar besser zu handhaben, da es sich um einen großen monolithischen Dämon für "alles" handelt.
IMO sind aber Sysvinits Startskripte leichter zu debuggen und zu ändern, als die fertig kompilerten Systemd-Module, die u.a. in C geschrieben sind und entsprechend schwerer so "nebenher" zu modifizieren sind.
Durch Systemd mutiert der Admin so zum Nutzer des Systems, dessen Eigentümer er vorher gewesen ist.
Das wird dann wichtig, wenn tatsächliche Probleme auftreten, die mit der Yast-Attitüde üblicher Desktopsystem nicht zu lösen sind.
So bootet Systemd gemeinhin schneller als Sysvinit, weil die einzelnen Startsegmente parallel übers Sytem gejagt werden. Sysvinit startet aber auch schneller, wozu allerdings eigene Systemoptimierungen notwendig sind. Das heißt, dass der Admin Ahnung in punkto Syvsinit haben muss. In punkto Systemd ist das so nicht mehr notwendig, da es sich hier um eine reine Nutzerperspektive handelt. An die Stelle der Lösung durch modifizierte Skripte tritt nun unter Umständen der bloße Bugreport gegenüber Red Hat.
Systemd kenne ich allerdings nicht genau genug. OpenSUSE 12.2 ist hierbei die erste Distro, über die ich mit Systemd in Kontakt gekomemn bin. Die Umstellung auf Sysvinit war hier allerdings noch so einigermaßen möglich.
Da auch Systemd im Quellcode vorliegt, sehe ich nicht warum ein Admin diesen nicht selbst als Basis für seine Arbeit nutzen sollte. Ein Admin, der nur fertige Scripte anschauen muss, ist für mich kein guter Admin. Sicherlich, C-Code ist schwerer zu lesen, auf der anderen Seite gibt es auch weniger Grund, diesen anzufassen. Schon bei den Init-Scripten gab es oft keinen Grund, außer Monkeypatching. Fas ist in Zukunft etwas schwerer, aber am Ende durchaus auch sinnvoller es ordentlich zu lösen.
Welch erziehungswissenschftlich angehauchter Enthusiasmus, meinen herzlichen Glückwunsch zu solch einem überbordenden, wohlwollenden Impetus.
Systemd managt offenbar alles u.a. vom Init bzw. eigentlichen Start des Systems über das Session Management und Nutzer-Logins bis hin zu den Logging- und Netzwerkdiensten sowie Cron-Jobs und Multi-Seat-Support.
Unabhängig von der Frage, ob so eine Heransgehensweise nun vorteilhaft ist oder nicht, das ist IMO nicht der oben angesprochene Unix-Weg: Systemd ist im Gegensatz zu Sysvinit nämlich ein Mega-Dämon für "fast alles", nicht nur für Init.
"systemd ist im Gegensatz zu Sysvinit nämlich ein Mega-Dämon für "fast alles", nicht nur für Init."
Nein, ist er nicht. Systemd ist ein relativ schlanker Dämon. Was du meinst ist das Systemd Projekt, das weitere (meist eher kleine) Dienste und Programme enthält.
Deinen Beitrag kann ich nur unterschreiben, besonders die Aspekte Overkill, over-engineered und "Mist-Lizenz". Volle Zustimmung.
Wegen dieser Entwicklungen sind Gnewsense und Trisquel in ihrem Zustand. Diese Projekte sind personell recht dünn besetzt und von den Entscheidungen der Basis-Distros abhängig.
Red Hat ist also plötzlich Schuld, wenn es in gNewSense oder Trisquel nicht gut läuft? Schuld auf andere abzuschieben ist natürlich einfacher als das Problem bei sich zu suchen.
Darf ich ketzerischerweise fragen, inwiefern gNewSense freier ist als Debian ohne non-free-Pakete (was ja immerhin der Default-Zustand ist)? Wenn es lediglich um das Hosten von non-free-Paketen oder Hinweise auf solche Pakete geht, warum hinkt man dann (dem sowieso schon gut abgehangenen) Debian um 3 Jahre hinterher? Auf der gNewSense-Website werde ich nicht erleuchtet, dort wird lediglich allgemein über die Vorteile freier Software referiert. Mir erscheinen die Vorteile von gNewSense zu klein, um die Installation derart veralteter Pakete zu rechtfertigen. Aber vielleicht fehlt mir der Weitblick?
IMO sind das nur noch Kleinigkeiten: So ist z.B. irgendein kleines File in Xdrawchem unfrei, weil hier der Autor eine unfreie Lizenz gewählt hat. IMO ist da aber nichts wirklich Bewegendes dabei.
Da ist nichts, was man nicht innerhalb Debians über den Bugtracker des Projekts erledigen könnte.
Gnewsense hängt deshalb derart hinterher, weil die Community sehr klein ist und bereits jahrelang an der Squeeze-Ausgabe arbeitete, bevor diese dann - wohlgemerkt nach dem Wheezy-Release Debians - herauskam. Diese Verffentlichung war notwendig, da man den vorherigen Release- die Gnewsense Debian Lenny-Version - leider skippen musste.
Ich wiederhole mich zwar, aber das Folgende kann gar nicht oft genug gesagt werden: Aufgrund der fehlenden Sicherheitsupdates z.B. bei der mitgelieferten Webbrowser-Software kann man Gnewsense 3 IMO aber nicht für Newbies empfehlen. Die zugehörigen Webkit- (Epiphany-Webbrowser aus Gnome 2.30/2.32) und Gecko-Engines (Iceweasel 3.5) sind uralt und stehen ohne jeden Sicherheitssupport da.
Ich glaube, ein Kritikpunkt an Debian ist, dass unfreie Firmware zwar in den Non-Free Bereich ausgelagert ist, der Kernel aber immer noch darauf verlinkt und bei entsprechender Hardware danach verlangt. Bei Linux-libre ist unfreie Firmware hingegen komplett entfernt. Offenbar ist der Hintergedanke, dass der User mit unfreier Software gar nicht in Berührung kommen soll. Meiner Meinung nach hat das aber nichts mehr mit Freiheit zu tun, sondern ist Bevormundung.
Genau das haben Sie wohl mit Debian 6 gemacht. Nur brauchten Sie so lange, dass inzwischen Debian 7 herauskam :).
Hier ist übrigens eine Liste mit Software, die gegen die Richtlinien der FSF verstößt: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines. Da wird zum Beispiel bei Iceweasel, der Debian-Version des Firefox, bemängelt, dass dieser unfreie Software empfiehlt. Deshalb solle man Icecat nehmen, die GNU-Version des Firefox. Bei der Debian-Reference wird bemängelt, dass darin beschrieben wird, wie man unfreie Software installieren kann. Solche Kleinigkeiten ziehen sich durch diese Liste durch.
Das was da aufgeführt ist größtenteils ein Witz. Aus den Augen aus dem Sinn? Kein Wunder, dass sich kaum Leute finden um Hinweise auf non-free Software rauszupatchen, da muss man schon hartgesottener RMS Anhänger sein.
Der Rest besteht wohl Hauptsächlich aus irgendwelchen übersehenen non-free Dateien in Paketen was bei Debian (und vermutlich vielen anderen Distributionen) sowieso als ernstzunehmender Bug gilt und an der Stelle gefixt werden kann.
Genau das haben Sie wohl mit Debian 6 gemacht. Nur brauchten Sie so lange, dass inzwischen Debian 7 herauskam :).
Hier ist übrigens eine Liste mit Software, die gegen die Richtlinien der FSF verstößt: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines. Da wird zum Beispiel bei Iceweasel, der Debian-Version des Firefox, bemängelt, dass dieser unfreie Software empfiehlt. Deshalb solle man Icecat nehmen, die GNU-Version des Firefox. Bei der Debian-Reference wird bemängelt, dass darin beschrieben wird, wie man unfreie Software installieren kann. Solche Kleinigkeiten ziehen sich durch diese Liste durch.
"sondern Debian 6 mit allen oder jedenfalls fast allen Updates."
Das "fast" muss hier leider rot unterstrichen werden. Man startet dazu einfach die Gnewsense 3.0-Live DVD und schaut dann nach, wieviele Sicherheitsupdates zur Verfügung stehen. Dann trägt man einen Sicherheitsupdate-Server für Debian Squeeze ein und schaut dann, was da aktualisiert werden muss. Tja, q.e.d.
Und bitte keinesfalls die in Gnewsense integrierten Webbrowser wie Epiphany oder Iceweasel 3.5.16 benutzen, wegen der ungepatchten Sicherheitslücken. Debian hat hier den Support mit Sicherheitsupdates schon längst eingestellt. Eine gangbare Alternative ist hierbei das Noch-Squeeze-Mozillaprodukte-Angebot von mozilla.debian.net. Zudem ist Squeeze sehr bald EOL.
Man muss sich auch fragen, wie sinnvoll es eigentlich ist, das freie Debian noch ein bisschen mehr "befreien" zu wollen. IMO wäre ein RHEL6 hierfür der weitaus geeignetere Kandidat.
Debians alter Gnome 2.30/2.32-Mix ist aber in Gnewsense schön anzuschauen. Ein Jammer, was da mittlerweile der Linuxgemeinschaft verlorengegangen ist.
> Debians alter Gnome 2.30/2.32-Mix ist aber in Gnewsense schön anzuschauen. Ein Jammer, was da mittlerweile der Linuxgemeinschaft verlorengegangen ist.
Auch das wird doch nicht mehr richtig gepflegt - es gibt aber einen Nachfolger
... teilweise schon in testing, aktuell noch von http://repo.mate-desktop.org
Bedanke dich bei Red Hat dafür. Red Hat und seine Entwickler töten gerade Gnu/Linux (systemd, Restricted Boot, uvm.). Auch deshalb ist es klug, Red Hat zu meiden. Der jämmerliche Zustand von gNewSense, Trisquel & Co untermauert das nur.
Gnewsense und Trisquel verwenden ebenso wie Ubuntu kein Systemd als Default.
Ich empfinde Systemd für Unixsysteme als kompletten Overkill, genauso over-engineered wie z.B. Grub2. Es ist aber zur Zeit das "Init-System", das in Zukunft wohl am besten supportet sein wird. Upstream hat eine Shuttleworthsche "Mist-Lizenz", so dass Debian hier automatisch zum Upstream werden müsste, wenn es sich für Upstart entscheidet. Und wenn man z.B. Sysvinit auswählen würde, dann steht sofort die Frage im Raum, wer das dann weiterentwickeln und supporten soll.
Auf der openSUSE-Mailingliste gab es auch einmal eine diesbezügliche Streiterei. OpenSUSE hätte auch Sysvinit gerne weiterhin unterstützt, doch auf die Frage, wer in der Community die Maintainerschaft hierfür übernehmen möchte, gab es leider keine entsprechenden Einlassungen.
Man kann nicht mehrere Init-Systeme dauerhaft supporten.
Man überlegt sich anscheinend hierbei, wie man die Konfiguration im Nachhinein möglichst kompliziert gestaltet, damit man als gemeiner Nutzer nicht einfach alles gemäß dem eigenen Geschmack ruck-zuck anpassen kann. Für ein Init-System mischt sich Systemd in zuviele andere Angelegenheiten ein und möchte anscheinend verhindern, dass normale Nutzer möglichst einfach an Systemd herumschrauben können.
Mit Systemd verliert Linux einen Teil seines ursprünglichen Unixcharakters (ein Tool, eine Aufgabe).
Der Vergleich mit Grub2 hinkt zwar etwas, nur hat man bei Grub2 genau diejenigen Vorteile aufgegeben, die einstmals Grub1 gegenüber Lilo als vorteilhaft erscheinen ließen. /Sbin/lilo heißt jetzt plötzlich gewissermaßen z.B. update-grub, Grub1 benötigte dieses Unfeature nicht, um bloße textliche, dauerhafte Änderungen zu übernehmen.
Ähnlich ist es von der Philosophie her bei Systemd. Einfach ist anders, nämlich etwa so wie bei Sysvinit.
Ein Teil des folgenden Gedichtes (nämlich der rationale, nicht beleidigende Teil) drückt etwa das aus, was ich auch denke (natürlich nicht das, was im dortigen Text Lennart Pöttering mit der NS-Zeit und dem Zweiten Weltkrieg i Zusammenhang bringen soll):
https://lists.debian.org/debian-ctte/2014/02/msg00376.html
Ich zitiere aus dem obigen Link:
------------------ Zitat Anfang
"Fuck systemd from the bottom of my heart.
Fuck it.
Fuck it.
FUCK SYSTEMD.
I do not want to learn systemd.
I do not want to deal with systemd.
I hate the way it does things.
I hate the way their community works.
I hate that it does so much.
I hate that it changes the system.
I hate what it is: system Daemon.
I want an init that does few things.
An init that doesn't crash (not systemd!)
An init that doesn't care that I have encrypted hdd, and _never_ did care.
An init that's small and doesn't contain
security errors (the larger the code the more there are,
and nope C is not run directly on the iron, so whatever
you think you're coding, guess again because you don't
have as much control as you think once the real code
is running on the machine)
SystemD isn't it.
I hate the attitude of it's fuck faced devs and fans.
It's either them or us.
They make that clear.
Fuck them, Fuck their system. Fuck SystemD
Fuck SystemD.
We are "obsolete" and must obey their way.
Our beliefs are superceded, says them.
Fuck Systemd.
Viva unix (please!).
Fuck Systemd."
------------------ Zitat Ende
Zudem sind die Unix-Tools mitnichten alle nach der Philosophie "Ein Tool für eine Aufgabe" aufgebaut. "ls" übernimmt z.B. auch die Formatierung der Darstellung, dabei könnte man das auch per Pipe mit einem anderen Tool realisieren.
Das Gegenteil ist der Fall. Bei SysVInit z.B ist es so, das Funktionalitäten redundant in verschiedenen Shell-Skripten implementiert ist. Das ist nicht nur fürchterlich unübersichtlich, sondern auch wenig performant.
In systemd hast du pro Dienst eine kleine Konfigurationsdatei, in dem du das Verhalten festlegst. Du muss nicht alles noch mal neu implementieren, weil systemd das schon gemacht hat.
Auch hier sehe ich das völlig anders. Ein normaler Nutzer kann keine Shell-Skripte bearbeiten, die Syntax eines systemd-Unitfiles ist aber leicht zu erlernen. In der Regel kommt der Nutzer mit systemd gar nicht in Berührung.
Dieses "Gedicht" war wohl eher ein Eigentor, nicht wahr?
"Man überlegt sich anscheinend hierbei, wie man die Konfiguration im Nachhinein möglichst kompliziert gestaltet, damit man als gemeiner Nutzer nicht einfach alles gemäß dem eigenen Geschmack ruck-zuck anpassen kann."
Inwiefern empfindest du den den typischen Init-Script als einfach?
Abgesehen davon, das die meisten immer und immer wieder ein identisches Verhalten implementieren, sind sie weder sonderlich übersichtlich - wenn sie komplexere Dienste steuern - noch wirklich immer sauber nach Konfiguration und Steuerung getrennt.
Bezüglich des "Liedes": Es enthält keine wirklich greifbaren Argumente. Was willst du damit aussagen?
Nebenher, wessen Sockenpuppe ist das eigentlich?
Es sei zudem angemerkt, das Systemd der Unix-Philosophie sogar eher folgt als dies bei SysVinit der Fall ist. Seine Teile sind besser wiederverwendbar, zudem folgt eine Sammlung von klar definierten Programmen mit definierten Schnittstellen dem Prinzip eher als eine Sammlung von Shellscripten, die gerne mal tun und lassen was sie wollen
Wenn Du den Level betrachtest, auf welchem man z.B. einfach angibt, ob man einen Dienst stoppen oder starten möchte, dann ist gegen Systemd nichts zu sagen. Für Desktopnutzer ergibt sich zu Sysvinit kein wirklicher Unterschied, es ist vielleicht sogar besser zu handhaben, da es sich um einen großen monolithischen Dämon für "alles" handelt.
IMO sind aber Sysvinits Startskripte leichter zu debuggen und zu ändern, als die fertig kompilerten Systemd-Module, die u.a. in C geschrieben sind und entsprechend schwerer so "nebenher" zu modifizieren sind.
Durch Systemd mutiert der Admin so zum Nutzer des Systems, dessen Eigentümer er vorher gewesen ist.
Das wird dann wichtig, wenn tatsächliche Probleme auftreten, die mit der Yast-Attitüde üblicher Desktopsystem nicht zu lösen sind.
So bootet Systemd gemeinhin schneller als Sysvinit, weil die einzelnen Startsegmente parallel übers Sytem gejagt werden. Sysvinit startet aber auch schneller, wozu allerdings eigene Systemoptimierungen notwendig sind. Das heißt, dass der Admin Ahnung in punkto Syvsinit haben muss. In punkto Systemd ist das so nicht mehr notwendig, da es sich hier um eine reine Nutzerperspektive handelt. An die Stelle der Lösung durch modifizierte Skripte tritt nun unter Umständen der bloße Bugreport gegenüber Red Hat.
Systemd kenne ich allerdings nicht genau genug. OpenSUSE 12.2 ist hierbei die erste Distro, über die ich mit Systemd in Kontakt gekomemn bin. Die Umstellung auf Sysvinit war hier allerdings noch so einigermaßen möglich.
Da auch Systemd im Quellcode vorliegt, sehe ich nicht warum ein Admin diesen nicht selbst als Basis für seine Arbeit nutzen sollte. Ein Admin, der nur fertige Scripte anschauen muss, ist für mich kein guter Admin.
Sicherlich, C-Code ist schwerer zu lesen, auf der anderen Seite gibt es auch weniger Grund, diesen anzufassen. Schon bei den Init-Scripten gab es oft keinen Grund, außer Monkeypatching. Fas ist in Zukunft etwas schwerer, aber am Ende durchaus auch sinnvoller es ordentlich zu lösen.
grub.cfg:
Was ist an der grub2 Konfiguration kompliziert?
Was ist an der grub2 Konfiguration kompliziert?
Vielleicht die Doku, weil sie 1000 Spezialfälle abhandelt, ohne die Grundlagen mit einem einfachen Beispiel wie Deinem zu vermitteln?
Ist allerdings schon länger her, dass ich mich damit beschäftigt hatte; es war einfacher, wieder zu grub1 zurückzukehren.
Mag sein, dass die Doku inzwiwschen besser geworden ist.
Welch erziehungswissenschftlich angehauchter Enthusiasmus, meinen herzlichen Glückwunsch zu solch einem überbordenden, wohlwollenden Impetus.
Systemd managt offenbar alles u.a. vom Init bzw. eigentlichen Start des Systems über das Session Management und Nutzer-Logins bis hin zu den Logging- und Netzwerkdiensten sowie Cron-Jobs und Multi-Seat-Support.
Unabhängig von der Frage, ob so eine Heransgehensweise nun vorteilhaft ist oder nicht, das ist IMO nicht der oben angesprochene Unix-Weg: Systemd ist im Gegensatz zu Sysvinit nämlich ein Mega-Dämon für "fast alles", nicht nur für Init.
"systemd ist im Gegensatz zu Sysvinit nämlich ein Mega-Dämon für "fast alles", nicht nur für Init."
Nein, ist er nicht. Systemd ist ein relativ schlanker Dämon.
Was du meinst ist das Systemd Projekt, das weitere (meist eher kleine) Dienste und Programme enthält.
Deinen Beitrag kann ich nur unterschreiben, besonders die Aspekte Overkill, over-engineered und "Mist-Lizenz". Volle Zustimmung.
Wegen dieser Entwicklungen sind Gnewsense und Trisquel in ihrem Zustand. Diese Projekte sind personell recht dünn besetzt und von den Entscheidungen der Basis-Distros abhängig.
Red Hat ist also plötzlich Schuld, wenn es in gNewSense oder Trisquel nicht gut läuft? Schuld auf andere abzuschieben ist natürlich einfacher als das Problem bei sich zu suchen.
Darf ich ketzerischerweise fragen, inwiefern gNewSense freier ist als Debian ohne non-free-Pakete (was ja immerhin der Default-Zustand ist)? Wenn es lediglich um das Hosten von non-free-Paketen oder Hinweise auf solche Pakete geht, warum hinkt man dann (dem sowieso schon gut abgehangenen) Debian um 3 Jahre hinterher? Auf der gNewSense-Website werde ich nicht erleuchtet, dort wird lediglich allgemein über die Vorteile freier Software referiert. Mir erscheinen die Vorteile von gNewSense zu klein, um die Installation derart veralteter Pakete zu rechtfertigen. Aber vielleicht fehlt mir der Weitblick?
IMO sind das nur noch Kleinigkeiten: So ist z.B. irgendein kleines File in Xdrawchem unfrei, weil hier der Autor eine unfreie Lizenz gewählt hat. IMO ist da aber nichts wirklich Bewegendes dabei.
Da ist nichts, was man nicht innerhalb Debians über den Bugtracker des Projekts erledigen könnte.
Siehe hierzu:
https://savannah.nongnu.org/bugs/?39670
Gnewsense hängt deshalb derart hinterher, weil die Community sehr klein ist und bereits jahrelang an der Squeeze-Ausgabe arbeitete, bevor diese dann - wohlgemerkt nach dem Wheezy-Release Debians - herauskam. Diese Verffentlichung war notwendig, da man den vorherigen Release- die Gnewsense Debian Lenny-Version - leider skippen musste.
Ich wiederhole mich zwar, aber das Folgende kann gar nicht oft genug gesagt werden:
Aufgrund der fehlenden Sicherheitsupdates z.B. bei der mitgelieferten Webbrowser-Software kann man Gnewsense 3 IMO aber nicht für Newbies empfehlen. Die zugehörigen Webkit- (Epiphany-Webbrowser aus Gnome 2.30/2.32) und Gecko-Engines (Iceweasel 3.5) sind uralt und stehen ohne jeden Sicherheitssupport da.
Ich glaube, ein Kritikpunkt an Debian ist, dass unfreie Firmware zwar in den Non-Free Bereich ausgelagert ist, der Kernel aber immer noch darauf verlinkt und bei entsprechender Hardware danach verlangt. Bei Linux-libre ist unfreie Firmware hingegen komplett entfernt.
Offenbar ist der Hintergedanke, dass der User mit unfreier Software gar nicht in Berührung kommen soll. Meiner Meinung nach hat das aber nichts mehr mit Freiheit zu tun, sondern ist Bevormundung.
Dann wäre es doch schlauer, wenn sie Debian 7 übernehmen und lediglich die Kernelversionen durch eigene ersetzen, oder?
Genau das haben Sie wohl mit Debian 6 gemacht. Nur brauchten Sie so lange, dass inzwischen Debian 7 herauskam :).
Hier ist übrigens eine Liste mit Software, die gegen die Richtlinien der FSF verstößt: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines. Da wird zum Beispiel bei Iceweasel, der Debian-Version des Firefox, bemängelt, dass dieser unfreie Software empfiehlt. Deshalb solle man Icecat nehmen, die GNU-Version des Firefox. Bei der Debian-Reference wird bemängelt, dass darin beschrieben wird, wie man unfreie Software installieren kann. Solche Kleinigkeiten ziehen sich durch diese Liste durch.
Na wenn die FSF sonst keine Probleme hat…
Das was da aufgeführt ist größtenteils ein Witz. Aus den Augen aus dem Sinn? Kein Wunder, dass sich kaum Leute finden um Hinweise auf non-free Software rauszupatchen, da muss man schon hartgesottener RMS Anhänger sein.
Der Rest besteht wohl Hauptsächlich aus irgendwelchen übersehenen non-free Dateien in Paketen was bei Debian (und vermutlich vielen anderen Distributionen) sowieso als ernstzunehmender Bug gilt und an der Stelle gefixt werden kann.
Genau das haben Sie wohl mit Debian 6 gemacht. Nur brauchten Sie so lange, dass inzwischen Debian 7 herauskam :).
Hier ist übrigens eine Liste mit Software, die gegen die Richtlinien der FSF verstößt: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines. Da wird zum Beispiel bei Iceweasel, der Debian-Version des Firefox, bemängelt, dass dieser unfreie Software empfiehlt. Deshalb solle man Icecat nehmen, die GNU-Version des Firefox. Bei der Debian-Reference wird bemängelt, dass darin beschrieben wird, wie man unfreie Software installieren kann. Solche Kleinigkeiten ziehen sich durch diese Liste durch.
Keith hat es geschafft zumindest die 17er IceCat Version unter gNewSense 3.1 zu bauen:
http://www.sohcahtoa.org.uk/pages/gNewSense.html