CRE209 Das Linux System

systemd leitet die neue Generation der Linux Systemarchitektur ein

Episode image forCRE209 Das Linux System

Der einst von Linus Torvalds geschaffene Betriebssystemkernel Linux ist eine freie Reimplementierung der UNIX Betriebssystemfamilie und hat sich in den letzten 20 Jahren sehr eigenständig entwickelt. Der Rest des Systems, das Userland, hat sich aber noch sehr stark an der klassischen Struktur von UNIX orientiert. Mit der Initiative systemd hat sich dies geändert und es entsteht eine sehr eigenständige Definition einer Linux-Systemebene, die sich zwischen Kernel und Anwendungen entfaltet und dort die Regeln der Installation und Systemadministration neu definiert.

Ich spreche mit dem Initiator des Projekts, Lennart Poettering, der schon vorher verschiedene Subsysteme zur Linux-Landschaft beigetragen hat über die Motivation und Struktur des Projekts, den aktuellen und zukünftigen Möglichkeiten der Software und welche kulturellen Auswirkungen der Einzug einer neuen Abstraktionsebene mit sich bringt.

avatar
Tim Pritlove
avatar
Lennart Poettering
Shownotes

116 Gedanken zu „CRE209 Das Linux System

  1. Hi,
    Tolle und Informative Folge, Danke.

    Ich denke auch das Secure Boot an sich eine gute Idee ist, aber wer Hindert denn ein die z.B. US Regierung daran ein Gesetz zu erlassen das da per Default eine NSA Key drin sein muss? Es gibt ja jetzt schon Gesetze die US Firmen zwingen Daten raus zu geben und die Firma darf dann nicht darüber sprechen.

    Das ist jetzt nur eine dunkle Erinnerung an ein News von vor einiger Zeit, aber gibt es in Deutschland nicht schon so ein Gesetz wo so was in etwa drin steht „…es muss die Möglichkeit bestehen bis zu 3 (Geheim) Diensten Überwachungszeug einzufugen ohne das sie es gegen seitig merken/behindert werden…“

  2. Interessant. Als ich das Thema der Sendung las, wollte ein Teil von mir die Sendung erst skippen, da ich noch gerade den grossen Systemd-Kampf in Debian im Hinterkopf und eher die Argumente der Gegner angenommen hatte. Einem anderen Teil von mir was aber auch bewusst, dass ich eigentlich gar nicht viel Substanzielles zu dem Thema wusste. Also Sendung angehoert und das war auch gut so. Schoene Sendung. Technisch sowie auch menschlich.

  3. Sehr Interessantes Interview.
    Die Einlassungen zu Secure Boot waren aber sehr oberflächlich. Ich denke das Secure Boot mehr Akzeptanz finden würde wenn der Nutzer im Desktop bereich die Hoheit über die Schlüssel bekommt und sie selbst erzeugen kann auf seinen Rechner. Genauso wie ich das auch mit gnupg mache. So das ich selbst bestimmen kann welche OS auf dem Rechner läuft und dieses dann auch absichern kann, ohne das ich „nicht vertrauenswürdigen Firmen“ ausgeliefert bin.
    Wer das will gerne, ich will das nicht!

    • Aber ist nicht genau das der aktuelle Stand auf Desktop-Rechnern? Man kann seine eigenen Schlüssel erzeugen, damit den Kernel (oder was auch immer) signieren, und dann im UEFI-Setup diesem Schlüssel explizit vertrauen. Nur weil das für die meisten Nutzer zu komplex ist, lassen manche Linux-Distributoren ihre Binaries (indirekt) von Microsoft signieren.

      • Ich fand auch es war ein sehr interessanter und informativer Podcast. Mir ist einiges klar geworden. War auch verständlich für nicht Systementwickler.

        Zu UEFI habe ich 2 größere Kritikpunkte. Zum Einen an die Stelle muss auch Opensource Coreboot.
        Zum Andern ist die Einstiegsschwelle hier größer. Benutzer werden schnell abgeschreckt wenn es am Anfang von der Installation kompliziert wird.
        Vor allem auch beim Chromebook. Es müsste schon irgendwie subtiler darauf aufmerksam gemacht werden als groß Developer Mode. Hab ich zumindest so verstanden.
        Systemd kann da natürlich nichts drann ändern, aber ein kritischer Nebensatz oder kurz versuchen den Perspektivwechsel zum normalen Nutzer zu machen, wäre gut.

        Ansonsten danke dafür!

  4. Mal wieder ein knaller. Da hab es grad einen ultra-spannenden CRE neulich und dann steht schon wieder einer vor der Tür! Da ich nach aktueller Chemotherapie eh auch der Couch rumliege ist das der beste Stoff mir nützlich Informationen ungestört zukpommen zu lassen.
    Ich hatte (naiv) nach dem Titel was ganz anderes erwartet aber nun immerhin kenne ich mich ganz gut mit Systemd aus :-) Nur die Konfiguration habe ich nciht ganz verstanden… muss ich mich wohl mal bei Gelegenheit reinwühlen :-)
    DANKE!

  5. Danke für diesen interessanten Einblick in systemd &co.

    Zum Thema „Secure Boot“ empfehle ich als zweiten Einblick den Vortrag von Rüdiger Weiss beim CCCamp 2015.

    https://www.youtube.com/watch?v=NoyTutU1VlI

    Der kritische Blick auf das Phänomen und auch die Probleme, die es schon damit gab, sollten nicht unerwähnt bleiben, obwohl ich in den Kernaussagen (Stichwort „User braucht Kontrolle über Keys“) durchaus Konsens mit den Aussagen von L. Poettering sehe.

    Also auch hier „Chancen und Risiken“, wie immer ……

    • Hallo!

      Danke für den Podcast lieber Tim. Habe es ca. 1,5 Stunden durchgehalten. Meine ca. 5 Versuche Linux aufzusetzen und zu nutzen sind am selben gescheitert wie der Podcast: Sperrigkeit.

      LG

      Peter

      • Dieser Podcast dreht sich nicht um die normale Benutzererfahrung mit Linux, sondern um hochkomplexe Systeminterna. Da bezweifle ich, dass es mit anderen Betriebssystemen weniger „sperrig“ zu erklären ist… Auf Userebene empfehle ich, es nochmal auszuprobieren – Distributionen wie Linux Mint zum Beispiel lassen sich ohne jede Sperrigkeit installieren und benutzen!

          • Ich habe mir beim Thema eigentlich was anderes vorgestellt. Aber hier haben zwei Nerds (was überhaupt nicht negativ gemeint ist) sich über Syteminternas der verschiedenen Linux-Diatributionen ausgelassen. Leider war das dem Verständnis der interessierten Hörer nicht gerade förderlich, ohne gleich ein abgebrochenes Informatikstudium vorzuweisen. Manchmal ist weniger tatsächlich mehr und leicht verständlicher. Ansonsten den 1. Teil des Podcast fand ich sogar sehr informativ. Beim zweiten habe ich leider kaum etwas verstanden und habe dann geistig meinen Kernel runtergefahren. Schade…

    • Jo, ich kenne Jolla. Hab schon damit rumgespielt. Aber es ist halt nicht mehr so, dass große Handyhersteller auf nen nicht-Android-Linux setzen. Das Ubuntu-Phone und das Jolla-Phone (die wohl beide systemd + PA einsetzen), sind eben ein Nischenprodukt, kein Massenprodukt, und ich sehe nicht, dass sich das ändern würde.

      • Äußersten dank für Deine werte Einschätzung!
        Klar der Consumer-Zug über die Hersteller ist längst abgefahren und der Markt gesetzt. Aktuell ist es ein Kampf gegen Windmühlen für die Underdogs.
        Es tun sich aber langfristig spannende Möglichkeiten auf sobald einer der Platzhirsche mit seinem Geschäftsmodel über z.B. gesellschaftliche Entwicklungen stolpert. Da finde ich den relative Ideellen Ansatz „Linux Telefon“ an allen Fronten begrüßens- und unterstützenswert, aktuell auch um überhaupt eine Chance auf diversifizierung des Marktes zu wahren.

        • Kingdoms rise and kingdoms fall …
          Bei Windows war es auch so, dass es von absoluter Führung nun deutliche Konkurrenz hat.

          Aber bei Jolla sehe ich derzeit wenig Ambitionen den Markt wirklich aufzumischen und wirklich eine Alternative zu sein (offen, sicher, portabel, unabhängig, …). Ich warte ja auch auf mein Tablet, habe derzeit aber eher den Eindruck, dass Sailfish eher sowas geschlossenes wie Android wird.

      • Aber auch Tizen (Konsolidierungsprojekt verschiedener Linux basierter Systeme IVI/Mobile von Samsung und Intel) dürfte dir bekannt sein. Bspw. kennst du sicherlich Gustavo Barbieri (bspw. durch systemd), oder Carsten Haitzler, die daran arbeiten oder gearbeitet haben.
        Tizen benutzt (afaik) systemd und das UI System wird wohl (nachdem die EFL nun auch Wayland einigermaßen ordentlich implementiert) in absehbarer Zukunft auf Wayland umgestellt werden.
        Tizens Zielmarkt ist die (emerging) dritte Welt, abgesehen von Spiegelreflexkamers. Mittlerweile hat es bereits Blackberry überholt (http://www.mobilecomputingtoday.co.uk/1147/samsungs-tizen-superseded-blackberry/)

  6. Ich bin skeptisch, wenn der Hardwarebesitzer nicht mehr bestimmen kann, was auf dem Rechner läuft.

    Ein Secureboot mit dem Eigentümer als Herr über die Schlüssel wäre wünschenswert aber wie sehen die Machtverhätlnisse am Markt aus? Wenn die Hardware in Massen bei Aldi & Lidl mit Windows bespielt in die Läden kommt, dann besteht die Freiheit des Kunden wieder nur darin das Produkt nicht zu kaufen.

    Bei Smartphones, wo die Interessenlagen für den Konsumenten noch undurchsichtiger sind, sehe ich die Gefahr für den Nutzer noch größer, an Systeme gekettet zu werden um Einkommenshighways für die Anbieter abzusichern.

  7. Habe viel gelernt, tolle Folge. Auch viel über LaunchDaemon gelernt.

    Zu 2 Punkten hätte ich mir noch etwas mehr gewünscht:
    – Die Kritik an SystemD hätte ich mir etwas strukturierter aufgearbeitet gewünscht. Einiges wurde erklärt; z.B. gabs mal die Kritik: SystemD macht jetzt auch Container – wohl weil man Container mit cgroups gleichsetzt. Das wurde gut herausgerarbeitet, wofür cgroups eingesetzt werden.
    – Von cgroups hätte man durchaus einen kurzen Ausflug in die Container-Welt machen können: In „der Cloud“ setzen ja inzwischen viele reine Container-Umgebungen mit minimalem OS. Hat da SystemD noch eine Berechtigung?

  8. Sinngemäß: „Bestimmte Dinge sind so wahnsinnig komplex und unnötig, ich bin dafür das bestimmte Dinge einfach sind.“ Und was ist da mit Systemd? Tausende komplexe Use-Cases und Sonderanfertigungen werden runtergebrochen auf die Funktionalität eines Programms und dessen Konfigurierbarkeit. Klingt für mich wie ein Widerspruch, andere Leute Programme sind komplex, nur meine nicht. Ebenso bei Pulseaudio, hat eine Weile gedauert bis es einigermaßen funktionierte. Und bis heute brauch ich das Teil nicht.

      • Bist du sicher ob du das richtig verstanden hast? All diese „Programme“ sind ohne die Infrastruktur von Systemd gar nicht überlebensfähig. Komplexität heißt ich konzentriere mich auf eine Sache und überlasse best. Dinge anderen die mehr davon verstehen. Die Unix-Tools wurden nicht entwurfen damit sie auf einer Diskette passen sondern damit Komplexität auf einfache Bestandteile heruntergebrochen werden kann, auch in dem Bewusstsein es wird stets langsamer sein als hochintegrierte Lösungen denen es an Flexibilität mangelt.

        • Die „Programme“ die vorher Systemdienste übernommen haben waren auch ohne „init“ nicht überlebensfähig und letztlich halte ich das auch für irrelevant, denn wenn systemd da ist, ist es ja da und dann stirbt auch nichts.

    • Geht mir genauso. Ich habe zuerst jahrelang über Pulseaudio geflucht, weil es am Anfang bei mir tatsächlich schlechter funktioniert hat als ALSA – mittlerweile bin ich trotzdem heilfroh, dass wir Pulseaudio haben, und Lennart auch dankbar dafür, dass er den Mut hatte, einfach mal die Machete zu nehmen und diesen unsäglichen Dschungel aus alten Zöpfen mal ein wenig auszuräuchern.

      Genauso ist es auch mit systemd: Als Archlinux-Benutzer bin ich mit systemd vermutlich schon etwas länger konfrontiert als Nutzer „klassischer“ Distributionen, und ich hab Jahre lang rumgeflucht, weil systemd halt ältere Kernel-Versionen nicht unterstützt, und ich dann irgendwann gezwungen war, von meinem alten OpenVZ-Server auf nen (teureren) KVM-Server zu migrieren, um auf dem Server auch weiterhin Arch fahren zu können. Natürlich war mir immer klar, dass OpenVZ bedauerlicherweise auch einfach ein großer Haufen Scheiße ist, der sicherlich nicht ohne Grund seit Jahren nicht auch eine neuere Kernel-Version als 2.6.32 portiert wird, aber ich dachte mir halt immer „eigentlich muss das Ding doch bloß Prozesse starten, das muss doch auch mit nem Kernel aus der Kreidezeit möglich sein!“ – mittlerweile bringe ich da dann doch etwas mehr Empathie für die Entwickler auf.

      Letztlich ist mir die Einstellung „Wenn die Leute Support wollen, sollen sie gefälligst aktuelle Versionen meiner Software einsetzen, und mich nicht behelligen mit 5 Jahre altem Code, an dem dann noch ungefragt 2 Linux-Distributoren in weitgehender Unkenntnis der Lage frei von Geist und Verstand dran rumgebastelt haben“ durchaus sympathisch – genau aus dem Grund benutze ich ja auch selber Arch und keine der klassischen Distros. Es reicht mir vollkommen aus, wenn ich mich mit solchen Distros jeden Tag auf der Arbeit rumplagen muss, und die Menschen, die diesen Zustand der systematischen Dysfunktionalität zu verantworten haben, die destraströsen Auswirkungen ihres beruflichen Schaffens mit solchem Unsinn wie „Bloß keine Updates einspielen, sonst gehen Dinge kaputt!!1!11“ zu lindern versuchen, weil sie schlicht zu faul und bequem sind, sich nach 10 oder 15 Jahren mit SysVInit mal in ein zeitgemäßes System einzuarbeiten.

      An Tim: Danke für den tollen (und streckenweise Augen öffnenden) Podcast!

      An Lennart: Danke für deine tolle Arbeit und die Beseitigung der ganzen alten Zöpfe! Falls du irgendwann bei systemd fertig bist – könntest du bitte bei make, den autotools und diesem ganzen Zoo weitermachen? :-)

  9. Super, jetzt muss ich schon wieder einen 2:50 Stunden CRE in eine die dreistündige Schlafphasen meiner neugeborenen Tochter einplanen, Himmel noch einmal! Herr Pritlove, Ihre CRE-Podcasts erscheinen neuerdings viiiieeeellll zu häufig. *ROFL* Danke für den Podcast. :)

  10. Vielen Dank für diese Folge!

    Ich benutze Debian und Ubuntu Serverseitig und habe mich die ganze Zeit gewundert, wieso es so einen großen Aufschrei gab, als Debian auf systemd umgestellt hat. Zumal ich systemd vorher überhaupt nicht kannte.

    Diese Folge CRE hat wirklich einen _shitload_ an Fragen für mich beantwortet. Vielen dank dafür!

    Gruß
    deg0nz

  11. Was für mich immer noch nicht beantwortet ist, was passiert wenn einer der Services stirbt. Werden dann zu diesem Zeitpunkt für einen Restart wieder die Abhängigkeiten und Reihenfolgen aufgelöst?

    • Die daemontools benutzen aber nicht die cgroups und haben damit keine Kontrolle über Kinder, die sich mit einem double-fork von Ihren Eltern verabschieden, können keine Resourcenkontrolle oder Ähnliches, und machen sich noch nicht einmal zum subreaper der geforkten Prozesse. Das ist also nicht wirklich vergleichbar.

  12. Sehr erhellende Folge. Es ist jetzt viel klarer warum systemd
    so ist wie es ist. Für Desktops und Notbooks mit Gui sind viele
    Konzepte sehr passend, und das ist offensichtlich die Zielrichtung
    der Entwickler.

    Der Grund warum so viele Admins Systemd hassen, ist aber nicht ihr elitäres Gehabe. Kein BSD Admin hat etwas gegen MacOS, kein Linux Admin hat etwas gegen Android.

    Der Schaden den Systemd in der Linux Community erzeugt, ist die überhebliche Einstellung der Entwickler zu behaupten sie wissen wie ein Unix System auzusehen hat und durch Dependencies und Bundeling alle auf Systemd zu zwingen.

    Aber es gibt genug Unix Admins die viel besser wissen, wie sie Ihre
    Server betreiben wollen. Sie wollen aber nicht gezwungen werden die unpassenden Konzepte von systemd zu verwenden.

    Systemd kann ein OS erzeugen das für 95% der User genau richtig ist. Aber dafür gibt es schon MaxOS und Windows. Für die 5% die volle Kontrolle wollen muss die Wahl bleiben systemd nicht zu verwenden.
    Das erzeugt die Hasspostings gegen Systemd.

    • Die Einschätzung, dass systemd sich primär an Desktops richtete, habe ich nie verstanden. Es gibt viel im systemd-Projekt, das auf Desktops (und Laptops) keinen oder nur wenig Sinn hat. Z.B. dass networkd derzeit kein WiFi unterstützt, also NetworkManager auf Laptops nicht ersetzen kann, Resource Management für einzelne Services, der umfassende Support für Container, die Sache mit den Predictable Network Interface Names (auf einem Laptop, der immer nur ein eth0 und ein wlan0 hat, braucht man das eher nicht), Watchdogs, die im Vergleich zu SysVInit deutlich einfachere Konfiguration (auf Desktops ändert man die vom Distributor/Entwickler gesetzen Defaults hinsichtlich des Starts von Systemdiensten ja äußerst selten), …

      Natürlich werden auf einem beliebig herausgegriffenen Server nicht alle Features von systemd Verwendung finden. Aber das ist auf einem beliebig herausgegriffenen Desktop oder Laptop nicht anders. Und bei anderen ähnlich umfangreichen Projekten ist es genauso; der typische Anwendungsfall wird nie alle Features einsetzen.

      Auch die Behauptung, dass „5% die volle Kontrolle wollen“, halte ich angesichts des allgemeinen Marktanteils von Linux und anderen alternativen Betriebssystemen für extrem übertrieben. Ganz abgesehen davon habe ich seit meinem Umstieg auf systemd den Eindruck, meine Systeme mehr unter Kontrolle zu haben als zuvor (ich tue mich schwer damit auch nur halbwegs komplexe Shell-Skripte zu lesen; „richtige“ Programmiersprachen sind mir da viel lieber).

      • Manche Nerds stehen auf Systeme die sich voll automatisch dynamisch auf Hardware Netzwerkumgebung einstellt und Dependency oder Usage driven Services automatisch gestartet werden.

        Andere Nerds wollen fix und unverändlich bei Systemstart selbst bestimmen was, wann, wie gestartet wird. Ein System startup kann auch aus nur einem „rc.startup“ script mit 10 Zeilen bestehen.

        Beides ist vollkommen in Ordnung. Wichtig ist nur, dass auch ich Zukunft beides möglich bleibt. Deswegen ist es wichtig dass die Systemd Leute einsehen dass sich nicht Linux von systemd abhängig machen dürfen.

        Auch wenn es nur 1% der Sysadmins ist, die ihre System ohne systemd laufen lassen wollen. Linux soll das für sie möglich machen. Die Linux Philosophie sollte über dem Egoismus und der Respektlosigkeit der Systemd Entwickler stehen.

        Die Wahlmöglichkeit ist das was Linux von MacOS und Windows unterscheidet.

        • Linux hängt nicht von systemd ab und wird es auch nicht (wie denn auch?); die allermeisten Linux-Systeme (z.B. Android-Geräte) laufen ja derzeit ohne systemd. Es ist anders herum: systemd hängt von Linux ab. Ja, meist ist die Unterscheidung zwischen dem Kernel „Linux“ und Betriebssystemen, die den Kernel namens „Linux“ verwenden, sinnlose Erbsenzählerei. Das hier ist eine der wenigen Außnahmen, da es explizit um Unterschiede in unteren Layern des Userspace geht. Deshalb finde ich auch nebulöse Begriffe wie „Linux Philosophie“ hier sehr wenig hilfreich.

          Niemand wird daran gehindert, ein System ohne systemd zu bauen (wie denn auch?). Allerdings kann man (gerade als Nerd der etwas vom System versteht) nicht erwarten, dass einem andere freiwillig und unentgeltlich die Entwicklungsarbeit abnehmen.

          Wenn man Software nutzen will, die eine systemd-API verwendet, gleichzeitig aber nicht systemd laufen lassen will, so hat man mehrere Möglichkeiten: Man kann z.B. die Software so patchen, dass sie auch ohne systemd läuft (z.B. indem man die Nutzung einer anderen API einbaut oder aber das entsprechende Feature deaktiviert). (Ob ein solcher Patch auch upstream angenommen wird, ist eine andere Sache.) Oder man baut eine alternative Implementierung derselben API (siehe systembsd). Oder man löst den verwendeten Teil so aus systemd heraus, dass er auch ohne systemd as PID1 läuft (siehe logind mit systemd-shim). Welche dieser Alternativen die beste ist (und ob überhaupt eine davon gut ist), hängt vom spezifischen Fall ab.

          Ja, manche Software nutzt systemd APIs. Das ist doch genau der Sinn und Zweck einer API. Was genau sollen die systemd-Entwickler denn Deiner Meinung nach tun? Schlechtere APIs schreiben, damit sie ja niemand nutzt?

          Die Wahlmöglichkeit ist das was Linux von MacOS und Windows unterscheidet.

          Nicht notwendigerweise. Der Hauptgrund für mich, Linux(-basierte Betriebssysteme) OSX und Windows vorzuziehen, ist, dass letztere keine Freie Software sind. Das impliziert natürlich, dass man prinzipiell alles austauschen kann, sagt aber selbstverständlich nichts darüber aus, wie viel Aufwand man dafür ggf treiben muss. Und das war schon immer so; systemd ändert daran gar nichts.

          • Du hast natürlich recht dass man sich nach wie vor sein System selbst bauen kann. Ich mach das auch je nach Anforderung.

            Aber die Systemd Entwickler können das Unterstützen oder möglichst schwierig machen. Die aktuelle Methode „machen wir aus Systemd die eierlegende Wollmilchsau“, macht es für Distributionshersteller sehr schwierig die Flexibilität zu erhalten.

            Dieses Problem ist in der Debian Community sehr hart aufgeschlagen.

    • Menschen sind aber keine Maschinen. Menschen reagieren emotional auf Themen die ihnen extrem wichtig sind. Und es gibt Menschen denen ist Linux wie es existiert nahezu heilig. Wenn jemand antritt das Linuxsystem endlich mal „richtig“ zu machen, impliziert das schon mal, dass es alle vorher falsch gemacht haben. Allein das kann Überwindung oder wenigstens eine distanziert sachliche Analyse kosten es einzugestehen. Wenn derjenige der es richtigstellen will dann auch mit der Haltung antritt, keinen Respekt vor Menschen haben zu müssen, ist es mMn. nicht verwunderlich wenn einige mit Feindseligkeit reagieren.

      Zum Vergleich kann man sich ja mal die Diskussionen um Wayland anschauen. Da wird auch ein Gestrüpp aus jahrzehntelang gewachsenen Merkwürdigkeiten „richtig“ gemacht und alte Zöpfe abgeschnitten. Es gibt ebenfalls Leute die mit der Konzeption von Wayland unzufrieden sind und einige der alten Zöpfe vermissen. Ich sehe dort aber nicht dieses Riesendrama wie die systemd-„Kritiker“ vom Zaun brechen.

    • Ich will Hassposter nicht rechtfertigen. Ich wollte nur erklären warum systemd überdurchschnittlich viele Gegner hat. Sachliche Diskussion ist natürlich immer vor zu ziehen.

      Viele Sysadmins fürchten, dass Linux in Richtung MacOS und Windows geht. Die Friss oder Stirb Mentalität von Mac und Windows bei der man bevormundet wird, hat viele zu Unix getrieben.

      Gnome3 wird sicher von viel mehr Leuten abgelehnt, aber man kann es einfach _nicht_ verwenden. Dadruch gibt es weniger Hater. Die Unix Idee der freien Wahl.

      Und bitte glaubt nicht dass alles bei systemd besser ist. Für viele Anwendungen ist systemd nicht das richtige Tool. Die Scheuklappen gibt es auf beiden Seiten.

      • Wie heisst es so schön „Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel“.

        Der Hammer hatte bisher nur den Namen Shell Skript und hat eine Menge Nägeln in der Wand versenkt von denen einige auch Schrauben waren.

        systemd ist ein Werkzeug wie jedes andere und darum kann es bestimmte Dinge besser und andere nicht so gut. Ich würde sagen man kann sich darauf einigen das systemd einige Probleme besser löst, andere nicht so gut und bei wieder anderen ist es eben keine Lösung aber es kann schon vieles das man immer schmerzlich vermisst hat.

        • Ich möchte noch einmal betonen: Ich bin nicht gegen systemd. Systemd ist für die meisen Fälle das richtige Startupsystem.

          Aber wir müssen trotzdem darauf achten, dass den Admins die Wahlmöglichkeit bleibt, denn es gibt Aufgaben auf die der neue Hammer systemd nicht passt ;-)

  13. Was mich bei der ganzen systemd-Diskussion immer wundert, ist die vergleichsweise schwache Dokumentationsqualität für Admins/User (also alles unter http://www.freedesktop.org/software/systemd/man/).

    Nicht, dass es um die bisherigen Init-Systeme irgendwie bessere stünde, aber gerade im Ruby, Python, Node und Go-Umfeld sind die Dokumentationen bei sämtlichen Projekten eine art „must-have“ geworden und haben sicherlich auch für eine schnelle und breite Verbreitung diverser Tools gesorgt. Docker, Vagrant (bzw alles von Hashicorp) sind gute Beispiele von starker Dokumentation.

    Viele von systemd angegangenen Probleme sind nicht ernsthaft zu bestreiten, viele Hater sind sich derer nicht bewusst oder administrieren nur sehr wenige, sehr statische Systeme. Das sind aber dann meist auch die Leute, die am meisten Zeit haben, sich negativ zu äussern, weil sie mit ihrem einfachen Use-case die Vorteile (u.a. wegen der Dokumentations-Schwäche) nicht nachvollziehen können.

    Leider habe ich erst auf heise von der systemd.conf-Konferenz erfahren, halte das aber schon mal für einen sehr guten Schritt. Jetzt noch eine ordentliche systemd-Website mit Beispielen für populäre Anwendungsfälle als Vorlage für Umsteiger…

  14. Wir diskutieren im Job viel über den Sinn von Desktop Systemen und der „richtigen“ Distro oder gleich ob UNIX „besser“ ist als Linux.
    Ich bin da ganz bei Lennart, dass Linux aber auch Unix im Desktopbereich besser oder leichter werden müssen. Als Nerd, IT Jobinhaber etc. habe ich natürlich diese große Freiheit und das Wissen und Know-how zu wählen was mir gefällt.
    Was mir aber überhaupt nicht gefällt ist dieses Gehabe, was leider viele „alteingesessene“ haben, dass nur dieses oder jenes in diesem Bereich gut ist – und was einen Linux oder Unix Experten ausmachen kann.
    Ich bin davon überzeugt, dass Linux und Unix auch für den Enduser sinnvoll und einfach sein kann. Aber die Community steht sich da selbst im Weg! Ist einfacher immer gleich dümmer?
    Ich glaube hier gibt es einfach immer noch eine ganz stark ausgeprägte Meinung, dass nur Shellgurus die richtigen Hacker sind. Ist schade…
    Da kommt natürlich schon der Punkt zum Tragen, den Tim auch angesprochen hat. Die DAUS. Ja es gibt genug Gründe und Situationen mal seinen Frust in einer solcher Form Raum zu geben. Ich denke, dass kann jeder der beruflich jeden Tag in diesem Gebiet tätig ist bestätigen. Was aber viele vergessen ist: man muss auch die User ABHOLEN! Wenn ich das nicht mache und mich ständig auch auf User einstelle, kann ich nichts ändern und auch nicht erwarten, dass User ein Verständnis – geschweige denn Interesse haben.
    Zum anderen finde ich diese Diskussion über das zusammenarbeiten in der LINUX Entwickler Community interessant und bezeichnend. Da hat Lennart ja auch schon so seine Erfahrungen gemacht und auch deutlich geäußert. So oder ähnlich ist es doch leider fast überall in der IT – in der einen oder anderen Form. Warum? Sitzen wir alle zu lange im dunkeln, dass unsere Umgangsformen dabei völlig über den Jordan gehen?
    Vielleicht sehe ich das zu schwarz – aber schon von einem Glaubenskrieg zu reden, wenn es um LINUX oder UNIX geht ist schon genau der falsche Ansatz – meiner Meinung nach. Wenn einem etwas soo heilig ist hat er schon den Weitblick und die ersten Fähigkeiten ein Hacker zu sein verloren.
    Wahrscheinlich bekomme ich dafür jetzt auch schon einen auf den Deckel – ist mir aber egal :)

    • Ich kann dir da nur zustimmen – wobei nach meiner Erfahrung vielen „alten Hasen“, die sich heute so sehr an systemd abarbeiten, selber oft ganz erheblich an fundiertem Fachwissen mangelt, das sie dann gerne mal durch tradiertes und oft gefährliches Halbwissen zu kompensieren versuchen. Nach meiner Erfahrung sind die Admins, die sich heute so schwer tun mit systemd, oft dieselben Leute, die z.B.

      – ihre ssh-Server lieber durch Rate Limiting als durch das Deaktivieren von Passwort-Logins „schützen“,

      – ausgehende TCP-Verbindungen auf allen Zielports außer 443 sperren um es „Hackern“ schwerer zu machen, Daten aus dem lokalen Netz rauszuschleusen,

      – auch im Jahr 2015 immer noch ICMP und IPv6 komplett wegfiltern, weil sie vor Jahren irgendwo mal aus dritter Hand gehört haben, dass diese Protokolle angeblich „gefährlich“ seien, und sie im Zweifelsfall lieber ein Protokoll sperren als sich damit mal ernsthaft auseinanderzusetzen und sich in die Materie einzuarbeiten,

      – ihre Systeme nach der Prämisse „never touch a running system“ administrieren, weil sie ihre Systeme nicht souverän genug beherrschen, um bei Updates auftretende Probleme zu debuggen und zu beheben.

      (Liste ohne Anspruch auf Vollständigkeit)

  15. Hm, bei dieser Episode musste ich beim Hören checken, ob ich versehentlich das Einleitungs- und Definitionskapitel geskippt habe. Üblicherweise schätze ich es, wenn CRE ein gewisses Grundwissen voraussetzt und nicht jeden elementaren Begriff erklärt. Bei dieser Folge musste ich als nicht-Linuxer jedoch aussteigen, weil ich auch nach einer Stunde keinen blassen Schimmer hatte, was systemd nun überhaupt ist und was es ersetzt…

    • Ging mir genau so. Normalerweise bin ich gewohnt, dass CRE auch anspruchsvollere Dinge auf das Nötigste runterbringt. Mit den Fachbegriffen konnte ich nix anfangen. Das nächste mal wünsche ich mir Linux Systeminternas für Dummies.

  16. Ich fand die Sendung zwar auch ein wenig anspruchsvoll, aber nicht zu sehr und würde gerne mehr in die Richtung hören, etwa zu wayland/’Xorg-X11. Geschichte, Unterschiede, Entwicklung.

    Und/oder ibus/dbus.

  17. Für Noobs ein bisschen schade diese Folge. Es wird zwar viele von der Bedeutung für die Systeme und für die Szene her recht klar, aber wie denn nun Linux und Unix eigentlich funktionieren weiß man dadurch trotzdem nicht und muss dann öfter mal in den Erzählstrang von Tim und Lennart „Magie“ einsetzen, um sich zu erklären, dass da halt anscheinend igendwie irgendwas passiert :3

  18. Tolle Folge. Lennart kommt viel sympathischer rüber als es die Berichterstattung um systemd vermuten lies.
    In den Firmen in denen ich bisher gearbeitet habe wurden Linux basiert Produkte immer nur also Installer, der Linux und die Software installierte ausgeliefert. Die Windowsversion war hingegen nur eine Installer der eigentlichen Anwendung. Schön das sich bei Linux nun auch was tut, das Distribution und Software universeller vereinbar werden, damit werden Kräfte frei für sinnvollere Dinge!

  19. Hi Tim,

    tolle Folge. Freue mich sehr, dass du dich endlich wieder mehr den technischen Themen zuwendest.

    Da Lennart (natürlich) sehr systemd-fokussiert ist und fast das ganze Gespräch diesen Rahmen nicht verließ, würde es nicht schaden, einen eigenen CRE über den Linux-Kernel zu machen.
    Bei OS X hast du ja damals auch eine eigene Folge zum Kernel gemacht.

    Bei einem Linux-Boot passiert extrem viel im Kernel, bevor systemd überhaupt ins Spiel kommen kann. (Abgesehen vom systemd-boot)

    Interessante Punkte für ein Gespräch zum Thema Linux Kernel:
    – Memory Management
    – Scheduler
    – CGroups / Namespaces und andere Hilfsmittel für die Containerwelt
    – KVM
    – ext4 & btrfs
    – Unterschiede zum FreeBSD-, Solaris und Darwin/XNU-Kernel: epoll vs kqueue, etc.

    :)

  20. Vielen Dank Tim und Lennart für diesen interessanten Podcast. Ich habe die ganze systemd-Diskussion bislang eher halbherzig verfolgt und mir keine ausgeprägte Meinung dazu gebildet. Nach diesem Podcast denke ich, dass Lennart durchaus Recht haben könnte und systemd vielleicht nicht der Weltuntergang ist, den viele herbeibeschwören.
    Am interessantesten aber finde ich, dass viele Überlegungen und Entscheidungen, die Lennart erklärt hat, ganz ähnlich im NextBSD Entwicklungszweig von FreeBSD zu finden sind, bis hin zu „IPC wandert in den Kernel“ (in dem Falle die MachIPC).
    Siehe auch Jordan Hubbards Talk bei der EuroBSDCon[1] und sein Interview bei BSDNow[2].

    [1] https://www.youtube.com/watch?v=ZKouICXCPq4#t=5h41m19s
    [2] http://www.bsdnow.tv/episodes/2015_10_28-Whats_next_for_BSD

  21. Hi Tim,
    die Folge hat mich so sehr weitergebracht, dass ich dafür einen flattr-Account angelegt habe.
    So kann das gerne weitergehen…

    So hübsch der Mac auch sein mag – richtig cool sind die OpenSource-Themen.

    Besten Dank!

  22. Also nach dem Hören des Podcast komme ich zu zu dem Entschluss, dass ich systemd nicht als init-System sondern als neues LSB[1] ansehen sollte. Zumindest war LSB auch mal der Versuch, die ganzen Distro-Unterschiede zu Verallgemeinern. Wenn ich systemd als LSB sehe, verstehe ich auch besser, warum systemd versucht „alles“ zu machen und akzeptiere es deutlich stärker.
    Daher danke für den die Aufklärung.

    [1] Linux Standard Base

  23. Ich fand die Folge hervorragend. Vielen Dank an Lennart und Tim. Ich hätte gerne noch etwas zu der Container-Infrastruktur in Systemd gehört, das klingt nämlich ziemlich cool (https://www.youtube.com/watch?v=d4SwL2t5Yh4).

    Zu anspruchsvoll fand ich die Folge nicht, aber ein Stück weit Special Interest. Als ganz normaler Anwender muss man das so im Detail ja meist nicht kennen. Das Thema ist einfach nicht sehr voraussetzungsfrei.

  24. Schöne Folge, auch wenn sie an einigen Punkten doch extrem komplex war. Aber sie hat einige kontroverse Entscheidungen ganz gut erklärt.

    Mich hätte die persönliche Dimension noch etwas mehr interessiert. Seit Ubuntu (etwas zu früh) auf PulseAudio umgestellt hat, gilt Lennart in vielen Kreisen als Symbol für scheiternde Technik, und die Diskussionen um SystemD haben zu einigen Zeitpunkten jeden zivilisatorischen Boden verlassen. Lennart musste einiges ertragen – Hatemails, diffamierende Videos, Hass auf Twitter, und es gab sogar eine Bitcoin-Sammlung um einen Profikiller anzuheuern, damit Lennart Linux nicht vollständig zerstören kann. Selber hat er dafür die toxische Diskussionskultur im Open Source Bereich und nicht zuletzt Linus Torvald verantwortlich gemacht. Mich hätte interessiert, ob er das immer noch so sieht und ob sich die Diskussion insgesamt verändert hat.

    Auf jeden Fall hat es mich gefreut, mal wieder eine technische Folge zu hören. Die halb angeteaserte Idee, sich den Linux Kernel anzuschauen, gefällt mir auch sehr – da ließe sich in Sachen Geschichte, Entwicklung, Codedesign und technischen Details einiges rausholen, und mit Harald Welte zum Beispiel hättest du ja einen Kernelentwickler im CCC…

    • PulseAudio habe ich damals in Fedora kennen gelernt, da gab es PulseAudio nur für Fedora und sonst nirgendwo. Und es lief trotz seines frühen Stadium schon sehr gut. Andere Distributoren haben PulseAudio später integriert und genau da lief es nicht rund. Zum Beispiel unter Ubuntu.

  25. Vielen Dank für diese Folge! Ich hatte zwar einiges an Doku zu systemd gelesen, als die Diskussion in Debian aufkam, mich im Endeffekt aber nie wirklich damit beschäftigt (lass das mal die Distribution erledigen, solange ich einen aktuellen g++ habe, ist alles gut…).

    Die Shell-Scripte zum Booten waren mir immer ein Rätsel, das ich nie wirklich durchschaut habe. In welches Verzeichnis muss ich was reinlegen? Oder muss ich gar nur einen Symlink erzeugen? Das wirkte alles sehr alt!

    Sehr interessant auch der Bereich „socket activation“.

    Also großes Lob für diese sehr interessante Sendung!

  26. Hm, im Titel steht „Linux“, war dann aber eine 2-stuendige SystemD-Werbeveranstaltung :-\ Und da der Gast auch der Autor ist, war das auch leider alles sehr einseitig. „SystemD“ haette als Sendungstitel wirklich besser gepasst.

  27. Hat jemand mal gezählt, wie oft Poettering das Wort „irgendwie“ nutzt? Wenn man sich darauf konzentriert, wird das Interview unerträglich.
    Das Interview wäre vermutlich eine Stunde kürzer, hätte Poettering auf das Wort „irgendwie“ verzichtet. Irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie irgendwie…. Da ist wohl irgendwie irgendwas beim Abtauchen in die Coding-Welt im Gehirn ausgerenkt, was für Kommunikation in der realen Welt wichtig ist. Hoffentlich gibt es eine Therapie für ihn… ansonsten kann man sich ihn nur in Textform antun.

  28. Vielen Dank für die Folge, die bei mir gleich mehrere Nerven getroffen hat.

    Ich verwende Lennarts Schöpfungen sowohl auf dem Desktop als auch auf dem Server und weis die Features und die hohen Ansprüche, die offensichtlich bei der Umsetzung angesetzt werden sehr zu schätzen. Avahi ist super, an Pulseaudio mag ich vor allem die Netzwerk-Features und auch Systemd bietet viel interessantes.

    Trotzdem gehörte ich grad bei Pulseaudio und Systemd klar zu den Skeptikern, da vor Allem Pulseaudio für mich Probleme mit sich brachte, die ich davor nicht hatte.

    Die Situation ist bei mir etwas speziell, da ich blind und somit auf einen Screenreader angewiesen bin um mit dem Computer zu arbeiten. Im Desktopbereich ist Orca der Screenreader für Linux. Orca ist ein Gnome-Projekt und ist auf ein Accessibility-API angewiesen, um überhaupt die nötigen Informationen vom System zu bekommen. Das Anwendungs-Toolkit (GTK, Qt, etc.) wiederum muß die nötigen Informationen über das Accessibility-API (AT-SPI) bereitstellen. Das hat zur Folge, daß beispielsweise Programme die SDL für das UI verwenden überhaupt nicht zugänglich sind, weil SDL keine Anbindung an AT-SPI2 beinhaltet. Bei Qt hat sich die Situation in den letzten Jahren sehr verbessert, vorher waren auch Qt-Anwendungen nicht zugänglich.

    Jedenfalls gibt es immer noch reichlich graphische Programme, die ich nur mit Einschränkungen oder gar nicht bedienen kann, daher verbringe ich noch immer sehr viel Zeit auf Text-Terminals. Ein graphisches Terminal ist kein Ersatz, da graphische Screenreader nur extrem eingeschränkt für das arbeiten mit textbasierten Programmen taugen. Da ein graphischer Screenreader auf der Textkonsole nicht einsetzbar ist, verwende ich dafür noch einen zweiten Screenreader parallel, der nur auf der Textkonsole aktiv ist, mir wiederum aber auf dem graphischen Desktop nix bringt. Im Textmodus gibt es kein API, der Screenreader holt sich die Informationen über die entsprechenden VT-Schnittstellen des Kernels, was leider als Root passieren muß, zumindest hat noch niemand einen Weg mit weniger privilegierten Rechten gefunden. Das Teil muß also als Root laufen. Mit Pulseaudio gab es nun plötzlich das Problem, daß als Root keine Audioausgabe und somit keine Sprachausgabe mehr möglich war. Vom Sicherheitsaspekt her mag das wohl begründet sein, aber von einem sicheren Rechner ohne Sprachausgabe hab ich auch nix. Es gibt verschiedene Workarounds, aber eine zufriedenstellende Lösung für das Problem hab ich bislang noch nicht. Generell ist die Einschränkung, daß lediglich ein User gleichzeitig
    die Hoheit über die Soundkarte hat, an vielen Stellen ein Problem für mich. Pulseaudio bringt tolle Features und klare Vorteile mit, für mich ist das System dadurch jedoch wesentlich komplizierter handhabbar geworden als nur mit ALSA – und Streams mixen konnte das auch schon.

    Auf Systemd hab ich gewechselt, als Gnome es verlangt hat, was sich damals schon nach Zwangsmaßnahme angefühlt hat. Lennart hat es auf den Punkt gebracht, die Bootkonfiguration ist etwas, womit man sich aus der Notwendigkeit heraus beschäftigt und froh ist, wenn alles läuft, da möchte man sich ungerne „grundlos“ neu reinarbeiten und nimmt dann auch die Ausweitung vom eigentlichen Boot-Management aufs Loggin, Networking, usw. als Vereinnahmung wahr.

    Emotional reagiere ich generell auf die Desktopisierung, also das „moderne“ Konzepte oder Schnittstellen gefühlt fast ausschließlich für den Einsatz mit dem graphischen Desktop konzipiert werden. Das Pairing mit einem Bluetooth-Device war bis vor nicht all zu langer Zeit außerhalb von graphischen Umgebungen ein Graus und auch der Session-Bus von Dbus setzt ein laufendes X voraus. Von Gnupg2 und Pinentry mag ich gar nicht anfangen. Und wenn ich dann unter anderem von Lennart auf der Pulseaudio-Mailing-Liste lese, daß Text-Terminals eh noch nur maximal zum Debugging eingesetzt werden sollten und eigentlich per Default deaktiviert gehören, kommen halt im ersten Moment auch Systemd und Pulseaudio gleich in diese Schublade. Im Fall von Systemd waren meine Befürchtungen zum Glück nicht gerechtfertigt und
    bei Pulseaudio sind die Einschränkungen außerhalb der X-Umgebung technisch bedingt und die Steuerung ist immerhin grundsätzlich möglich.

    Der nächste Brocken wird wohl Wayland werden, da es bei den vielen Zöpfen die abgeschnitten werden gleich auch die erwischt, die für das Accessibility-Framework benötigt werden. Es gibt Entwickler in dem Bereich, die sich wirklich ins Zeug legen, aber deren Zahl ist leider überschaubar. Mit den 95 Prozent, für die es problemlos funktioniert, ist mir nicht geholfen, wenn ich zu den anderen 5 gehöre.
    Im Schlimmsten Fall werden die ersten Distris die Wayland als Default ausliefern erst mal überhaupt nicht zugänglich sein. Das fühlt sich dann schon manchmal wie ein frustrierender Kampf gegen Windmühlen an.

    Gerade darum bin ich froh, wenn ich wenigstens nachvollziehbare und überzeugende Erklärungen für solche Umstellungen habe, dafür vielen Dank an Lennart und Tim.

    • Ich nehme an, das ist so ein bisschen die Nerd-Variante von „Stoppt-den-Fluglärm“-Bürgerinitiativen…

      Ich meine, man kann ja über alles diskutieren, aber da so ein Spektakel drum zu machen, ist halt albern.

  29. Gute Folge über ein interessantes Thema.

    Nur eine Anmerkung zum elitären Verhalten mancher Linux-Anhänger: Ich würde das auch auf die Apple-Fraktion ausdehnen ;) : Man muss nicht bei jeder IT-lastigen Folge Microsoft-Bashing veranstalten (auch wenn es eher subtil und vllt. unbewusst gemacht wird).

    Ich möchte nur darauf hinweisen, dass heute Microsoft wesentlich offener ist und aktiv zu Open Source beiträgt. Das sehe ich bei Apple nicht in dem Ausmaß.

    • Apple war deutlich früher als Microsoft auf Open Source Pfaden und ist es auch heute noch. WebKit und LLVM/clang sind keine Kleinigkeiten. Mittlerweile hat eigentlich jede große Firma eine irgendwie geartete Investition in Open Source Projekte getätigt.

      • Stimmt, aber habt ihr nicht auch den Eindruck, dass Apple heutzutage nicht mehr so viel Engagement für Open Source zeigt, wie früher? Das ging doch mit der zunehmende Marktmacht stetig bergab. Aber vielleicht täuscht dieser Eindruck auch.

        Die begonnenen Projekte, werden weiter betreut, ob WebKit, LLVM, oder sogar noch ein bisschen Mitarbeit an FreeBSD. Aber wann wurde das letzte Mal ein Open Source Projekt von Apple ins Leben gerufen? Wer kann sich erinnern?

        Ich bin sehr gespannt auf den Swift Code. Hoffentlich wird er komplett veröffentlicht und unter eine ordentliche Lizenz gestellt.

        Microsoft fängt gerade erst an, aber man spürt, dass dort frischer Wind weht.

          • Vielleicht ich der Blick getrübt durch die aktuelle Entwicklung in CUPS. Dort ist (nach meinem Kenntnisstand) der GNU/Linux-Support langsam am wegsterben.

          • Ich bin sehr positiv überrascht über das Swift Release: GitHub, Apache License, volle Git Commit History gepushed sowie auch Core Foundation veröffentlicht. Besser hätte ich es mir nicht wünschen können.

            Sehr interessant für alle, die des C++ mächtig sind und gerne mitmachen möchten. C und C++ sind eben die Mütter aller Sprachen. Sehr schön zu sehen, wie Apple das angeht, welche Coding Guidelines sie verwenden usw.

            Man stelle sich vor, die würden auch XNU/Darwin auf GitHub pushen und auch dort die Community miteinbeziehen, anstatt nur alle paar Jahre mal die Archive auf opensource.apple.com zu stellen..

      • Moin Tim, IMHO sperrt sich Apple gegen veröffentlichungen wo es nur geht. Die Zeiten wo man das klassische „MS buh“ und „Apple hurra“ rufen konnte sind schon lange vorbei (gefühlt bei mir seit 2009/2010). Im User/Developer Bereich geht nichts mehr ohne Kreditkarte, die BSD Variante ist nur alter Schrott, die Tools sind grotten alte Binaries (sorry für den Ton, aber tipp mal rsync –version ein, das nervt mich schon seit Jahren). Achja, ich hab (leider) auch ein haufen Mac’s .. aber die sortier ich nach und nach aus … ;-)

  30. „Das Linux System“ (mit Deppenleerzeichen) ist ein sehr vollmundiger Titel für eine systemd-Dauerwerbesendung. Ich stehe systemd jetzt etwas offener gegenüber, dafür wars schon ganz gut. Aber CRE/Tim ist mir leider auch hier wieder unverzeihlich uninformiert im Detail. Ich meine diese großkotzige Uninformiertheit, die zeigen will, dass sie mitreden kann und die Dinge oft genug doch nicht präzise auseinanderhalten kann (oder „RHEL“ hört und an „Rel[ease]“ denkt).

    • Ich finde gerade Tims „Uninformiertheit“ gut. Das macht für mich einen der grossen Reize von CRE aus. Tim lernt dabei genau wie die Hörer, und stellt dadurch oft die Fragen, die ich auch gern stellen würde. Bei Omega Tau ist das ähnlich. Daher sehe ich das eher als einen Vorteil.

      Viele Grüße
      Steve

    • Auch ich mag die „Uninformiertheit“ von Tim sehr, meist schafft er es damit Vorgetragenes in eine allgemeinverständlichere Form zu bringen. Hier in diesem CRE209 hat er das nicht immer geschaft, was aber wohl eher an Lennart Poettering lag, der –wie ich finde– ziemliche Zirkel gedreht hat. Ich hätte mir von Lennart Poettering eine besser strukturierte Präsentation gewünscht, die auch pro und cons aufzeigt. Was man Tim evtl. ankreiden kann ist, dass er nicht kritisch nachhakt; warum systemd so aufgebläht ist / warum systemd für newbies unverständlich bleibt / ob es evtl. nicht besser wäre systemd auf die genannten Motivationen (die ja begründet sind) runterzukürzen statt einer eierlegenden Wollmichsau weitere funktionen zu geben.

  31. systemd war für mich immer ein Unding. Ein Monster, das mir meine schönen init Skripte wegfresssen will. Ich war einfach aus Gewohnheit auf das alte fixiert. Ich muss aber sagen, das die Konzepte hinter systemd ganz gut klingen und ich evtl einfach mal über meinen Schatten springen muss.
    Ich habs probiert und mich einfach mal unvoreingenommen mit systemd beschäftig, und ich muss sagen: „es ist gut“. Das Hauptproblem ist das Altwissen das einen verleitet alles so zu tun wie immer.

    Danke für diese Sendung und, wenn auch etwas einseitige, Betrachtung des Themas. Mir hat es geholfen über meinen Schatten zu springen und bewahrt mich evtl davor irgendwann in ferner Zukunft als weisshaariges IT Relikt Tag ein Tag aus zu sagen,: „Früher war alles Besser“

  32. Naja es gibt ja jetzt cmake und das wird auch viel genutzt. Nur alte C/C++ Projekte verwenden automake, dachte ich. Ich hätte nicht vermutet, dass systemd automake verwendet! Gut, cmake ist auch nicht der Oberhammer, aber weniger wahnsinnig wie automake ist es auf alle Fälle. Würde mich interessieren was cmake konkret nicht kann, dass automake kann und systemd braucht.

  33. PulseAudio war am Anfang einfach nur furchtbar. Wenn es überhaupt Ton gespielt hat, war er stark Zeitverzögert. D.h. Videos und Spiele waren da unmöglich. Leider ist PulseAudio so stark im System integriert (in den Distributionen die ich verwende), dass man es nicht deaktivieren kann. Bzw. wenn man es deaktiviert gibt’s gar keinen Sound mehr, obwohl die Programme ALSA-Ausgabe unterstützen würden. Keine Ahnung wie das funktioniert.

    Ja, PulseAudio hat ein paar nette Features (Volumen für jedes Programm steuerbar), aber im Großen und Ganzen lief Sound besser mit purem ALSA, jedenfalls in meiner Erinnerung. Die PulseAudio Settings sind auch buggy. Ich stell ein Default-Mikrofon ein, dann wird das aber trotzdem nicht als default genommen und ich muss es erst für jedes Programm einzeln setzen, was aber (über’s GUI) nur geht wenn das Programm grade auf das Mikrofon zuzugreifen versucht. Da bin ich auch lange gesessen um da drauf zu kommen.

    D.h. alles in allem mehr Probleme als es mir bringt. Außer der Volumenkontrolle auf Programmebene habe ich keine Vorteile dadurch.

    Ich find’s ja toll, wenn jemand so viel zu Open Source beiträgt und begrüße das! Nur ist’s halt ungut wenn das Resultat das brechen von Features ohne wirklichen Mehrwert ist.

    • PS: Mit „stark Zeitverzögert“ meine ich halbe Sekunde bis Sekunde. Völlig unbrauchbar war das und trotzdem schon so stark im System verankert, dass man es nur sehr schwer entfernen konnte. Aber damals hab ich es noch geschafft es zu entfernen. Sonst hätt ich Linux vergessen können. Zu der Zeit war das erste was ich nach dem Installieren einer Linux Distribution gemacht habe immer PulsAudio entfernen.

    • Unter debian wheezy kann man PulseAudio problemlos runter werfen. Dann hat man nur noch die libpulse0, aber die Audioausgabe läuft bei mir per ALSA. Für jessie habe ich _noch_ keine Erfahrung, aber gehe davon aus, dass ich auch dort das Paket „pulseaudio“ deinstallieren kann.

  34. „Linux ist gefühlt auf 99% aller Server.“

    FreeBSD ist auf mehr Servern als man denkt. Kenn da keine genauen Zahlen und ja, Linux hat die absolute Mehrheit, aber so krass ist es nicht.

    • Hier gibt es die Infos: https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
      Demnach sind es so in etwa 96.6 Prozent Marktanteil bei öffentlich zugänglichen Servern, und FreeBSD hat auch noch so viel Marktanteil wie Windows (1,7%).

      Nicht Statistiken auf der Seite sind aktuell, und teilweise vielleicht mit Vorsicht zu betrachten (z.B. auf dem Desktop gibt es User Agent Changer…) Insgesamt finde ich die Seite aber ganz ausgezeichnet.

    • Oh, ich war mal wieder etwas schnell. Ich habe mir die Statistik ausgewählt die für Linux am vorteilhaftesten ist, andere zeigen aber einen Marktanteil von 20-30+ Prozent für Windows.

  35. Für jemanden mit Linux-Erfahrung ein wirklich spannender Podcast.
    Leider spricht Lennart manchmal etwas schnell, so dass das zu Hören anstrengend wird.

  36. Hallo,
    hatte gehofft in dem Podcast was über LinuX zu erfahren ;-).
    Abgesehen von der Einleitung habe ich jedoch nichts verstanden.
    … reiner Tech-Talk für LimurX-Profis.
    Nach ca. einer Stunde 1000x System-D und 500 mal init-ID
    habe ich aus-gemacht.
    Habe mich wohl von der Überschrift locken lassen.
    Obwohl ich auf diversen Systemen LinuX (D-Box, VDR, Rockbox etc.) installiert habe und verwende, hatte das gesagte, keinerlei Bedeutung für Mich. Vieles hätte auch viel einfacher formuliert werden können. Ich was aber wohl dann doch nicht der Adressat. Für die SUPER-Nerds (Coder) aber sicherlich ein Leckerbissen zum d’ran schubbeln :-]

    P.S. Deamon wird doch wohl anders ausgesprochen?

  37. Weil es mir mehrfach bei den ganzen Kommentaren aufgefallen ist.

    Spelling
    Yes, it is written systemd, not system D or System D, or even SystemD. And it isn’t system d either. Why? Because it’s a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it’s called systemd. It’s that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don’t like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÿstëmd. But then again, Système D is not an acceptable spelling and something completely different (though kinda fitting).

    http://www.freedesktop.org/wiki/Software/systemd/

  38. Schöne Folge. IMO die beste der letzten 10 Folgen.

    Das ganze ist halt einfacher wenn man Informatik studiert hat oder sich sonst mit SystemV oder systemd auseinandergesetzt hat. Simpel ist das Thema trotzdem nicht. Ich verstehe, warum es hier einige nicht durchgeblickt haben.

    Kopf hoch: Das Thema wird einfacher mit jeder Kleinigkeit die man aus dem Bereich Betriebssysteme, Programmieren, Linux und Informatik lernt.

  39. Ich wollte nur sagen dass mir dieser podcast sehr gut gefallen hat. Insbesondere die Abschnitte über die Motivation für systemd und die Inspiration (launchd, smf, auch mdns etc.) waren spannend und nachvollziehbar. Wieder was gelernt!

  40. Ich höre ja sehr gerne CRE und üblicherweise sind die Folgen von sehr guter Qualität, aber diese Folge war schon arg schlecht. Es fängt schon bei dem Titel an. Das war eine, wenn auch sehr unstrukturierte, Werbeveranstaltung für systemd, mit Linux hat es nur am Rande zu tun.
    Ich muss ja bedauerlicher weise sagen, dass es mich bei dem Gast nicht überrascht hat..

  41. Beim Lesen der ganzen Kommentare bin ich erst auf den Trichter gekommen, dass der Inhalt des Podcast um systemd ging. Leider ist der Titel doch etwas irreführend, da ich gedacht habe, dass man hier einen kleinen Einblick in das Betriebssystem bekommt, dass kein abgebrochenes Informatikstudium voraussetzt. Schade. Für nicht Nerds war der Podcast dann wenig erhellend. Da bin von Tim aber ganz andere Sachen gewohnt. So bleibt es für mich die schlechteste CRE Folge seit langem. Nach 1,5h habe ich dann die Segel gestrichen, da durch die ganzen Fachbegriffe der Inhalt des Gesagten auf der Strecke blieb.

    Thema verfehlt würde ich mal sagen…

    • Der Titel lautet „Das Linux System“ und bezieht auch genau darauf. „Der Linux Kernel“ wäre etwas anderes gewesen. systemd ist das zentrale Element, dieses „System“ in Linux neu zu definieren. Und genau darum ging es auch. Dass der Podcast etwas anspruchsvoll ist und Vorwissen erfordert hätte man eingangs noch mal betonen sollen, das stimmt.

    • Beim ersten Anhören war ich auch etwas irritiert von dem Inhalt dieser Folge. Meine Feststellung war, dass meine Vorbildung einfach nicht hinreichend war, um dieses Thema zu erfassen. Daher habe ich mir etwas Literatur gegönnt. Beim zweiten Anhören war dann alles glasklar und das Thema wurde brilliant abgedeckt.

      Ich habe mir zu den üblichen Onlinequellen und Hands-on Aktionen das Buck „How Linux Works“ von Brian Ward durchglesen. Es ist mit Sicherheit nicht ausreichend um dananch seinen eigenen Kernel zu entwerfen, aber es gibt einen guten Überblick.

      Last but not Least. Danke Tim, für eine weitere, ganz starke Folge.

  42. Meinermeinung nach gibt es zumindest für mittelständische Unternehmen heutzutage keine Alternative mehr zu Linux. Die Kosten für Betriebssystem, Office-Software, Datenbakservern, usw. steigen und steigen für den Windows-Nutzer ins unendliche, während es bei Linux fast alles umsonst gibt. Aber erfahrungsgemäß wehren sich die alteingesessenen Nutzer noch sehr dagegen aus Angst vor etwas Neuem … Schade eigentlich, würde die Wirtschaft mit Sicherheit ordentlich ankurbeln …

  43. Ein bisschen späte Korrektur, aber trotzdem:

    Ardour benutzt NICHT pulseaudio per default, sondern alsa — es kann garnicht pulseaudio als primären Soundserver verwenden.

    Dankeschön für die Folge! :)

  44. Ist ja nun schon eine Weile her das der CRE 209 veröffentlicht wurde, aber ich höre mir ältere Folgen immermal wieder gerne an, dann sieht man die Dinge Rückblickend etwas genauer.
    Ich habe nichts gegen systemd, im Gegenteil. Ich sehe es so, dass es sich fortschrittlich weiterentwicklen muss. Enttäuschend fand ich allerdings, das Lennart seinerseits ziemlich über Admins gelästert hat, die systemd nicht gut finden. Auch wenn ich systemd nutze, hab ich mich doch angegriffen gefühlt, weil er es als etwas verwerfliches darstellt, wenn man einen gewissen Stolz darauf hat, etwas erlernt zu haben.
    Und muss immer alles „einfach“ sein? Das kann man nicht mit ja und nein beantworten. In den letzten 4 Jahren ist mir zunehmend aufgefallen, dass immer alles „noch einfacher“ sein muss. Leider wird beim einfacher machen immer nur auf GUI gesetzt. Ist ja okay, aber wenn ich etwas nur noch grafisch bedienen kann, geht es an denen vorbei, die ohne Grafik schneller sind. Lennart sagt selbst, dass er viel die Kommandozeile benutzt. Aber es gibt auch Einstellungen die man mittlerweile nur noch grafisch herstellen kann. Schade. Neben dem hochinformativen Inhalt, wäre es doch schön zu wissen, dass hier nicht einfach nur auf „das Alte“ geschlagen wird.

  45. Es nervt halt dass sich so eine emotionale Debatte überhaupt entspinnen muss, ich bin nicht frei von Vorurteilen, ich würde die Gesamtproblematik beiden Seiten zu 50% zurechnen. Den Pöttering könnte man einfach auch öfters einfach mal (auf der persönlichen und emotionalen Ebene) ignorieren…

    Meine Vorurteile reichen zurück bis zu meinem Thinkpad X21, das mit Pulseaudio nicht knackfrei _irgendwas_ abspielen konnte, mit Alsa aber schon. Dann irgendwann zu begreifen dass dafür nur eine, für die meisten Fälle überflüsse, Abstraktions-Software verantwortlich ist + (und das hat sich damals wirklich bisschen so abgezeichnet) immer mehr (‚audioclient‘)-Software ausschließlich auf diesen Mist (sorry) setzt, das hat sich mir ein bissl eingebrannt. Solche Vorurteile sind schwer loszuwerden.
    (beim späteren Thinkpad T40 lief PA übrigens auch noch nicht, und ich habe in der Zeit bestimmt ein halbes dutzend Rechner aus dem Bekanntenkreis durch abschalten von PA ‚reparieren‘ können)
    Inzwischen hat sich der Trend (zum Glück) nicht fortgesetzt, das letzte Programm das ausschließlich auf PA gesetzt hat war die letzte Linux-Version von Skype. (…passt ja auch, oder?)

    Wie oben schon von jemandem erwähnt, ein init-skript kann mit wenigen Zeilen ein System booten, wer systemd nicht will kann theoretisch auch ohne. Falls sich so ein (von mir da oben hypothetischer) Trend in Richtung Abhängigkeit von Userland- bzw. benötigter Systemssoftware durchsetzt wird es Mist. Und die Kritik müssen sich auch die systemd-Entwickler gefallen lassen.

    Das hat nichts mit Glauben zu tun. Da werden immer ‚Seiten‘ eingenommen, sowas kennt man doch sonst nur von Apple- oder M$-Fanboy-Kindereien. Das muss echt aufhören, peinlich.

    Ich weiß, der Podcast is oll, aber systemd ist ja trotzdem noch genuch Nachrichten wert, deswegen meine 2ct.

    Gruß k.

Schreibe einen Kommentar zu txt.file Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.