Forum: PC Hard- und Software Devuan ohne initrd?


von Bauform B. (bauformb)


Lesenswert?

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
9
the work!" Perens wrote. ®
https://www.theregister.com/2018/06/12/devuan_ascii_stable_ships/

von Jack V. (jackv)


Lesenswert?

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.

Beitrag #6357634 wurde von einem Moderator gelöscht.
von Hmmm (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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...

von Jack V. (jackv)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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...

von Christobal M. (c_m_1)


Lesenswert?

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?

von Jack V. (jackv)


Lesenswert?

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?

von Hmmm (Gast)


Lesenswert?

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...

von Jack V. (jackv)


Lesenswert?

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?

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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 ;)

von (prx) A. K. (prx)


Lesenswert?

Bauform B. schrieb:
> / auf LVM finde ich unangebracht.

Sehr nützlich. Weil mühelos bei Bedarf vergrösserbar, 
unterbrechungsfrei.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Club der toten Pferde (Gast)


Lesenswert?

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?

von Jemand (Gast)


Lesenswert?

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)

von Jack V. (jackv)


Lesenswert?

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?

von S. Ramon (Gast)


Lesenswert?

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.

von Netplan.YAML (Gast)


Lesenswert?

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?

von Jack V. (jackv)


Lesenswert?

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.

von Ralf D. (doeblitz)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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...

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von ? DPA ? (Gast)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

? 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!

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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.

Beitrag #6360090 wurde vom Autor gelöscht.
von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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...

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

? 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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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... ;-)

von Bauform B. (bauformb)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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]

von ? DPA ? (Gast)


Lesenswert?

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!

von Nano (Gast)


Lesenswert?

? DPA ? schrieb:
> und ich weiss, welche
> Zukunft ich anstrebe!

World domination

von Andreas M. (amesser)


Lesenswert?

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:
1
andi@bla:~$ sudo aptitude install task-gnome-desktop
2
Die folgenden NEUEN Pakete werden zusätzlich installiert:
3
aisleriot{a} argyll{a} argyll-ref{a} atril{a} atril-common{a} baobab{a} bolt{a} caribou{a} cheese{a} 
4
  chrome-gnome-shell{a} dconf-cli{a} dleyna-server{a} eog{a} espeak-ng-data{a} evince{a} evince-common{a} 
5
  evolution{a} evolution-common{a} evolution-data-server{a} evolution-data-server-common{a} 
6
....
7
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.

von Jack V. (jackv)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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!

von Bauform B. (bauformb)


Lesenswert?

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).

von Jack V. (jackv)


Lesenswert?

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“

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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?

von Andreas M. (amesser)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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?)

von Le X. (lex_91)


Lesenswert?

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).

von Andreas M. (amesser)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

: Bearbeitet durch User
von ? DPA ? (Gast)


Lesenswert?

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...).

von Jack V. (jackv)


Lesenswert?

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?

: Bearbeitet durch User
von ? DPA ? (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

? 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.

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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..

von Andreas M. (amesser)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von ? DPA ? (Gast)


Lesenswert?

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/

von Karl Käfer (Gast)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

? 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? :)

von Sheeva P. (sheevaplug)


Lesenswert?

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! ;-)

von Jack V. (jackv)


Lesenswert?

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 …

von Sheeva P. (sheevaplug)


Lesenswert?

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ß? ;-)

von Club der toten Pferde (Gast)


Lesenswert?

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 :)

von Sheeva P. (sheevaplug)


Lesenswert?

Club der toten Pferde schrieb:
> 
https://www.danisch.de/blog/2018/07/10/systemd-war-eine-massive-fehlentscheidung/

Vielen Dank, daß Du für mich gegoogelt hast. Aber dieser Mensch hat es 
geschafft, daß ich niemanden ernst nehme, der ihn verlinkt.

> Wir hatten auch schon an anderer Stelle die Diskussion

Du und ich? Sicher nicht.

Guten Tag.

von Club der toten Pferde (Gast)


Lesenswert?

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 :)

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von Club der toten Pferde (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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?

von Club der toten Pferde (Gast)


Lesenswert?

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?

von Jack V. (jackv)


Lesenswert?

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.

von TR.0LL (Gast)


Lesenswert?

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.

von Club der toten Pferde (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Club der toten Pferde (Gast)


Lesenswert?

Jack V. schrieb:
> 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.
Das beweist, daß du es genausowenig verstanden hast, weil nicht richtig 
gelesen und darüber nachgedacht, wie der\die\das Antwortende. Es zeigt 
(auch bei dir) den u.a. von Hadmut festgestellten Zustand der heutigen 
OS Community.

Wer es sich selber antun will, für den sind hier seine eigenen 
Erwähnungen dieses Vorgangs.
Wem das zu viel sein sollte : Bitte nicht lesen !
https://www.danisch.de/blog/2018/05/04/code-of-conduct/
https://www.danisch.de/blog/2018/09/17/die-zerlinksung-des-open-source-bereichs-erreicht-linux/
https://www.danisch.de/blog/2020/06/28/vom-verfall-der-informationstechnik/

von Jack V. (jackv)


Lesenswert?

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.

von Andreas M. (amesser)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.]

: Bearbeitet durch User
von Club der toten Pferde (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

: Bearbeitet durch User
von Club der toten Pferde (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.