Mir ist das letztlich egal, hauptsache es funktioniert.
Auf meinem Hauptsystem ist es RPM/zypper, auf den Raspis DEB/apt, hatte aber auch schon pacman-basierte Distributionen zum Test laufen. Am Ende ist das für mich sozusagen transparent, hauptsache ich kann meine Pakete installieren und die Abhängigkeiten werden vernünftig aufgelöst.
Das wollte ich auch gerade schreiben. Ein Paketsystem ist ein Paketsystem.
Wobei ich apt-* und yum/rpm lieber von der Kommandozeile nutze, während ich bei bei pacman die GUI-Alternativen bevorzuge. Ich finde pacman's Syntax nicht so intuitiv, wie die der anderen ...
Nachdem ich viele Paketsysteme durch habe, bin ich inzwischen bei etwas angekommen, von dem ich mir verspreche, daß es den Aufwand, in stark heterogenen Umgebungen deutlich verringert: Ravenports (http://www.ravenports.com/).
Es ermöglicht auf derzeit fünf Plattformen (DragonFlyBSD, FreeBSD, Linux, macOS, Solaris/Illumos) die gleichen Paketversionen mit dem gleichen Paketmanager zu installieren. Es ist noch recht jung, funktioniert aber schon ausgezeichnet. Natürlich gibt es mit gut 3.000 Paketen noch ziemlich viel Software, die fehlt. Aber es bringt zumindest mir erheblich viel mehr Spaß, dafür Pakete zu bauen als für alle anderen Systeme, mit denen ich es früher getan habe. Auch wenn es in Zukunft das offizielle Paketsystem von dfly werden soll und daher schon ziemlich sicher feststeht, daß es nicht einfach wieder verschwindet, hat es zur Zeit noch recht wenige Nutzer. Insbesondere einige Linuxer wären mehr als willkommen, wenn jemand etwas Lust hat zu experimentieren.
Nun, nicht ganz. Man kann die Pakete leicht selbst aus den Quellen bauen (mittels "ravenadm"), man muß aber nicht. Nach dem Bootstrap des Paketmanagers (derzeit ausschließlich "pkg", potentiell können aber weitere hinzugefügt werden) auf der jeweiligen Plattform können einfach Binärpakete installiert werden.
Grundsätzlich ist das System darauf ausgelegt, daß die meisten die Pakete nicht selbst bauen müssen. Die Konfiguration der Quellen erfolgt deutlich weniger feinkörnig als etwa unter Gentoo, mit dem Ziel, über sogenannte "variant packages" unterschiedliche Anwendungsfälle abzudecken. Beispiel: "vim" (Langschreibweise: "vim:standard") ist ein für die meisten Leute richtig konfiguriertes Kommandozeilen-Vim, statt dessen könnte man auch "vim:loaded" installieren, welches viel mehr Features einkompiliert. Weitere Varianten können leicht hinzugefügt werden, wenn sich ein sinnvoller Anwendungsfall auftut (vielleicht :minimal oder etwas ähnliches). Außerdem werden "subpackages" unterstützt, so daß Dokumentation, Lokalisierung, etwaige GTK- oder Qt-Unterstützung modular mitinstalliert werden können oder auch nicht.
Pakete selbst bauen sollten eigentlich nur Entwickler oder Leute, die spezielle Anforderungen haben (OpenSSL statt LibreSSL, anderer Prefix (z.B. /opt statt /raven) usw.).
Außerdem macht "nur ein Ports-Manager" das System auch sonst kleiner, als es ist. Einige Ports lehnen sich mehr oder weniger an das jeweilige FreeBSD-Gegenstück an - alle Ports sind aber eigenständig und spezifisch für Raven unter Berücksichtigung mehrerer Plattformen geschrieben und mit plattformspezifischen Patches versorgt. In Raven stecken jahrelange Planung und viel Herzblut von einem Entwickler, der in der Vergangenheit mit zahlreichen Paketierungssystemen Erfahrung gesammelt hat und (nicht übertrieben sondern wörtlich gemeint) Maintainer für mehrere tausend Pakete gewesen ist.
Ich verwende am liebsten pacman oder yaourt weil ich mir bei den anderen nie die Syntax merken kann. Beruflich habe ich aber auch mit yum und apt zu tun (mit Spickzettel )
Ich finde es relativ egal wie das Paket verschnürt wurde, das Frontend macht den Komfort aus. So empfinde ich Yum als sehr mächtig, obwohl ich zu RH ein gespaltenes Verhältnis habe.
Beruflich muss ich mehrere Unix- und Linux-Systeme administrieren. Gerade im wissenschaftlichen Bereich sind RPM-Systeme dominierend. Aber auch wenn YUM nicht schwach ist, bleibt Portage mein Favorit.
Portage ist IMHO um einiges übersichlticher als DPKG, APT, YUM, YAST,Pacman &co.. Portage ist transparenter und die Bedienung gut strukturiert. Besonders in Bezug der Flexibilität (durch versch. SLOTs und USE-flags) schaft es portage, dass man jederzeit den Ueberblick behaelt. Dies gilt auch wenn man die versch. Stabilitätsgrade vermischt Zusammen mit EIX und Zubehör wie revdep-rebuild (gentoolkit) etc finde ich es unschlagbar. revdep-rebuild prüft Dependencies und kann sie sogar wieder reparieren.
... welches mir nicht das ganze System mit Abhängigkeiten vollmüllt, welche gar nicht gebraucht werden. Welches außerdem ein simples Buildsystem mitbringt, um Pakete neu zu bauen und ein darauf aufbauendes ports-artiges System, welches aktiv von der Community gepflegt wird.
Das alles bietet mir Slackware mit slackbuilds.org und sbopkg.
Nach Deiner Beschreibung zu folgern wünschst Du Dir Portage. Die ersten 4Buchstaben dieses Paketmanagers sind nicht frei erfunden ;-) Das Aufräumen der "Abhängigkeiten-Hölle" erledigt ein emerge --depclean und ggf. hilft Dir revdep-rebuild (falls mal was kaputt gegangen ist) und EIX hilft Dir eine Configuration aufzuräumen ;
Also wenn man schon nach Paketmanagern fragt, dann sollten auch innovative Neulinge berücksichtigt werden.
Auch wenn ich mit Nixos noch nicht ganz warm geworden bin, gefällt mir deren Paketmanagement und damit Nix sehr gut. Unter Nixos kann man damit als Nutzer und auch als root Pakete installieren. Es gibt keine unauflösbaren Abhängigkeiten und man kann jederzeit einen Rollback zu älteren Installationsständen machen. Man kann Nix auch zusätzlich zu anderen Paketmanagern auf anderen Distributionen nutzen.
Meiner Meinung nach machen die da sehr viel richtig, allerdings verträgt sich der Ansatz nicht mit dem FHS.
Ich bin Anwender und finde, dass Linux das anwenderfreundlichste Betriebssystem ist.
Deshalb habe ich nur Linux-Distributionen, die anwenderfreundlich sind und mich mit so einer Frage wie Paketformat nicht belästigen, ich klicke im Anwendungs-Store (oder wie das Ding auch immer heissen mag) und ich habe die Anwendung die ich will. Punkt
Dinge wie Paketformat interessieren mich nicht, ich verwende abwechselnd und auf den 10 verschiedenen Computern meiner Familie Mint, Unbuntu und OpenSuse und hier finde dich DEB, RPM und manchmal auch ein neues Paketformat.
Und was soll ich sagen, meine Distribution löst für mich das Problem der Auswahl. Ich klicke und erhalte die gewünschte Anwendung.
Somit ist mir das Paketformat echt nicht wichtig! So soll Linux sein.
Für die anderen, die mehr wollen, die dürfen sich gerne einen Kopf über diese Frage machen, ich nicht.
Ich benutze seit Jahren APT per apt-* unter Debian bzw. Devuan und kann mich kaum beklagen.
Allerdings erscheint mir das .deb-Paketformat vergleichsweise kompliziert. Als ich vor einiger Zeit ein angepasstes Paket eines Fenstermanagers bauen wollte, das eine aktualisierte deutsche Übersetzung enthält, bin ich auf Debian komplett gescheitert. Auf Slackware hatte ich die Sache dagegen in recht kurzer Zeit zusammen – und das, obwohl ich mich mit Slackware kaum auskenne und nicht wie bei Debian schon so einige Stunden damit zugebracht hatte, das Paketformat zu verstehen.
Sehr gute Erfahrungen habe ich kürzlich mit den apk tools von Alpine Linux[1] gemacht. apk ist nicht nur besser strukturiert als apt-* (ein Hauptkommando mit Unterbefehlen, statt mehrere), sondern auch viel schneller. Neben Alpine wird apk auch von Adélie Linux[2] eingesetzt.
Von Der Lucky aus Kentucky am Sa, 10. November 2018 um 18:42 #
Versuch es mal mit CheckInstall, einfacher geht es kaum. CheckInstall funktioniert auch mit .rpm und .tgz und ist ideal für den Hausgebrauch, wenn man das Paket nicht weitergibt. Das Debian-Wiki beschreibt den Paketbau recht anschaulich. Das Beispiel dort lässt sich 1:1 auf dein Szenario übertragen.
APT wurde doch auch mittlerweile überarbeitet, du musst nicht mehr "apt-get update && apt-cache search foo" verwenden, sondern nur noch "apt update && apt search foo". Ganz nebenbei ist die Ausgabe auch noch etwas schicker geworden.
Apk finde ich aber auch in ordnung, eigentlich funktionieren die meisten Paketmanager ganz ordentlich. Bei den Paketformaten würde Vereinheitlichung aber wirklich mal etwas bringen, zumindest sofern auch die Dateisystemstrukturen und Paketnamen angeglichen würden. Ich tu mich immer wieder schwer zwischen z.B. Debian und RedHat zu wechseln.
APT wurde doch auch mittlerweile überarbeitet, du musst nicht mehr "apt-get update && apt-cache search foo" verwenden, sondern nur noch "apt update && apt search foo". Ganz nebenbei ist die Ausgabe auch noch etwas schicker geworden.
Ja, ist mir bekannt und hätte ich mit erwähnen sollen. Auch aptitude funktioniert ja bereits so. Um Missverständnisse zu vermeiden, sollte man aber noch dazusagen, dass apt nicht eine neue Version von apt-* ist, sondern eine separate Implementierung eines vereinfachten APT-Frontends.
Wenn Sie die Wahl haben, welches Paketverwaltungssystem favorisieren Sie? Eine solche Umfrage ist sinnfrei. Weil die wenigsten werden alle der dort Aufgelisteten kennen. Daher mischt sich da sehr viel rein, wie oft bestimmte Paketformate verwendet werden.
Außerdem ist es weniger interessant zu wissen, welches Paketformat verwendet wird, sondern warum sich genau für dieses entschieden wird. Zum Glück sind genau darauf die User im Kommentarbereich eingegangen. Insofern betrachte ich jetzt die Umfrage einfach als Aufhänger, um sich darüber auszutauschen.
Von Port-Porta_Westfalica-Portage am Mo, 12. November 2018 um 10:20 #
Danke für den Tip. xbps kannte ich nicht, nach der Lektüre der Website: ...kann Binärpakete aus dem Quellcode compilieren und installieren, aber auch aus dem Repositorium herunterladen. Es besteht auch die Möglichkeit der Cross-Compilierung...
Funktioniert ähnlich wie Homebrew, oder Ports, oder Portage, aber:
...ist kompatibel mit dem POSIX/SUSv2/C99 Standards
Von Verfluchtnochmal-05995bd7b am Fr, 23. November 2018 um 16:22 #
Vielleicht bist du einfach nur zu blöde deine Systeme zu optimieren!
Ich fahre hier eine fast 8 Jahre alte Kiste und das booten bis zum grafischen Login dauert exakt 14 Sekunden inkl. 5 virtueller Maschinen, 2 MySQL-Instanzen und einem Haufen anderem Server/Netzwerkzeugs
Als das RAID10 noch SSD's waren hat es 30 Seunden gedauert
+1
Portage & Gentoo
Hauptsache Zypper findet es ;o))
Mir ist das letztlich egal, hauptsache es funktioniert.
Auf meinem Hauptsystem ist es RPM/zypper, auf den Raspis DEB/apt, hatte aber auch schon pacman-basierte Distributionen zum Test laufen.
Am Ende ist das für mich sozusagen transparent, hauptsache ich kann meine Pakete installieren und die Abhängigkeiten werden vernünftig aufgelöst.
Das wollte ich auch gerade schreiben. Ein Paketsystem ist ein Paketsystem.
Wobei ich apt-* und yum/rpm lieber von der Kommandozeile nutze, während ich bei bei pacman die GUI-Alternativen bevorzuge. Ich finde pacman's Syntax nicht so intuitiv, wie die der anderen ...
Nachdem ich viele Paketsysteme durch habe, bin ich inzwischen bei etwas angekommen, von dem ich mir verspreche, daß es den Aufwand, in stark heterogenen Umgebungen deutlich verringert: Ravenports (http://www.ravenports.com/).
Es ermöglicht auf derzeit fünf Plattformen (DragonFlyBSD, FreeBSD, Linux, macOS, Solaris/Illumos) die gleichen Paketversionen mit dem gleichen Paketmanager zu installieren. Es ist noch recht jung, funktioniert aber schon ausgezeichnet. Natürlich gibt es mit gut 3.000 Paketen noch ziemlich viel Software, die fehlt. Aber es bringt zumindest mir erheblich viel mehr Spaß, dafür Pakete zu bauen als für alle anderen Systeme, mit denen ich es früher getan habe. Auch wenn es in Zukunft das offizielle Paketsystem von dfly werden soll und daher schon ziemlich sicher feststeht, daß es nicht einfach wieder verschwindet, hat es zur Zeit noch recht wenige Nutzer. Insbesondere einige Linuxer wären mehr als willkommen, wenn jemand etwas Lust hat zu experimentieren.
Das System ist einfach nur ein Ports-Manager für verschiedene Plattformen. Die Pakete werden immer aus den Quellen gebaut.
Da kann ich persönlich darauf verzichten.
Nun, nicht ganz. Man kann die Pakete leicht selbst aus den Quellen bauen (mittels "ravenadm"), man muß aber nicht. Nach dem Bootstrap des Paketmanagers (derzeit ausschließlich "pkg", potentiell können aber weitere hinzugefügt werden) auf der jeweiligen Plattform können einfach Binärpakete installiert werden.
Grundsätzlich ist das System darauf ausgelegt, daß die meisten die Pakete nicht selbst bauen müssen. Die Konfiguration der Quellen erfolgt deutlich weniger feinkörnig als etwa unter Gentoo, mit dem Ziel, über sogenannte "variant packages" unterschiedliche Anwendungsfälle abzudecken. Beispiel: "vim" (Langschreibweise: "vim:standard") ist ein für die meisten Leute richtig konfiguriertes Kommandozeilen-Vim, statt dessen könnte man auch "vim:loaded" installieren, welches viel mehr Features einkompiliert. Weitere Varianten können leicht hinzugefügt werden, wenn sich ein sinnvoller Anwendungsfall auftut (vielleicht :minimal oder etwas ähnliches). Außerdem werden "subpackages" unterstützt, so daß Dokumentation, Lokalisierung, etwaige GTK- oder Qt-Unterstützung modular mitinstalliert werden können oder auch nicht.
Pakete selbst bauen sollten eigentlich nur Entwickler oder Leute, die spezielle Anforderungen haben (OpenSSL statt LibreSSL, anderer Prefix (z.B. /opt statt /raven) usw.).
Außerdem macht "nur ein Ports-Manager" das System auch sonst kleiner, als es ist. Einige Ports lehnen sich mehr oder weniger an das jeweilige FreeBSD-Gegenstück an - alle Ports sind aber eigenständig und spezifisch für Raven unter Berücksichtigung mehrerer Plattformen geschrieben und mit plattformspezifischen Patches versorgt. In Raven stecken jahrelange Planung und viel Herzblut von einem Entwickler, der in der Vergangenheit mit zahlreichen Paketierungssystemen Erfahrung gesammelt hat und (nicht übertrieben sondern wörtlich gemeint) Maintainer für mehrere tausend Pakete gewesen ist.
Für mich ist eindeutig das *.deb Format am besten. Synaptic, gdebi oder auch mal die Anwendungsverwaltung. Je nach dem, es funktioniert.
Ich verwende am liebsten pacman oder yaourt weil ich mir bei den anderen nie die Syntax merken kann.
Beruflich habe ich aber auch mit yum und apt zu tun (mit Spickzettel )
Ich auch. Mit pacman und yaourt hatte bisher auch im Vergleich zu anderen Paketmanagern die wenigsten Probleme zu beklagen.
Interessant! Bei mir ist es eher anders herum. ich kann mit den teilweise unsinnigen Option von pacman & yaourt nix anfangen.
Ich würde aber einfach mal behaupten, das liegt einfach daran, das du mehr mit dem Arch-System arbeitest.
Ich finde es relativ egal wie das Paket verschnürt wurde, das Frontend macht den Komfort aus. So empfinde ich Yum als sehr mächtig, obwohl ich zu RH ein gespaltenes Verhältnis habe.
Beruflich muss ich mehrere Unix- und Linux-Systeme administrieren. Gerade im wissenschaftlichen Bereich sind RPM-Systeme dominierend. Aber auch wenn YUM nicht schwach ist, bleibt Portage mein Favorit.
Portage ist IMHO um einiges übersichlticher als DPKG, APT, YUM, YAST,Pacman &co..
Portage ist transparenter und die Bedienung gut strukturiert.
Besonders in Bezug der Flexibilität (durch versch. SLOTs und USE-flags) schaft es portage, dass man jederzeit den Ueberblick behaelt. Dies gilt auch wenn man die versch. Stabilitätsgrade vermischt
Zusammen mit EIX und Zubehör wie revdep-rebuild (gentoolkit) etc finde ich es unschlagbar. revdep-rebuild prüft Dependencies und kann sie sogar wieder reparieren.
... welches mir nicht das ganze System mit Abhängigkeiten vollmüllt, welche gar nicht gebraucht werden. Welches außerdem ein simples Buildsystem mitbringt, um Pakete neu zu bauen und ein darauf aufbauendes ports-artiges System, welches aktiv von der Community gepflegt wird.
Das alles bietet mir Slackware mit slackbuilds.org und sbopkg.
Nach Deiner Beschreibung zu folgern wünschst Du Dir Portage.
Die ersten 4Buchstaben dieses Paketmanagers sind nicht frei erfunden ;-)
Das Aufräumen der "Abhängigkeiten-Hölle" erledigt ein emerge --depclean und ggf. hilft Dir revdep-rebuild (falls mal was kaputt gegangen ist) und EIX hilft Dir eine Configuration aufzuräumen ;
Also wenn man schon nach Paketmanagern fragt, dann sollten auch innovative Neulinge berücksichtigt werden.
Auch wenn ich mit Nixos noch nicht ganz warm geworden bin, gefällt mir deren Paketmanagement und damit Nix sehr gut. Unter Nixos kann man damit als Nutzer und auch als root Pakete installieren. Es gibt keine unauflösbaren Abhängigkeiten und man kann jederzeit einen Rollback zu älteren Installationsständen machen. Man kann Nix auch zusätzlich zu anderen Paketmanagern auf anderen Distributionen nutzen.
Meiner Meinung nach machen die da sehr viel richtig, allerdings verträgt sich der Ansatz nicht mit dem FHS.
Ich bin Anwender und finde, dass Linux das anwenderfreundlichste Betriebssystem ist.
Deshalb habe ich nur Linux-Distributionen, die anwenderfreundlich sind und mich mit so einer Frage wie Paketformat nicht belästigen, ich klicke im Anwendungs-Store (oder wie das Ding auch immer heissen mag) und ich habe die Anwendung die ich will. Punkt
Dinge wie Paketformat interessieren mich nicht, ich verwende abwechselnd und auf den 10 verschiedenen Computern meiner Familie Mint, Unbuntu und OpenSuse und hier finde dich DEB, RPM und manchmal auch ein neues Paketformat.
Und was soll ich sagen, meine Distribution löst für mich das Problem der Auswahl. Ich klicke und erhalte die gewünschte Anwendung.
Somit ist mir das Paketformat echt nicht wichtig! So soll Linux sein.
Für die anderen, die mehr wollen, die dürfen sich gerne einen Kopf über diese Frage machen, ich nicht.
Ich benutze seit Jahren APT per apt-* unter Debian bzw. Devuan und kann mich kaum beklagen.
Allerdings erscheint mir das .deb-Paketformat vergleichsweise kompliziert. Als ich vor einiger Zeit ein angepasstes Paket eines Fenstermanagers bauen wollte, das eine aktualisierte deutsche Übersetzung enthält, bin ich auf Debian komplett gescheitert. Auf Slackware hatte ich die Sache dagegen in recht kurzer Zeit zusammen – und das, obwohl ich mich mit Slackware kaum auskenne und nicht wie bei Debian schon so einige Stunden damit zugebracht hatte, das Paketformat zu verstehen.
Sehr gute Erfahrungen habe ich kürzlich mit den apk tools von Alpine Linux[1] gemacht. apk ist nicht nur besser strukturiert als apt-* (ein Hauptkommando mit Unterbefehlen, statt mehrere), sondern auch viel schneller. Neben Alpine wird apk auch von Adélie Linux[2] eingesetzt.
[1] https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management, https://dockercon.docker.com/watch/6nK1TVGjuTpFfnZNKEjCEr (ab 5:24)
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Nov 2018 um 17:21.[2] https://adelielinux.org
Versuch es mal mit CheckInstall, einfacher geht es kaum. CheckInstall funktioniert auch mit .rpm und .tgz und ist ideal für den Hausgebrauch, wenn man das Paket nicht weitergibt. Das Debian-Wiki beschreibt den Paketbau recht anschaulich. Das Beispiel dort lässt sich 1:1 auf dein Szenario übertragen.
Kann apt-get nach fast 30 Jahren schon ein Paket-Downgrade?
Oder muss man immer noch alles weg werfen wenn die Paket-Daten-Bank defekt ist?
APT wurde doch auch mittlerweile überarbeitet, du musst nicht mehr "apt-get update && apt-cache search foo" verwenden, sondern nur noch "apt update && apt search foo". Ganz nebenbei ist die Ausgabe auch noch etwas schicker geworden.
Apk finde ich aber auch in ordnung, eigentlich funktionieren die meisten Paketmanager ganz ordentlich. Bei den Paketformaten würde Vereinheitlichung aber wirklich mal etwas bringen, zumindest sofern auch die Dateisystemstrukturen und Paketnamen angeglichen würden. Ich tu mich immer wieder schwer zwischen z.B. Debian und RedHat zu wechseln.
Ja, ist mir bekannt und hätte ich mit erwähnen sollen. Auch
aptitude
funktioniert ja bereits so. Um Missverständnisse zu vermeiden, sollte man aber noch dazusagen, dassapt
nicht eine neue Version vonapt-*
ist, sondern eine separate Implementierung eines vereinfachten APT-Frontends.Im Normalfall Debian.
Für Software zum Testen oder neue Versionen sehr gerne Appimage
AppImage ist ja nicht unbedingt ein Paketsystem. Es ist ja nur ein Containerformat für Software.
Wenn Sie die Wahl haben, welches Paketverwaltungssystem favorisieren Sie?
Eine solche Umfrage ist sinnfrei. Weil die wenigsten werden alle der dort Aufgelisteten kennen. Daher mischt sich da sehr viel rein, wie oft bestimmte Paketformate verwendet werden.
Außerdem ist es weniger interessant zu wissen, welches Paketformat verwendet wird, sondern warum sich genau für dieses entschieden wird.
Zum Glück sind genau darauf die User im Kommentarbereich eingegangen.
Insofern betrachte ich jetzt die Umfrage einfach als Aufhänger, um sich darüber auszutauschen.
http://www.strcat.de/eigenes/xbps.html
Danke für den Tip. xbps kannte ich nicht, nach der Lektüre der Website:
...kann Binärpakete aus dem Quellcode compilieren und installieren, aber auch aus dem Repositorium herunterladen. Es besteht auch die Möglichkeit der Cross-Compilierung...
Funktioniert ähnlich wie Homebrew, oder Ports, oder Portage, aber:
...ist kompatibel mit dem POSIX/SUSv2/C99 Standards
Das ist eine gute Sache.
Und das Void als unabhängige Linux Distri dazu.
https://voidlinux.org/
Kein systemd und solch'n Kram, dadurch sauschnell, unkompliziert und stabil.
So wie Linux eben sein sollte.
Aha systemd macht Maschinen langsam und instabil?
Selten so einen Müll gelesen
Ach nee, Fanboy aus dem Delirium aufgewacht?
Nach so langer Zeit auf Schnee von Gestern zu antworten ist schon was.
Hast Du denn schon mal was Anderes probiert?
Oder redest Du nur Müll weil der Tag so lang ist und Du sonst nichts produktives zu tun hast?
Dann probiere mal VOID auf einer alten Kiste mit HDD und nehme irgendwas mit systemd auf einer nagelneuen irgendwas Core-Kiste mit SSD und staune.
Und dann darfst Dich wieder melden, denn vorher ist alles nur gelaber.
Vielleicht bist du einfach nur zu blöde deine Systeme zu optimieren!
Ich fahre hier eine fast 8 Jahre alte Kiste und das booten bis zum grafischen Login dauert exakt 14 Sekunden inkl. 5 virtueller Maschinen, 2 MySQL-Instanzen und einem Haufen anderem Server/Netzwerkzeugs
Als das RAID10 noch SSD's waren hat es 30 Seunden gedauert
So und jetzt du!
Bevor Du Dich lächerlich und zum Affen machst, schon mal das Andere probiert??
Vermutlich nicht!
Darum behalte Deinen Quatsch für Dich und kontaminiere damit nicht deine Umwelt!
Es ist schon so was von traurig mit den ganzen systemd Fanboys.
Haben die Alle eine Gehirnwäsche bekommen?
kommt mir vor wie bei M$ und Apple.
Übrigens, Dein Diskussions-Niveau entspricht genau dem der Initiatoren deines favorisiertem Init-Systems.
Liegt da was im Sourcecode versteckt?
Auf
Niveau
wird
geschissen
....dem gibt es nichts weiter hinzuzufügen!