Login


 
Newsletter
Werbung

Thema: Umfrage-Ergebnisse zu Systemd in Debian

97 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
7
Von Tuco am Do, 30. Mai 2013 um 09:33 #
7
Von Unerkannt am Do, 30. Mai 2013 um 09:48 #

Ich darf gestehen systemd macht mir Angst. Da wird sich Distribution nach Distribution einverleibt. Ich kann mir eigentlich nicht Vorstellen das dies gut sein kann. Hoffentlich kippt Debian nicht. Sonst bleiben nur noch Gentoo und Slackware und ich habe meine Zweifel ob die beiden groß genug sind um auf Dauer standzuhalten.

  • 4
    Von Kinch am Do, 30. Mai 2013 um 09:57 #

    Dito! Das gleiche Spiel findet ja mit ext4 statt. Nutzen die Distris einfach so neuere Technologien, was soll denn das?

    • 1
      Von blablabla am Do, 30. Mai 2013 um 10:29 #

      Tja solls geben, bei gegenteil wird ja auch gemotzt. Ext4 ist ein fortschritt zu Ext3...eine Evolution. Systemd ist eine Revolution, ob gut oder schlecht muss jeder selber entscheiden. Für mich will das tool zuviel, das technisch gesehen der log zu bootprozess gehört ist klar, aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an....aber hat eben auch seine vorteile.

      • 2
        Von Mr. Y am Do, 30. Mai 2013 um 11:10 #

        aber das ich nun systemctl eingeben muss

        "... aber dass ich nun den roten Fuchs statt das blaue e anklicken muss ..." Auf dem Level zu kritisieren ist schon ein bisschen flach.

        • 0
          Von blablabla am Do, 30. Mai 2013 um 19:22 #

          Ja stimmt :-) aber ich meinte auch den nebenaufwand, logs können nicht mehr so leicht als text kopiert werden und hunderte scripts müssen geändert werden, teilweise auch hinterherhinkende überwachungssoftware im code geändert werden. Aber eben das ist nicht die sache von systemd, im allgemeinen finde ich das system sehr gut, nur ich bin faul und will meine 10 Jahre alten bash flickereien nicht anschauen, vom meine Ada-code ganz zu scheigen ;-)

          • 0
            Von TC am Do, 30. Mai 2013 um 19:58 #

            logs können nicht mehr so leicht als text kopiert werden

            Das stimmt doch gar nicht. Journalctl gibt die Logs im gleichen Format aus wie messages.log, alternativ z.B. auch als JSON, und ist deutlich flexibler als vorher. Die Texte kannst du weiterhin mit allen gängigen Unix-Tools verarbeiten.

            • 0
              Von blablabla am Do, 30. Mai 2013 um 23:18 #

              Ja sind aber nicht mehr OHNE journalclt auszulesen. Aber ja es ist flexibler aber erfordert trotzdem arbeit bei der anpassung.

              • 0
                Von Felix Schwarz am Fr, 31. Mai 2013 um 09:17 #

                Ich glaube, das ist falsch. Was hindert dich daran, einen traditionellen syslogd als Backend for journald zu benutzen? So wird das zumindest bei Fedora (und ich glaube auch bei Arch+Suse) gemacht.

                Damit merkst du von journald überhaupt nichts, wenn du nicht willst. /var/log/messages etc. existieren dann genauso wie vorher. Du hast exakt gar keinen Umstellungsaufwand.

                • 0
                  Von 0mark am Fr, 31. Mai 2013 um 09:49 #

                  Es hindert mich nichts, aber man kann den journald nicht abstellen. Das loging kann man abstellen, aber der journald läuft trotzdem.

                  0
                  Von blablabla am Fr, 31. Mai 2013 um 17:49 #

                  Wie bitte das geht??? Ich nehme alles zurück wenn dem so ist! systemd alleine produziert logs im eigenen format die signiert, komprimiert unsw....werden können, coole sache, aber hat eben den auslese-direkt nachteil. Wenn man aber denn traditionellel rsyslog anhängen könnte....das wär/ist sehr elegant.

                  0
                  Von blablabla am Fr, 31. Mai 2013 um 17:51 #

                  Den aufwand hat man immer, das backend will ja angehängt werden :-) aber um vielfaches weniger.

                  PS: Nein bei Arch ist das bin-format std.

        1
        Von Felix Schwarz am Do, 30. Mai 2013 um 12:05 #

        "aber das ich nun systemctl eingeben muss und die logs ein eigenes format haben, dass kotzt mich teilweise gewaltig an"

        Habe ich früher auch mal so gesehen, aber Fedora 16/17 haben mich da "bekehrt":

        1. 'service ... restart' funktioniert immer noch

        2. Die Logs werden (bei Fedora) immer noch per default im syslog gespeichert, nur dass jetzt eben auch early boot dabei ist und mir journald auf Wunsch auch nur die Log-Einträge eines daemons geben kann.

        Man kann sich sicherlich fragen, wie viel denn wirklich zum "init" gehört, da befindet sich systemd jetzt sicherlich in einer Grauzone. Aber aufgrund der bisherigen Erfolge und Verbesserungen, die systemd gebracht hat, bin ich zuversichtlich, dass die Entwickler schon richtig entscheiden werden.

        • 1
          Von LH am Do, 30. Mai 2013 um 12:15 #

          Eine Aufteilung in auch von außen besser erkennbare Systemteile hätte sicher einen Großteil der Kritik beseitigt.

          Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile, selbst wenn es die gleichen Entwickler sind. Dies schafft Transparenz und beseitigt Unklarheiten, bevor sie entstehen.
          Aber sie haben sich dagegen entschieden, und jetzt muss man dort eben auch mit der daraus entstehenden Kritik leben.

          Das hätte man natürlich ändern können, aber Lennart Poettering bleibt sich da ja lieber selber treu ;)

          • 2
            Von rio am Do, 30. Mai 2013 um 12:23 #

            > Ähnlich wie es bei GNOME gemacht wird. Ein großes Projekt, aber viele klar getrennte Teile

            Zu viel Kleinstückelung ist auch nicht gut, das war bei Gnome früher extremer. Bei Gnome 3 wurde da einiges konsolidiert, Bibliotheken zusammengefasst etc. Jede Shared Library, jede Abstraktionsschicht hat auch ihren Preis.

            • 2
              Von LH am Do, 30. Mai 2013 um 12:39 #

              Sicherlich muss das Verhältnis stimmen.
              Ob journald jetzt wirklich Teil von systemd sein musste? Oder diverse der kleineren Dienste?

              Sicherlich muss man systemd nicht in > 60 kleine Pakete zerteilen, nur weil es entsprechend viele binaries gibt, eine Gewisse Aufteilung hätte dem Ansehen des Projekts jedoch gut getan.

              Nun hat das Ansehen seiner Arbeit Lennart Poettering wohl noch nie sooo sehr interessiert, oder zu einem Umdenken bewegt, jedoch hätte sich manche Kritik am Anfang verhindern lassen.

              • 1
                Von woweil am Fr, 31. Mai 2013 um 06:53 #

                Die Frage sehe ich genau so. Und es wird noch verrückter. Ohne einen in Betrieb befindlichen journald "kommt das System nicht mehr hoch"!. Das habe ich bei Fedora 18 selbst getestet. Ich hatte den journald mit "mask" deaktiviert. Ein "disable" funktionierte erst gar nicht. Anschließend fuhr das System wahrscheinlich bis zu der Stelle auch, an der journald wohl aktiviert werden sollte.
                An meinen Äußerunge hört man wahrscheinlich auch heraus, daß die Fehlermeldungen so unverständlich sind, daß man nicht erkennen kann, wo der Fehler liegt.

                Und die Geschichte mit dem journald hat mir den Boden aus dem Faß getrieben. So was brauche ich nicht, wo mir Dinge aufgezwungen werden und zwar in der Form, daß systemd nicht mehr funktioniert, wenn journald deaktiviert wird.

                Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen -die werden bestimmt nicht sowas nicht mit machen aufgrund ihres KISS (keep it small and simple) Prinzips. Sollte ich mich diesbzgl. irren, lande ich mit an Sicherheit grenzender Wahrscheinlichkeit bei einem BSD-Derivat.

                Von den Machern ist außer arroganten Äußerungen nichts anderes substantiiertes zu vernehmen. Das ist für mich auch schon ein Grund skeptisch zu sein. Wenn anstatt echten Argumenten nur Polemik gegen die Skeptiker geworfen wird.

                Fast bin ich geneigt meinen Kommentar

                mit grummelnden Grüßen

                zu beenden.

                Wolfram

                • 0
                  Von LH_ am Fr, 31. Mai 2013 um 08:04 #

                  "Sollte systemd wirklich bei allen Distributionen Standard werden, dann dürfte für mich wahrscheinlich nur noch Slackware in Betracht kommen"

                  Wie es scheint, bleibt Canonical sich relativ treu und wird wohl bis auf weiteres auf Upstart setzen. Einzelne Elemente werden wohl aus Systemd verwendet, jedoch nicht deren Init-Implementierung an sich.

                  • 2
                    Von blubb am Fr, 31. Mai 2013 um 08:16 #

                    Wie es scheint, bleibt Canonical sich relativ treu und wird wohl bis auf weiteres auf Upstart setzen. Einzelne Elemente werden wohl aus Systemd verwendet, jedoch nicht deren Init-Implementierung an sich.
                    Das wird wohl so sein, allerdings hat Canonical solche Entscheidungen doch quasi nie auf Grund technischer Überlegungen getroffen sondern eher auf Grund eines NIH-Komplexes.

                    Zumal man ja sicher einige Argumente gegen systemd auf den Weg bringen kann, aber sicher ist auch, dass Upstart wohl kaum die "technisch korrekte" Lösung sein ist.

                    • 2
                      Von LH_ am Fr, 31. Mai 2013 um 08:21 #

                      Auch Upstart hat seine stärken. Aber lass uns nicht zu sehr in diese Richtung mit der Argumentation abdriften, viele Vorteile und Nachteile sind auch stark davon abhängig, wie man die Zukunft des Linux-Desktops sieht, sowie welche anderen Dienste und Prozesse man in einer Distribution erwartet. Weder Upstart noch Systemd sind Lösungen, die ohne Umfeld laufen. Diskutiert man also über die Features beider Systeme, muss man zwingend auch über das Umfeld diskutieren. Doch in diesem Punkt müssen wir hier passen, den niemand kann sicher sagen, wie Canonical, Red Hat und co. sich wirklich entwicklen. Aber erst die zukünftige Entwicklung macht klar, welche Lösung der bessere Idee ist.

                      Upstart ist, da dürften wir uns einig sein, eine eher bewusst kleiner gehaltene Lösung, die eher auf Interaktion mit bestehenden Systemen hin entwickelt wurde. Auch das macht es schwer es mit Systemd zu vergleichen, das bewusst mehr Arbeiten selbst erledigt, die es nicht erledigen müsste.

                      Zudem sollte man nicht ignorieren, das Canonical Upstart begonnen hat, als es noch kein Systemd gab. Man kann ihnen also hier nichts vorwerfen.

                      • 2
                        Von blubb am Fr, 31. Mai 2013 um 08:37 #

                        Upstart ist, da dürften wir uns einig sein, eine eher bewusst kleiner gehaltene Lösung, die eher auf Interaktion mit bestehenden Systemen hin entwickelt wurde.
                        Das stimmt natürlich, aber genau das ist ja auch Teil des Problems. Upstart ist in meinen Augen eher Patchwork für das bestehende System. Das kann, wenn man es gut und konsequent betreibt ganz ok funktionieren, aber in der Realität sieht das leider oft anders aus.
                        Einen Schnitt zu machen und sysvinit hinter sich zu lassen war die richtige Entscheidung. Über die anderen Entscheidungen kann man sicher lange diskutieren, aber diese eine sollte eigentlich kein Thema mehr sein.
                        Zudem sollte man nicht ignorieren, das Canonical Upstart begonnen hat, als es noch kein Systemd gab. Man kann ihnen also hier nichts vorwerfen.
                        Ich würde Canonical auch nicht vorwerfen, dass sie mit Upstart begonnen haben, zumal sie ja im Endeffekt auch selbst wissen wollen was sie mit ihrer Zeit anfangen. (Wobei Upstart einer der Gründe war warum ich mich nicht mehr mit dieser Distribution beschäftige, da mir das ständig Probleme bereitet hat.)
                        Was ich Canonical vorwerfe ist, dass sie beim Design der Lösung (meiner Meinung nach) einfach gepatzt haben, nicht konsequent genug waren. Evtl. muss man nicht so radikal wie systemd vorgehen (was sicher Vor- und Nachteile hat), aber nur an der Oberfläche kratzen bringt es auch nicht.

                  0
                  Von blubb am Fr, 31. Mai 2013 um 08:13 #

                  Finde ich auch ein Unding, zumal das Ding in 6 Tagen ganze 11 kB Speicher und 7.5s Rechenzeit gefressen hat. Das muss ich unbedingt deaktivieren!

              1
              Von endnote am Fr, 31. Mai 2013 um 06:23 #

              Das ist auch der Grund warum Gnome 3 nur unter Linux richtig funktioniert mit den meisten Funktionen. Da müssen sich die Entwickler nicht wundern, warum Forks und KDE4 so viel erfolgreicher sind.

      0
      Von Mr. Y am Do, 30. Mai 2013 um 10:55 #

      Nutzen die Distris einfach so neuere Technologien

      Wenn sie besser sind, ja.

    1
    Von Marcus Moeller am Do, 30. Mai 2013 um 20:10 #

    Also mir macht systemd in erster Linie Spass. Es vereinfacht meine tägliche Arbeit und bietet mir viele tolle Funktionen die früher nicht möglich waren. Ich empfehle einfach mal die Bedenken/Ängste beiseite zu lassen und sich systemd mal wirklich anzusehen bzw. es auszuprobieren.

    Ich würde mich sehr freuen wenn Systemd auch in Debian mehr Akzeptanz erfahren würde.

    • 0
      Von Unerkannt am Fr, 31. Mai 2013 um 00:54 #

      Da ich mit dem bisherigen Init-System meiner Distribution keine Probleme habe, werde ich mir bestimmt kein neues System anschauen. Den Zwangskontakt den ich mit systemd durch die "Predictable Network Interface Names"-Änderungen in udev hatte, der hat mir bereits genug gestunken. Hoffentlich bleibt mir weiterer Kontakt erspart.

      • 1
        Von ich am Fr, 31. Mai 2013 um 10:01 #

        Meine Pferdekutsche rollt doch auch, warum soll ich mir "Autos" ansehen?

        • 0
          Von Unerkannt am Fr, 31. Mai 2013 um 10:29 #

          Wenn du mit deiner Pferdekutsche zufrieden bist, dann würde ich sagen bleib dabei. Schon alleine einen Führerschein zu machen kostet, Geld, Zeit und je nach Fahrprüfer auch einiges an Nerven. An deiner Stelle würde ich mir das Abenteuer Auto nicht antun. Die Straßen sind zu Stoßzeiten ohnehin schon viel zu verstopft. Ich bitte dich inständig, sieh dir Autos nicht an. Ich beineide dich um die einfache und zweckmäßige Funktionsweise deiner Pferdekutsche.

          • 0
            Von =HAL-9000= am Fr, 31. Mai 2013 um 11:12 #

            Dabei solltest du aber nicht vergessen, pro Pferd zahlst du durchschnittlich 500 Euro im Monat (Stall, Futter, Hufschmied, ...), deine Kutsche muss Verkehrssicher sein (Bremse, Beleuchtung, ...). Als Privat Person kann man zwar auf den Führerschein verzichten, braucht aber aus Versicherungsgründen für die Pferdehalterhaftpflichtversicherung mit Risiko durch Gespannfahrten das sog. Fahrabzeichen. Dieses Fahrabzeichen der FN entspricht in Stufen, Ausbildung etc. etwa dem Reitabzeichen und muß in einer Prüfung erworben werden. Es beginnt mit Klasse IV, danach folgt III und II, die Anforderungen der Abzeichenstufen steigen entsprechend an.

            Rechnet man das alles zusammen, lohnt der Blick auf das Auto durchaus wenn man nicht zufällig ein sehr großer Enthusiast in Sachen Kutsche und Pferde ist.

            MfG =HAL-9000=

2
Von Fronz am Do, 30. Mai 2013 um 10:25 #

Warum werden jahrzehnte bewährte Mechanismen auf Teufel komm raus ersetzt? Wegen der paar Sekunden gesparten Bootzeit?
Ich muss (archlinux, SuSE) mich zwangsweise damit befassen: systemd ist ein großes schwarzes Loch.
Außerdem widerspricht es der Lunix-Philosophie "ein Programm, ein Zweck". Es geht ja noch weiter: zumindest udev und dbus sollen in systemd aufgehen. Monilithisierung.
Schade, ich finds ungünstig.

  • 1
    Von blablabla am Do, 30. Mai 2013 um 10:44 #

    Ahhhh auch ein Archer :-) . Nein es geht nicht nur um die Bootzeit, es geht auch um sicherheit, systemd hat wirklich viele vorteile die man selber bei Lennards blog nachlesen kann, aber wie ich oben geschrieben habe will dass tool einfach zuviel, da geb ich dir absolut recht.

    Aber macht das nicht zb auch BTRFS mit ihrem eigenen Raid-gewurschte? Und bei denen freut man sich nur :-)

    Das ganze Lennard gebashe versteh ich auch nicht ganz, wer mal soviel für oss gemacht hat kann sich ja gerne melden. Wenn man bisschen in der öffentlichkeit steht wird man regelrecht angeschissen für arbeit die die "anscheisser" KOSTENFREI beziehen, ich sagt dann immer "fresse halten oder mitmachen", Linus sagt es bisschen schöner aber mit gleichem effekt:
    Show me your code!!

    • 0
      Von zettberlin am Do, 30. Mai 2013 um 13:04 #

      > Das ganze Lennard gebashe...

      Hängt sehr wahrscheinlich mit Pulse Audio zusammen. Dass PA so ein Chaos in den Desktopdistros verursacht hat, ist sicher nicht nur seine Schuld, fest steht, dass er als Autor dran war, weil es einfach nicht gut funktioniert hat(und immer noch nicht sehr gut funktioniert).
      Obwohl er mit PA ein gutes und richtiges Konzept hatte, muss er jetzt damit leben, dass die Packager der Distros es immer noch falsch konfigurieren. Vielleicht hat er es ja auch nicht gut genug dokumentiert?

      Obwohl ich selber in Ubuntu und Fedora noch nie echte Probleme mit systemd hatte, mag es sein, dass das anderen anders geht. Und dann fragt niemand: "Welcher inkompetente Trottel hat das so falsch eingebaut?" sondern: "Welcher inkompetente Trottel hat das programmiert?!"

      Übrigens: Hast Du einen Link zu einem Handbuch, nach dem man systemd und PA fehlerlos richtig in eine Linux-Distro einbauen kann?

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Mai 2013 um 13:06.
      • 0
        Von blablabla am Do, 30. Mai 2013 um 19:32 #

        Zum handbuch....kann ich dir nur die "arch-upgrade sysV zu systemd-anleitung" empfehlen, aber es zeigt gut welche schritte vorgenommen werden müssen bzw was in welcher kombi gemacht werden muss, ich denke aber auch das die Distri diese Entscheidung machen muss, ansonsten hast du die ganze zeit damit zu tun systemd an das OS anzupassen, würde also davon abraten AUSSER wenn du zb Arch (gentoo? andere???) einsetzt, dass Systemd zum standard erklärt hat. Oder du testest mit Debian Wheezy wo du Systemd optional installieren kannst, für produktive maschinen würd ich mir den Aufwand und das risiko aber sparen.

        0
        Von devent am Do, 30. Mai 2013 um 22:23 #

        Vielleicht war es einfach nur dass Audio in Linux Jahrelang ein gefrickel war?
        Seit der Einführung von PA hatte ich keine Probleme damit und es ist nun wesentlich besser als alles was davor in Linux war.

        • 0
          Von Unerkannt am Fr, 31. Mai 2013 um 00:42 #

          Wann war denn bitte Audio unter Linux ein gefrickel? Selbst damals 2000 herum als ich mir zum ersten mal ein SuSE installiert habe da ging Audio einfach. Was macht denn PA für dich was du vorher gebraucht hast und nicht bekommen konntest?

          • 0
            Von LH_ am Fr, 31. Mai 2013 um 08:00 #

            Dann hast du aber nur sehr einfache Situationen gehabt.
            Spätestens bei Hot-Plug Audiogeräten (USB und co.) und komplexeren "Routings" (welche App wohin/woher) konnten einem schnell die Haare zu berge stehen.

            • 0
              Von Unerkannt am Fr, 31. Mai 2013 um 09:48 #

              Ja meine Anforderungen waren vermutlich nicht sehr hoch. Mir hat es in der Vergangenheit einfach gereicht wenn ich Musik hören konnte oder Ton in Spielen/Filmen hatte. Mit USB Hot-Plug, was ich vor etwa vier Jahren zuletzt verwendet hatte, traten bei mir eigentlich keine größeren Probleme auf. Zumindest kann mich nicht daran erinnern. Ich glaube ich musste irgendwas anpassen, damit die eingebaute Soundkarte und die USB-Soundkarte bei einem Cold-Plug die von mir gewünschte Reihenfolge haben. Die Anwendungen mussten natürlich noch auf die jeweils gewünschte Soundkarte eingestellt werden. So genau kann ich mich nicht mehr erinnern. Es war einmal etwas Einzustellen und danach lief es wie ich es wollte. Hängen geblieben ist bei mir eher die Freude die ich damals hatte, dass die USB-Soundkarte einfach ging. Denn ich hatte damals befürchtet USB-Sound ist etwas exotisches und könnte deshalb von Treiberwegen Probleme bereiten. Allerdings war die Annahme wohl unbegründet.

              Bei mehreren Hot-Plug-Geräten kann es vielleicht etwas unüberschaubar werden. Das ist allerdings sehr weit von meinem Nutzungsprofil weg.

              • 0
                Von zettberlin am Sa, 1. Juni 2013 um 00:21 #

                > Mir hat es in der Vergangenheit einfach gereicht wenn ich Musik hören konnte oder Ton in Spielen/Filmen hatte.

                Das sind ganz normale Anforderungen, die ein modernes System auch einfach so erfüllen sollte. Allerdings war das mit OSS nicht zu haben also kam Alsa, das aber erst mal nicht viel besser als OSS mit mehreren Soundquellen gleichzeitig umgehen konnte, also kamen diverse Sound-Daemons und die haben dann das berüchtigte Chaos von Linuxaudio geschaffen.
                PA schießt da mit der Schrotflinte drauf: es versucht so ziemlich alles zu unterstützen, was jemals gemacht wurde, was wahrscheinlich der richtige Ansatz ist. Wenn DOSBox zum Beispiel nach /dev/dsp sucht, sollte PA dort lauern und sagen: "komm mit, ich bin Deine freundliche OSS-Schnittstelle, hier lang gehts zur Soundkarte." Wenn es das nicht tut, sucht entweder DOSBox nicht nach /dev/dsp oder PA setzt sein an sich gutes Konzept in diesem Fall nicht richtig um.

                Dieser Beitrag wurde 1 mal editiert. Zuletzt am 01. Jun 2013 um 00:23.
                • 0
                  Von LH_ am Sa, 1. Juni 2013 um 10:05 #

                  Die Einschränkungen galten allerdings allesamt nicht für OSS4, das sich unter Linux aber nie durchsetzen konnte.
                  Aufgrund von den teils massiven Problemen bei der Einführung von PA nutze ich OSS4 eine Zeit lang, eigentlich eine sehr gute Lösung, die heute allerdings tatsächlich nicht mehr nötig ist.

        0
        Von jwd am Fr, 31. Mai 2013 um 10:17 #

        > Dass PA so ein Chaos in den Desktopdistros verursacht hat, ist sicher nicht nur seine Schuld, fest
        > steht, dass er als Autor dran war, weil es einfach nicht gut funktioniert hat(und immer noch nicht sehr
        > gut funktioniert).
        > Obwohl er mit PA ein gutes und richtiges Konzept hatte, muss er jetzt damit leben, dass die Packager
        > der Distros es immer noch falsch konfigurieren. Vielleicht hat er es ja auch nicht gut genug
        > dokumentiert?

        PA blockiert zuverlässig die Musikausgabe von DosBox. Erst wenn ich PA stoppe, kann ich die Musik von alten Spiele-Klassikern genießen. Vor PA funktionierte das jahrelang tadellos. Da ist es mir egal, ob die Packager PA in Poetterings Augen falsch konfigurieren, was ich schlicht für eine seiner Ausreden halte. So à la "Alle doof außer mich!" Der Kerl erinnert mich an einen verrückten Wissenschaftler, der von der Idee besessen ist, die Welt mit seinen Kreationen zu beglücken. Geht die Chose dann schief, heißt es lapidar, er sei missverstanden worden und niemand wisse ihn richtig zu würdigen.

        • 0
          Von Unerkannt am Fr, 31. Mai 2013 um 10:37 #

          PA blockiert zuverlässig die Musikausgabe von DosBox. Erst wenn ich PA stoppe, kann ich die Musik von alten Spiele-Klassikern genießen.
          Hört sich nach dem an, was man vor einigen Jahren, artsd vorgeworfen hat. Kommt scheinbar alle Jahre mal wieder.

          Wenn du PA eigentlich nichts brauchst, dann deinstalliere es doch einfach. Dürfte die einfachste Lösung sein.

      0
      Von Frank Frank am Do, 30. Mai 2013 um 15:21 #

      > Aber macht das nicht zb auch BTRFS mit ihrem eigenen Raid-gewurschte? Und bei denen freut man sich nur

      Eigentlich kenne ich überhaupt niemanden, der das gut findet.

      • 0
        Von blablabla am Do, 30. Mai 2013 um 19:35 #

        Oh ok :-( ...ich eben auch nicht...ich dachte ja nur.....weil dort halt niemand was gegen sagt....undso

        0
        Von Hyäne am Do, 30. Mai 2013 um 22:43 #

        Ist die RAID-Funktionalität nicht optional? Ich meine, kann man das nicht ignorieren, soweit sich keine kritischen Fehler in den Code einschleichen?

        • 0
          Von blablabla am Do, 30. Mai 2013 um 23:23 #

          Klaro kannst du dass, eine Code-duplikation ist es trotzdem, und damit fehleranfälliger und aufwändiger zu warten. Aber es wird schon seine technischen gründe haben wieso die ihr eigenes süppchen köcheln...welcher?...keine ahnug....

        0
        Von =HAL-9000= am Fr, 31. Mai 2013 um 11:19 #

        Ich finde es gut. Der Grund dafür ist simpel, Features wie DeDup, Checksum, etc. pp. lassen sich nicht stabil implementieren wenn das FS nicht über alle Schichten hinweg Wissen hat und dieses entsprechend nutzen kann Es ist schlicht zu problematisch das über APIs zu realisieren. Nebenbei kann man via JBOD relativ günstige Storage Units realisieren verglichen mit den Hardware Lösungen. Nur BBU bleibt in der Konstellation natürlich ein ungelöstes Thema.

        MfG =HAL-9000=

    1
    Von dfgdfg am Do, 30. Mai 2013 um 10:54 #

    > Warum werden jahrzehnte bewährte Mechanismen auf Teufel komm raus ersetzt?

    Sysvinit bewährt sich schon lange nicht mehr auf modernen Systemen, wo sich z.B. die Hardware jederzeit ändern kann.

    > Wegen der paar Sekunden gesparten Bootzeit?

    Myth 2

    > Außerdem widerspricht es der Lunix-Philosophie "ein Programm, ein Zweck".

    Myth 10

    > Monilithisierung.

    Myth 1

    3
    Von Mr. Y am Do, 30. Mai 2013 um 11:00 #

    Warum werden jahrzehnte bewährte Mechanismen auf Teufel komm raus ersetzt?

    Aus dem gleichen Grund, weshalb jahrhunderte bewährte Mechanismen wie Pferdekutschen auf Teufel komm raus durch Autos ersetzt wurden.

    • 1
      Von tuxtöter am Fr, 31. Mai 2013 um 08:53 #

      Um die Menschen von Ölscheichs, Autokonzernen und anderen Kapitalisten abhängig zu machen?

      GNU/Linux ist in der Tat wie Pferd und Kutsche:

      - Das nötige Know-How vorausgesetzt, kann man die Kutsche selbst bauen und warten.
      - Pferde kann man selbst züchten.
      - Das Futter kann man selbst anbauen.
      - Das alles macht sehr viel Arbeit, bringt aber Bezug zur Sache und damit Spaß.
      - Pferd und Kutsche sind skalierbar. Kleinere Besorgungen erledigt man nur mit dem Pferd.
      - Bei Kneipenbesuchen ist die Kutsche hilfreich. Das Pferd findet von alleine nach Hause und zieht dabei den Wagen.


      • 0
        Von Fiaker am Fr, 31. Mai 2013 um 11:05 #

        Es gibt ja auch weiterhin Pferdekutschen. Genauso wird es sicher auch in Zukunft folkloristische Distributionen mit Sysvinit geben.

        • 0
          Von Unerkannt am Fr, 31. Mai 2013 um 11:32 #

          Die dann aber vielleicht nicht mehr über den selben Funktionsumfang verfügen können. Da wird in kleinen Schritten ausgehöhlt. Erst braucht Xorg udev für seine Geräte Erkennung (da dürfen sich die nicht Linuxe schon einmal drüber freuen). Dann schnappt sich systemd udev. Fehlt als nächster Schritt nur noch, dass udev für den Rest nicht mehr richtig funktioniert. Zack ist man an systemd gebunden oder darf sich über ein statisches /dev freuen und über verminderten Funktionsumfang in Xorg.

          • 0
            Von Tronar am Fr, 31. Mai 2013 um 14:02 #

            Erst braucht Xorg udev für seine Geräte Erkennung (da dürfen sich die nicht Linuxe schon einmal drüber freuen).
            Die haben sich schon mächtig gefreut, als etwa HAL von Xorg als Abhängigkeit gefordert wurde. In *BSD hat man nach einigem Zögern laut fluchend dieses HAL-Monster portiert, owbohl man selbst bessere Systeme hatte (z. B. devd). Und als sie es so einigermaßen geschafft hatten, verlautete aus dem Xorg-Lager, man werde in Zukunft wieder auf HAL verzichten. Einige BSD-Leute kamen dann, glaube ich, in psychiatrische Behandlung ...

    2
    Von blubb am Do, 30. Mai 2013 um 13:36 #

    dbus sollen in systemd aufgehen
    Das stimmt nicht. Das soll im Kernel integriert werden, oder willst du gegen den nun auch wettern?

3
Von devent am Do, 30. Mai 2013 um 11:10 #

Also als Benutzer finde ich systemd wesentlich besser als die alten init-scripte.
Es ist einfacher zu benutzen:


systemctl start service
systemctl stop service
systemctl status service
systemctl enable service
systemctl disable service
usw.

Die systemd Scripte sind wesentlich einfacher als die Hochkomplexen init-Scripte:


[Unit]
Description=PDNSD
ConditionPathIsMountPoint=/mnt/read
After=NetworkManager.service

[Service]
Type=forking
ExecStart=/usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
PIDFile=/var/run/pdnsd.pid

[Install]
WantedBy=multi-user.target

Sehr informationsreich:


# systemctl status pdnsd
pdnsd.service - PDNSD
Loaded: loaded (/usr/lib/systemd/user/pdnsd.service)
Active: active (running) since Thu 2013-05-16 07:20:27 CEST; 2 weeks 0 days ago
Process: 1788 ExecStart=/usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid (code=exited, status=0/SUCCESS)
Main PID: 1790 (pdnsd)
CGroup: name=systemd:/system/pdnsd.service
└─1790 /usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid

May 16 07:20:27 vostrotitan.localdomain systemd[1]: Starting PDNSD...
May 16 07:20:27 vostrotitan.localdomain pdnsd[1790]: pdnsd-1.2.9a-par starting.
May 16 07:20:27 vostrotitan.localdomain systemd[1]: Started PDNSD.
May 23 04:18:20 vostrotitan.localdomain pdnsd[1790]: Error in udp send: Operat...

Im Grunde finde ich es gut, dass systemd Linux-only ist. Ehrlich gesagt interessieren mich andere Systeme nicht und wenn systemd durch Linux-only sehr gut in Linux wird, dann bin ich nicht dagegen.

systemd ist freie Software, auch die Abhängigkeiten von systemd sind alle freie Software, somit steht es jedem frei es auf sein System zu portieren. Wenn Hurd oder die *BSD es nicht portieren wollen, ist es doch deren Problem.

  • 1
    Von macs am Do, 30. Mai 2013 um 11:39 #


    systemctl start service
    systemctl stop service
    systemctl status service

    Nervt mich total. Ich finde es sollte genau umgekehrt sein, z. B.

    systemctl service start
    . Zum Glück gibts noch die Weiterleitung von "service".

    • 1
      Von ..,- am Do, 30. Mai 2013 um 11:58 #

      Ich finde es sollte genau umgekehrt sein

      Das ist gängige Konvention bei Kommandozeilen-Tools, zuerst das Unterkommando zu spezifizieren und dann die Parameter, siehe z.B. auch Git.

      • 0
        Von macs am Do, 30. Mai 2013 um 12:41 #

        Mag sein, aber "service" hatte das besser gelöst, wiel man eben mal schnell "status" durch "start" ersetzen konnte. Jetzt muss ich da erst aufwendig zurück...

        • 0
          Von blubb am Do, 30. Mai 2013 um 13:44 #

          Dafür gibt es bei der Shell Bindings um das einfacher zu gestalten. Bei bash weiß ich nicht, was man setzen muss, aber bei zsh nimmt man einfach 'insert-last-word'. Standard Belegung ist "^[." (Also Esc und Punkt).
          Das zusammen mit der completion von zsh macht systemctl sehr gut verwendbar.

          Übrigens ist das ein großer Vorteil, denn dadurch, dass jetzt endlich mal "ein" Tool dafür existiert welches über sehr viele Distributionen verbreitet ist, existieren auch endlich gute und weit verbreitete completions dafür.

          1
          Von safddsafsda am Do, 30. Mai 2013 um 13:58 #

          mach dir einfach einen alias und fertig!

    2
    Von .-,.-,.-,.- am Do, 30. Mai 2013 um 20:57 #

    Debian hat eben auch die Freiheit, Systemd nicht als Standard einzusetzen, genauso wie Ubuntu ebenfalls kein Systemd als Standard benutzt. Wenn es so kommen sollte, dann ist IMO Systemd im Linux-Ökosystem praktisch gescheitert und nur noch weitgehend Red Hat- und Suse-only.

    • 0
      Von blablabla am Fr, 31. Mai 2013 um 00:09 #

      Naja was Redhat einsetzt würd ich nicht als gescheitert ansehen.....oder macht eine andere Firma mit Linux soviel geld und unterstützt esin gleicher art und weise? Aber ja das mag ich an debian, mein Favorit für Desktop und Server und zwar das STABLE! Aber auf priv Pc und labi hab ich Arch...einfach weils spass macht :-)

      0
      Von blablabla am Fr, 31. Mai 2013 um 00:11 #

      Ja Ubuntu gibt dir die freiheit upstart zu nutzen....sonst nix....das ist ja noch viel übler da sie die einzigen sind die es überhaupt einsetzen wollen.

0
Von Tronar am Fr, 31. Mai 2013 um 17:50 #

Für alle, die sich mal einen ganz großen Überblick darüber verschaffen möchten, was es da überhaupt so gibt: A Survey of Unix Init Schemes

  • 0
    Von endnote am Fr, 31. Mai 2013 um 18:59 #

    Bei allem Respekt, dass ist der schlechtaufbereiteste Überblick der Init Systeme die ich in jüngster Zeit gelesen hab.

0
Von Miss Abuse am Mo, 3. Juni 2013 um 01:27 #

... *wenn* es dort als Standard ankommt, dann kommt es dort wohl so ziemlich als letztes an. Das erhöht die Chance, dass es bis dahin tatsächlich halbwegs funktioniert und dokumentiert ist. :)

Jedenfalls war das bisher immer so. (Obwohl, mit dem Betriebssystem innerhalb des Betriebssystem aka grub2 stehe ich immer noch auf Kriegsfuss.)

Wie auch immer, Wheezy ist gerade raus, d.h. für die nächsten 2 Jahre ist das Thema systemd für mich persönlich uninteressant. Oder auch 3 Jahre, oldstable ist ja auch ein temporär gangbarer Weg. Und dann...

Ja, dann wird es wohl schon wieder jemanden geben, der meint noch was besseres als systemd erfunden zu haben.

Pro-Linux
Frohe Ostern
Neue Nachrichten
Werbung