1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Boycott Systemd

Dieses Thema im Forum "Geplauder, Fun und Chillzone" wurde erstellt von Athaba, 27 April 2014.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.060
    Nein, auch nicht indirekt ;) Sie haben schlicht gar nichts miteinander zu tun.

    Du kannst den Kernel halt über einen Bootloader wie Grub starten, oder halt direkt von EFI selbst. Letzteres hängt halt davon ab, wie mächtig dein EFI von Haus aus ist. Sollte es z.B. das nicht können, dann helfen EFI-Programme wie rEFInd oder gummiboot. Diese starten dann den Kernel. Der Kernel selbst ist aber seit Version 3.3 als EFI-Programm startbar.

    Normalerweise sucht das EFI auf der EFI-Systempartition nach Dateien mit der Endung .efi und listet diese auf. Bennenst du den Kernel entsprechend, dann sollte dieser aufgelistet werden.
     
  2. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.852
    Ort:
    Schleswig-Holstein
    Man kann den Kernel sogar dem NVRAM bekannt machen. Dann taucht er unter schönem Namen als Bootoption auf.
     
  3. Azazyel

    Azazyel Active Member

    Registriert seit:
    2 Juni 2005
    Beiträge:
    694
    Quelle bzw. Link zum Bug-Report?

    Der Erfolg von systemd liegt meiner Meinung nicht an Red Hats Marktmacht (Fedora ist alleine zu klein, RHEL/CentOS stellt erst jetzt um), sondern ausschließlich an der Untätigkeit des Rests. Die Diskussion um systemd läuft seit 3 Jahren, in denen systemd immer mehr zeitgenössische Anforderungen umgesetzt hat, während sich der Rest in Gejammere geübt und auf den Lorbeeren vergangener Tage ausgeruht hat.

    Das Ergebnis habe ich erst kürzlich bei mir im Unternehmen erleben können. Aus dem unternehmensinternen Test der Beta von RHEL 7 (vgl. mein Beitrag vom Februar) entstand ein Anforderungskatalog der Admins, der Teil der bevorstehenden Standardisierungsrunde der Betriebssysteme im Hause wird. Über die Jahre hat sich - größtenteils durch Firmenübernahmen - ein Wildwuchs von AIX, FreeBSD (seit April im Hause :)), Solaris und diversen Linux-Distributionen (CentOS/RHEL, Debian und SuSE) gebildet.

    Die Wahrscheinlichkeit, dass FreeBSD bei der Evaluation einen beträchtlichen Teil davon gar nicht oder nur mit erheblichen Einschränkungen erfüllen wird, ist sehr hoch. Daran haben die Features von systemd einen erheblichen Anteil.
    Selbst die FreeBSD-Verfechter unter unseren Admins können leider schwerlich mit absehbarer Feature-Parität von FreeBSD argumentieren. Spenden an Open-Source-Projekte sind im Hause aber nur möglich, wenn das entsprechende Projekt auch im Hause eingesetzt wird. :(

    Gibt's eine nachvollziehbare Begründung abseits der teilweise sehr alten Softwareversionen, die unter RHEL 6.x mitgeliefert werden?

    Welche guten Alternativen mit Support-Zeiträumen größer 5 Jahren gibt es, die nicht auf RHEL basieren?
     
  4. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.756
    Ort:
    Aachen
    @Azazyel
    [ketzerei]
    systemd ist nicht erfolgreich, weil es irgendwas erfüllt, was bis jetzt nicht ging, sondern weil ein Haufen Leute an entscheidenden Positionen in heller Begeisterung auf den Zug aufspringt und den inkompatiblen Scheiß pusht.
    [/ketzerei]

    *SCNR*
     
  5. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.060
    Hat zwar nur indirekt was damit zu tun, aber das Core Dump handling in systemd ist einfach grundlegend kaputt. Siehe auch:

    https://bugs.archlinux.org/task/40737

    Unten findest du eine Liste von Upstream Bugreports und systemd-Entwickler typisch interessiert es keine Sau ;)
     
  6. Kamikaze

    Kamikaze Bottom Poster Mitarbeiter

    Registriert seit:
    26 Mai 2005
    Beiträge:
    10.861
    Ort:
    /Earth/Europe/Germany/Karlsruhe
    Nun, der Bug wurde bei Arch abgegeben, nicht beim Systemd Projekt. Das ist ja mal blöd.

    Aber die Designentscheidung die hinter dem Problem steht ist schon hirnrissig.
     
  7. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.060
    Wie ich sagte, schaue einfach in den Kommentaren unten. Dort sind die meisten diesbezüglichen Bugs im offiziellen Bug-Tracker.

    Auch der CoreDump in Memory-Bug:
    Code:
    https://bugs.freedesktop.org/show_bug.cgi?id=62650 - systemd-coredump maintains the dump in memory
    
    weitere Bugs dazu, samt Kommentar (mal übernommen aus dem Link)
    Code:
    https://bugs.freedesktop.org/show_bug.cgi?id=62501 - "fixed", but now instead of truncating just doesn't save at all
    https://bugs.freedesktop.org/show_bug.cgi?id=62043 - executables can't have spaces in their names
    https://bugs.freedesktop.org/show_bug.cgi?id=59623 - same dumb "truncation fix" that breaks large coredumps
    https://bugs.freedesktop.org/show_bug.cgi?id=55613 - Open since october 2012 with no response
    https://bugs.freedesktop.org/show_bug.cgi?id=54288 - cores are unvisible to normal users (need root or adm group access), unfixed since august
    
    Wie schon gesagt, es ist nicht alles Gold was glänzt. Systemd hat auch extrem krassen Mist in seinem Ökosystem. Und das niemand bereit ist, darüber zu reden, bzw. es zu beheben sagt eigentlich auch schon den Rest. Stattdessen baut man lieber bereits existierende Projekte nach.

    Der Höhepunkt war ja die Geschichte mit, dass systemd den Linux-Kernel lahmlegt und man nicht bereit war darauf zu reagieren. Erst als Linus damit drohte sämtliche Pull-Requests abzulehnen.
     
  8. Crest

    Crest rm -rf /*

    Registriert seit:
    25 Juni 2008
    Beiträge:
    1.571
    Ort:
    /dev/random
    Der Bugreport wurde von einem Arch User bei Arch eingereicht, weil der Upsteam nicht reagierte.
     
  9. foxit

    foxit Moderator Mitarbeiter

    Registriert seit:
    4 Juli 2012
    Beiträge:
    1.427
    Ort:
    /home
  10. Athaba

    Athaba Libellenliebhaber Mitarbeiter

    Registriert seit:
    10 März 2005
    Beiträge:
    3.306
  11. chaos

    chaos *nix'ler

    Registriert seit:
    22 Juli 2003
    Beiträge:
    839
    Ort:
    München
    Ganz schauderlich. Ich zitiere mal daraus:
    und dafür den /etc/passwd-Ersatz nach

    verschieben. Und die Konfiguration erfolgt mit viel Voodoo.

    Wofür hatte man in UNIX verschiedene Verzeichnisse erfunden?
    Achso, wie man in diversen Quellen nachlesen kann, hat das nur historische Gründe und daher sind bei einigen Linuxen inzwischen /[s|]bin nur ein Symlink auf die entsprechenden Unterverzeichnisse von /usr. Ähnliche Gründe lassen sich bestimmt auch für die Aufhebung der Trennung weiterer Unterverzeichnisse aufführen.

    Zukünftig bitte ienfach Binärdateien nach /usr/etc und Textdateien nach /usr/lib!
     
  12. sanbiber

    sanbiber Member

    Registriert seit:
    16 Januar 2013
    Beiträge:
    94
    Oh, man.
    Wieso ueberhaupt noch Verzeichnisstrukturen? Wenn ein Prozess eine Datei benoetigt, fragt er bei systemd nach und der findet das passende. Dann muesste man allerdings bald von GNU/systemd sprechen als von GNU/Linux ...
    [ketzermodus off]
     
  13. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.060
    Registry-Prinzip ^^
     
  14. CommanderZed

    CommanderZed OpenBSD User

    Registriert seit:
    1 Juni 2005
    Beiträge:
    1.205
    Ort:
    Weyhe
    Ahhh ich krieg Kopfschmerzen ... darf man den Poettering auf schadenersatz verklagen wenn man wegen dem nen Herzinfakt bekommt ... mir fallen da keine sinnvollen Worte mehr ein ...
     
  15. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.852
    Ort:
    Schleswig-Holstein
    Dank systemd kann man doch heute schon nicht mehr richtig partitionieren. Das ist für sich genommen schon ziemlich blöd. Wenn dann noch systemds Behandlung von /tmp ins Spiel kommt (die man aber wenigstens abschalten kann), wird es ganz lustig.
     
  16. chaos

    chaos *nix'ler

    Registriert seit:
    22 Juli 2003
    Beiträge:
    839
    Ort:
    München
    -v, please!

    Wobei gleich kommen mir Zweifel, ob ich das wirklich wissen will.
     
  17. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.852
    Ort:
    Schleswig-Holstein
    In Standardeinstellung mountet systemd ungefragt ein tmpfs auf /tmp. Also auch, wenn in der /etc/fstab nichts Entsprechendes steht. Das allein ist schon nervig, denn es gibt durchaus Anwendungen, die sehr große Mengen Daten in /tmp zwischenspeichern. Die blockieren dann den RAM oder laufen irgendwann gegen die Dateisystembegrenzung. Aber damit kann man leben, wenn man es weiß. Es ist einfach abzuschalten:
    Code:
    systemctl mask tmp.mount
    
    Das Gefährliche ist nun, dass damit die Welt keinesfalls in Ordnung ist. Denn es gibt noch systemd-tmpfiles [1], was in Standardeinstellung einfach rigoros alle Dateien löscht, die älter als 10 Tage sind. Und es soll Server geben, die mehr als 10 Tage Uptime erreichen und entsprechend auch Prozesse besitzen, die schon mal Dateien länger als 10 Tage in /tmp liegen lassen. Für /var/tmp ist die Standardeinstellung 30 Tage. systemd kann anscheinen übrigens auch nicht - zumindest nicht ohne einen eigenen Service zu definieren - /tmp beim Boot ausräumen. Es verlässt sich darauf, dass es ein tmpfs ist und daher per Definition leer.

    Klar, es gibt bösere Fehler. Aber mir stößt sowas sehr sauer auf, da systemd ja immer gern als so wahnsinnig vorteilhaft für Systemadministratoren dargestellt wird. Dabei baut es eine ganze Reihe neuer, interessante Randfälle ein, was vorhandene Strukturen bricht und in Sysiphusarbeit behandelt werden muss. Zu /tmp war seit ca. 1975 die Aussage "temporary files that are not guaranteed to persist across system reboots". Davon, dass zur Laufzeit jemand mal einfach so Dateien weglöscht, weil er es kann, war nie die Rede. Und entsprechend rechnen viele Anwendungen, inklusive meine eigenen, einfach nicht damit.

    1: http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
     
  18. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.060
    Weitere nette Erfahrung meinerseits:
    systemd schafft es überall die NIC umzubenennen. Außer in meiner QEMU-VM. Dort nicht. Da gibt es irgendwo in den Untiefen von systemd einen Timeout und das Interface bleibt beim Namen "eth0". Ist dann natürlich doof, wenn man erst mal sucht, warum die Maschine plötzlich keine IP bekommt.
     
  19. mark05

    mark05 Member

    Registriert seit:
    19 November 2003
    Beiträge:
    794
    Ort:
    Bergisch Gladbach
    ich bin mal gespannt wenn systemd in der naecshten Redhat Release auftaucht und all die kunden die die dist
    im komeziellen einsatz haben , zu mossern anfangen weil nix mehr funktioniert .

    holger
     
  20. darktrym

    darktrym Fahnenträger

    Registriert seit:
    21 August 2006
    Beiträge:
    1.637
    Ort:
    Düsseldorf
    Ist doch bereits in 7 drin.
     
  21. peterle

    peterle Forenkasper

    Registriert seit:
    19 August 2006
    Beiträge:
    1.756
    Ort:
    Aachen
    Keine Angst, mit systemd nicht mehr, Lennart macht das schon! :D
     
    CrimsonKing und lme gefällt das.
  22. sanbiber

    sanbiber Member

    Registriert seit:
    16 Januar 2013
    Beiträge:
    94
    Ah, so wuerde das Ganze wieder Sinn machen: systemd als inetd fuer den ganzen Rechner - deshalb auch der Fokus auf schnellem Booten ... Und wenn ein Dienst fertig genutzt wurde, schaltet systemd den Rechner ab. Dann passt das auch wieder mit den tmp-files ...
     
  23. skull-y

    skull-y Member

    Registriert seit:
    13 Februar 2010
    Beiträge:
    42
    Ort:
    Halle/Saale
    Das Schlimme an Poettering ist, dass er Kritik an seiner Person und seinen Projekten nicht wahrnehmen kann oder will.
     
  24. sanbiber

    sanbiber Member

    Registriert seit:
    16 Januar 2013
    Beiträge:
    94
    Das koennte ja eigentlich egal sein, wenn es Verantwortliche gaebe, die ihn in die Schranken wiesen, wie es normalerweise der Fall waere: Wenn man Mist baut, bekommt man ne Verwarnung und wenn man weiter Mist baut, dann fliegt man. Aber offenbar laesst man ihm bei RedHat freie Hand, was wohl auch zu den strategischen Ueberlegungen, die RedHat verfolgt, passt: Man macht die eigenen "Technologien" unentbehrlich, usw.
    Neben Oracle ist RedHat eine der Firmen, die mir in Bezug auf Linux/Unix und OpenSource in letzter Zeit uebel aufgestossen sind. Aber irgendwann sind Firmen wohl so maechtig, dass sie vieles verkraften/anstellen koennen, ohne dass sie nennenswerte Schaden davon tragen ... Aber was soll oder kann man dagegen tun?
     
  25. solarix

    solarix Konsolenpenner

    Registriert seit:
    17 Juni 2004
    Beiträge:
    377
    Ort:
    Kuchen (Fils)
    Was man dagegen tun kann? Im kommerziellen Umfeld kann man immer noch AIX, oder Solaris einsetzen.... es gibt also durchaus Alternativen, die seit Jahrzehnten funktionieren und nicht den Geschmack eines Pickelgesichtigen Gymnasiasten OS versprühen.

    Lasst Poettering ruhig machen, wenn die kommerziellen Anbieter wie SAP, EMC, Oracle den Daumen senken und gerade SAP und Konsorten nutzen z.B. /tmp ziemlich exzessiv wird es da früher oder später Thematiken geben die Schmerzen verursachen. Auch Großkunden haben da eine gewisse Marktmacht, die schmeissen den Kram dann evtl. raus und ersetzen es durch Windows Krampen. Denen ist das OS wurscht, die Anwendung muss tun. Alles andere ist für die irrelevant.
     
Status des Themas:
Es sind keine weiteren Antworten möglich.