Arch Linux

Neuerungen, systemd, KISS, sog. "Lennartware"…

agaida

Kleine Anmerkung zu syslinux und gfxboot. Für CDs ist das Klasse. Auf einem realen System hat das Imho wirklich nichts zu suchen. Aber auch das sehen einige Leute anders.

Dirk

Creshal schriebGenerell, die Abhängigkeitsauflösung erspart einem einiges an Ärger

Ich meine eher die Entwicklerabhängigkeit …

runiq

Aber ich bleibe dabei: Ein Logdaemon, und Berechtigungsverwaltung sollten in einem Init-System nichts zu suchen haben.

+1. :/

Creshal schriebGenerell, die Abhängigkeitsauflösung erspart einem einiges an Ärger

Etwas OT: Gibt es eigentlich eine ganz allgemeine Bibliothek, mit der Abhängigkeiten aufgelöst werden können? Ich hab mich grade ein bisschen durch libalpm geklickt, und es hat seine eigene Routine dafür. Ich nehme an, dass auch systemd da was eigenes benutzt, aber auf die Schnelle hab ich im Git-Repo nichts gefunden. Eine (zugegebenermaßen kurze) Google-Suche hat auch kein Ergebnis gebracht.

Letzten Endes ist es wahrscheinlich kein sonderlich kompliziertes Problem, wenn man sich mit Graphentheorie auskennt (was ich definitiv nicht tue), aber es wundert mich trotzdem, dass an dieser Stelle das Rad scheinbar immer wieder neu erfunden wird.

efreak4u

Creshal schrieb...
Aber ich bleibe dabei: Ein Logdaemon, und Berechtigungsverwaltung sollten in einem Init-System nichts zu suchen haben.
Full ack. 🙁

Den Logdaemon kann man abschalten... klappt das auch mit der Berechtigungsverwaltung?

open-source greg

Dirk Sohler schriebNa ja, du hast dann irgendwann die Wahl zwischen systemd und upstart

Upstart enthält aber nicht die Sachen mit denen einen Systemd aufgezwungen wird z.B. udev .

Was nimmt ubuntu eigentlich für udev, systemd-tools ?
Mit upstart wäre ich übrigens eher zufrieden als mit Systemd 🙂

@Creshal: sysvinit ist natürlich aus heutiger Sicht kein wirklich gutes Init-System mehr. Ich bin auch der Meinung das neue Init-Systeme hermüssen (welche mehrere Jobs parallel starten und Abhängigkeiten auflösen etc. ) , mir gefällt allerdings nicht was man bei Systemd noch alles dazukriegt.

Ich verstehe ausserdem nicht warum man eine Einheitliche Lösung für alle Distris haben muss. Letztendlich wird es immer unmöglich sein alle Linux nutzer mit einen Init-System zufriedenzustellen. Zum Beispiel konnte Arch lange Zeit mit seinen einfachen BSD scripten werben, während Ubuntu das mit seiner schnellen Bootzeit getan hat.
Ein Init-System ist zumindest nicht der Bestandteil eines Betriebssystems den jeder Nutzer von selbst austauchen will.

Dirk

open-source greg schriebZum Beispiel konnte Arch lange Zeit mit seinen einfachen BSD scripten werben, während Ubuntu das mit seiner schnellen Bootzeit getan hat.

Ja, inzwischen hat Arch nicht mehr viel, das als Alleinstellungsmerkmal gelten kann. Für alles, das mir spontan bei Arch neben Rolling Release einfällt, fallen mir entsprechende Techniken anderer Distributionen ein (bzw. Distributionen, die es genau so wie Arch lösen). Einzig die Tatsache, dass die meisten anderen Distributionen entweder sehr spezielle Anwendungsnischen haben, oder viel zu viel Bloat mitliefern, unterscheidet uns nicht mehr viel von anderen. Die Diversität geht leider immer mehr flöten.

agaida

Um mal auf einen ganz wesentlichen Punkt für mich zu kommen: Eigentlich ist es mir wurstegal, womit mein System startet. Es hat aber erst einmal zu funktionieren oder die Chance zum Funktionieren zu haben. Ich habe einfach keine Böcke darauf, was denn nun die schönere Krankheit ist, Beulenpest, Cholera oder meintewegen auch Vogelgrippe. Der einzige Einwand gegen "Lennartware" ist, dass das noch nicht mal Bananensoftware ist, wenn sie auf $user losgelassen wird.

Ein modernes Initsystem ist eine feine Sache, ein funktionierendes und gut dokumentiertes auch. Auch wenn ich Arch und Sid nutze, ab und zu will ich auch mal schmerzfrei damit arbeiten können. Wenn das so nicht vollständig möglich ist, dann will ich mir wenigstens die Schmerzen aussuchen können.

Army

@Dirk, was Arch ausmacht ist pacman, ABS und das AUR. Seh ich zumindest so. Wenn pacman mal ersetzt wird durch den lpm (lennart's package manager), dann bin ich weg, dann installier ich mir Windows 10, scheißegal.

efreak4u

Army schrieb... dann installier ich mir Windows 10, scheißegal.

Ob das eine Alternative ist? Im Prinzip hast du da ja das gleiche... Ich glaube, da ist das konservative BSD ein besserer Ersatz.

Ovion

efreak4u schriebIch glaube, da ist das konservative BSD ein besserer Ersatz.

ACK. Es wäre aber schon höchst ironisch, wenn der Herr "BSD-ist-tot" Pöttering BSD damit einen Nutzerboost bescheren würde...^^

EDIT: Wie sieht das eigentlich bei Gentoo mit einem möglichen Umstieg (als Standard) aus? Debian zögert, Fedora ist (natürlich), SuSE will oder ist, Ubuntu will nicht, nur bei Gentoo und Mageia finde ich nix dahingehend.

feuri

Gentoo nutzt ein eigenes init-System, OpenRC. Die wollten auch schonmal, dass das für Arch benutzt wird, gab dazu ne recht lange Diskussion auf der ML. Wenn ich den Link dazu wiederfinde, setz ich den hier rein.

Ovion

feuri schriebGentoo nutzt ein eigenes init-System, OpenRC. Die wollten auch schonmal, dass das für Arch benutzt wird, gab dazu ne recht lange Diskussion auf der ML. Wenn ich den Link dazu wiederfinde, setz ich den hier rein.

Und keine Avancen für systemd?

feuri

Systemd ist zwar unterstützt, aber Standard ist OpenRC. Mehr weiß ich auch nicht, ich nutz kein Gentoo.

Hier noch der Link zur Diskussion: http://mailman.archlinux.org/pipermail/arch-general/2012-April/026311.html

Dirk

Army schrieb@Dirk, was Arch ausmacht ist pacman, ABS und das AUR. Seh ich zumindest so.

Ich sehe da das Alleinstellungsmerkmal aber nicht so wirklich … Paketmanager; die Möglichkeit, Programme nach Vorgaben selbst zu bauen; und von Nutzern verwaltete Repos (wobei das AUr sich dank Yaourt & Co. zwar wie eines anfühlt, aber eigentlich keines ist) gibt es auch bei anderen Distributionen. Ich sehe bei Arch eher den Vorteil darin, dass die fast genau Pakete so in die Repos gehen, wie sie von Upstream kommen.

LongHairedHacker

Apropos Gentoo ...

Ich hab hier ja Freitag schon mit BSD und Gentoo geliebäugelt.
Allerding frage ich mich wenn Gentoo kein systemd einsetzt was ist dann mit udev ?
Wenn die beiden immer enger verbunden werden, müssten die dann auf udev verzichten und setzen wieder devfs ein ?
Es hieß ja mal das man udev weiterhin auch ohne systemd kompilieren können soll.
Stimmt https://lwn.net/Articles/490413/ so noch ?

Ich werde jedenfalls doch erstmal bei Arch bleiben, und mir systemd soweit möglich zurecht konfigurieren,
das es meinen Vorstellungen entspricht. (z.B. logs weiterhin mit syslog-ng)
Weil wer sagt das man die Sache nicht auch aus sitzen kann ?
Jetzt gibt es keine wirklich Alternative zu systemd, aber wenn so viele Leute mit der Architektur davon ein Problem haben,
wird früher oder später da jemand mit was ankommen, was mir mehr zusagt.
Ums auf den Punkt zu bringen : Gute Software ist für mich modular, mit geringen Abhängigkeiten zwischen Modulen. Starke Bindung, lose Kopplung.

Ich leg das ganze jetzt unter Software dich ich nicht unbedingt mag, um die man aber nicht einfach drum herum kommt ab.
Außerdem hab ich keine Lust mehr mich drüber auf zu regen.

Gruß
Sebastian

sven_s

Ja, es ist weiterhin moeglich udev ohne systemd einzusetzen.

Aber was ich dabei auch erfahren habe ist, das es wohl Plaene von KDE, GNOME und Xfce gibt einige Systemd API zu nutzen. Das waere dann wohl fuer ein voelliges Desaster fuer mich, da dann schon die DE mit dem Init-System verknuepft waere, da geht die Freiheit und die Modularitaet doch floeten.

Aber zum Glueck gibt es ja noch andere Init-Systeme und DE oder Window-Manager.

Quelle

mannohneschuh

Naja nur weil man in irgendeiner DE die API von irgendwo implementiert heißt das ja nicht das es ohne diese API nicht mehr geht. die größeren DEs werden sich hüten da sowas fest zu verdrahten.

Ovion

Nur so am Rande: wir Archer haben doch jetzt alle (sofern Nutzer der Initscripts oder gleich systemd) ein voll einsatzfähiges systemd auf der Platte, ohne Zusatzpakete installieren zu müssen, oder? Ob man das jetzt nutzt, steht auf 'nem anderen Blatt.

GerBra

jean-paul schrieb
GerBra schrieb Der Vorgang an sich zeigt microsoft'sche Tendenzen (Dominanz aufgrund Ausnutzung selbstgeschaffener Fakten, udev IST systemd). Somit für mich eine grobe Verletzung all dessen, was in vergangenen Zeiten ein GNU/Linux zu dem gemacht hat was es heute (noch) ist.
Da hast du absolut recht, NOCH.
Ich denke aber, Linux ist gerade dabei sich selbst zu zerlegen. Und am Ende ist es dann vorbei mit freier Auswahl.
Es wird dir von EINER Person vorgeschrieben, wie dein System aussieht. Lennart hat mehr als einmal klar geäußert, dass non-systemd Systeme für ihn keine Option sind.
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

Er wird bestimmen, wie dein System startet, was wie (und ob überhaupt) protokolliert wird, ob und wann du ins Internet gehst und ob zeitgesteuerte Prozesse laufen.
Nicht du bestimmst wann deine Hardware gemountet wird, sondern systemd.
Und ich befürchte, Lennart wird sein Ziel erreichen, dass auf jedem Linuxsystem sein systemd zu laufen hat.
Und am Ende wird es egal sein ob du Arch, Fedora, Suse, Magaia oder sonst was installierst. Alle Systeme werden gleich aussehen und gleich funktionieren.

Das ist mir ein bißchen zu sehr "Verschwörung" dabei, daß "zitierte Zitat" von L.P. würde ich so absolut nicht dafür hernehmen. "Userland" (inkl. init) ist ja zum Glück so ausgelegt, daß Alternativen möglich sind (erfordert halt abweichen vom Default, ergo Arbeit). Wo deine Gedanken aber IMHO wieder einen Sinn kriegen ist im Zusammenhang mit der (auch von mir angeführten) Art und Weise, wie - langfristig - so eine Situation entstehen konnte. Es begann ja schon mit dem Wechsel zu udev (über static dev hinzu devfs, dann udev). Und dieses "Killerfeature" von damals sehe ich heute nachträglich eher als Ursache für die jetzt - für mich - eher unbefriedigende Situation. udev ist in den initrd-Images mittlerweile quasi "unverzichtbar" (erinnert sich noch jemand an Zeiten als initrd-Images ausschließlich für Distributions-*INSTALL*-Kernel verwendet wurden?), und dieses udev ist nun mit einem bestimmten, fragwürdigen init-System verschmolzen und die separate Nutzung ist nicht langfristig gesichert.
Hier würde ich es zumindest begrüßen, wenn das Verfahren zur Kernel-/kernelmodul-Deviceerzeugung/verwaltung in den Händen der Kernelentwickler liegen würde (und evtl. doch wieder eine Mischung aus statischen Devicefiles und nach Bedarf dynamisch hinzugefügten). Das würde IMHO die Entwicklung im System-/Userland wieder wesentlich vielfältiger (und ggf. langfristig gesicherter) machen.

jean-paul schrieb
GerBra schrieb Solange ich noch meine Arbeit machen kann/muß (ein: pacman -S was-ich-gerade-brauche gibt es ja noch nicht…) wird *mir* das Drumherum zusehends egal.
So denken leider viel zu viele und das ist das Problem.

Ok, du hast ein Schäfchen vor dem Ertrinken gerettet ;-) Ich bin nochmal "in mir" gegangen und habe systemd als init wieder runtergeschmissen. Zählt mich wieder zu den "Verweigerern"! ;-) <g>

Wir haben das für Server (v.a. die Archlinux-Server) nochmal mit anderen diskutiert (alles etwas ältere Admins, wie ich auch <g>) und sehen wirklich keinen Vorteil jetzt etwas umzustellen (gerade auch wenn durch die Unzulänglichkeiten von SysVInit drumherum eine speziell auf die Gegebenheiten zugeschnittene "Toollandschaft" entstanden ist die systemd nicht oder nur mit Mühen(Arbeit) ersetzen könnte. Usus war auch, die aktuelle Entwicklung dieser Tendenzen im Zusammenhang mit systemd erstmal zu beobachten, wohin die Reise geht.

Man kann also die Archlinux-DEVs wirklich nur bitten/bestärken neben systemd - wie angekündigt - sysvinit doch gleichwertig weiterhin zu unterstützen und nicht (wenn sich alle an den Bootzeiten aufgegeilt haben) nächsten Monat ins AUR zu verschieben.

fs4000

GerBra schriebudev ist in den initrd-Images mittlerweile quasi "unverzichtbar"

Mit devtmpfs kann man da doch super drauf verzichten. Meine 4 Module lad ich einfach manuell: i915 sd_mod ahci ext4. Direkt danach kommt dann nur der Overhead von Plymouth. 😛

« Vorherige Seite Nächste Seite »