Servus!
Benutzt hier jemand Devuan ohne initrd? Das sollte eigentlich weniger
Bastelei kosten als unter Debian?
Meine PCs laufen schon immer ohne initrd unter Debian. Der Trend geht
anscheinend dahin, dass die initrd immer unersetzlicher wird. Jetzt
steht die nächste Neu-Installation an, meine erste AMD64, deshalb dachte
ich, kann ich auch gleich auf Devuan umsteigen. Ist Devuan immer noch
das bessere Debian?
1
The release even has won an endorsement from Bruce Perens,
2
a coder widely credited as the founder of the open source
3
software movement.
4
5
"I was the second Debian project leader. These days, I prefer
6
to run Devuan, a true Debian derivative engineered the way
7
I would probably have decided to make it. It's efficient and
8
trouble-free. Thanks to the Devuan developers for all of
Bauform B. schrieb:> Ist Devuan immer noch> das bessere Debian?
War’s das je? Ich hab’s eher als ein Trotzprodukt irgendwelcher
selbsternannten Admin-Veteranen (die nannten sich wirklich selbst so) in
Erinnerung, die mit Neuerungen nicht recht umgehen konnten. Das Problem
ist, dass viele Projekte mehr und mehr die Möglichkeiten der Neuerungen
nutzen, und damit nicht mehr für Devuan zur Verfügung stehen. Ob das für
dich relevant ist, kannst du nur selbst entscheiden – außer dir weiß ja
keiner was zur Konzeption deiner Systeme.
Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht
hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als
solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so
dass da recht tiefgreifende Basteleien nötig sein werden.
Jack V. schrieb:> Das Problem ist, dass viele Projekte mehr und mehr die Möglichkeiten der> Neuerungen nutzen, und damit nicht mehr für Devuan zur Verfügung stehen.
Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine
Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand
systemd.
Hmmm schrieb:> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand> systemd.
Was gibt es denn außer Windows und Linux noch? Ich meine jetzt: wirklich
relevantes...
Das, was da bleibt, sind sterbende Nischen. Nicht mehr. Einzig in den
USA hat Apple mit seinem weitgehend propräitarisierten BSD noch einen
nennenswerten Marktanteil. Naja, Amis sind halt in ihrer Mehrheit
schlicht strunzdoof. 40% von denen halten ja sogar die Tatsache der
Evolution für einen Fake...
Wird also über kurz oder lang auch noch sterben...
Hmmm schrieb:> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand> systemd.
Stimmt. Ich halte es aber nicht für ein Verbrechen, die Möglichkeiten
eines Systems zu nutzen, ohne sich mit Blick auf andere Systeme
einzuschränken. Ist ja nicht so, dass es auf anderen Systemen nicht
genauso gemacht würde.
Und wer Wert auf die Portabilität seiner Sachen legt, ist nicht
gezwungen, linuxspezifische Funktionalität zu nutzen. Nur eben von allen
anderen zu verlangen, dass sie’s auch so zu machen haben, ist, meiner
Ansicht nach, daneben.
Ist das Gleiche, wie diese ewige Diskussion um Abwärstkompatibilität:
klar ist’s schön, wenn jahrzehntealter Kram noch zum Laufen zu bringen
ist. Aber wenn der Preis dafür ist, dass aktuelle Möglichkeiten nicht
genutzt werden können, oder der Code sich immer mehr aufbläht und
unwartbar wird, dann kann man auch schonmal ’nen Schnitt machen. Die
dann am lautesten maulen, können ja die alte Version forken und
weiterpflegen – dann sehen sie mal, was für Arbeit das ist.
c-hater schrieb:> Was gibt es denn außer Windows und Linux noch? Ich meine jetzt: wirklich> relevantes...
Wenn Du Relevanz aus der "Millionen Fliegen fressen
Scheisse"-Perspektive siehst, nicht viel.
Ansonsten findet man BSDs sowohl bei namhaften Unternehmen wie Netflix
als auch haufenweise in Appliances (IronPort, Juniper, NetApp etc.)
Auch Solaris ist wohl gerade im Enterprise-Umfeld immer noch nicht tot.
Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach
nicht zu wissen. Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts,
die jede Bourne Shell verdaut, nicht erklären.
Hmmm schrieb:> Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach> nicht zu wissen
Das ist gut möglich angesichts der schieren Irrelevanz des Rests...
> Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts,> die jede Bourne Shell verdaut, nicht erklären.
Wenn das dein einziges Problem ist, dann beherrschst du deine
BSD-basierte Umgebung nicht wirklich. Es wäre ein Kinderspiel, das z.B.
auf sh umzulenken...
Du kannst nicht erwarten, dass die weit überwiegende Mehrheit sich
Gedanken um die Sorgen und Nöte einer jetzt schon geringen und
potentiell völlig aussterbenden Minderheit macht.
Wenn es dir Spaß macht, zu dieser Minderheit zu gehören, kein Problem.
Dann löse aber auch die Probleme selber, die sich daraus ergeben, wenn
man anders als (fast) alle anderen sein will...
Keine initrd kann man machen wenn das root Blockdevice und Filesystem
einfach so vom Kernel erkannt und gemounted werden kann. "sda1" z.b.
Sobald das Root Filesystem zuerst konfiguriert werden muss
(Verschlüsselung, LVM, "SCSI Treiber", Kernelmodul laden...) geht afaik
nichts an einer initrd vorbei.
Zu meinen Gentoo Zeiten hab ich mir eine Zeit lang meine initrd selbst
gebaut um zum Spass das Betriebssystem in einem tmpfs laufen zu
lassen... War schön schnell, dann kamen SSD's auf den Markt.
Also was genau ist schlimm an initrd's?
Hmmm schrieb:> Aber dass es eine Welt ausserhalb von Linux gibt, scheinen viele einfach> nicht zu wissen. Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts,> die jede Bourne Shell verdaut, nicht erklären.
Ich spreche da mal für mich: wissen kann ich es schon. Beziehungsweise:
ich weiß es. Warum ich trotzdem keine Rücksicht auf andere Systeme
nehme? Weil ich selbst nur Linux habe, und es daher auf anderen
Systemen weder testen, noch sonst irgendwie Support geben kann. Warum
sollte ich mich da also einschränken, um die mit zu bedienen?
Wenn jemand meinen Kram nimmt, und ihn auf ’nem anderen System zum
Laufen bringt: da freu’ ich mich drüber. Und wenn er an mich herantritt,
und konkrete Änderungen dafür anfragt (nicht: „verlangt“. Das ist
wichtig), setze ich das im Rahmen meiner Möglichkeiten auch gerne um.
Aber pauschal mir unbekannte Systeme berücksichtigen? Wozu soll das gut
sein?
c-hater schrieb:>> Anders kann ich mir Unfug wie "#!/bin/bash" in Scripts, die jede Bourne>> Shell verdaut, nicht erklären.>> Wenn das dein einziges Problem ist, dann beherrschst du deine> BSD-basierte Umgebung nicht wirklich.
Wie kommst Du auf die Idee, dass das für mich mehr als ein Ärgernis
wäre?
c-hater schrieb:> Du kannst nicht erwarten, dass die weit überwiegende Mehrheit sich> Gedanken um die Sorgen und Nöte einer jetzt schon geringen und> potentiell völlig aussterbenden Minderheit macht.
Selbst unter Linux kann und sollte man das Vorhandensein einer Bash
nicht voraussetzen.
Aber warum an Standards halten, wenn man auch planlos rumbasteln kann...
Hmmm schrieb:> Selbst unter Linux kann und sollte man das Vorhandensein einer Bash> nicht voraussetzen.
… das ist aber in ungefähr die Argumentation, wie „du kannst unter
Linux das Vorhandensein eines Python-Interpreters nicht voraussetzen –
schreib deinen Kram also gefälligst in ’ner anderen Sprache“.
Die Lösung kann sein: ich definiere in diesem Beispiel Python als
Abhängigkeit, oder im Fall der Bash, eben diese. Wo ist das Problem?
Jack V. schrieb:> Die Lösung kann sein: ich definiere in diesem Beispiel Python als> Abhängigkeit, oder im Fall der Bash, eben diese. Wo ist das Problem?
Der Vergleich hinkt. In 99% der Fälle wird faktisch gar keine Bash
benötigt, sondern eine POSIX-konforme /bin/sh.
Das ist fast so, als würdest Du bei der Installation Python
voraussetzen, es dann aber gar nicht benutzen.
Hmmm schrieb:> Das ist fast so, als würdest Du bei der Installation Python> voraussetzen, es dann aber gar nicht benutzen.
Okay – ich ging davon aus, dass auch Bash-Features genutzt würden. In
dem von dir gezeichneten Bild wäre die She-Bang-Zeile mit der Bash in
etwa das, was dem Buntu-User sein ›sudo‹ – wird überall vorgeklatscht,
egal, ob sinnvoll, sinnlos, oder gar gefährlich. Das ist in der Tat
doof.
Christobal M. schrieb:> Sobald das Root Filesystem zuerst konfiguriert werden muss> (Verschlüsselung, LVM, "SCSI Treiber", Kernelmodul laden...) geht afaik> nichts an einer initrd vorbei.
Verschlüsselung lasse ich gelten und / auf LVM finde ich unangebracht.
SCSI- und Filesystem-Treiber kann man fest einbauen und die meisten
anderen Module werden nicht zum Booten gebraucht. Also brauche ich für
meine Rechner keine initrd.
> Also was genau ist schlimm an initrd's?
Die bzw. die initramfstools sind ein unnötiges Risiko, dass bei einem
Update etwas schief geht. Und beim nächsten Rechner macht evt. jemand
ein Update, der dann hilflos ist.
Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu
gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es
sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist?
Das sollte ja bei Devuan nicht nötig sein und den Aufwand, einen eigenen
Kernel zu bauen, würde ich schon gerne sparen.
Inzwischen habe ich eine freie Partition gefunden und Devuan (ohne
Desktop) installiert. Soweit merkt man praktisch keinen Unterschied zu
Debian, naja, bis auf den einen, "ifconfig eth0" funktioniert wieder ;)
Bauform B. schrieb:> Die bzw. die initramfstools sind ein unnötiges Risiko, dass bei einem> Update etwas schief geht. Und beim nächsten Rechner macht evt. jemand> ein Update, der dann hilflos ist.
Sorry, aber eigentlich verhält’s sich genau andersrum: während bei mir
in den vergangenen zwanzig Jahren keine Systeme wegen fehlgeschlagener
initrd-/initramfs-Erstellung (initrd wird schon länger nicht mehr
benutzt) unbootbar waren, ist die Gefahr bei ’nem selbstgebauten Kernel
höher, dass „jemand“ (also nicht der, der’s System aufgesetzt hat) ein
Update fährt und anschließend nix mehr geht.
Bauform B. schrieb:> Soweit merkt man praktisch keinen Unterschied zu> Debian, naja, bis auf den einen, "ifconfig eth0" funktioniert wieder
Funktionierte bei mir durchgehend. Waren einmalig wenige Tastendrücke.
A. K. schrieb:> Bauform B. schrieb:>> / auf LVM finde ich unangebracht.>> Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar,> unterbrechungsfrei.
Tja, vielleicht war früher doch manches einfacher? Vieleicht war /usr
auf einer eigenen Partition keine so dumme Idee?
Bauform B. schrieb:>> Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar,>> unterbrechungsfrei.>> Tja, vielleicht war früher doch manches einfacher? Vieleicht war /usr> auf einer eigenen Partition keine so dumme Idee?
Bei /, /opt und /usr ist das nur unnötige Arbeit, reduzierte
Flexibilität und bringt keinen Vorteil. Erst recht, wenn sich der Kram
untenrum auf dem gleichen Medium wieder einfindet, nicht auf getrennten
HDDs.
Routinemässig gibts bei mir heutzutage ein Root-FS mit allem weitgehend
statischem Zeug drin, ggf plus /var für viel Logging und zusätzliche
Filesysteme für die Anwendung, wenn es lohnt. Und das alles im LVM. Bei
Systemen mit grossem Anwendungsbereich landen die gerne in zweiter VG.
Was mehr Platz braucht wird dann eben bei Bedarf vergrössert, das ist
trivial und ohne Betriebsunterbrechung möglich, so lange die VG nicht
voll ist (lvresize + resize2fs/xfs_sonstwas). Die VGs werden dafür
erheblich grösser angelegt als anfangs verwendet, weil angelegter aber
nicht benutzter LVM-Space bei VMs nichts kostet (thin provisioning).
Bereits IBMs AIX liess sich vor 3 Jahrzehnten so ähnlich betreiben, es
hatte aber in alter Tradition noch etliche getrennte Filesysteme im LVM.
Gebootet hat das übrigens grob ähnlich wie Linux heute.
Jack V. schrieb:> War’s das je? Ich hab’s eher als ein Trotzprodukt irgendwelcher> selbsternannten Admin-Veteranen (die nannten sich wirklich selbst so) in> Erinnerung, die mit Neuerungen nicht recht umgehen konnten. Das Problem> ist, dass viele Projekte mehr und mehr die Möglichkeiten der Neuerungen> nutzen, und damit nicht mehr für Devuan zur Verfügung stehen.
Kommt drauf an, was man alles so "Neuerung" nennen will. Habe vor ca.
1/2 Jahr nach mehrjährigem problemlosem Betrieb auf allen meinen
Rechnern mal einen Rechner mit Debian neu aufgesetzt, um die tollen,
heute erzwungenen Web-Neuerungen überhaupt nutzen zu können (müssen).
Ging alles soweit problemlos. Aber ach: Was soll ich sagen? Als dann mal
ein simples ifconfig anstand war ich echt bedient. Vollkommen neue
Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend. Alles in
einen Monolithen gekloppt, ganz in systemd Manier. Durch die Manpage zu
steigen ist eine Kunst. Da braucht man schon das Internet um selbigem
Rechner das Interface zu konfigurieren.
Neenee, wer sowas verzapft ist in meinen Augen nicht wirklich an
produktiven Neuerungen interessiert. Da wende ich mich dankend nach über
20 Jahren Debian ab. Schön war die Zeit, aber nun ist Schluß.
Auch der Kernel wird mit seinen erzwungenen politischen Korrektheiten
und dem ganzen sinnlosen Zinnober sterben. Ganz sicher.
Welches Bild soll man da jetzt von den jungen, nachwachsenden
Entwicklern haben?
Club der toten Pferde schrieb:> Welches Bild soll man da jetzt von den jungen, nachwachsenden> Entwicklern haben?
auch Club der toten Pferde:
- Wird von der seit min. 9 Jahren absehbaren Ablösung durch ein min. 19
Jahre* altes Werkzeug völlig überrumpelt
*(systemd ist übrigens deutlich jünger)
Club der toten Pferde schrieb:> Als dann mal> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue> Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend.
Entschuldige, aber: Hä??
›ifconfig‹ lässt sich bedienen, wie all die Jahrzehnte bislang auch. Was
genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?
Wieso wird hier initramfs mit systemd gleichgesetzt oder zumindest in
Verbindung gebracht. Du kannst dein System auch über PXE booten, es
einen initramfs nachladen und dein spezielles /init ausführen lassen.
Diskless. Funktioniert und ist nichts ungewöhnliches.
Jack V. schrieb:> Was> genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?
"ifconfig" ist nicht mehr als default installiert!
man muss bei einem neu aufgesetztem System sofort ekelhafte Kommandos
wie
>> apt install net-tools
eintippen, und damit seine Tastatur besudeln.
Geheimtipp: Statt dem Krasser-Hipster-Ekelkommando "apt" geht auch heute
noch das gute, althergebrachte
>> apt-get install net-tools
Damit ist die Sache doch nur noch halb so schlimm, oder?
Netplan.YAML schrieb:> "ifconfig" ist nicht mehr als default installiert!
Ja, aber wie du schon schreibst: man kann es problemlos
nachinstallieren, wenn man Probleme hat, sich auf Neues einzulassen. Das
ist auch völlig problemlos: wer nämlich schon Probleme hat, ’ne neue
Syntax zu nutzen, der würde die neuen Funktionen, wie etwa das einfache
Handling mehrerer IPs und Routen pro Interface, wohl auch gar nicht erst
angucken.
›apt‹ ist eher ’n Wrapper, der einige Funktionalität der anderen Sachen
zusammefasst. Auch da ist man nicht drauf angewiesen, sondern es stehen
die hergebrachten Sachen einzeln zur Verfügung. Aber auch da verzichtet
man halt auf Annehmlichkeiten, die’s mit sich bringt, wie etwa das
einfache Installieren lokal vorliegender Pakete mit automatischer
Auflösung der Abhängigkeiten. Wenn man’s vorher mit ›dpkg‹ gemacht hat,
durfte man alles selbst raussuchen, ›gdebi‹ kann’s zwar auch
automatisch, hat aber andere Nachteile.
Club der toten Pferde schrieb:> Kommt drauf an, was man alles so "Neuerung" nennen will. Habe vor ca.> 1/2 Jahr nach mehrjährigem problemlosem Betrieb auf allen meinen
[...]
> Ging alles soweit problemlos. Aber ach: Was soll ich sagen? Als dann mal> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue
Wenn man die Entwicklung mehr als ein Jahrzehnt lang verschläft, dann
wird man natürlich mal überrascht. Aber das sollte man nicht den
Maintainern der Distribution anlasten, sondern eher der eigenen
Faulheit.
ifconfig wurde aus sehr guten Gründen durch iproute und iproute2
abgelöst, auch wenn du diese Funktionalität vielleicht nie gebraucht
hast. Und wenn man sich die Syntax ansieht, dann versteht man auch
schnell, warum bei den vielen Gemeinsamkeiten daraus keine zig getrennte
Tools gebaut wurden.
S. Ramon schrieb:> Wieso wird hier initramfs mit systemd gleichgesetzt oder> zumindest in Verbindung gebracht.
Eigentlich wollte ich genau das vermeiden, weil es immer ausartet, wenn
man dieses Wort benutzt. Ich installiere entweder Debian mit sysvinit
oder eben, vielleicht, demnächst, Devuan. Das ist nicht verhandelbar.
> Du kannst dein System auch über PXE booten, es einen initramfs> nachladen und dein spezielles /init ausführen lassen. Diskless.> Funktioniert und ist nichts ungewöhnliches.
Bei meinen Rechnern mache ich gerne solche Sachen und natürlich würde
ich Devuan ohne initrd betreiben, kein Problem. Aber jetzt muss ich
einen Rechner installieren, bei dem jemand root wird, der sich dafür
nicht interessiert - "es muss nur funktionieren". Also sollte ich auf
meine Spezial-Konfigurationen verzichten. Entscheidend ist, was
zuverlässiger funktioniert.
Aber erzählt doch mal etwas von praktischen Erfahrungen mit Devuan...
Hmmm schrieb:> Wer solche "Neuerungen" zwingend voraussetzt, will offenbar keine> Portabilität, denn ausserhalb der bunten Pinguinwelt benutzt niemand> systemd.
Auch wenn ich als alter SunOS-Entwickler dabei ein bisschen Wehmut
empfinde, komme ich trotzdem nicht um die Erkenntnis herum, daß es im
UNIXoiden Umfeld außerhalb der "Pinguinwelt" mittlerweile gar nicht mehr
so viel gibt.
Tatsächlich ist systemd aber in vielerlei Hinsicht viel besser als sein
Ruf, aber letztens habe ich einen sehr zutreffenden Satz gelesen: "Nerds
have a complicated relationship to change; it's awesome when we are the
ones creating the change, but it's untrustworthy when it comes from
outside".
Außerdem ist es ebenfalls eine Tatsache, daß das alte SysV-Init schon
seit geraumer Zeit... ziemlich in die Jahre gekommen war. Auf modernen
SMP-Systemen nicht parallel booten zu können, war ein Punkt, und wenn
man Abhängigkeiten zwischen verschiedenen Diensten berücksichtigen mußte
-- zum Beispiel: starte den Webserver erst, wenn die Datenbank
hochgefahren und initialisiert wurde -- war mit SysV-Init oft ein fieser
Krampf. Und -- ich kann da natürlich nur für mich sprechen -- ich fand
es ärgerlich und nervig, für die Distributionsfamilien X und Y jeweils
Init-Skripte schreiben, testen, ausliefern und pflegen zu müssen.
Eine Folge der zunehmenden Schwierigkeiten mit SysV-Init war, daß dann
verschiedene Distributoren angefangen haben, wieder jeweils eigene
Süppchen zu kochen. Sun hat, wie so oft in einer Vorreiterrolle, schon
2004 mit der Service Management Facility (SMF) begonnen, sich von
SysV-Init abzuwenden, und auch im Linux-Umfeld kam dann Bewegung in die
Sache -- seien es Exoten wie Void und Artix Linux, die auf runit gesetzt
haben, oder auch Canonical mit seiner Eigenentwicklung Upstart, Apple
mit SystemStarter und später launchd oder Gentoo mit OpenRC. Sogar das
hier so gelobte Devuan benutzt meines Wissens gar kein reines SysV-Init
mehr, sondern OpenRC. Und die BSDs hatten noch nie ein SysV-Init,
nebenbei bemerkt...
Jetzt auf einmal zu behaupten, die bööösen systemd-Leute hätten auf
einmal (und, natürlich, aus unbekannten, aber zweifellos sinistren
Gründen) die ganze schöne Harmonie und Einheitlichkeit im UNIX-Umfeld
kaputtgemacht, ist also ganz offensichtlich entweder inkompetenter
Unsinn oder üble Nachrede, jedenfalls aber falsch. De facto hat systemd
mehr für die Vereinheitlichung zumindest der größten (verbreitetsten)
Linux-Distributionen gebracht als die meisten anderen bekannten
Standardisierungsbemühungen, als Beispiele seien nur FHS und LSB
genannt.
Und wer nun -- aus welchen Gründen auch immer -- nun trotzdem kein
systemd haben will, der kann ja auf etwas anderes ausweichen. Aber immer
diese Seitenhiebe und Falschbehauptungen sind doch nur kindischer Trotz.
systemd funktioniert ziemlich reibungslos (ja, das war anfangs nicht
immer so, aber Kinderkrankheiten gehören bedauerlicherweise nun einmal
dazu), alle großen und vor allem kommerziellen Distributoren haben sich
aus guten Gründen dafür entschieden, und irgendwelche Meckerer in einem
Mikrocontroller-Forum werden sie nicht mehr davon abbringen.
systemd ist die Realität, und es wird die Realität bleiben. Findet Euch
damit ab, geht im Garten ein paar Scheite Holz hacken oder fahrt
meinetwesen nach China und schubst ein paar Säcke Reis um. ;-)
Ich werde die Systemd fanatiker mal ignorieren – immerhin hatten wir da
woanders schon differenzierte Diskussionen spezifisch zu der Thematik –
und mal versuchen, zum Thema zurückzukommen.
Also, nun zu Devuan. Ich verwende es momentan auf all meinen Geräten -
auf meinem Surface Pro 3, auf meinem Server, in meinen zahlreichen
libvirt-lxc Containern (die ich statt VMs verwende), auf meinem RPI3
basierten Backup Server, ja sogar auf meinem Librem 5 Smartphone. Auch
Netzwerkboot per PXE hab ich mir eingerichtet, geht alles einwandfrei.
Ich bin soweit sehr zufrieden damit. Ich verwende es schon seit einigen
Jahren, und hatte noch nie ernsthafte Probleme damit. Mein Server und
meine >10 libvirt-lxc Container darauf updaten täglich automatisch mit
cron-apt, und ich erinnere mich nicht daran, das da je etwas schief
gelaufen wäre.
Zur Installation kann ich nicht viel sagen, ich bootstrappe meine
Systeme immer manuell. Ich denke diese sollte aber problemlos laufen.
Zu initrd/initramfs, ich hatte Zeitweise schon Systeme, die ich ohne
verwende. Es geht, aber ich bevorzuge es, ein initramfs zu haben. Einer
der Hauptgründe ist, dass wenn z.B. das Dateisystem mal beschädigt ist,
und man fsck laufen lassen muss, ist es unpraktisch, wenn fsck auf der
Partition drauf ist, die man fsckn will. Und auf meinem Smartphone hab
ich ein Keyboard für die linux console, das ich erstellt habe, mit rein
gepackt, so dass ich z.B. das Passwort für ein verschlüsseltes root
eingeben kann, oder sonstige boot Probleme beheben könnte, falls mal
welche auftreten. Bei Servern mit verschlüsseltem rootfs packen dort
manche einen ssh Server rein, damit sie das Passwort remote eingeben
können. Also für all solches early-boot zeug ist es schon praktisch.
Probleme damit hatte ich auch noch nie. Falls bei nem kernel update was
schief ginge, kann ich ja einfach den letzten Kernel auswählen. Wäre
doch ein mal was mit allen initramfs kaputt, kann ich z.B. in grub
immernoch einfach die entsprechende Zeile rauslöschen, und ohne booten.
Das dürfte in Debian eigentlich alles genauso sein.
Zum init system in devuan, sysvinit und openrc sind offiziell supportet,
und können glaube ich bei der Installation beim regulären Installer
sogar direkt ausgewählt werden. Nachträgliches ändern ist aber auch
möglich. runit als init soll anscheinend auch machbar sein, ausprobiert
hab ich es aber noch nicht.
Zum Verhältnis zwischen Debian und Devuan. Devuan versucht, einen
Reibungslosen systemd-freien Betrieb der selben Software, die auch in
Debian existiert, zu gewährleisten. Dabei wird versucht, so nahe wie
irgendwie möglich an Debian zu bleiben. Ein paar Packete werden
exkludiert (https://pkgmaster.devuan.org/bannedpackages.txt). Ein paar
Devuan spezifische als für den reibungslosen Betrieb zur Verfügung
gestellt. Man läuft also kaum Gefahr, sich versehentlich per dependency
Systemd einzufangen, oder mit einem kaputten System aufzuwachen.
Die restlichen, guten Packete werden direkt von Debian geholt. Hin und
her wechseln sollte eigentlich problemlos gehen, mischen sollte man die
Repos aber nicht. Auch zukünftig wird das voraussichtlich so bleiben.
Zudem versucht Devuan, soweit möglich, mit Debian zusammenzuarbeiten.
Das beinhaltet, soweit möglich, hilfe bei der Maintance von in sysvinit
upstream, upstreamen von änderungen soweit möglich, und die Intergration
von Packeten wie z.B. elogind als ersatz für libsystemd & logind.
Es ist noch zu beachten, dass devuan nur sehr wenige Entwickler &
Maintainer hat, vielleicht ein Dutzend oder so. Das schränkt deren
Möglichkeiten etwas ein. Um die Belastung der Entwickler zu reduzieren,
sollten z.B. Bugs für Packete, die z.B. Direkt von Debian und nicht von
Devuan kommen, in der regel zuerst bei Debain gemeldet werden, da dort
bei verwendung von sysvinit die selben Probleme zu erwarten sind, und
erst, wenn dort nichts gemacht wird, wird diskutiert, ob es geforkt
werden muss.
In vielen Aspekten ist Devuan eher ein Pflaster als eine Lösung für die
durch systemd verursachten Probleme. elogind z.B. ist glaub ich
eigentlich ein Fork von Systemd, aber mit dem eigentlichen systemd teil
usw. entfernt. Um alle Packete die Systemd voraussetzen zu Forken sind
schlicht nicht genug Ressourcen vorhanden, und viele APIs von Systemd
lassen sich Architekturbedingt nicht einzeln zur run-time ersetzen,
deshalb müssen leider solche Kompromisse gemacht werden. Aber es
verschafft immerhin etwas zeit, um mit neuen Strategien den totalen
systemd-lockin abzuwenden, aufkommen zu können.
In sehr seltenen fällen gibt es bei neueren Paketen manchmal welche, die
noch kein init script haben. In bilden sich Debian Maintainer auch mal
ein, sie müssten aus unerfindlichen gründen das Initscript entfernen.
Wie gegen diese Debian seitige Sabotage am besten vorgegangen wird, ist
momentan noch in diskussion. In der regel ist es aber einfach, mit z.B.
init-d-script
(https://manpages.debian.org/stretch/sysvinit-utils/init-d-script.5.en.html)
ein kleines simples initscript zu erstellen.
Bei externen Repos / Packeten ist es etwas Wahrscheinlicher, dass mal
eines nur Systemd units anbietet. Es kann auch sein, pre- / post-
install Scripte bei derartigen Paketen stark systemd spezifisch sind,
auch wenn die Software ansonsten auf Devuan funktionieren würde. Es
kommt zwar recht selten vor, nodejs, tor, etc. gehen problemlos, aber
externe Repos sind halt bei jeder Distro immer eine Glückssache, und
sollten sowieso vermieden werden.
Bei Firmen und Projekten gibt es gibt wohl auch vereinzelte (z.B.
devuanhosting.com), die Devuan einsetzen. Die meisten Firmen
interessieren sich aber nur für die Grossen und bekannten Distros. Die
kleinen Distributionen werden von Firmen und Projekten meistens in
Situationen eingesetzt, wo die grossen Distributionen nicht sinnvoll,
oder Systemd problematisch oder gar nicht verwendbar, sind.
Bei Problemen gibt es eine aktive Community. IRC und die Mailingliste
kann ich sehr empfehlen. Es gibt auch ein unabhängiges Forum
dev1galaxy.org, das relativ aktiv zu sein scheint.
? DPA ? schrieb:
den besten Beitrag den ich je in diesem Forum lesen durfte
> Also, nun zu Devuan. Ich verwende es momentan auf all meinen Geräten -> auf meinem Surface Pro 3, auf meinem Server, in meinen zahlreichen> libvirt-lxc Containern (die ich statt VMs verwende), auf meinem RPI3> basierten Backup Server, ja sogar auf meinem Librem 5 Smartphone. Auch> Netzwerkboot per PXE hab ich mir eingerichtet, geht alles einwandfrei.
o.k., das geht als praktische Erfahrung durch
> Zur Installation kann ich nicht viel sagen, ich bootstrappe meine> Systeme immer manuell. Ich denke diese sollte aber problemlos laufen.
Eine Installation mit dem netinstall.iso und eine per netboot liefen mit
priority=low problemlos. Praktisch genau wie Debian, auch die
grub-Installation hat erst beim 2. Versuch geklappt ;)
> Zu initrd/initramfs, ich hatte Zeitweise schon Systeme, die ich ohne> verwende. Es geht, aber ich bevorzuge es, ein initramfs zu haben.
Es ging mal drum, beim booten jede Millisekunde zu sparen, da war die
initrd natürlich das erste Opfer. Und bis heute war es reine Gewohnheit.
> Also für all solches early-boot zeug ist es schon praktisch.
Einverstanden.
> Zum init system in devuan, sysvinit und openrc sind offiziell supportet,> und können glaube ich bei der Installation beim regulären Installer> sogar direkt ausgewählt werden.
Das geht, sysvinit ist (noch?) Default.
> Nachträgliches ändern ist aber auch möglich.
Sogar mit aptitude ;)
> Man läuft also kaum Gefahr, sich versehentlich per dependency> Systemd einzufangen.
Das ist für mich das entscheidende Argument, weil man auch Debian
absolut problemlos mit sysvinit betreiben kann -- solange man bei der
nachträglichen Installation von einzelnen Paketen genau aufpasst.
Deshalb fällt mir die Entscheidung Devuan/Debian auch nicht so leicht.
> elogind z.B. ist glaub ich eigentlich ein Fork von Systemd, aber> mit dem eigentlichen systemd teil usw. entfernt. Um alle Packete> die Systemd voraussetzen zu Forken sind schlicht nicht genug> Ressourcen vorhanden
Das ist ja auch nicht so wichtig, es gibt doch fast immer Alternativen,
bis jetzt hab' ich noch nichts vermisst, auch policykit nicht. Deshalb
werde ich vermutlich auch elogind nicht brauchen. Die beiden werden
scheinbar nur für wenige, ziemlich spezielle Funktionen gebraucht.
> Bei externen Repos / Packeten ist es etwas Wahrscheinlicher, dass mal> eines nur Systemd units anbietet. Es kann auch sein, pre- / post-> install Scripte bei derartigen Paketen stark systemd spezifisch sind
Egal, traue keinem Script, dass du nicht selber gefälscht hast ;)
> Bei Problemen gibt es eine aktive Community. IRC und die Mailingliste> kann ich sehr empfehlen. Es gibt auch ein unabhängiges Forum> dev1galaxy.org, das relativ aktiv zu sein scheint.
Danke!
A. K. schrieb:> Bei /, /opt und /usr ist das nur unnötige Arbeit, reduzierte> Flexibilität und bringt keinen Vorteil. Erst recht, wenn sich der Kram> untenrum auf dem gleichen Medium wieder einfindet, nicht auf getrennten> HDDs.
So ist es. Man hat dann eine “volle” Platte mit /n/-1 halbleeren
Partitionen und einer bei der es knapp wird. Dann beginnt das große
Verschieben und Verändern.
Vor längerer Zeit bin ich daher auf Desktop und Laptop dazu übergegangen
eine einzige BTRFS Partition (plus EFI) und ggf. mehrere Subvolumes (@,
@home) einzurichten. Dazu kommen noch etliche weitere Subvolumes für
tägliche, wöchentliche und monatliche Snapshots (timeshift). Partitionen
haben sich spätestens mit GPT irgendwie überlebt.
Club der toten Pferde schrieb:> Aber ach: Was soll ich sagen? Als dann mal> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue> Befehlsstruktur mit allem drum und dran. Ekelhaft. Abstoßend. Alles in> einen Monolithen gekloppt, ganz in systemd Manier. Durch die Manpage zu> steigen ist eine Kunst. Da braucht man schon das Internet um selbigem> Rechner das Interface zu konfigurieren.
Das Problem sitzt hier eher vor dem Bildschirm.
Zum konfigurieren des Netzwerks verwendet man das nmcli Tool, also das
Network Manager Command Line Interface. Damit ist das auch extrem
einfach.
Sogar vlan lassen sich damit kinderleicht konfigurieren und aufbauen.
Der ip Befehl, der ipconfig ersetzt, konfiguriert den Kernel direkt und
daher ist das auch etwas komplexer und weniger abstrahiert.
Wenn man kein Masochist ist, lässt man das bleiben und nutzt den
bequemeren nmcli oder gleich eine GUI für den NM.
Der ip Befehlt bietet sich für den Nutzer allerdings an, um lediglich
die IP Adressen und Mac Adressen anzuzeigen (mit "ip a"). ipconfig
dürften die meisten früher auch nicht anders genutzt haben.
Netplan.YAML schrieb:> Jack V. schrieb:>> Was>> genau hat dich daran nun abgestoßen und das Ekelgefühl erzeugt?>> "ifconfig" ist nicht mehr als default installiert!>> man muss bei einem neu aufgesetztem System sofort ekelhafte Kommandos> wie>>> apt install net-tools> eintippen, und damit seine Tastatur besudeln.
Nein, muss man nicht.
Man nimmt dafür einfach den nmcli und dieses Tool ist bei jedem modernen
Debian ein vorinstalliertes Standardtool.
Bauform B. schrieb:> Bei meinen Rechnern mache ich gerne solche Sachen und natürlich würde> ich Devuan ohne initrd betreiben, kein Problem. Aber jetzt muss ich> einen Rechner installieren, bei dem jemand root wird, der sich dafür> nicht interessiert - "es muss nur funktionieren". Also sollte ich auf> meine Spezial-Konfigurationen verzichten. Entscheidend ist, was> zuverlässiger funktioniert.
Dann nimm Debian wie es vanilla unverändert daherkommt.
Das hat von den Debiansystemen die breiteste Nutzerbasis und er kriegt
dafür auch am ehesten Support.
Devuan würde ich dafür ganz gewiss nicht verwenden. Devuan will kein
systemd und will somit am ewig Gestrigen festhalten, das kann allerdings
nur solange funktionieren, solange es dafür auch genug Leute gibt, die
das pflegen.
Tja und die alten Hasen sterben aus und die jungen lernen Debian mit
systemd kennen. Also ist klar wo das am Ende hinführt.
Solange er keine triftigen Gründe gegen systemd hat, ist Debian so wie
es offiziell geliefert wird, die sinnvollste Variante und wenn er
ohnehin Anfänger ist, dann wird er auch sowieso keine triftigen Gründe
gegen systemd haben und diese argumentativ verteidigen können.
Und könnte er das, dann bräuchte er nicht deine Hilfe.
Nano schrieb:> dieses Tool ist bei jedem modernen> Debian ein vorinstalliertes Standardtool.
Nein, ist es nicht. Und wenn’s das irgendwann mal sein sollte, lösche
ich die restlichen Debiansysteme, und mache mir Devuan oder so drauf.
Nano schrieb:> Bauform B. schrieb:>> Aber jetzt muss ich einen Rechner installieren, bei dem jemand>> root wird, der sich dafür nicht interessiert - "es muss nur>> funktionieren".>> Dann nimm Debian wie es vanilla unverändert daherkommt.
Recht hast du, vernünftig wäre das. Aber das kann ich nicht bzw. das
würde viel zu lange dauern.
> Devuan will kein systemd und will somit am ewig Gestrigen festhalten,> das kann allerdings nur solange funktionieren, solange es dafür auch> genug Leute gibt, die das pflegen.> Tja und die alten Hasen sterben aus und die jungen lernen Debian mit> systemd kennen. Also ist klar wo das am Ende hinführt.
Für meine Alternative, Debian mit sysvinit, gilt ja das gleiche. Die
Frage ist, was wohl länger unterstützt wird. Im Prinzip ist mir das
sogar egal, ich hatte deshalb schon ein Debian mit meinem eigenen
init-"System" laufen. Aber momentan sehe ich schwarz.
Die dritte Alternative: Windows, kombiniert mit einem uC für den Teil,
der mit Windows nicht so einfach geht. Die Leiterplatten sind bestellt
und Windows kann ja jeder...
? DPA ? schrieb:> Ich werde die Systemd fanatiker mal ignorieren
Wer nicht Deiner Meinung ist, ist also ein Fanatiker. Wenn jemand anders
so etwas schriebe, würde ich lachen. Aber bei Dir nicht.
Solche "Argumentationen" kenne ich nur von Fanatikern, die es sich
dadurch einfach machen, andere Meinungen einfach zu ignorieren, statt
sich damit auseinandersetzen. Denn "Fanatiker aller Couleur kennen keine
Ambivalenzen, keinen Kompromiss und keinen Dialog. Sie würden dies als
Verrat an ihrer heiligen Sache verurteilen." (Ernst-Dieter Lantermann)
Es ist und bleibt aber eine Tatsache, daß ausnahmslos alle großen
Distributoren trotz aller -- mal mehr und mal weniger -- berechtigten
Kritikpunkte zu systemd gewechselt sind. Diese Entscheidungen waren
meistens Mehrheitsentscheidungen von Menschen, die zum Teil deutlich
mehr Erfahrung haben und von denen viele sehr viel mehr Maschinen
betreiben als wir beide zusammen -- oft auch für andere wie ihren
Arbeitgeber oder gar für diese widerspenstigen Besserwisser, genannt
Kunden.
Ich für meinen Teil kann nur sagen, daß ich schon mehr als genug Arbeit
habe und aus diesem Grunde alles begrüße, was mir etwas davon abnimmt
oder sie erleichtert. Nach einigen Jahren Erfahrung damit kann ich
sagen: das tut systemd, auch wenn ich -- wie Du weißt -- auch selbst
einige Kritikpunkte daran habe. Aber ich habe -- und wie mir scheint, im
Gegensatz zu Dir -- keinerlei emotionale Bindung an ein Init-System, und
im Laufe der letzten dreißig Jahre auch schon mit verschiedenen davon
gearbeitet. Es gab dabei allerdings keines, an dem ich keine
Kritikpunkte gefunden hätte, und ich würde niemals auf die Idee kommen,
mein Betriebssystem oder dessen Distribution von der Frage abhängig zu
machen, welches Init-System darin benutzt wird.
Und hey, wenn morgen ein neues Init-System kommt, das genausogut
funktioniert, sich genauso weit verbreitet und mir noch mehr Arbeit
abnimmt als systemd: dann werde ich das nutzen und mich darüber freuen,
interessantere Dinge tun zu können. Solch eine Einstellung ist nicht
fanatisch, sondern einfach nur pragmatisch.
Sei mir bitte nicht böse, lieber Daniel, Du weißt, ich mag Dich und
halte Dich für einen klugen, talentierten, kompetenten und netten
Menschen. Darum mache ich mir langsam ernsthafte Sorgen um Dich, weil Du
Dich nach meiner Wahrnehmung immer mehr in eine Wagenburgmentalität
zurückzuziehen scheinst. Du opponierst momentan gegen alle aktuellen
Strömungen in der Linux- und IT-Welt, egal ob es Python, Docker oder
systemd ist. Deswegen mache ich mir ernsthaft Sorgen um Dich, sowohl
menschlich als auch fachlich: menschlich, weil Dir früher niemals so
eine Entgleisung wie dieser dumme Fanatiker-Spruch herausgerutscht wäre,
und fachlich, weil Du Dich selbst von der Weiterentwicklung abhängst,
Deine Energie auf Schlachten vergeudest, die längst geschlagen sind und
die Du niemals gewinnen kannst, und weil ich das, was Du grade machst,
als sinn-, zweck- und nutzlose Verschwendung Deines großen Talents sehe.
Ich bin niemand, der jemandem wegen einiger launischer Beiträge in einem
Forum plötzlich seine Hochachtung oder seine Sympathien entzieht,
schließlich haben wir alle mal bessere, mal schlechtere Tage, und auch
immer mal wieder unsere eigenen psychotischen Zustände, das ist völlig
normal und menschlich. Aber was ich von Dir in letzter Zeit lese, macht
mir Angst. Natürlich, nur tote Fische schwimmen immer mit dem Strom.
Aber wer immer gegen jeden Strom kämpft, endet irgendwann wie der Lachs
nach dem Ablaichen: erst läuft er puterrot an, und dann stirbt er.
Nano schrieb:> Club der toten Pferde schrieb:>> Als dann mal>> ein simples ifconfig anstand war ich echt bedient. Vollkommen neue>> Befehlsstruktur mit allem drum und dran.>> Das Problem sitzt hier eher vor dem Bildschirm.
Unbedingt!
> Zum konfigurieren des Netzwerks verwendet man das nmcli Tool
Oder halt ip(8).
> Der ip Befehl, der ipconfig ersetzt, konfiguriert den Kernel direkt und> daher ist das auch etwas komplexer und weniger abstrahiert.
Der IP-Befehl hat zudem und vor Allem den großen Vorteil, daß sich seine
Ausgabe(n) deutlich einfacher maschinell parsen und weiterverarbeiten
lassen -- und daß diese neuen Befehle neue Funktionen des
Betriebssystemkernels zugänglich machen, die es früher noch nicht
gegeben hat.
Leuten die nur ihren Desktop und vielleicht einige kleine kleine Server
manuell zu betreuen haben, kann das natürlich gleichgültig sein. Aber
wer ernsthaftes (und in der Regel automatisiertes) Computing in
Netzwerken jenseits dieser "Größe" machen will oder muß, für den sind
die neuen Funktionen und die Werkeuge, die die neuen Funktionen
zugänglich machen, ein Gewinn.
Bauform B. schrieb:> Nano schrieb:>> Bauform B. schrieb:>>> Aber jetzt muss ich einen Rechner installieren, bei dem jemand>>> root wird, der sich dafür nicht interessiert - "es muss nur>>> funktionieren".>>>> Dann nimm Debian wie es vanilla unverändert daherkommt.>> Recht hast du, vernünftig wäre das. Aber das kann ich nicht bzw. das> würde viel zu lange dauern.
Entschuldige, aber das ist ja Unsinn. Du bootest vom
Installationsmedium, dann setzt Du ein Huhn vor die Tastatur, und legst
in periodischen Abständen ein Weizenkorn auf die Return-Taste. Bisschen
warten, fertig. Danach nochmal tasksel(8) und eventuell einige Male
apt(8) oder, für Traditionalisten, apt-get(8) aufrufen, und schon hast
Du ein System auf der Platte, das zu allen verfügbaren, seriösen
Dokumentationen und zu allen Best Practices kompatibel ist, ohne nach
jeder Installation größere Nacharbeit leisten zu müssen. Ach, es könnte
alles so einfach sein... ;-)
Sheeva P. schrieb:> Du bootest vom Installationsmedium, dann setzt Du ein Huhn vor> die Tastatur (...) und schon hast Du ein System auf der Platte
Die klassische Debian-Installation. Kenne ich. Funktioniert nach einem
"apt install sysvinit-core" einwandfrei. Mit Devuan spart man diesen
Schritt. Das sind die beiden Möglichkeiten.
Meine Frage war, welche die bessere ist. Die Antwort ist offenbar
"keine", mein Plan ist nicht realisierbar. Ein System, das "zu allen
Best Practices kompatibel ist", kommt wegen unkalkulierbarem Risiko
nicht in Frage.
Dankeschön.
Bauform B. schrieb:> Sheeva P. schrieb:>> Du bootest vom Installationsmedium, dann setzt Du ein Huhn vor>> die Tastatur (...) und schon hast Du ein System auf der Platte>> Die klassische Debian-Installation. Kenne ich. Funktioniert nach einem> "apt install sysvinit-core" einwandfrei.
Nein. Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige
Komponenten nun einmal von systemd abhängen sollen.
> Mit Devuan spart man diesen> Schritt. Das sind die beiden Möglichkeiten.>> Meine Frage war, welche die bessere ist. Die Antwort ist offenbar> "keine", mein Plan ist nicht realisierbar. Ein System, das "zu allen> Best Practices kompatibel ist", kommt wegen unkalkulierbarem Risiko> nicht in Frage.
"Unkalkulierbares Risiko"... So ein Unsinn. Du bastelst manuell an
Deinem System herum, und kreierst Deine eigene Abart davon, ohne Initrd
und Systemd und... hälst Deine Ergebnisse für stabiler und
kalkulierbarer als Software, die auf Millionen von Rechnern installiert
und getestet wird?
Na klar. Und die Erde ist eine Scheibe.
Sheeva P. schrieb:> Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige> Komponenten nun einmal von systemd abhängen sollen.
Diese Komponenten lassen sich nicht installieren, also machen sie auch
keine Probleme. Genau hier kommt Devuan ins Spiel, da werden diese
garnicht angeboten, bei Debian muss man aufpassen. Man kann nicht alles
haben, vor allem nicht alles gleichzeitig. Manche Windows-Programme
lassen sich auch nicht installieren, na und?
> "Unkalkulierbares Risiko"... So ein Unsinn.
Kein Unsinn, praktische Erfahrung. Man könnte es anders formulieren,
vielleicht: "ich kann den Arbeitsaufwand, bis es funktioniert, nicht
abschätzen". Zum Beispiel haben die meisten PCs 2 oder 3
Netzwerk-Interfaces. Ich brauche aber genau 1, aber mit mehreren
Adressen. Zum Beispiel habe ich mich an eine eigene Keymap gewöhnt...
Von DNS und NTP liest man auch Schauergeschichten. Und das sind nur
Beispiele, die mir jetzt schon einfallen. Spannender sind ja die
Probleme, von denen ich jetzt noch nichts ahne.
> Du bastelst manuell an Deinem System herum
Naja, das wollte ich ja bei der nächsten Installation vermeiden, genau
darum geht's hier eigentlich.
> hälst Deine Ergebnisse für stabiler und kalkulierbarer als Software,> die auf Millionen von Rechnern installiert und getestet wird?
langzeitstabiler vielleicht nicht, kalkulierbarer auf jeden Fall. Schon
alleine, weil weniger Features im Spiel sind.
Bauform B. schrieb:> Zum Beispiel haben die meisten PCs 2 oder 3> Netzwerk-Interfaces. Ich brauche aber genau 1, aber mit mehreren> Adressen. Zum Beispiel habe ich mich an eine eigene Keymap gewöhnt...> Von DNS und NTP liest man auch Schauergeschichten.
Und inwiefern sind das nun Argumente für oder gegen ein initramfs?
Netzwerkinterfaces habe ich genau so konfiguriert, eigene Keymap (Neo)
ist gar schon beim Eintippen der Passphrase der verschlüsselten
Systempartition aktiv und von da aus durchgängig, und weder mit DNS,
noch mit NTP habe ich irgendwelche Probleme. Und das auf modernen
Systemen mit initramfs und systemd.
Jack V. schrieb:> Und inwiefern sind das nun Argumente für oder gegen ein initramfs?
Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur
ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich
Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass
etwas wie initramfs zwingend nötig sein soll, genau wie manch andere
Neuerungen.
> weder mit DNS, noch mit NTP habe ich irgendwelche Probleme.
Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben,
hilft mir das garnichts. Mehrere Leute hatten Probleme. Es waren
genug, dass es in der Zeitung stand und mir deshalb aufgefallen ist.
Bauform B. schrieb:> Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur> ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich> Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass> etwas wie initramfs zwingend nötig sein soll, genau wie manch andere> Neuerungen.
Wenn du mit den Einschränkungen leben kannst, spricht zumindest nix
gegen Devuan.
Ein initramfs hast du trotzdem, wenn du nicht verhältnismäßig tief ins
System eingreifst (in Form von selbstgebautem Kernel, um die zum Booten
benötigten Sachen drin zu haben).
Der Trend geht zum initramfs (bzw.: ist gegangen zu, vor vielen, vielen
Jahren schon – Ausnahme ist der Embedded-Bereich), weil das nunmal
einfach praktisch ist, und zudem die Folgen von Fehlern abfangen kann.
Außerdem sind einige Sachen gar nicht ohne das möglich, siehe
verschlüsselte Systempartition und Ähnliche.
Bauform B. schrieb:> Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben,> hilft mir das garnichts. Mehrere Leute hatten Probleme.
99,9% der Leute verdrehen sich beim Aufstehen aus dem Bett heraus nicht
den Fuß. Hilft dir wahrscheinlich gar nichts, weil es mehreren Leuten
passiert ist. Du solltest liegenbleiben. [scnr]
Sheeva P. schrieb:> ? DPA ? schrieb:>> Ich werde die Systemd fanatiker mal ignorieren>> Wer nicht Deiner Meinung ist, ist also ein Fanatiker. Wenn jemand anders> so etwas schriebe, würde ich lachen. Aber bei Dir nicht.>> Solche "Argumentationen" kenne ich nur von Fanatikern, die es sich> dadurch einfach machen, andere Meinungen einfach zu ignorieren, statt> sich damit auseinandersetzen.
Klar, das Wort zu verwenden war etwas krass. Duden Definiert einen
Fanatiker als:
> jemand, der von bestimmten Ideen, einer bestimmten Weltanschauung o. Ä. so> überzeugt ist, dass er sich leidenschaftlich, mit blindem Eifer [und> rücksichtslos] dafür einsetzt
Also warum habe ich die Systemd Diskussion diesmal ignoriert, und warum
hab ich dieses Wort gewählt?
Nun, der TO schien die Systemd Diskussion vermeiden zu wollen. Soweit
ich das sehe wollte er nur wissen, ob Devuan sorgenfrei und einfach zu
verwenden ist, oder ein Identisches Setup mit Debian weniger
problematisch ist.
Aber was machen die anderen hier? Ihr seht, jemand schreibt Devuan -> oh
nein, das war das ohne Systemd, schnell Systemd empfehlen und sysvinit
schlecht reden! Nun, wie würdet ihr das bezeichnen?
Aber warum habe ich die Diskussion ignoriert, und keine Gegenargumente
gebracht?
Kurzgesagt, weil es sinnlos gewesen wäre. Fürs erste hab ich das im
Forum schon mal durchgekaut. Zum anderen macht es auch sonst keinen
Unterschied. Es würde eure Position nicht verändern, es würde meine
nicht verändern, es würde wohl auch dem TO nicht weiterhelfen. Ausserdem
habe ich schlicht die Zeit und Energie nicht mehr, mich auf solche
Diskussionen einzulassen.
Also warum sollte ich die Diskussion anfangen?
Sheeva P. schrieb:> Du opponierst momentan gegen alle aktuellen> Strömungen in der Linux- und IT-Welt, egal ob es Python, Docker oder> systemd ist.
Gegen Python und Docker habe ich eigentlich nichts. Es mögen nicht meine
Favoriten sein, aber das heisst nicht, dass ich diese schlecht finde
oder nicht verwenden würde, wenn es sinnvoll ist. Ich habe durchaus
Projekte, in denen ich diese verwende. So würde ich z.B. meinen eigenen
ACME2 client (https://github.com/Daniel-Abrecht/DPA-ACME2) definitiv
nicht in c oder bash schreiben wollen.
Auch mit Systemd kann ich gut umgehen. Auf der Arbeit betreue ich solche
Systeme auch. Aber Privat werde ich es nicht nutzen, das ist etwas
anderes, als ein simples nicht gerne haben. Natürlich beobachte ich
trotzdem genau, welche Neuerungen es bei Systemd gibt, denn diese
betreffen jene, die systemd vermeiden wollen, viel mehr, als jene, die
es verwenden.
Aber wisst ihr, es gibt einige simple Prinzipien und Ideale, an die ich
mich so gut es geht halte:
1) Ich Trinke und Rauche nicht
2) Ich versuche jegliche lock-in Möglichkeit zu vermeiden, wenn dies
möglich ist und Ich betrachte alles zuerst aus der Perspektive "wer
kontrolliert was, und was für Konsequenzen kann das haben"
3) Ich bin für möglichst vielfältige & möglichst uneingeschränkte
persönliche Freiheiten, sowie für die Optimierung des Wohlstandes aller
natürlicher Personen (wobei Kapitalismus eine brauchbare Methode dafür
ist). Das heist aber auch, das ich dagegen bin, diese durch Firmen und
Technologien automatisiert einschränken zu lassen.
Klar, Ideale zu haben, das bringt auch Opfer mit sich. Ich habe keine
Ahnung, wie Wein oder Bier schmeckt. Ich habe meinen Google Account
geschlossen, und nutze keine Google Services mehr. Ich nutze kein
Systemd. Ich bin dabei, mein Android Smartphone durch ein reines Linux
Smartphone zu ersetzen. Und Google, Facebook, etc. haben keine Ahnung,
was meine Interessen sind, wie ich aussehe, ja nicht einmal welche
Sprachen ich Spreche.
Klar, die Dinge wären Komfortabel. Aber wisst ihr, darauf zu verzichten,
das ist es mir wert. Ich kenne die Alternativen, ich weiss wie alles
unter der Haube funktioniert, ich kenne den Preis, den man für die
Verwendung diversen Sachen da draussen zahlt, und ich weiss, welche
Zukunft ich anstrebe!
Es wurde ja schon einiges zum Thema geschrieben, vielleicht kann ich als
Devuan Nutzer auch noch was dazu beitragen.
Ich nutze seit Jahren Devuan auf all meinen Systemen hier: NAS,
Workstation, Wohnzimmer PC, Notebook. Und ich darf mich auch gleich als
einer der ewig gestrigen outen, ich bin nämlich einer der wenigen Devuan
Maintainer....
Nun, der Grund für Devuan ist auch bei mir - wie sollte es anders sein -
systemd, bzw. das man Debian nur noch anständig mit systemd verwenden
kann. Ja, auch auf Debian kann man immer noch ein SysV benutzen,
allerdings gibt es viele Stolpersteine, z.B. das o.g. Gnome.
Nun ist es nicht so, dass ich systemd grundsätzlich schlecht finde.
Gerade am Anfang als er noch frisch war, (damals war ich noch auf
ArchLinux) war ich davon geradezu begeistert. Der Bootvorgang war eine
Erfrischung. Ab und an mal gab es irgendwelche Dependency-Loops, aber
gut, war ja alles noch neu. Mit der Zeit habe ich jedoch einige
Erfahrungen gemacht, später auch mit Debian/systemd, die mich haben
umdenken lassen:
Nach Aktualisierungen von systemd ist es regelmäßig dazu gekommen, das
ich das system per "systemctl reboot/poweroff" oder auch per
Logout-Dialog im Grafikmodus nicht mehr einfach so neu starten oder
herunterfahren konnte. (Irgendwas mit Filedescriptor, erinnere mich
nicht mehr) Das einzige was noch ging war es, dass Herunterfahren per
Powerknopf auszulösen. Nach dem nächsten Start ging dann wieder alles.
Weiter ging es dann, dass zwei mal nach Updates das System nicht mehr
gebootet hat (allerdings beim ArchLinux) weil irgendeine Lib vom Systemd
nicht sauber installiert wurde und sich das Programm mit einem
Symbolfehler direkt beendet hat.
Den letzten, und der für mich schwerwiegenste Punkt, war jedoch das man
mit so ziemlich jedem größeren systemd Update im Hintergrund eine
Veränderung ins System bekommen hat bei der man nicht mal gefragt wurde
ob man das will. Z.b hab ich einmal verwundert festgestellt, das mein
/tmp plötzlich ein tmpfs war und nicht wie vorher die normale Platte.
War ganz toll, weil war halt ein paar GByte kleiner als vorher. Dann hat
hat sich systemd auf einmal als DNS Resolver in system gesetzt usw.
Damit sind wir auch bei meinem größten Kritikpunkt, das durch systemd
über die Hintertür Änderungen gemacht werden und Festlegungen getroffen
werden, die ich persönlich nicht möchte und das aktiv meine Wahlfreiheit
eingeschränkt wird. Weil es eben nur den in systemd vorgesehenen Weg
gibt. Merged /bin /sbin ist eine weitere solche Sache, von dem Unsinn
mit den Home-Verzeichnissen möchte ich gar nicht erst sprechen: Nein ich
möchte nicht das jeder dahergelaufene Hanswurst seinen USB-Stick an
meinen Rechner steckt und sich dann anmelden kann.
Problematisch finde ich auch die immer größer werdende Abhängigkeit
verschiedener grundlegender Tools von systemd. So sind inzwischen sogar
apt und lvm gegen die libsystemd gelinkt. Dadurch wird das Gesamtsystem
einfach viel fragiler. Nehmen wir z.B. an, dass aus irgendeinem Grund
ein Update schief geht, die libsystemd nicht richtig installiert wurde
aber das System noch nicht neu gestartet wurde. Dann kann ich trotzdem
kein apt mehr starten, weil die lib weg ist, die Möglichkeiten das
Problem zu beheben sind unnötig eingeschränkt. Natürlich gibt es auch
andere Libs, wie z.B. die libc von der so ziemlich alles abhängt.
Allerdings ändert sich die libc bei weitem nicht so regelmäßig wie
systemd. Ich denke man sollte mögliche Fehlerquellen soweit wie möglich
minimieren, gerade bei den wirklich wichtigen Programmen.
Mein generelles Gefühl zu systemd ist, (als jemand der systemd in der
aktuellen Form ablehnt, also möglicherweise mit Vorurteilen) dass eben
gerade von systemd heraus eine Haltung propagiert wird, dass es eben nur
einen richtigen Weg gibt, und das ist der den systemd geht. Das ist aber
genau nicht das für was Linux steht. Da kann ich auch gleich Windows
einsetzten, ob ich mich nun von Microsoft oder RedHat bevormunden lasse
spielt doch keine Rolle.
Für den Fall das man sich bei systemd dazu entscheidet das Teil zu
entbündeln, zu modularisieren, so dass man die reine "Dienstverwaltung"
ohne riesigen Aufwand wieder unabhängig vom Rest einsetzen kann (so wie
am Anfang) dann wäre ich sofort wieder dabei.
Ich versuche dann nochmal auf ein paar der Beiträge oben im Detail
einzugehen:
Jack V. schrieb:> Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht> hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als> solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so> dass da recht tiefgreifende Basteleien nötig sein werden.
Unsinn. Das mag bei systemd so sein, bei SysV mit Sicherheit nicht. Das
einzige was es dafür braucht, ist das alle zur Bootzeit benötigen
Treiber in den Kernel hineincompiliert werden. Man muss sich dann eben
einschränken, im allgemeinen kein lvm oder md für /. Wobei ich mir da
gar da nicht mal so sicher bin, man kann dem Kernel über Komandozeile
und Device-Tree so allerlei beibringen.
Inzwischen ist Btrfs eine ganz gute Alternative zu lvm. Da kann man auch
zu Laufzeit neue Physical devices hinzufügen oder entfernen. Es hat
(u.a.) sogar den Vorteil, das der gesamte Speicherplatz allen Subvolumes
zur Verfügung steht. Man muss sich nicht Entscheiden wie man den Platz
aufteilt und hat trotzdem sowas wie Partitionen. Ich nutze es daher auf
meiner NAS (mit vielen thematischen Subvolumes)
Jack V. schrieb:> Wenn jemand meinen Kram nimmt, und ihn auf ’nem anderen System zum> Laufen bringt: da freu’ ich mich drüber. Und wenn er an mich herantritt,> und konkrete Änderungen dafür anfragt (nicht: „verlangt“. Das ist
Wäre schön wenn das alle Debian Maintainer so sehen würden. Leider
fallen einige einzelne aber damit auf, ohne Not vorhandene SysV Init
Skripte zu entfernen und auch nicht wieder hinzuzufügen. Darüber sind
auch einige Debian-Devs nicht erfreut und es wird vermutlich auch
Debian-intern Diskussionen auslösen.
Bauform B. schrieb:> Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu> gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es> sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist?
Updates finden immer dann statt, wenn ein neuer Kernel installiert
wurde, oder aber irgend ein Programm installiert/aktualisiert wurde,
welches ebenfalls Bestandteil der initrd ist weil es beim Bootvorgang
frühzeitig benötigt wird. z.B. udev aber auch lvm.
Nano schrieb:> Zum konfigurieren des Netzwerks verwendet man das nmcli Tool, also das> Network Manager Command Line Interface. Damit ist das auch extrem
Warum, wer hat das festgelegt? Wenn ich einen Server habe der genau ein
Netzwerkinterface hat, was immer mit der gleichen, festen IP ohne DHCP
laufen soll, von mir aus auch DHCP, warum soll ich dann so ein Monstrum
wie Network-Manager installieren, der dann auch noch an Dateien wie z.B.
/etc/resolv.conf rumspielt? Und dazu noch alle möglichen Tools für
Modems, WLan und LTE als Abhängikeiten nach zieht.
Im übrigen ist das Benutzen von "nmcli" auf einem systemd-System schon
längst veraltet. Poettering hat entschieden, das er das auch besser kann
und deswegen hat ein echter systemd Jünger hat gefälligst
systemd-networkd zu benutzen.
Auf einem Desktop oder Notebook, keine Frage da nutze ich auch
Network-Manager aber das schöne an Linux ist ja gerade das man die
Möglichkeit hat, dass passende Tool für seinen Anwendungsfall frei zu
wählen.
Bauform B. schrieb:> Sheeva P. schrieb:>> Mit GNOME wirst Du damit vermutlich Probleme bekommen, weil einige>> Komponenten nun einmal von systemd abhängen sollen.>> Diese Komponenten lassen sich nicht installieren, also machen sie auch> keine Probleme. Genau hier kommt Devuan ins Spiel, da werden diese> garnicht angeboten, bei Debian muss man aufpassen. Man kann nicht alles
Aha, als auf meinem Devuan schon:
0 Pakete aktualisiert, 342 zusätzlich installiert, 0 werden entfernt und 96 nicht aktualisiert.
8
288 MB/288 MB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 902 MB zusätzlich belegt sein.
9
Möchten Sie fortsetzen? [Y/n/?] n
10
Abbruch.
11
andi@bla:~$
Genau aus dem Grunde gibt es ja den elogind im Devuan statt dem systemd.
Dieser implementiert alle notwendigen Dinge bzgl. Login und Session
Management. Und natürlich kann ich bei Devuan einfach einen USB Stick
einstecken und als normaler Benutzer mounten.
Andreas M. schrieb:> Jack V. schrieb:>> Wie auch immer – ein modernes System dürfte sich ohne initramfs nicht>> hochbekommen lassen, insofern wäre Devuan schon ein besserer Ansatz, als>> solche Systeme. Allerdings ist auch das auf ein initramfs ausgelegt, so>> dass da recht tiefgreifende Basteleien nötig sein werden.>> Unsinn. Das mag bei systemd so sein, bei SysV mit Sicherheit nicht.
Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen,
sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer
absoluten Kernkomponente den Pfad seiner Distribution. Insofern weise
ich das „Unsinn“ zurück.
Andreas M. schrieb:> Nun ist es nicht so, dass ich systemd grundsätzlich schlecht finde.> Gerade am Anfang als er noch frisch war, (damals war ich noch auf> ArchLinux) war ich davon geradezu begeistert.
Genau so ging es mir, die Ideen in "Rethinking PID 1" im
0pointer.net/blog/ haben mir wirklich gut gefallen. Aber von da an
ging's bergab.
Bauform B. schrieb:
> Inzwischen frage ich mich allerdings, wann die initrd überhaupt neu> gebaut wird. Natürlich bei einem Kernel-Update, aber sonst? Kann es> sein, dass es auch bei udev-Updates passiert (und schief gegangen) ist?> (initramfs) Updates finden immer dann statt, wenn (...) irgend ein> Programm installiert/aktualisiert wurde, welches ebenfalls> Bestandteil der initrd ist
Also doch relativ häufig, das erklärt meine Probleme damit, danke.
> andi@bla:~$ sudo aptitude install task-gnome-desktop> 0 Pakete aktualisiert, 342 zusätzlich installiert
dass das auch schon funktioniert hätte ich nicht gedacht, das ist ja der
Wahnsinn. Ich sollte bannedpackages.txt nicht nur überfliegen...
Dankeschön!
Jack V. schrieb:> Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen,> sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer> absoluten Kernkomponente den Pfad seiner Distribution.
Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es
viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die
Distribution ist nur formal tiefgreifend, technisch ändert sich fast
garnichts. Man könnte sagen, die Distribution merkt das garnicht. Man
darf ganz offiziell zusätzliche Kernel bei grub eintragen, das würde
doch reichen?
Ich benutze allerdings sowieso eine Bootpartition und syslinux, weil ich
immer mehrere Systeme auf einer Platte habe. Man kann auch ganz
offiziell "ohne Bootloader" installieren. Dadurch bin ich sicher, dass
syslinux und -config nicht überschrieben werden. /boot wird nicht
benutzt, die Distribution kann da rein schreiben, was sie will, es stört
nicht.
Diese Boot-Mimik funktioniert natürlich genauso gut mit wie ohne
initramfs, das ist ja unabhängig, aber aus "tiefgreifend" wird "minimal"
(oder so).
Bauform B. schrieb:> Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es> viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die> Distribution ist nur formal tiefgreifend, technisch ändert sich fast> garnichts.
Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man
das Ding für jeden Patch und Fix neu bauen muss, statt einfach das
Update der Distribution einzuspielen, wobei das initramfs ohne weiteres
Zutun neu gebaut wird, ist in meinen Augen ’n tiefgreifender
Unterschied. Letzteres dauert auf ’nem ältlichen Pentium Silver hier
immerhin geschlagene 10 Sekunden, während ein Kernel mit einiger
Sicherheit nicht in der Zeit zu bauen ist, allerdings nahezu genauso oft
gebaut werden müsste.
Aber mach’s halt einfach, und berichte dann. Ich werd’ bestimmt kein
Anhänger der Idee, Linux auf heutiger HW ohne initramfs starten zu
wollen, dafür ist das initramfs einfach viel zu flexibel und einfach zu
handhaben (und meinen PC würde ich ohne das nicht mal sinnvoll
hochbekommen, weil das Modul für die Grafik via DKMS gebaut wird, und
zur Bootzeit geladen werden sollte. Bei anderen Rechnern funktioniert’s
nicht, weil die Systempartitionen vor dem Starten des Systems
entschlüsselt werden müssen, LVM und sonstiger Kram gestartet muss, und
einige andere Sachen ablaufen sollen), aber das heißt ja nicht, dass ich
nicht auch gerne über den Tellerrand schaue um zu sehen, wie’s andere so
machen, und wie’s dabei so läuft.
Das Schöne an den offenen Systemen ist und bleibt ja: „There’s always
more then one way to do it“
Bauform B. schrieb:> Jack V. schrieb:> Meine Frage ist eigentlich "kann man Devuan empfehlen", "initrd" ist nur> ein Aufhänger. Es ist aber ein interessantes Detail, inwieweit sich> Devuan und Debian unterscheiden. Mir scheint, der Trend geht dahin, dass> etwas wie initramfs zwingend nötig sein soll, genau wie manch andere> Neuerungen.
Ein initramfs ist schlicht und ergreifend: sinnvoll, denn es verhindert,
daß man nach jeder Änderung an etwas, das zum Mounten des
Root-Dateisystems mit den Kernelmodulen benötigt wird, der Kernel neu
kompiliert werden muß. Zudem bleibt der Kernel kleiner und man kann die
Software in der initrd unabhängig vom Kernel aktualisieren. Im Grunde
genommen ist das die logische Konsequenz aus der Modularisierung des
Kernels mit dynamisch ladbaren Modulen.
>> weder mit DNS, noch mit NTP habe ich irgendwelche Probleme.>> Schön für dich, aber auch wenn 99.9% der Benutzer keine Probleme haben,> hilft mir das garnichts. Mehrere Leute hatten Probleme. Es waren> genug, dass es in der Zeitung stand und mir deshalb aufgefallen ist.
Also in meiner Zeitung stand nichts, aber das will ja nichts heißen.
Meine Erfahrung ist, daß Probleme meistens dann auftreten, wenn die
Anwender oder Admins abseits der Best Known Practices am System
herumfummeln. Häufig ist es so, daß solch "abseitige" Fummeleien
zunächst einmal funktionieren, es dann jedoch beim nächsten Update
Probleme gibt, weil die neue Softwareversion andere Defaults nutzt, die
Konfiguration nicht mehr lesen kann, oder die Konfiguration nicht mehr
automatisch für die neue Softwareversion migriert oder konvertiert
werden kann. Klar, so ein Linux bietet enorme Flexibilität, und das ist
ja auch einer der wichtigsten Gründe für seine Beliebtheit. Aber je
weiter man sich von den üblichen und getesteten Pfaden entfernt, desto
fragiler wird die Sache, vor allem im Hinblick auf die
Langzeitstabilität.
Das Traurige an solchen Problemen ist, daß die meisten Anwender, die
diese Probleme höchstselbst verursacht haben, nicht erkennen, einsehen
oder gar zugeben wollen, daß sie selbst die Ursache des Problems gewesen
sind. Sowas erleben wir hier im Forum ja ziemlich häufig, daß sich
jemand über Probleme mit einer Softwarekomponente X beschwert, und auf
Nachfrage kommen dann oft zwei Szenarien: entweder, der Betreffende weiß
gar nicht mehr, was er gemacht und wie genau sich der angebliche Fehler
geäußert hat, oder er rastet schon deswegen prophylaktisch aus, weil man
es wagt, nachzufragen und damit seine (natürlich unantastbare) Kompetenz
in Frage zu stellen.
Die initrd gibt es im stabilen Linux-Kernel seit Version 2.6.13, also
seit ziemlich genau 15 Jahren. Ich selbst nutze sie auf einigen hundert
Rechnern, mir persönlich seit vielen Jahren gut bekannte, erfahrene
Administratoren und Anwender von Linux-Systemen auf einigen weiteren
tausend Maschinen jedweder Couleur. Von größeren Problemen mit dieser
Technik habe ich bisher sehr, sehr selten gehört, viel seltener als von
Problemen mit selbstgestelten Kernels.
Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der
dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem
früher oder später auf die Füße fällt. Und ich befürchte, genau das gilt
auch für Dein Ansinnen, ein System ohne initrd betreiben. Letzten Endes
erhöhst Du die Fehlerwahrscheinlichkeit, anstatt sie zu reduzieren.
Eine womöglich fehlertolerantere Möglichkeit wäre, die zum Mounten des
RooFS nötigen Module in den Kernel zu kompilieren und trotzdem eine
initrd zu verwenden. Die Module aus der initrd werden nur genutzt, wenn
das benötigte Modul nicht fest einkompiliert ist. Habe ich aber nicht
getestet, YMMV.
Jack V. schrieb:> Der Trend geht zum initramfs (bzw.: ist gegangen zu, vor vielen, vielen> Jahren schon – Ausnahme ist der Embedded-Bereich), weil das nunmal> einfach praktisch ist, und zudem die Folgen von Fehlern abfangen kann.
Im Embedded-Bereich ist es ja auch meistens so, daß die Hardware bei
Weitem nicht so modular, flexibel und erweiterbar ist wie bei einem
Computer. Daher macht es dort natürlich viel mehr Sinn, alle benötigten
Module fest in den Kernel einzukompilieren und alles Überflüssige
herauszulassen, so daß am Ende ein schlankerer und genau auf die
Hardware abgestimmter Kernel herauskommt.
Auch bei besonders sicheren Systemen, beispielsweise für Firewalls, ist
es häufig sinnvoll, einen passenden Kernel zu kompilieren und das
dynamische Laden von Kernelmodulen zu deaktivieren -- und dann macht
eine initrd mit ladbaren Kernelmodulen natürlich auch keinen Sinn.
Andreas M. schrieb:> Für den Fall das man sich bei systemd dazu entscheidet das Teil zu> entbündeln, zu modularisieren,> [...]> Genau aus dem Grunde gibt es ja den elogind im Devuan statt dem systemd.> Dieser implementiert alle notwendigen Dinge bzgl. Login und Session> Management. Und natürlich kann ich bei Devuan einfach einen USB Stick> einstecken und als normaler Benutzer mounten.
Das ist ja interessant: man kann Teile von systemd also durch andere
ersetzen? Und wenn das so ist: ist das nicht genau jene Modularisierung,
deren Fehlen Du gerade noch beklagt hattest?
Jack V. schrieb:> Einen Kernel zu bauen und die Bootkonfiguration entsprechend anzupassen,> sehe ich als „recht tiefgreifende Bastelei“ – man verlässt bei einer> absoluten Kernkomponente den Pfad seiner Distribution. Insofern weise> ich das „Unsinn“ zurück.
Zwischen Kernel und Distribution gibt es so gut wie keine einzige
direkte Abhängigkeit, außer das der Kernel seine API anbieten muss, auf
der dann alles andere aufsetzt. Was im Kernel passiert, welche Treiber
eincompiliert sind, welche als Modul geladen werden müssen, und mit
welchen Optinen die geladen werden interessiert kein einziges Program
innerhalb der Distribution. Natürlich haben diese Einstellungen
Auswirkungen auf Performance und verfügbarkeit der Hardware im
Gesamtsystem, aber ein Gnome, KDE und selbst systemd interessiert sich
herzlich wenig dafür ob die Festplatte nun über den Sata, Scsi, iScsi
oder was auch immer angesprochen wird, pb diese Module hart im Kernel
waren aus der initrd kamen oder sogar erst viel später geladen wurden,
es bleibt ne Festplatte.
Was glaubst du denn, warum Docker, lxc, flatpak und Konsorten
funktionieren? Denkst Du im Ernst, das die ganzen Leute und Projekte die
solche Container anbieten sich irgendwelche Gedanken über den Kernel des
Hostsystem, ja die Distribution machen? Genau das tun sie nämlich nicht,
denn das ist der Sinn dieser Geschichten, das eben nicht für jede
Distribution ind jeden Kernel ein eigenen Container bauen müssen.
Jack V. schrieb:> Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man> das Ding für jeden Patch und Fix neu bauen muss, statt einfach das> Update der Distribution einzuspielen, wobei das initramfs ohne weiteres
Es ist doch etwas völlig anderes zu sagen "ich möchte automatisch
Updates bekommen" als "das ist Bastelei". Während das erste eine völlig
legitimer Grund ist, zu sagen, dass man den vorcompilierten Kernel
benutzen möchte zeugt das letztere in diesem Fall hier einfach nur
davon, das man keine Ahnung hat.
Karl Käfer schrieb:> Ein initramfs ist schlicht und ergreifend: sinnvoll, denn es verhindert,> daß man nach jeder Änderung an etwas, das zum Mounten des> Root-Dateisystems mit den Kernelmodulen benötigt wird, der Kernel neu> kompiliert werden muß. Zudem bleibt der Kernel kleiner und man kann die> Software in der initrd unabhängig vom Kernel aktualisieren.
Was ist den "etwas" was grundsätzlich zum Mounten benötigt werden soll?
Wenn man gar keine initrd hat, dann braucht man auch keine zu
aktualisieren? Nach deiner Logik also noch besser. Oder? Ob der Kernel
zur Boot-Zeit kleiner ist, ist vollkommen irrelevant, da spätestens zur
Laufzeit normalerweise eh alle Treiber geladen werden. Ein rein
monolitischer Kernel der alle Module eincompiliert hat, die das
Zielsystem braucht ist sogar noch kleiner. Und es soll sogar möglich
sein, nur die zum Booten und mounten notwendigen Treiber in den Kernel
zu compilieren und die restlichen Treiber vom gemounten root
nachzuladen. Der Linux Distribution ist das herzliche egal, wie das
konfiguriert ist.
Karl Käfer schrieb:> Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der> dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem> früher oder später auf die Füße fällt. Und ich befürchte, genau das gi
Ja ich denke auch, es ist besser wenn Du lieber andere entscheiden
lässt, was gut und richtig für Dich ist. Ich habe übrigens meine ersten
Schritte mit Linux Kernel 2.0 gemacht nur mal so am Rande. Damals hat
man auch mal über den Tellerrand geschaut und sich intensiver mit den
Sachen beschäftigt.
Karl Käfer schrieb:> Das ist ja interessant: man kann Teile von systemd also durch andere> ersetzen? Und wenn das so ist: ist das nicht genau jene Modularisierung,> deren Fehlen Du gerade noch beklagt hattest?
Nein kann man eben nicht. Du kannst entweder libelogind installieren
oder systemd. Wenn systemd modular wäre, dann würde ein systemd-networkd
z.B. mit libelogind funktionieren. Oder der elogind könnte mit der
libsystemd laufen. Genau das ist aber nicht der Fall. Weil es beim
systemd eben keine saubere Trennung der Schnittstellen gibt und jede
Teilkomponente ein "Teilwissen" über den Rest der Komponenten hat,
darüber was und wie sie es tun. z.B. Ist in jede systemd Komponente die
cgroup Struktur von systemd hart einkompiliert, statt diese in der
libsystemd zu abstrahieren. Da elogind jedoch eine komplett anderes
cgroup Layout benutzt kann man also kein einziges systemd-* Program
zusammen mit elogind benutzen, obwohl technisch eigentlich nichts
dagegen sprechen würde. Diese Software wurde absichtlich so designt,
dass man das nicht kann.
Andreas M. schrieb:> Zwischen Kernel und Distribution gibt es so gut wie keine einzige> direkte Abhängigkeit, außer das der Kernel seine API anbieten muss, auf> der dann alles andere aufsetzt. Was im Kernel passiert, welche Treiber> eincompiliert sind, welche als Modul geladen werden müssen, und mit> welchen Optinen die geladen werden interessiert kein einziges Program> innerhalb der Distribution.
… bis auf die, die bestimmte Funktionalität voraussetzen, die beim
Distributionskernel garantiert dabei ist, bei ’nem selbstgedrehten
Kernel vielleicht nicht – sei’s aufgrund eines Fehlers, aus Unwissen,
oder einfach, weil sich mal wieder ’ne Option geändert hat, und das beim
Bauen übersehen wurde. Ist ja nicht so, als wäre TE der erste, dem sowas
passieren würde …
Andreas M. schrieb:> Es ist doch etwas völlig anderes zu sagen "ich möchte automatisch> Updates bekommen" als "das ist Bastelei".
Ansichtssache. Etwas, das man für jedes Update selbst neu bauen muss,
ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles,
wartungsarmes System, wie sie heutige Linuxdistributionen nunmal
ermöglichen. Und wenn’s dann noch am Paketsystem vorbei installiert
würde, wie’s die allermeisten Selbstbauer machen, die ich kenne, wär’s
erst recht Bastelei.
Andreas M. schrieb:> Ich habe übrigens meine ersten> Schritte mit Linux Kernel 2.0 gemacht nur mal so am Rande. Damals hat> man auch mal über den Tellerrand geschaut und sich intensiver mit den> Sachen beschäftigt.
Ja gut … als ich ’99 bei 2.2 eingestiegen bin, war das schon völlig
anders. Keiner hat irgendwohin geschaut, oder sich gar noch mit dem Kram
beschäftigt. Vielleicht erklärt das die unterschiedlichen
Wahrnehmungsweisen?
(ich hoffe, der Hauch von Ironie ist erkennbar?)
Andreas M. schrieb:> Karl Käfer schrieb:>> Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der>> dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem>> früher oder später auf die Füße fällt. Und ich befürchte, genau das gi>> Ja ich denke auch, es ist besser wenn Du lieber andere entscheiden> lässt, was gut und richtig für Dich ist.
Ein guter und zutreffender Satz.
Es wäre schließlich vermessen zu glauben, man wäre schlauer als die
Schwarmintelligenz aus Linux-Entwickler, -maintainer und -distributoren.
Als ambitionierter aber pragmatischer Privatanwender habe ich in 15
Jahren Linuxerei (jaja, ich ahnungsloser Späteinsteiger) keinen Grund
gefunden einen Kernel zu bauen oder irgendein grundlegendes Systemsetup
gegenüber dem abzuändern was der Distributor als sinnvoll erachtet.
Ich möchte halt gerne mit dem System arbeiten als am System
(Da ich aber auch nerdige Hobbies betreibe kann ich mich in euch gut
hineinversetzen und gönne jedem den Spaß, sich sein Systm nach Belieben
zu Verbasteln und nach jedem mittelgroßen Update alles wieder flott zu
kriegen).
Jack V. schrieb:> Ansichtssache. Etwas, das man für jedes Update selbst neu bauen muss,> ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles,> wartungsarmes System, wie sie heutige Linuxdistributionen nunmal> ermöglichen.
Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket
zu bauen, dieses regelmäßig zu aktualisieren und per lokalem
Paket-Repository (das es als Mirror und wegen spezifischer Software
sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen.
Dafür bekomme ich einen schlanken Kernel, der alles was man nicht
braucht gar nicht erst enthält und somit generell eine kleine
Angriffsfläche bietet.
Le X. schrieb:> Als ambitionierter aber pragmatischer Privatanwender habe ich in 15> Jahren Linuxerei (jaja, ich ahnungsloser Späteinsteiger) keinen Grund> gefunden einen Kernel zu bauen oder irgendein grundlegendes Systemsetup> gegenüber dem abzuändern was der Distributor als sinnvoll erachtet.
Du vielleicht nicht, andere aber schon. Ich hab ein Problem damit das
einfach als "Gebastel" in die Ecke zustellen, weil das einfach nicht
stimmt.
Le X. schrieb:> hineinversetzen und gönne jedem den Spaß, sich sein Systm nach Belieben> zu Verbasteln und nach jedem mittelgroßen Update alles wieder flott zu> kriegen).
Ich benutze schon immer selbst kompilierte Kernel und stell Dir vor, ich
habe mein System von Debian Jessie nach Devuan Ascii und zuletzt nach
Beowulf per dist-upgrade aktualisiert, ohne irgend ein Problem. Als ob
ein selbst kompilierter Kernel automatisch zu Upgrade Problemen führen
würde. Der Kernel ist das kleinste Problem bei einem Upgrade.
Andreas M. schrieb:> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket> zu bauen, dieses regelmäßig zu aktualisieren und per lokalem> Paket-Repository (das es als Mirror und wegen spezifischer Software> sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen.
Dann solltet ihr, im Sinne der Diskussion schleunigst mal klären wie der
Kontext aussieht.
Gehts um den Privatanwender mit Email und Office?
"Poweruser" mit NAS, mehreren OSen und etwas mehr Ambition?
Konzern mit großer IT-Abteilung?
Also ich hab keinen MA abgestellt der mir zuhause den Kernel baut und
die Pakete einspielt, deshalb versuche ich jeglichen Aufwand zu
vermeiden der mir nicht wesentliche Vorteile einbringt (Rebellion gegen
Pöttering zum reinen Selbstzweck ist für mich kein Vorteil).
Ich bin sehr zufrieden wenn sich mein Adminstrationsaufwand auf ein
"pacman -Syu " beschränkt.
Von einem Privatanwender hier im Forum ist bekannt dass er sich im
Keller auch Serverfarmen hält und die Devuan-Repos spiegelt (könnten ja
morgen weg sein. Was es aber bringt sich Kopien einer nicht mehr
existenten Distri vorzuhalten ist mir aber unklar).
Das läuft dann wohl unter Hobby, damit kann man natürlich jeden
Mehraufwand rechtfertigen.
Beim TO hatte ich aber bisher eher den Eindruck er möchte sein System
einfach nur nutzen.
Jack V. schrieb:> Bauform B. schrieb:>> Die ersten Versuche sind wohl Bastelei, aber sobald es läuft, ist es>> viel überschaubarer und stabiler als ein initramfs. Der Eingriff in die>> Distribution ist nur formal tiefgreifend, technisch ändert sich fast>> garnichts.>> Gut, da bin ich halt anderer Meinung. Schon alleine der Punkt, dass man> das Ding für jeden Patch und Fix neu bauen muss, statt einfach das> Update der Distribution einzuspielen, wobei das initramfs ohne weiteres> Zutun neu gebaut wird, ist in meinen Augen ’n tiefgreifender> Unterschied.
Ein großer Unterschied ist es natürlich, ein Eingriff ist es eher
nicht. "das Ding" besteht ja nur aus dem Kernel, also muss es nur bei
einem Kernel-Update neu gebaut werden und meistens nicht einmal dann,
weil z.B. ein Patch im Bluetooth-Stack für mich nicht relevant ist.
Karl Käfer schrieb:> Von größeren Problemen mit dieser Technik (initramfs) habe ich> bisher sehr, sehr selten gehört, viel seltener als von> Problemen mit selbstgestelten Kernels.
Das glaube ich gerne, aber entscheidend ist doch, wann diese Probleme
auftreten. Wenn ich gerade am Kernel bastel, muss ich mit Problemen
rechnen, ich kann sie aber auch sofort beheben. Im anderen Fall
passieren sie ohne mein Zutun, irgendwann, überraschend, irgendwo.
> Eine womöglich fehlertolerantere Möglichkeit wäre, die zum Mounten des> RooFS nötigen Module in den Kernel zu kompilieren und trotzdem eine> initrd zu verwenden. Die Module aus der initrd werden nur genutzt, wenn> das benötigte Modul nicht fest einkompiliert ist.
Ein Beispiel wäre, wenn ich / von ext4 auf btrfs umstelle (oder so).
Aber sonst? Welches Modul sollte plötzlich nötig werden, wenn es beim
Kernelbau noch nicht nötig war? USB-Hardware kommt und geht, klar, aber
die kommt später dran, wenn / gemountet ist.
Karl Käfer schrieb:> Im Embedded-Bereich ist es ja auch meistens so, daß die Hardware bei> Weitem nicht so modular, flexibel und erweiterbar ist wie bei einem> Computer.
Trotz Modularität und Erweiterbarkeit braucht auch ein Desktop-PC die
Module nicht bevor / gemountet ist. Apropos Embedded: die meiste Zeit
habe ich mit PCs zu tun, die einfach ein- und ausgeschaltet werden wie
eine Schreibtischlampe. Daher kommt meine Vorliebe für kurze Bootzeiten
und tiefgreifende Eingriffe.
Edit: und die Idee, dass man den Kernel selbst bauen sollte, stammt aus
der Zeit, als das devtmpfs im Kernel auftauchte und Debian das (noch)
nicht genutzt hat.
Jack V. schrieb:> Etwas, das man für jedes Update selbst neu bauen muss,
nur bei einem Kernel-Update, und nicht einmal bei jedem
> ist meiner Ansicht nach Bastelei, aber nicht die Basis für ein stabiles,> wartungsarmes System, wie sie heutige Linuxdistributionen nunmal> ermöglichen. Und wenn’s dann noch am Paketsystem vorbei installiert> würde, wie’s die allermeisten Selbstbauer machen, die ich kenne, wär’s> erst recht Bastelei.
Mein Kernel auf der extra Bootpartition ist natürlich am Paketsystem
vorbei, das ist ja genau der Sinn der Sache. Ohne Bootpartition und ohne
initramfs müsste ich eben ein Kernel-Paket bauen, das ist ja auch
offiziell vorgesehen. Und mehr ändert sich doch nicht.
Ich verwende auch manchmal selbstgebaute Kernels, meistens weil es
einfach nicht anders geht.
Als ich z.B. mein Surface Pro 3 bekam, war der Debian Kernel einfach zu
alt. Als ich später nochmal nachsah waren gewisse Treiber erstmal nicht
aktiviert (wer nutzt den schon Linux auf nem Surface? Viel zu
exotisch!). Ob es mittlerweile ootb geht, keine Ahnung.
Aber Problematisch ist es nicht. Man könnte eine minimale config
generieren (make localyesconfig oder localmodconfig), und die dann
nehmen (obwohl, die sind doch etwas gar minimal), aber man kann auch die
alte Config vom debian Kernel nehmen (/boot/config-*), und die dann
erweitern "make menuconfig". Wenn man das hat, einfach das kernel packet
von Debian auf hold setzen (linux-image-amd64 glaub ich) (oder
deinstallieren, falls möglich), "make deb-pkg" oder "make bindeb-pkg"
nehmen, die relevanten Packete installieren, und fertig.
Updates sind kein Problem. Einfach .config kopieren, "make deb-pkg", mit
dpkg installieren, fertig. Ich hab das in nem Script automatisiert, und
muss jetzt nur noch "update-kernel" eintippen, und es lädt und
kompiliert mir den aktuellen stable oder longstable Kernel, jenachdem,
ob letzterer schon neu genug ist. Alles total schmerz und gefahrlos. Und
notfalls kann man auf den vorherigen Kernel kann man immer noch zurück,
ist ja in grub auswählbar.
Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag
temporär wegnehmen, und wenn es geht, einfach mit apt initramfs-tools
deinistallieren & grub updaten.
Sobald das System mal sauber eingerichtet ist werden dann auch
zukünftige Updates nichts kaputt machen. Nur dass der Kernel ständig
neue fixes bekommt ist nervig, fast jede Woche wieder eins. Da muss man
dann aufpassen, dass einem /boot nicht volläuft, und auch mal alte
Kernels + quellen löschen...
Andere Orte, wo ich einen eigenen Kernel habe, ist mein Librem 5 (auch
hier, debian kernel zu alt), und ein Server (dort hauptsächlich, um den
selbst zu signieren, und ich glaube zu jessie Zeiten brauchte ich noch
was für meine Container...).
Andreas M. schrieb:> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket> zu bauen, dieses regelmäßig zu aktualisieren und per lokalem> Paket-Repository (das es als Mirror und wegen spezifischer Software> sowieso gibt) zu verteilen, dann hält sich der Aufwand in engen Grenzen.
Natürlich. Bestimmt wird der TE das genau so machen, oder?
Le X. schrieb:> Es wäre schließlich vermessen zu glauben, man wäre schlauer als die> Schwarmintelligenz aus Linux-Entwickler, -maintainer und -distributoren.
Da erhebe ich nun wieder Einspruch: es wäre vermessen, zu glauben, die
Entwickler und Maintainer könnten jeden speziellen Fall gleichermaßen
vorhersehen und abdecken. Schon alleine, weil das nicht geht. Es gibt
triftige Gründe, es anders zu machen. Und wenn’s ein „aber ich will
das Neue nich!!k“ ist – das ist zwar kein objektiver, aber ein valider
subjektiver Grund.
Nur ist’s wichtig, das dann auch genau so zu sagen: technisch spricht
bei einem herkömmlichen Setup und Einsatzzweck nichts gegen ein
initramfs.
Bauform B. schrieb:> Ein großer Unterschied ist es natürlich, ein Eingriff ist es eher> nicht. "das Ding" besteht ja nur aus dem Kernel, also muss es nur bei> einem Kernel-Update neu gebaut werden und meistens nicht einmal dann,> weil z.B. ein Patch im Bluetooth-Stack für mich nicht relevant ist.
Die Frage ist ja: du hast die LKML abonniert und verfolgst die
Entwicklung aufmerksam, und bist in der Lage, den Einfluss der einzelnen
Sachen auf dich abzuschätzen und zeitnah einen neuen Kernel zu bauen?
Zum Kernel gehört übrigens schon auch bisschen mehr, als das einzelne
Binary.
? DPA ? schrieb:> Updates sind kein Problem. Einfach .config kopieren, "make deb-pkg", mit> dpkg installieren, fertig.Damit sind schon Leute böse aufs Gesicht gefallen :D
? DPA ? schrieb:> Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag> temporär wegnehmen
Das geht irgendwie bei keinem meiner Debiansysteme. Vielleicht braucht’s
da ja tatsächlich Devuan für?
Jack V. schrieb:> ? DPA ? schrieb:>> Initramfs entfernen ist auch sehr unproblematisch. In grub den Eintrag>> temporär wegnehmen>> Das geht irgendwie bei keinem meiner Debiansysteme. Vielleicht braucht’s> da ja tatsächlich Devuan für?
Hast du grub, ist es bei Debian noch standard? Beim Grub Menu ist das
glaub ich die E taste zum editieren, und dann F10 zum booten. Ist aber
schon länger her, das ich das mal gebraucht habe.
? DPA ? schrieb:> Hast du grub, ist es bei Debian noch standard?
Nein. Und es bootet nicht ohne initramfs – der Bootloader ist da
unerheblich. Kann’s auch gar nicht, weil da Module drin sind, die’s bei
mir zum Booten braucht (verschlüsseltes Root-FS, LVM, etc.).
Das mag für den TE okay sein, wenn er eh ’nen eigenen Kernel baut, aber
den Standardkernel von Debian bootet man wohl nicht ohne initramfs, auch
ohne meine (eigentlich gar nicht mehr so exotischen) Sachen da.
Andreas M. schrieb:> Zwischen Kernel und Distribution gibt es so gut wie keine einzige> direkte Abhängigkeit, außer das der Kernel seine API anbieten muss, auf> der dann alles andere aufsetzt.
Oh, lustig. Daß die APIs, die der Kernel anbietet, natürlich inhärent
davon abhängig sind, wie der Kernel -- und womöglich seine Module --
übersetzt worden sind, ignorierst Du einfach mal. Alleine auf dem
System, vor dem ich gerade sitze, ist die config-Datei 9621 Zeilen groß.
> Was glaubst du denn, warum Docker, lxc, flatpak und Konsorten> funktionieren?
Weil die Kernel-Sourcen den Code für Cgroups und Namespaces inegriert
hat, sowie derjenige der den Kernel übersetzt hat, die Optionen
CONFIG_CGROUPS, CONFIG_CGROUP_*, CONFIG_NAMESPACES und weitere aktiviert
-- also auf 'y' oder 'm' gesetzt hat. Bei Deinem Linux 2.0 wäre das
alles natürlich nicht möglich gewesen, da dieser Kernel weder Cgroups
noch Namespaces unterstützt hat und die betreffenden Features daher auch
nicht aktiviert werden konnten.
Du siehst schon an diesem Deinem eigenen einfachen Beispiel: es gibt
starke Abhängigkeiten zwischen dem Kernel, seiner Konfiguration, und der
Software, die dann auf einem System mit diesem Kernel genutzt werden
kann. Huch?!
> Karl Käfer schrieb:>> Ein initramfs ist schlicht und ergreifend: sinnvoll, denn es verhindert,>> daß man nach jeder Änderung an etwas, das zum Mounten des>> Root-Dateisystems mit den Kernelmodulen benötigt wird, der Kernel neu>> kompiliert werden muß. Zudem bleibt der Kernel kleiner und man kann die>> Software in der initrd unabhängig vom Kernel aktualisieren.>> Was ist den "etwas" was grundsätzlich zum Mounten benötigt werden soll?
Klar, nichts. Deswegen ist die initrd immer leer und man braucht sie
eigentlich gar nicht... Ach nee, Ironie aus.
Zweifelohne ausgesprochen sinnvoll, daß der Kernel das Dateisystemformat
des Root-Dateisystems lesen kann, findest Du nicht? Wenn mein
Root-Dateisystem nun auf einem BTRFS, LVM2 liegt oder verschlüsselt ist,
dann benötigt er für das Mounten des Root-Dateisystems vermutlich auch
die Treiber dafür, oder? Jedoch sind die Kerneltreiber für die
vorgenannten Kernelfeatures in den meisten Standard-Distributionskernels
als dynamisch ladbare Module kompiliert (Option "m" anstatt "y")
kompiliert, und deswegen braucht der Kernel zum Booten (zu dem inhärent
das Einhängen ("Mounten") des Root-Dateisystems gehört) nun eine
Möglichkeit, diese dynamisch ladbaren Module... nunja, dynamisch zu
laden. Um das zu tun, braucht er natürlich zwingend eine Möglichkeit,
diese Module aus irgendeiner Quelle zu beziehen, denn vom
Root-Dateisystem kann er sie ja ohne besagte Module nicht laden. Und
genau hier kommt die initrd ins Spiel... Wenn Du magst, kann ich Dir das
gerne noch genauer erklären, frag einfach -- aber jetzt kürze ich hier
erstmal ab, um unsere Mitleser nicht zu langweilen.
Jedenfalls kann man die betreffenden Module natürlich auch fest in den
Kernel einkompilieren. Als ich mit Linux angefangen habe, mußte man das
sogar, weil es damals noch gar keine Möglichkeit gab, Kernelmodule zur
Laufzeit zu laden. Wie dem auch sei, bedeutet das allerdings nun einmal
zwingend, daß man nach jedem Kernelupdate einen neuen Kernel kompilieren
muß, denn das Kernelupdate installiert natürlich zunächst den
Standardkernel der Distribution, der viele Module wie beispielsweise die
im vorigen Abschitt genannten nicht fest in den Kernel, sondern als
ladbare Module übersetzt.
> Wenn man gar keine initrd hat, dann braucht man auch keine zu> aktualisieren? Nach deiner Logik also noch besser. Oder?
Die "Logik", die Du mir unterstellst, ist nicht meine. Sie ist Deine
eigene und findet, Pardon, lediglich in Deinem eigenen Kopf statt.
Schau, Du darfst gerne sachlich mit mir diskutieren, aber mit Deinen
Strohpüppchen wirst Du alleine spielen müssen. Viel Glück!
> Ob der Kernel> zur Boot-Zeit kleiner ist, ist vollkommen irrelevant, da spätestens zur> Laufzeit normalerweise eh alle Treiber geladen werden. Ein rein> monolitischer Kernel der alle Module eincompiliert hat, die das> Zielsystem braucht ist sogar noch kleiner.
Wenn Du meine Beiträge ein bisschen aufmerksamer gelesen und Dich mehr
auf deren tatsächliche Inhalte statt auf deren absichtliches
Mißverstehen und die Konstruktion Deiner Strohpuppen konzentriert
hättest, wäre Dir zweifells aufgefallen, daß ich genau diesen Umstand
bereits impizit angedeutet habe.
> Der Linux Distribution ist das herzliche egal, wie das> konfiguriert ist.
Warum Du jetzt plötzlich die Linux-Distribution ins Spiel bringst,
erschließt sich mir nicht.
> Karl Käfer schrieb:>> Wie dem auch sei: jedes manuelle Herumfummeln am System außerhalb der>> dafür vorgesehenen Pfade und Lösungen birgt das Risiko, daß es einem>> früher oder später auf die Füße fällt. Und ich befürchte, genau das gi>> Ja ich denke auch, es ist besser wenn Du lieber andere entscheiden> lässt, was gut und richtig für Dich ist.
Das passiert ja sonst nie, kleiner Freiheitskämpfer! Du alleine
entscheidest, welche Features Linus Torvalds in seinen Kernel übernimmt,
welche Features die nächste Version der Bash, der X-Server und Dein
Lieblingsdesktop unterstützen, und natürlich hast Du die Hoheit über Qt,
GTK, WxWidgets und... einfach alles.
> Ich habe übrigens meine ersten> Schritte mit Linux Kernel 2.0 gemacht nur mal so am Rande. Damals hat> man auch mal über den Tellerrand geschaut und sich intensiver mit den> Sachen beschäftigt.
Oh, wie süß, ein Schwanzlängenvergleich?!
> Karl Käfer schrieb:>> Das ist ja interessant: man kann Teile von systemd also durch andere>> ersetzen? Und wenn das so ist: ist das nicht genau jene Modularisierung,>> deren Fehlen Du gerade noch beklagt hattest?>> Nein kann man eben nicht. Du kannst entweder libelogind installieren> oder systemd. Wenn systemd modular wäre, dann würde ein systemd-networkd> z.B. mit libelogind funktionieren. Oder der elogind könnte mit der> libsystemd laufen. Genau das ist aber nicht der Fall.
Das liegt aber nicht an systemd, sondern an elogind. Wenn die Entwickler
von elogind es wollen, können sie die entsprechenden Schnittstellen von
systemd nutzen oder nötigenfalls nachbauen.
> Weil es beim> systemd eben keine saubere Trennung der Schnittstellen gibt und jede> Teilkomponente ein "Teilwissen" über den Rest der Komponenten hat,> darüber was und wie sie es tun.
Ui, das ist ja gräßlich! Du wirfst systemd also vor, daß es eine
integrierte und aufeinander abgestimmte Lösung ist. Das ist ungefähr so
intelligent wie sich darüber zu beklagen, daß Du Dein
ext2-Lieblingsmodul vom Linux-Kernel 2.0 nicht mehr in einen aktuellen
Kernel laden kannst oder daß das Cgroup-Modul für das CPU-Accounting nun
einmal zwingend vom Cgroup-Modul abhängt...
> z.B. Ist in jede systemd Komponente die> cgroup Struktur von systemd hart einkompiliert, statt diese in der> libsystemd zu abstrahieren. Da elogind jedoch eine komplett anderes> cgroup Layout benutzt kann man also kein einziges systemd-* Program> zusammen mit elogind benutzen, obwohl technisch eigentlich nichts> dagegen sprechen würde. Diese Software wurde absichtlich so designt,> dass man das nicht kann.
Ja, aber "diese Software" ist in diesem Fall nicht systemd, sondern
elogind. Schließlich hätten sich die elogind-Entwickler einfach an die
Vorgaben des Projekts halten können, mit dem sie kompatibel sein wollen.
Und ja, das geht, immerhin implementieren Gentoos eudev, Parabolas
notsystemd und s6 durchaus mehr oder weniger große Teile der
systemd-APIs und -Services.
Wie auch immer, Du darfst gerne mit mir diskutieren, aber das setzt
zwingend voraus, daß Du Dir die Polemik und die Strohpuppen verkneifst,
sachlich bist und zumindest den Versuch erkennen läßt, meine Aussagen
korrekt zu verstehen. Ansonsten ist mein Gespräch mit Dir hiermit
beendet.
Andreas M. schrieb:> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket> zu bauen, dieses regelmäßig zu aktualisieren
Wenn du das bezahlen willst....
Ich würde den IT Mitarbeiter ja die Kernelpakete der Distribution nutzen
lassen, das spart Arbeitszeit und die kann er dann in wichtiges
investieren.
Selber backen macht allerhöchstens beim High Performance Computing Sinn,
wo sich jede ms, die man einspart, zu was großem aufsummiert, aber sonst
ist das vergeudete Arbeitszeit.
> Dafür bekomme ich einen schlanken Kernel, der alles was man nicht> braucht gar nicht erst enthält
In Zeiten von Rechnern mit 16 GB RAM....
> und somit generell eine kleine> Angriffsfläche bietet.
Das einzige echte Argument, wenn es denn überhaupt zu einer größeren
Angriffsfläche führt.
In der Regel hat die eine Komponente nichts zu tun mit der anderen und
damit sieht's mit den Angriffsflächen oft schon wieder anders aus.
Beim Thema Sicherheit würde ich sogar Sachen zum Kernel dazupacken.
Man denke da mal an die Kernel Hardening features usw..
Karl Käfer schrieb:> Oh, wie süß, ein Schwanzlängenvergleich?!
Wenn ich mich recht erinnere Warst Du doch der erste der seine Weisheit
ins rechte Lich rücken wollte. Ich darf zitieren:
Karl Käfer schrieb:> seit ziemlich genau 15 Jahren. Ich selbst nutze sie auf einigen hundert> Rechnern, mir persönlich seit vielen Jahren gut bekannte, erfahrene> Administratoren und Anwender von Linux-Systemen auf einigen weiteren
Ich würde mich daher nicht soweit aus dem Fenster lehnen. Das Du in
deinem letzten Beitrag einbisl am Thema vorbei argumentiert hast ist Dir
sicher selbst nicht entgangen. Wo schrieb ich ein Kernel-Modul vom 2.0
in einem 5er Kernel laden zu wollen? Das man ein Feature anschalten
muss, wenn es brauch versteht sich wohl von selst. Aber mit Sicherheit
wird sich die Kernel API für die CGROUPS nicht von heute auf Morgen
ändern und unerwartet unermessliche Probleme beim Update erzeugen.
Karl Käfer schrieb:> Das liegt aber nicht an systemd, sondern an elogind. Wenn die Entwickler> von elogind es wollen, können sie die entsprechenden Schnittstellen von> systemd nutzen oder nötigenfalls nachbauen.
Nein können sie eben nicht. weil die Teilkomponenten von systemd numal
extra so designt wurden, dass das nicht geht.
Karl Käfer schrieb:> Zweifelohne ausgesprochen sinnvoll, daß der Kernel das> Dateisystemformat, des Root-Dateisystems lesen kann> (...) Und genau hier kommt die initrd ins Spiel...> Wenn Du magst, kann ich Dir das gerne noch genauer erklären,> frag einfach -- aber jetzt kürze ich hier erstmal ab,> um unsere Mitleser nicht zu langweilen.
zu spät :(
Ich hab's geahnt, manche Fragen darf man einfach nicht fragen.
Danke für die konstruktiven Beiträge.
Karl Käfer schrieb:> Ja, aber "diese Software" ist in diesem Fall nicht systemd, sondern> elogind. Schließlich hätten sich die elogind-Entwickler einfach an die> Vorgaben des Projekts halten können, mit dem sie kompatibel sein wollen.> Und ja, das geht, immerhin implementieren Gentoos eudev, Parabolas> notsystemd und s6 durchaus mehr oder weniger große Teile der> systemd-APIs und -Services.
Das sind komplett verschiedene Dinge, und sie lösen das Problem von
Systemds Monotolitismus und binary unmodularität und daraus
resultierendem lock-in nicht:
1. s6 soll etwas von Systemd implementieren? In welchem Universum?
2. eudev ist der udev teil, der nun in Systemd ist. Aber udev war nicht
immer teil von Systemd, also natürlich kann man den normalzustand da
wiederherstellen. Trotzdem hat Systemd weiterhin viele untereinander
abhängige Teile, die nicht one systemd gehen.
3. Bei Parabolas notsystemd scheint es um das Patchen von Programmen zu
gehen, dass diese nicht mehr von Systemd abhängig sind. Das zeigt also
eher, das das ein echtes Problem mit Systemd ist. Und solche Änderungen
werden upstream häufig auch nicht angenommen.
4. elogind ist im grunde systemd ohne systemd. Neben andere dinge,
werden ein paar Funktionen von libsystemd implementiert. Schau dir mal
all die komplett verschiedenen APIs an, die da drin sind:
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/libsystemd0.symbols
IPC zeug, journald zeug, devicemanagemant zeug, session managemant zeug,
warum ist der mist alles in der selben Library, so das man ja nicht
einen teil einzeln implementieren kann? Das Problem löst elogind nicht,
sondern es hat in der Hinsicht das genau selbe Problem, wie Systemd. Es
ist nur etwas weniger invasiv, und lässt das weg, was tatsächlich
möglich ist.
5. Das sind nur einige der public APIs. Sie Systemd komponenten müssen
sich aber nicht an die halten. Diese werden zusammen, in lock-step
gebaut, wenn da irgend was mal mit irgend einer Alternative
funktioniert, selbst wenn die public API die selbe wäre, ist das ein
reiner Glücksfall. Ausserdem wird ja auch nicht wirklich ein Geheimnis
daraus gemacht, dass das absichtlich so gebaut wird, das anderes zeug
möglichst inkompatibel bleibt, und systemd verwendet werden muss:
https://blog.darknedgy.net/technology/2020/05/02/0/
Bauform B. schrieb:> Ein großer Unterschied ist es natürlich, ein Eingriff ist es eher> nicht. "das Ding" besteht ja nur aus dem Kernel, also muss es nur bei> einem Kernel-Update neu gebaut werden und meistens nicht einmal dann,> weil z.B. ein Patch im Bluetooth-Stack für mich nicht relevant ist.
...solange Du kein Bluetooth benutzt, natürlich. :)
> Karl Käfer schrieb:>> Von größeren Problemen mit dieser Technik (initramfs) habe ich>> bisher sehr, sehr selten gehört, viel seltener als von>> Problemen mit selbstgestelten Kernels.>> Das glaube ich gerne, aber entscheidend ist doch, wann diese Probleme> auftreten. Wenn ich gerade am Kernel bastel, muss ich mit Problemen> rechnen, ich kann sie aber auch sofort beheben. Im anderen Fall> passieren sie ohne mein Zutun, irgendwann, überraschend, irgendwo.
Sie passieren dann nach dem Reboot, der nach einem Kernel-Update fällig
ist (ich weiß, daß verschiedene Parteien an Technologien arbeiten, den
Kernel zur Laufzeit ohne Reboot aktualisieren zu können, kenne aber noch
keine stabile Lösung dafür). Also im Prinzip... ach ja, im Zuge des
Update, also haargenau dann, wenn Du Deinen Kernel backst und danach
bootest...
>> Eine womöglich fehlertolerantere Möglichkeit wäre, die zum Mounten des>> RooFS nötigen Module in den Kernel zu kompilieren und trotzdem eine>> initrd zu verwenden. Die Module aus der initrd werden nur genutzt, wenn>> das benötigte Modul nicht fest einkompiliert ist.>> Ein Beispiel wäre, wenn ich / von ext4 auf btrfs umstelle (oder so).> Aber sonst? Welches Modul sollte plötzlich nötig werden, wenn es beim> Kernelbau noch nicht nötig war? USB-Hardware kommt und geht, klar, aber> die kommt später dran, wenn / gemountet ist.
Es sei denn, Du möchtest das Root-Dateisystem mit dem installierten
Kernel von irgendeinem USB-Gerät booten oder... Ach, ich bin zu faul,
mir jetzt passende Szenarien auszudenken. Aber klar, es geht immer
darum, daß der Kernel sein Root-Dateisystem erreichen, lesen und mounten
kann... aber nicht nur das. Mein initramfs enthält zum Beispiel auch
Microcode-Patches für Intel- und AMD-CPUs. Wie händelst Du das?
> Karl Käfer schrieb:>> Im Embedded-Bereich ist es ja auch meistens so, daß die Hardware bei>> Weitem nicht so modular, flexibel und erweiterbar ist wie bei einem>> Computer.>> Trotz Modularität und Erweiterbarkeit braucht auch ein Desktop-PC die> Module nicht bevor / gemountet ist.
An dieser Stelle wollte ich eher darauf hinaus, daß auf Embedded-Geräten
ein genau auf die Hardware zugeschnittener Kernel genutzt werden kann,
bei dem die Option zum dynamischen Nachladen von Kernel-Modulen
deaktiviert ist. Jedoch... ich meine mich noch an Schwierigkeiten mit
Kernelmodulen erinnern zu können, die dynamisch geladen werden mußten
und somit nicht fest einkompiliert werden konnten, aber das ist
Ewigkeiten her und ich habe die Details vergessen oder möglicherweie
auch verdrängt. ;-)
> Apropos Embedded: die meiste Zeit> habe ich mit PCs zu tun, die einfach ein- und ausgeschaltet werden wie> eine Schreibtischlampe. Daher kommt meine Vorliebe für kurze Bootzeiten> und tiefgreifende Eingriffe.
Also das Laden und Entladen des initramfs benötigt auf diesem Schleppi
hier etwa 1,05 Sekunden. Um diese Sekunde beim Booten zu sparen,
bastelst Du bei jedem Kernel-Update herum. Oder hast Du den Bau und das
Deployment Deines neuen Kernels automatisiert, etwa mit einer
Technologie wie Ansible?
Wie lange brauchst Du denn jeweils dafür, einen Kernel zu bauen und auf
Deine Maschinen auszurollen? Und: müssen die Zielmaschinen nicht
gebootet sein um Deinen Kernel auszurollen, und dann noch einmal
rebootet werden, um den neuen Kernel zu booten und zu testen, ob die
Büchsen mit Deinem Eigenbau dann auch wieder sauber hochkommen?
Summa summarum reden wir also von folgendem Aufwand pro Kernelupdate:
das Herunterladen und Auspacken der Kernelsourcen, Konfiguration,
Übersetzung und Zusammenpacken des Kernels, je eine Bootzeit für alle
ausgeschalteten Rechner, die Übertragungs-, Entpackungs- und
Installationszeit für jeden Deiner Rechner sowie eine weitere Bootzeit
je Rechner, um den neuen Kernel zu booten und zu testen... und bestimmt
habe ich noch etwas vergessen.
Sei mir nicht böse, aber auf dieser Basis habe ich nicht eben das
Gefühl, als ob Dein leztlich auf Wirtschaftlichkeit abzielendes Argument
einer genaueren Betrachtung standzuhalten vermag. Zumal ein bisschen
Rechnerzeit mir immer noch wesentlich billiger zu sein scheint als jeder
manuelle Handschlag... und die Kernelkompilation selbst ja auch
signifikante Rechenzeit kostet.
> Edit: und die Idee, dass man den Kernel selbst bauen sollte, stammt aus> der Zeit, als das devtmpfs im Kernel auftauchte und Debian das (noch)> nicht genutzt hat.
Ich kann mich an Zeiten erinnern, als man den Kernel ohnehin immer
selbst bauen mußte, um all seine Hardware nutzen zu können. Sooo neu war
die Idee damals also nicht... und ich habe ja einige Beispiele genannt,
in denen ein selbstgebauter und nicht-modularer Kernel
(CONFIG_MODULES="n") durchaus sinnvoll sein kann.
> Mein Kernel auf der extra Bootpartition ist natürlich am Paketsystem> vorbei, das ist ja genau der Sinn der Sache.
Oh, nicht... Und das, was Du Dir da jedesmal manuell und ausdrücklich am
System vorbei zusammenbastelst, soll dann stabiler sein als die seit
langer Zeit eingeführten, seit etlichen Jahren auf Abermillionen von
Computern und Virtuellen Maschinen absolut stabil funktionierenden und
automatisierten Technologien, die das Betriebssystem anbietet und
benutzt? Weil Du noch nie Probleme damit hattest (was ein noch viel
invalideres Argument ist als jenes, das zu zurückgewiesen hast, weil ein
minimaler Bruchteil eines Prozents der Anwender laut irgendeiner
nichtgenannten Zeitung Probleme mit DNS und NTP gehabt haben soll)? Oder
weil... die Kernelentwickler, die diese Technologie entwickelt haben und
ausdrücklich empfehlen, und die Distributoren, die sie benutzen, alle
keine Ahnung haben oder jedenfalls weniger als Du? Hm, bitte sei mit
nicht böse, aber, um es mit unserem ehemaligen Außenminister Josef
"Joschka" Fischer zu sagen: "I am not convinced".
Aber natürlich, ich will Dich nicht missionieren, natürlich kannst Du
das so halten wie Du magst und weitermachen wie bisher. Trotzdem gibt es
letztlich keine ernsthaften Sachargumente für solche Basteleien -- oder
zumindest habe ich in dieser Diskussion noch keines lesen dürfen.
Karl Käfer schrieb:> Aber natürlich, ich will Dich nicht missionieren, natürlich kannst Du> das so halten wie Du magst und weitermachen wie bisher. Trotzdem gibt es> letztlich keine ernsthaften Sachargumente für solche Basteleien
Das Aufsetzen und Administrieren des Systems kann ein Hobby sein.
Das ist ein valides Argument.
Und ja, ich habe auch schon viel Unnötiges am PC gebastelt und
konfiguriert, einfach nur aus Spieltrieb und weil ichs kann.
Unwürdig wirds erst wenn man da nicht einfach dazu stehen kann sondern
sich irgendwelche Szenarien ausdenken muss wieso die eigene Lösung jetzt
unbedingt sein muss und man nicht die 0815-Distro-Lösung nutzen kann.
Le X. schrieb:> Unwürdig wirds erst wenn man da nicht einfach dazu stehen kann sondern> sich irgendwelche Szenarien ausdenken muss wieso die eigene Lösung jetzt> unbedingt sein muss und man nicht die 0815-Distro-Lösung nutzen kann.
So sehe ich das auch. Kann jeder machen, wie er denkt – aber dafür muss
man „das Andere“ nicht schlechtreden, um’s vor sich selbst zu
rechtfertigen.
Bauform B. schrieb:> Apropos Embedded: die meiste Zeit> habe ich mit PCs zu tun, die einfach ein- und ausgeschaltet werden wie> eine Schreibtischlampe. Daher kommt meine Vorliebe für kurze Bootzeiten> und tiefgreifende Eingriffe.
Sie haben da ’ne ziemlich coole Sache erfunden: Standby/Suspend. Man
braucht dafür nur eine Konfiguration zu ändern, und das Ding geht mit
Druck auf den Knopf in diesen Modus, und ist bei erneutem Druck nahezu
sofort (1…2s dauert’s meist, bis man weiterarbeiten kann) wieder da. Das
ist genau für solche Szenarien geeignet.
? DPA ? schrieb:> Das sind komplett verschiedene Dinge, und sie lösen das Problem von> Systemds Monotolitismus und binary unmodularität und daraus> resultierendem lock-in nicht:
Ich sehe weder einen "Monolitismus" noch eine "Binary-Unmodularität".
Alleine auf diesem System hier gibt es insgesamt 32 systemd-Binaries,
von denen jedes einzelne eine bestimmte und begrenzte Funktionalität
bietet. systemd hat das Designziel, verschiedene Funktionen unter Linux
zu vereinheitlichen und zu vernetzen, die früher über etliche Programme
und Pakete verteilt waren, die meisten davon eher schlecht als recht
vernetzt und verbunden, und jedes mit einem oder mehrereren eigenen
Formaten für Konfigurationen etc... In Grunde war das ein heilloses
Chaos und zweifelsohne auch einer der Gründe dafür, warum Linux in
einigen Kreisen bis heute den zweifelhaften Ruf genießt, übermäßig
kompliziert und unzugänglich zu sein.
Eine der wichtigsten Aufgaben guter Entwickler und Sysops ist doch
außerdem, auseinanderlaufende oder -gelaufene Dinge zu vereinheitlichen,
oder? Und nun beschwert Ihr Euch ganz genau darüber, daß jemand genau
das macht?
Dieses "Lock-in"-Argument erschließt sich mir aber am Allerwenigsten.
systemd ist OpenSource-Software und steht unter der LGPL. Man kann sich
also, wie bei jeder OpenSource-Software, den Quellcode herunterladen,
ihn verändern und neu übersetzen, dank Github einfach forken und
verändern, wie man mag und kann.
Software, die mit systemd kompatibel oder sogar davon abhängig ist, kann
man mit verschiedenen Distributionen benutzen, sogar über
Familiengrenzen hinweg, was mit SysV-Init leider nicht ohne Weiteres der
Fall war. Denn da boten die verschiedenen Distributionen jeweils
unterschiedliche Befehle und Standards für Init-Skripte -- sogar die
Orte, wo die Init-Scripte lagen, waren IIRC nicht einheitlich
(/etc/rc.d/ versus /etc/init.d/).
Und man kann immer noch Linux-Systeme ohne systemd betreiben -- das
Devuan GNU/Linux, über das hier diskutiert wird, aber auch Void, Source
Mage, Artix, Alpine, Gentoo, Knoppix, Mint, Mageia, Manjaro, openSuSE
und SLES, Debian und sogar CentOS können (meines Wissens) alle ohne
systemd laufen. Wo soll dabei bitte ein "Lock-In" sein? Daß man
bestimmte Software -- wie etwa GNOME -- anscheinend nicht ohne Weiteres
ohne systemd benutzen kann?
Man kann einen großen Teil der etablierten Linux-Softwarepakete auch
nicht ohne libc, libld, libselinux, ... benutzen. Diese oben angeführten
Aussagen, daß ausgerechnet libsystemd dabei ein übermäßig großes Problem
darstellen soll, ist also ebenfalls Humbug, denn haargnau dasselbe gilt
natürlich für alle diese Bibliotheken. Oer man müßte diesen angeblichen
"Lock-In" genauso auch auf die anderen Bibliotheken, und im Prinzip
sogar auf das gesamte GNU-Userland beklagen. Daß das immer wieder als
Argument gegen systemd genannt wird, riecht für mich daher sehr nach
einem reichlich krampfhaft anmutenden Versuch, Argumente gegen systemd
zu konstruieren.
Nebenbei bemerkt: wenn einige Entwickler wie zB die des GNOME-Projekts
ihre Software von systemd abhängig machen, dann ist das kein Problem von
oder mit systemd, sondern allerhöchstens eines von GNOME. Und wenn
jemand schon dazu bereit ist, seine Distribution zu wechseln, nur um den
schrecklichen Klauen des bösen systemd-Monsters zu entgehen, dann ist es
immer noch einfacher, auf ein anderes Desktop Environment zu wechseln,
den seine Entwickler nicht von systemd abhängig gemacht haben. FVWM2,
anyone? twm? :)
Andreas M. schrieb:> Wenn ich in meiner IT einen Mitarbeiter dafür abstelle, ein Kernelpaket> zu bauen, dieses regelmäßig zu aktualisieren und per lokalem> Paket-Repository (das es als Mirror und wegen spezifischer Software> sowieso gibt) zu verteilen, [...]
... dann, wie mir scheint, hast Du zuviel Geld oder zuwenig Arbeit.
Meine Admins würden mir mit dem entblößten Gesäß ins Gesicht springen,
die haben nämlich alle schon mehr als genug zu tun.
> Du vielleicht nicht, andere aber schon. Ich hab ein Problem damit das> einfach als "Gebastel" in die Ecke zustellen, weil das einfach nicht> stimmt.
Nach jedem Kernelupdate manuell Hand anlegen zu müssen, ist Bastelei, es
sei denn, die automatischen Updates würden nicht absolut reibungslos
funktionieren, und das schon seit Ewigkeiten. Jeder manuelle Eingriff
ist eine potentielle Fehlerquelle, und in einer professionellen IT ab
einer gewissen Größe entweder zu vermeiden oder zumindest zu
automatisieren. Und selbst dann ist die Automatisierung wieder eine
weitere Fehlerquelle, denn Komplexität ist der natürliche Feind von
Stabilität, Verläßlichkeit, und Systemsicherheit.
> Ich benutze schon immer selbst kompilierte Kernel und stell Dir vor, ich> habe mein System von Debian Jessie nach Devuan Ascii und zuletzt nach> Beowulf per dist-upgrade aktualisiert, ohne irgend ein Problem. Als ob> ein selbst kompilierter Kernel automatisch zu Upgrade Problemen führen> würde. Der Kernel ist das kleinste Problem bei einem Upgrade.
Du nutzt einen Beowulf-Cluster auf Deinem Desktop? Shiqq! ;-)
Sheeva P. schrieb:> Du nutzt einen Beowulf-Cluster auf Deinem Desktop? Shiqq!
… ich befürchte, damit ist nicht gemeint, was wir alten Leute bei
„Beowulf“ vor Augen haben …
Jack V. schrieb:> Sheeva P. schrieb:>> Du nutzt einen Beowulf-Cluster auf Deinem Desktop? Shiqq!>> … ich befürchte, damit ist nicht gemeint, was wir alten Leute bei> „Beowulf“ vor Augen haben …
Insgeheim vermute ich das zwar ebenfalls, aber... ich hab' ja auch ein
paar kleine Cluster mit Gearpump, Redis und Elasticsearch zuhause
laufen, wer weiß? ;-)
Karl Käfer schrieb:> systemd hat das Designziel, verschiedene Funktionen unter Linux zu> vereinheitlichen und zu vernetzen, die früher über etliche Programme und> Pakete verteilt waren, die meisten davon eher schlecht als recht> vernetzt und verbunden, und jedes mit einem oder mehrereren eigenen> Formaten für Konfigurationen etc...
Zumindest in meiner Zeit hat man als Inschenör gelernt, komplexe und
unübersichtliche Aufgaben und Problemstellungen in kleine, überschaubare
und modulare Teilaufgaben bzw. Teilprobleme zu zerlegen. Warum scheint
mir nur, daß es in heutiger Zeit immer schneller und weiter in die
falsche Richtung geht? Ein wahnhafter Drang zu zentralistischen Ansätzen
und Gigantomanie. Wir waren und sind Zeugen von schweren
Sicherheitsproblemen in überkomplexen Prozessorsystemen, die niemand
mehr überblickt.
Aktuell von heute: Was Security betrifft sind Bugs kein Feature, sondern
festes Programm:
https://www.heise.de/news/Unsicherer-Code-ist-die-Regel-nicht-die-Ausnahme-4865594.html
Zu systemd kenne ich noch jene Einschätzung:
https://www.danisch.de/blog/2018/07/10/systemd-war-eine-massive-fehlentscheidung/
Wir hatten auch schon an anderer Stelle die Diskussion zu den Segnungen
neuzeitlicher IT:
Beitrag "Wie sich die Zeiten ändern oder eine Schmährede auf neuzeitliche IT"
Die modernen Ansätze bringen allenfalls eine Verschlimmbesserung der
alten und oft ohnehin selber schon komplizierten Tools mit sich.
Andreas M. schrieb:> Und ich darf mich auch gleich als einer der ewig gestrigen outen, ich> bin nämlich einer der wenigen Devuan Maintainer....
Und für diesen großen Einsatz und deine Standhaftigkeit, dem
Zeitgeistwahn zu widerstehen, möchte ich dir danken. Verbrate bitte
nicht zu viel von deiner Energie hier in der Diskussion :)
Sheeva P. schrieb:> Aber dieser Mensch hat es geschafft, daß ich niemanden ernst nehme, der> ihn verlinkt.
Na das ist doch wunderbar. Darf man sich da jetzt einen Reim drauf
machen, wie die Diskussionskultur und der sachliche Umgang mit
kritikwürdigen Punkten, z.B. systemd oder sonstwas betreffend, in der
OSS Community so gehandhabt wird, wenn schon alte Hasen, wie du es
vorgibst zu sein, derart reagieren? "Mir paßt deine Auffassung zu Thema
XY nicht und und welcher Leute Meinung zu Fremdthemen du dir sonst noch
so anhörst, also kann ich dich nicht mehr ernst nehmen und das $PROJEKT
wird durchgezogen, wie ich es will, denn ich habe Recht. Punkt."
>> Wir hatten auch schon an anderer Stelle die Diskussion>> Du und ich? Sicher nicht.
Sorry, aber die Welt und das Forum hier drehen sich nicht nur permanent
um dich, auch wenn du denkst eine größere Nummer als andere zu sein.
Scheens WE z'samme :)
Club der toten Pferde schrieb:> Darf man sich da jetzt einen Reim drauf> machen, wie die Diskussionskultur und der sachliche Umgang mit> kritikwürdigen Punkten, z.B. systemd oder sonstwas betreffend, in der> OSS Community so gehandhabt wird, wenn schon alte Hasen, wie du es> vorgibst zu sein, derart reagieren?
Geht’s um den verlinkten Blogeintrag vom Danisch? Das ist keine Kritik,
das ist oberflächliches Gerante über Dinge, ohne mal genau hinzuschauen
– teils basierts schlicht auf falschen Annahmen. So dieser „alle doof,
nur ich hab den Durchblick.“-Stil, der tatsächlich nicht
diskussionswürdig ist, und daher auch keiner Diskussionskultur bedarf.
Jack V. schrieb:> So dieser „alle doof,> nur ich hab den Durchblick.“-Stil, der tatsächlich nicht> diskussionswürdig ist, und daher auch keiner> Diskussionskultur bedarf.
Interessant, wie du das siehst. Ist ja prinzipiell der gleiche Inhalt
wie hier schon an Kritik angeführt wurde. Soll doch jeder selber mal
lesen und beurteilen, ob es falsche Annahmen und oberflächliches Gerante
ist.
Danisch schrieb:
> Da haben sie richtig Mist gebaut.> […]> Dazu kommt, dass ich den starken Eindruck habe, dass die Leute bei> den Distributionen immer weniger Ahnung vom Fach haben und immer> öfter nicht mal mehr das Problem verstehen.
… und darüber möchtest du kultiviert diskutieren?
Jack V. schrieb:> … und darüber möchtest du kultiviert diskutieren?
Sorry, aber mit dir dann eher doch lieber nicht.
Du kennst seinen Bericht zu seinem Bug Report für den DisplayPort
Treiber unter Ubuntu, der von einem Release auf das nächste plötzlich
nicht mehr funktionierte und als nicht fixwürdig abgetan wurde?
Club der toten Pferde schrieb:> Du kennst seinen Bericht zu seinem Bug Report für den DisplayPort> Treiber unter Ubuntu, der von einem Release auf das nächste plötzlich> nicht mehr funktionierte und als nicht fixwürdig abgetan wurde?
Nein, kenne ich nicht. Aber wenn der in dem gleichen Stil verfasst
wurde, wie der verlinkte Blogeintrag, würde ich als Verantwortlicher den
Bug auch mit „wontfix“ schließen. Wenn’s bedeutsam ist, wird bestimmt
noch jemand ’nen vernünftigen Bugreport verfassen.
Hmmm schrieb:> Ansonsten findet man BSDs sowohl bei namhaften Unternehmen wie Netflix> als auch haufenweise in Appliances (IronPort, Juniper, NetApp etc.)
Opnsense und Pfsense nutzen auch ein BSD als OS.
Auf Servern sind BSDs auch verbreitet.
Jack V. schrieb:> Nein, kenne ich nicht. Aber wenn der in dem gleichen Stil verfasst> wurde, wie der verlinkte Blogeintrag, würde ich als Verantwortlicher den> Bug auch mit „wontfix“ schließen.
Darf jeder selber lesen und entscheiden:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1767993
Der Bug ist seit fast 2 1/2 Jahren offen.
Ja, ist okay. Bezeichnend, beispielhaft für den Stil:
> Are you just here to keep me busy with useless conversation?
Als Antwort auf einen Beitrag, der durchaus valide Punkte und Recherche
des Antwortenden erkennen lässt. Da hätte ich auch keinen Bock, mich mit
dem rumzuärgern. Wenn er alles besser weiß, soll er den Patch
fertigmachen und gut.
Club der toten Pferde schrieb:> Das beweist, daß du es genausowenig verstanden hast, weil nicht richtig> gelesen und darüber nachgedacht, wie der\die\das Antwortende.
Nein, sorry – wenn ich mir die Mühe machte, dem Fehler nachzugehen,
und dann so angegangen würde, wäre ich genauso raus. Und ich verstehe
jeden, der’s genauso hält. Zumal der Buntu-Bugtracker für das Problem eh
die falsche Anlaufstelle war, aber das hat Herr Danisch in seiner Hybris
offensichtlich nicht erkennen können.
So hat die Community noch nie funktioniert, selbst früher™ zu
Usenet-Zeiten nicht (und die Sitten dort würden manchem heutigen
Forenuser die Tränen in die Augen, wahlweise auch die Zornesröte ins
Gesicht, steigen lassen). Wer da mit diesem „ich weiß alles, und ihr
sollt mich nicht langweilen!“-Stil ankam, war direkt raus.
Club der toten Pferde schrieb:> Andreas M. schrieb:>> Und ich darf mich auch gleich als einer der ewig gestrigen outen, ich>> bin nämlich einer der wenigen Devuan Maintainer....> Und für diesen großen Einsatz und deine Standhaftigkeit, dem> Zeitgeistwahn zu widerstehen, möchte ich dir danken. Verbrate bitte> nicht zu viel von deiner Energie hier in der Diskussion :)
Hey, Danke! Und keine Sorge, fachliche Diskussionen gehören ja dazu und
den Rest lernt man zu ignorieren. Wir haben im Projekt dieses Jahr auch
ein bisschen Zuwachs bekommen, von daher bin ich da ganz guter Dinge.
Auch dadurch das bei Debian jetzt anscheinend bei immer mehr Paketen die
SysV Init Skripte verschwinden entscheiden sich immer mehr bei uns als
Maintainer beizutragen.
Club der toten Pferde schrieb:> Karl Käfer schrieb:>> systemd hat das Designziel, verschiedene Funktionen unter Linux zu>> vereinheitlichen und zu vernetzen, die früher über etliche Programme und>> Pakete verteilt waren, die meisten davon eher schlecht als recht>> vernetzt und verbunden, und jedes mit einem oder mehrereren eigenen>> Formaten für Konfigurationen etc...> Zumindest in meiner Zeit hat man als Inschenör gelernt, komplexe und> unübersichtliche Aufgaben und Problemstellungen in kleine, überschaubare> und modulare Teilaufgaben bzw. Teilprobleme zu zerlegen.
Offensichtlich haben die systemd-Entwickler das auch gelernt.
> Warum scheint> mir nur, daß es in heutiger Zeit immer schneller und weiter in die> falsche Richtung geht?
Weil Du anscheinend lieber dagegen bist als kompetent.
Club der toten Pferde schrieb:> Sheeva P. schrieb:>> Aber dieser Mensch hat es geschafft, daß ich niemanden ernst nehme, der>> ihn verlinkt.> Na das ist doch wunderbar. Darf man sich da jetzt einen Reim drauf> machen, wie die Diskussionskultur und der sachliche Umgang mit> kritikwürdigen Punkten, z.B. systemd oder sonstwas betreffend, in der> OSS Community so gehandhabt wird, wenn schon alte Hasen, wie du es> vorgibst zu sein, derart reagieren?
Zu meiner Zeit hat man schon als kleines Kind gelernt: wie man in den
Wald hinein ruft, so schallt es wieder heraus. Wer seine Anliegen und
"Aussagen" so ausdrückt wie dieser "Herr" und Kompetenz durch
Beleidigungen und Überheblichkeit ersetzt, verspielt jedes Recht auf
Anhörung und Beachtung. Entgegen anderslautender Gerüchte ist es nämlich
immer noch der Ton, der die Musik macht.
Zumal -- extra Dir zuliebe habe ich jetzt doch noch den "Artikel"
überflogen -- der "Herr" im Wesentlichen auf folgende Punkte
hinauslaufen:
1.) Herr Danisch weiß alles, und zwar vor allem besser.
2.) Herr Danisch hatte Probleme mit systemd.
3.) Aus den Punkten 1 und 2 folgt: systemd muß schlecht sein.
4.) systemd.resolved hat zwar eine Konfigurationsdatei (resolved.conf)
und sogar eine Manpage dazu (natürlich in Sektion 5), aber Herr
Danisch hat beide nicht gefunden und / oder nicht gelesen, goto
Punkt 1.
Daß es sich bei den Ausführungen dieses Herrn Danisch nicht um sachliche
Argumente, sondern um eine reine Meinungsäußerung handelt, könnte sogar
ein "Inschenör" wie Du erkennen. Immerhin garniert er seinen Rant mit
Formulierungen wie, ich zitiere "ich halte" (zweimal) und daß er einen
"starken Eindruck habe".
> "Mir paßt deine Auffassung zu Thema> XY nicht und und welcher Leute Meinung zu Fremdthemen du dir sonst noch> so anhörst, also kann ich dich nicht mehr ernst nehmen und das $PROJEKT> wird durchgezogen, wie ich es will, denn ich habe Recht. Punkt."
Es sind weniger die "Auffassungen" dieses Herrn zu irgendeinem Thema als
die Art, wie er sie zum Ausdruck bringt. Meine Lebenszeit ist mir zu
kostbar, um sie auf derartige Pöbler zu verschwenden, zumal wenn sie --
wie eben an seiner "Kritik" an systemd-resolved(8) auch noch ganz
offensichtlich inkompetent sind. Bereits ein sehr kurzer Blick auf die
Startseite seiner Website läßt sehr gut erkennen, wes Geistes Kind
dieser "Herr" ist und wie ernst man ihn nehmen darf.
In einem -- ansonsten nicht weniger obskuren -- "Wikimannia" wird Herr
Danisch allerdings mit den Worten zitiert: "[...] weil man mit Dreck
wirft, wenn einem sonst nichts mehr einfällt (oder noch nie etwas
eingefallen ist)". Möglicherweise sollte dieser "Herr" sich diese seine
Worte einmal selbst zu Herzen nehmen. An anderer Stelle schreibt Herr
Danisch darüber, wie schrecklich es sei, in dieser Gesellschaft leben zu
müssen, denn da sei "immer und überall irgendein Idiot, der sich anmaßt,
einen erziehen zu wollen". Nun, ich ganz persönlich kann dazu lediglich
vermuten, daß ich womöglich nicht der Einzige bin, der den Eindruck hat,
daß dieser "Herr" dringend ein bisschen von jender Erziehung braucht,
die einem üblicherweise die Eltern angedeihen lassen, womit sich dann
auch der Kreis zum ersten Ansatz dieses meines Beitrags schließt.
> Sorry, aber die Welt und das Forum hier drehen sich nicht nur permanent> um dich, auch wenn du denkst eine größere Nummer als andere zu sein.
Meine Güte... Du bist dieser Herr Danisch, kann das sein?
[Edit: Formatierung korrigiert.]
Sheeva P. schrieb:> extra Dir zuliebe habe ich jetzt doch noch den "Artikel" überflogen
Oh gnädigsten Dank!
> In einem -- ansonsten nicht weniger obskuren -- "Wikimannia"
Und dessen bedienst du dich wegen der Bugmeldung, die du offensichtlich
nichtmal verstanden hast?
> Meine Güte...
Ja genau. Einen hinreichenden Eindruck deiner Schaumschlägerei
hinsichtlich deiner Erfahrungen und Fähigkeiten konnte ich mir nun
verschaffen.
> Du bist dieser Herr Danisch, kann das sein?
Mitnichten.
Vielen Dank, daß du den Beweis deiner verstehenden Fähigkeiten selbst
erbracht hast. Wenn die Entwicklung bedeutender Systeme von solcherlei
Universalgenies abhängt stellen sich plötzlich weniger Fragen nach
gravierenden Fehlentscheidungen.
Sheeva P. schrieb:> Du bist dieser Herr Danisch, kann das sein?
Anhand der Reaktionen würde ich auch dazu tendieren. Ist genau die
gleiche Überheblichkeit ohne die notwendige Substanz, um’s
ernstzunehmen.
Nix für ungut – der Gaul ist tatsächlich tot.
Jack V. schrieb:> Anhand der Reaktionen würde ich auch dazu tendieren.
Meinst du wirklich, der hätte es notwendig und die Zeit dazu, sich
ausgerechnet in diesem Forum und speziell in diesem Thread
herumzutreiben und sich mit euch abzugeben? Ohje, wie groß denkst du
nur?
Ich hätte hier natürlich auch andere Quellen bringen können, nur war mir
diese schneller in Erinnerung, aber egal.
> Nix für ungut – der Gaul ist tatsächlich tot.
Nix für ungut - die wahren Experten haben sich hier die Ehre gegeben.
Danke für diese erhellende Erkenntnis großartigen Expertentums.
Jack V. schrieb:> Sheeva P. schrieb:>> Du bist dieser Herr Danisch, kann das sein?>> Anhand der Reaktionen würde ich auch dazu tendieren.
Gerade nach den letzten beiden "Beiträgen" vom Sauerbraten... Beispiel:
wußtest Du, daß dieser Herr Danisch viel zu wichtig ist, um Zeit für
Diskussionen seiner "Ideen" in diesem Forum zu haben? ;-)
> Ist genau die gleiche Überheblichkeit ohne die notwendige> Substanz, um’s ernstzunehmen.
Das ist ein Aspekt, ja. Linguistische Features sind ein anderer...
> Nix für ungut – der Gaul ist tatsächlich tot.
Naja... manchmal kann man "Diskussionen" gewinnen, indem man einfach das
größte und aggressivste Mundwerk hat. Ein intelligenter Mensch hätte
natürlich bemerkt, daß das hier nicht funktioniert. ;-)