• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Boycott Systemd

Status
Nicht offen für weitere Antworten.

-Nuke-

Well-Known Member
#76
Klar, nicht direkt, aber zumindest indirekt.
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.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#77
Man kann den Kernel sogar dem NVRAM bekannt machen. Dann taucht er unter schönem Namen als Bootoption auf.
 

Azazyel

Well-Known Member
#78
Einfach ein kleines C-Programm schreiben, viel Speicher mit malloc() holen und mit Zufallszahlen überschreiben. Dann sich selbst per Segfault wegschießen. Fertig ist der DOS-Angriff für arme Leute... Und das ist nur die Spitze des Eisbergs.
Quelle bzw. Link zum Bug-Report?

Nur wie seine anderen Projekte wird systemd zumindest vorübergehend durch Red Hats Marktmacht und dem fehlenden Willen der anderen Distributionen in eigene Technologie zu investieren "alternativlos" werden bzw. bleiben.
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. :(

Red Hat ist ja nicht mehr erfolgreich, weil es eine gute Distribution ist. Zumindest in meinem Umfeld tendiert die Anzahl der Red Hat freiwillig einsetzenden Admins inzwischen gegen Null.
Gibt's eine nachvollziehbare Begründung abseits der teilweise sehr alten Softwareversionen, die unter RHEL 6.x mitgeliefert werden?

Es gibt eine ganze Reihe besserer Distributionen, egal welche Schwerpunkte man setzen möchte.
Welche guten Alternativen mit Support-Zeiträumen größer 5 Jahren gibt es, die nicht auf RHEL basieren?
 
#79
@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*
 

Kamikaze

Warrior of Sunlight
Mitarbeiter
#81
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.
 

-Nuke-

Well-Known Member
#82
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.
 
#86
Ganz schauderlich. Ich zitiere mal daraus:
So sollen die Verzeichnisse /var und /etc teilweise völlig verschwinden oder leer bleiben.
und dafür den /etc/passwd-Ersatz nach
/usr/lib/sysusers.d

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!
 

sanbiber

Well-Known Member
#87
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]
 
#89
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 ...
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#90
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.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#92
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
 

-Nuke-

Well-Known Member
#93
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.
 

mark05

Well-Known Member
#94
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
 

sanbiber

Well-Known Member
#97
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 ...
 

sanbiber

Well-Known Member
#99
Das Schlimme an Poettering ist, dass er Kritik an seiner Person und seinen Projekten nicht wahrnehmen kann oder will.
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?
 

solarix

Konsolenpenner
. Aber was soll oder kann man dagegen tun?
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
Nicht offen für weitere Antworten.