News Obarun: Arch Linux ohne Systemd als Schweizer Taschenmesser

SV3N

Redakteur
Teammitglied
Dabei seit
Juni 2007
Beiträge
17.413

Termy

Lt. Commander
Dabei seit
Mai 2007
Beiträge
1.843
Nach Auffassung der Obarun-Entwickler arbeitet die S6 Supervision Suite effizienter, stabiler, transparenter und offener als das komplexe Systemd und richtet sich deshalb eher nach den traditionellen Grundsätzen von Unix, GNU und Linux sowie freier Software.
Ich halte die extreme Kritik an systemd zwar großteils für maßlos überzogen und hatte bisher eigentlich nie Probleme damit, aber grade die Komplexität des inzwischen sehr umfangreichen systemd macht sich dann doch immer mal wieder in den gefixten Sicherheitslücken bemerkbar.
Vom Artix-Wiki her scheint das Service-Management von s6 ja bedienungstechnisch ähnlich komfortabel wie bei systemd zu sein, bleibt also primär der Nachteil, dass die wenigsten Projekte, die systemd-service-files mitbringen auch s6-bundles haben 🤔
Klingt aber auf jeden Fall nach ner ausprobierenswürdigen Distro :D
 

SV3N

Redakteur
Ersteller dieses Themas
Teammitglied
Dabei seit
Juni 2007
Beiträge
17.413
Ich stimme dir da zu @Termy und finde, in Sachen Systemd wird nichts so heiß gegessen wie’s gekocht wird.

Viel diskutiert wird aber über das Thema noch immer. Ich hatte in der Hinsicht aber ebenfalls noch nie Probleme.
 

gaelic

Lt. Commander
Dabei seit
Mai 2017
Beiträge
1.437
Kann nur zustimmen. Meine Erfahrung mit Kritik an systemd (vor allem z.b. auf heise.de):

a) Kritik an der Person Poettering (zum Teil sicher zu Recht), hat aber quasi nichts mit systemd direkt zu tun.
b) andere "Projekte" Poetterings werden in die Sache gezogen, z.b. pulseaudio
c) falsche Kritik ala: systemd ist monolithisch, systemd widerspricht dem unix Prinzip (was auch immer dieser Mythos sein soll), etc.
d) Kritik an angeblich unzulänglicher Umsetzung von Features (die es anderswo gar nicht gibt), Stichwort: default compile time fallback google DNS
 

pseudopseudonym

Commodore
Dabei seit
Mai 2017
Beiträge
5.023
@Termy @gaelic
Dazu kommt auch noch, dass ich mir ne fertige Distro suche, um mich nicht um jeden Furz selbst kümmern zu müssen. Mir doch egal, wie genau mein System initialisiert wird, solange es zuverlässig und sicher funktioniert.
 

shinXdxd

Lt. Junior Grade
Dabei seit
Feb. 2018
Beiträge
299
Obarun kann ich nicht empfehlen. Die verwenden alle arch-Pakete und da kann es schon mal passieren das sich Pakete aufgrund von systemd-Abhänigkeiten nicht installieren lassen. Ganz irrsinnig ist die Abhängigkeit vom Chromium Browser, denn der funktioniert auch ohne systemd.
Wer arch ohne systemd will dem kann ich Artix empfehlen.
 

ModellbahnerTT

Lt. Commander
Dabei seit
Jan. 2010
Beiträge
1.197

Miuwa

Captain
Dabei seit
Dez. 2011
Beiträge
3.468
Ist das den DEs eigentlich egal, ob Systemd läuft oder müssen die inzwischen für non-systemd Systeme extra angepasst werden?
 
Zuletzt bearbeitet:

aki

~amd64
Moderator
Dabei seit
Feb. 2002
Beiträge
3.715
Mittlerweile muss man einen Umweg gehen, da immer mehr DEs zumindest auf einen Teil von systemd setzen. Deshalb wurde elogind als eigenständiges Paket eingeführt. Das betrifft unter anderem KDE und Gnome.
 

Caramon2

Cadet 4th Year
Dabei seit
Jan. 2004
Beiträge
90
Obarun kann ich nicht empfehlen. Die verwenden alle arch-Pakete und da kann es schon mal passieren das sich Pakete aufgrund von systemd-Abhänigkeiten nicht installieren lassen. Ganz irrsinnig ist die Abhängigkeit vom Chromium Browser, denn der funktioniert auch ohne systemd.
Danke, gut zu wissen.

Bei mir hatte sich Obarun letztes Jahr schon disqualifiziert, da es sich nicht in KVM booten ließ. - Genauso übrigens wie Artix-S6, also scheint es daran zu liegen.

Bei Artix nutze ich Runit, da OpenRC den Bug hatte, dass man in Grub zwar der Rescue-Mode einrichten ließ, es aber trotzdem ins GUI bootete: Nutze den Rescue-Mode oft, da ich mit mehreren Distributionen auf diversen PCs (nativ und in der VM) jongliere und z. B. nicht erst bis ins GUI booten möchte, wenn ich nur ein "update-grub" oder "mkinitcpio -P" ausführen will.

Inzwischen würde ich sowieso Runit bevorzugen, da es für mich am direktesten ist: Man sieht und versteht auf dem ersten Blick, was man macht. Ganz anders als diese kryptischen systemd-Befehl, wo man vorher nicht weiß, was der bewirkt und man anschließend nicht sieht, was alles wo verändert wurde: Was hat das noch mit "Linux" zu tun? Und erst recht mit KISS?
 

Caramon2

Cadet 4th Year
Dabei seit
Jan. 2004
Beiträge
90
Linux ist für mich ein effizientes und effizient zu konfigurierendes Betriebssystem.

Würde ich wollen, dass die eigentlichen Vorgänge mutwillig vor mir verschleiert/verborgen werden, würde ich weiter Windows nutzen.
 

andy_m4

Commodore
Dabei seit
Aug. 2015
Beiträge
4.114
Linux ist für mich ein effizientes und effizient zu konfigurierendes Betriebssystem.
Das ist es doch schon lange nicht mehr. Die ganzen Dinge die Einzug gehalten haben wie dbus, SELinux, PulseAudio, polkit usw. usw. usw.
systemd ist da letztlich nur ne Fortführung dessen, was im Linux-Ökosystem schon Jahrelang vonstatten geht.

Würde ich wollen, dass die eigentlichen Vorgänge mutwillig vor mir verschleiert/verborgen werden, würde ich weiter Windows nutzen.
Kaum ein Linux-Nutzer durchblickt noch, was da "unter der Haube" geschieht wenn wir mal ehrlich sind.
 

Caramon2

Cadet 4th Year
Dabei seit
Jan. 2004
Beiträge
90
Kaum ein Linux-Nutzer durchblickt noch, was da "unter der Haube" geschieht wenn wir mal ehrlich sind.
Genau deshalb beschäftige ich mich mit Linux: Ich will lernen.

Ich habe schon viel gelernt, aber es ist noch lange kein Ende abzusehen. - Der Weg ist für mich das Ziel.

Wenn ich alles über Linux wüsste, wäre es ja langweilig. ;-)
 

andy_m4

Commodore
Dabei seit
Aug. 2015
Beiträge
4.114
Genau deshalb beschäftige ich mich mit Linux: Ich will lernen.
Dabei ging es mir weniger um "nicht wollen", sondern "nicht können". Weil die Komplexität einen Level erreicht hat, wo das in vernünftigen Zeitrahmen gar nicht mehr leistbar ist.
Hinzu kommt noch die linux-typische Volatilität. Was Du heute lernst ist innerhalb weniger Jahre schon veraltet. Du hast also das Problem neben echtem neuen Wissen auch stets bereits erworbenes Wissen wieder auffrischen zu müssen weil sich soviel geändert hat (klar; Fortschritt bringt natürlich auch Veränderungen aber häufig fragt man sich schon bei vielen Sachen, was diese oder jene Änderung jetzt soll weil kaum wirkliche Verbesserung zu erkennen ist).

Linux ist da immer noch im Vorteil sein gegenüber Windows was die Einblicksmöglichkeiten angeht. Aber man sollte sich nicht der Illusion hingeben a-la "Linux ist Open-Source und wenn man nur will, dann kann man alles durchschauen" und das KISS heute noch die zentrale Rolle spielt.
 

_roman_

Cadet 2nd Year
Dabei seit
Aug. 2021
Beiträge
30
Dabei ging es mir weniger um "nicht wollen", sondern "nicht können". Weil die Komplexität einen Level erreicht hat, wo das in vernünftigen Zeitrahmen gar nicht mehr leistbar ist.
Hinzu kommt noch die linux-typische Volatilität. Was Du heute lernst ist innerhalb weniger Jahre schon veraltet. Du hast also das Problem neben echtem neuen Wissen auch stets bereits erworbenes Wissen wieder auffrischen zu müssen weil sich soviel geändert hat

Da bin ich anderer Meinung. Meine GNU/linux Installation ist jetzt 14 oder 15 Jahre alt.
Gewisse Dinge muss man halt nicht verwenden wenn man sich nicht die Arbeit antun will. Ich will kein systemd lernen, ich brauche auch kein KDE oder gnome. (Ich habe jahrelang Kde3 und gnome 2.xx verwendet.)

Man muss sich halt eine flexible Distribution suchen dann hat man all diese Probleme nicht wie: Man muss etwas neues lernen, das Wissen ist veraltet. Es hat sich so viel geändert. Viele diese Änderungen lässte eine flexible Distribution zu den alten Zustand beizubehalten.


Der file hierarchy standard(kurz FHS) ist immer noch gleich, wobei jetzt der Schwachsinn beginnt alles in ~/.config zu verstecken. Beispiel mc. systemd wenn ich es richtig verstanden habe hält sich nicht mehr an den FHS. Es reicht schon einen zusätzlichen Unterordner in /etc oder ~.

openrc ist schon länger am Markt und es gab keine Änderungen.
graphische terminals bzw. bash ist auch noch immer gleich.
Ich investiere 10 Minuten pro Woche um meine GNU Linux installation aktuell zu halten. Die erste Platform war ein MSI barebone mit einem Turion MT-32 wo ich diese Installation aufgesetzt habe.

Da sich Dinge ängern aufgrund anderer config files wegen upstream, muss man halt etwas ändern. Aber dies ist keine Distro Problem sondern ein upstream Problem. Oft kann man den alten Zustand beibehalten wenn man die richtige Distribution verewendet.

ich verwende immer noch ifconfig und lehne das ip tool ab. Da müsste ich nochmals die Syntax lernen.
Ich verwende immer noch die alten Netzwerknamen wie eth0 oder wlan0. Da müsste ich mal das neuere System durchschauen bzw. lernen.

Der einzig große Brocken an Zeitaufwand in den letzten 5 Jahre war der wechsel zu lvm2+luks+adaptiertes initramfs. Da habe ich auch die Backupstrategie abgeändert.

Die startscripts welche ich verwende kann ich lesen und sinnerfassen nachvollziehen falls es mal Probleme gab. Meine Desktop environment hat ein handverfasstes Script. Die Aussage man kann es heutzutage nicht nachvollziehen was eine gnu linux distro tut kann ich nicht verstehen. Auch kann ich sehr oft aber nicht immer sinnerfassend compiler fehler lesen und beheben.

--

Ich wollte auf freebsd und slackware wechseln. Da kannst dann ricthig viel Zeit versenken alles neu zu erlernen.

Aber man kann es wenn man sich 1x die Arbeit antut eine ordentliche Distro zu suchen und eine ordentliche Installation durchzuführen. Und da rede ich nicht von einer Linux mint installation oder von einer Windows 10 installation mit allen optionen.
 

andy_m4

Commodore
Dabei seit
Aug. 2015
Beiträge
4.114
Gewisse Dinge muss man halt nicht verwenden wenn man sich nicht die Arbeit antun will. Ich will kein systemd lernen, ich brauche auch kein KDE oder gnome. (Ich habe jahrelang Kde3 und gnome 2.xx verwendet.)
Gut. Wenn Du nur den Kernel und die Bash verwendest, dann sind die Änderungen sicher überschaubarer. Nur ist das halt kein Maßstab für irgendwas.

Da sich Dinge ängern aufgrund anderer config files wegen upstream, muss man halt etwas ändern. Aber dies ist keine Distro Problem sondern ein upstream Problem.
Ist doch egal, wo die Ursache liegt. Entscheidend ist doch, was beim Anwender ankommt. Und selbst die konservativste Distribution kann sich dem nicht verschließen. Klar kann man hier und da was regeln. Aber Distributoren sind in erster Linie immer noch Leute die vorhandene Software einsammeln und daraus ein Gesamtsystem stricken. Die sind also ganz natürlicherweise von dem abhängig, was sie geliefert kriegen.

Klar kann man an als Distribution an der ein oder anderen Stelle was drehen, um gewisse Dinge abzumildern. Schlussendlich kommt man an vielen Sachen eben nicht vorbei.

Ich wollte auf freebsd und slackware wechseln. Da kannst dann ricthig viel Zeit versenken alles neu zu erlernen.
Wobei gerade FreeBSD ein gutes Beispiel dafür ist, das Wissen eben durchaus über längere Zeit stabil sein kann. Ganz frei von der Entwicklung können die sich natürlich auch nicht sprechen, weil halt auch hier viel von außen reingetragen wird weil Du am Ende des Tages ja kein System zum Selbstzweck betreibst, sondern halt auch Applikationen hast die Du darauf laufen lassen willst.

Viele Sachen entwickeln sich dort eher evolutionär. Selbst das ifconfig (um das Beispiel von Dir mal aufzugreifen) ist dort (wie schon seit Jahrzehnten) fester Bestandteil und wurde halt nach und nach ergänzt statt einfach etwas Neues zu basteln.

Das soll jetzt kein Schubs in die Richtung FreeBSD sein. Aber solche Systeme zeigen halt auch, das es anders geht. Wobei man fairerweise dazu sagen muss, das die halt auch anders organisiert sind. Da liegt quasi das gesamte Projekt in einer Hand und es ist nicht wie bei Linux, wo es ja im Prinzip alles nur Einzelprojekte sind aus denen dann durch die Distributoren versucht wird ein Gesamtsystem zu basteln.

Aber man kann es wenn man sich 1x die Arbeit antut eine ordentliche Distro zu suchen und eine ordentliche Installation durchzuführen.
Ich mach jetzt seit Mitte der 90er Jahren Linux-Kram und bilde mir einfach mal ein, das ich zumindest ungefähr weiß, wovon ich rede. :-)
 

Caramon2

Cadet 4th Year
Dabei seit
Jan. 2004
Beiträge
90
Ich denke ihr habe beide Recht: Zwei Seiten der selben Medaille. Bei Linux hat man ja freie Hand.

Für mich gilt, Stillstand ist Rückschritt und bin neuem gegenüber aufgeschlossen: Ist es gut, übernehme ich es, ansonsten sehe ich mich nach Alternativen um.

Manche bevorzugen z. B. vollständig ausgestattete Distributionen, während ich so zugemüllte Systeme grauenhaft finde: Ich will nur das haben, was ist brauche: Was man nicht hat, macht keine Probleme und kostet weder Zeit noch Platz bei Aktualisierung und Sicherung.

Deshalb würde ich Artix gerne per Terminal installieren, aber deren Beschreibung ist für mich zum Teil noch unverständlich und es gibt auch so noch viel zu entdecken (s. u.), dass ich mich damit nicht noch weiter verzetteln will: Alles zu seiner Zeit…

Meine Grundkonfiguration von LinuxMint 18.3 Xfce (das habe ich bis Februar genutzt, weil es mir ab LM 19 zu systemd-lastig und immer vermurkster wurde - Btw: Es war sehr angenehm, nicht mehr alle 6 Monate eine neue Version zu installieren, weshalb ich jetzt nur noch rolling Releases nutze/empfehle.) enthielt u. a. das (da ich viel mit Wildcards usw. gearbeitet habe, wurde in Wirklichkeit noch viel mehr entfernt):
Code:
apt purge memtest* virtualbox* openoffice* friendly* xfce4-{task*,screen*} ufw* intel* {red,time}shift* nvidia* radeon* fortune* adobe* metacity* compton compiz* libdec* catfish mint{-art,-back,-theme,-x,-y,wel,back,inst,stick}* xorg* xfburn xplay* libxplay* cheese* pix* evolut* hexchat* pidgin* rhyth* librhyth* tomboy btrfs* hfs* jfs* liblvm* reiser* brltty* liblouis* cari* onboard* bluez* ifuse usbmux* aspell* myspell-* wamerican* wswiss* mythes-{de-ch,en,fr,it,ru}* hunspell-{de-{ch,at},en,ru,it,fr}* hyphen-{en,fr,it,ru}* language-pack-en* libreoffice-help-{en,ru,zh,fr,es,it,pt}* libreoffice-l10n-{en,es,fr,it,pt,ru,zh}*
Nach "apt autoremove --purge" waren die Installation ca. 1,8 GiB "leichter": Diesen ganzen Müll wollte ich keinesfalls die ganze Zeit mitschleppen.

Runit hat den großen Vorteil, dass es nicht als Wolleiermilchsau konzipiert ist: Es ist schlank, übersichtlich und sehr leicht nachvollziebar. Es ist schon seit Jahren ausgereift, es ändert sich nichts gravierendes mehr und in der ganzen Zeit seiner Existenz gab es nur eine einzige Sicherheitslücke, die gleich gefixt wurde. (es gibt eine Seite, wo man das (afair CVE-Nummern, oder so) nachsehen kann, aber den Link habe ich nicht mehr)

Z. B. habe ich erst vor ein paar Wochen entdeckt, dass es bei Artix auch eine "universe"-Paketquelle gibt, die man aber manuell nachtragen muss. Dort gibt es u. a. eine einfache Methode zRAM einzurichten (vorher habe ich das mit fester Größe über die rc.local gemacht), was ich neulich für Bekannte dokumentiert habe:
Das wird dazu gefunden (nur das relevante):

---
$ pacman -Ss zram
universe/zramen 0.2.1-1
Manage zram swap space
universe/zramen-runit 0.2.1-1
runit script for zramen
---

Aufgrund der Abhängigkeit brauche ich nur das *-runit installieren (wobei die Anleitung zur Installation gleich mitgeliefert wird):

---
$ sudo pacman -S zramen-runit
Abhängigkeiten werden aufgelöst …
Nach in Konflikt stehenden Paketen wird gesucht …

Paket (2) Neue Version Netto-Veränderung Größe des Downloads

universe/zramen 0.2.1-1 0,01 MiB 0,00 MiB
universe/zramen-runit 0.2.1-1 0,00 MiB 0,00 MiB

Gesamtgröße des Downloads: 0,01 MiB
Gesamtgröße der installierten Pakete: 0,01 MiB

:: Installation fortsetzen? [J/n]
:: Pakete werden empfangen …
zramen-0.2.1-1-any 4,3 KiB 4,32 KiB/s 00:01 [############################################] 100%
zramen-runit-0.2.1-1-any 2,4 KiB 2,04 KiB/s 00:01 [############################################] 100%
Gesamt (2/2) 6,7 KiB 5,01 KiB/s 00:01 [############################################] 100%
(2/2) Schlüssel im Schlüsselbund werden geprüft [############################################] 100%
(2/2) Paket-Integrität wird überprüft [############################################] 100%
(2/2) Paket-Dateien werden geladen [############################################] 100%
(2/2) Auf Dateikonflikte wird geprüft [############################################] 100%
(2/2) Verfügbarer Festplattenspeicher wird ermittelt [############################################] 100%
:: Paketänderungen werden verarbeitet …
(1/2) Installation läuft zramen [############################################] 100%
(2/2) Installation läuft zramen-runit [############################################] 100%
:: Post-transaction-Hooks werden gestartet …
(1/1) Displaying runit service help ...
==> Add a service:
ln -s /etc/runit/sv/<service> /run/runit/service/
==> Start/stop/restart a service:
sv <start/stop/restart> <service>
---

Da einfach nur der Pfad verlinkt wird, kann man sich leicht anzeigen lassen was gemacht wird:

---
$ head /etc/runit/sv/zramen/*
==> /etc/runit/sv/zramen/conf <==
#export ZRAM_COMP_ALGORITHM='lz4'
#export ZRAM_PRIORITY=32767
#export ZRAM_SIZE=25
#export ZRAM_STREAMS=1

==> /etc/runit/sv/zramen/finish <==
#!/bin/sh
zramen toss

==> /etc/runit/sv/zramen/run <==
#!/bin/sh
[ -r ./conf ] && . ./conf
zramen make
exec pause
---

Da mir 25% zu wenig sind, ändere ich es auf 100% und auch gleich auf zStd und eine "schönere" Priorität:

$ sudo nano /etc/runit/sv/zramen/conf

---
export ZRAM_COMP_ALGORITHM='zstd'
export ZRAM_PRIORITY=100
export ZRAM_SIZE=100
#export ZRAM_STREAMS=1
---

Ich "aktiviere" den Dienst:

---
$ sudo ln -s /etc/runit/sv/zramen/ /run/runit/service/
$ sudo sv start zramen
ok: run: zramen: (pid 4436) 0s
----

Und kontrolliere es:

---
$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 15,6G 0B 100
---

Da dort der Kompressionsalgomyles nicht gezeigt wird, musste ich erst suchen:

---
$ find /sys/ -iname zram0
/sys/class/block/zram0
/sys/devices/virtual/block/zram0
/sys/block/zram0
---

Wobei ich mich für den letzten Treffer entschieden und es aufs relevante eingeschränkt habe:

---
$ head /sys/block/zram0/comp_
==> /sys/block/zram0/comp_algorithm <==
lzo lzo-rle lz4 lz4hc 842 [zstd]

==> /sys/block/zram0/max_comp_streams <==
8
---

Passt. :-)

===================================

Für die Standardeinstellungen würde also das reichen:

---
sudo pacman -S zramen-runit
sudo ln -s /etc/runit/sv/zramen/ /run/runit/service/
sudo sv start zramen
---

Aber:

- 25% sind Qutasch, da das selbst mit lz4 auf ca. 1/3 komprimiert werden soll: Also bei 100% würde selbst bei bis zum Anschlag vollen zRAM nur 1/3 des RAMs genutzt. - Empfohlen werden sogar bis zu 200%, habe ich damals gelesen, als ich mich über zRAM informiert habe.

- die Priorität 100 ist rein kosmetisch und vollkommen ausreichend, da standardmäßig (Swap-Partition/-Datei) -1 verwendet wird.

- zstd komprimiert langsamer aber effektiver (4 GHz AMD FX-8350 ohne Turbocore, da spannungsoptimiert):

---
zstd -b test.tar
3#test.tar : 255887360 -> 107719068 (2.376), 128.2 MB/s , 551.9 MB/s

lz4 -b test.tar
1#test.tar : 255887360 -> 148817847 (1.719), 354.4 MB/s ,2186.8 MB/s
---

Wichtig: Die Benches liefen nur mit einem Thread, während zRAM alle Kerne nutzt (s. o.: "max_comp_streams").

"test.tar" war das unkomprimierte "google-chrome-92.0.4515.159-1-x86_64.pkg.tar.zst" - In wie weit das mit dem vergleichbar ist, das im zRAM landet, weiß ich nicht.
/usr/bin/zramen ist auch nur ein Skript, da zRAM ja Teil des Kernel ist. Das werde ich mir irgendwann genauer ansehen, weil es mich interessiert, wie man in einem Skript die RAM-Größe ermittelt.

Aus gleichem Grund werde ich mir auch irgendwann das ventoy-Skript genauer ansehen, weil ich wissen will, wie man die Größe eines Datenträgers ermittelt und durch das AUR kann ich mir abgucken, wie man z. B. ein .deb in ein Pacman-Paket konvertiert, wie man kompiliert und vieles mehr.

Aber das ist noch auf unbestimmbar verschoben, da es bei Artix so schon sehr viel zu entdecken und ausprobieren gibt, dass ich mich schon ziemlich verzettelt habe:

Ich bin noch immer keine saubere Installation angegangen und nutze inzwischen meine Artix Testinstallation als Produktivsystem: Ich habe letzten Februar Artix-Mate-Runit installiert und auf Xfce umgebastelt, da es damals noch keine Xfce-Version gab. Aber obwohl ich damit schon wirklich viel ausprobiert und getestet habe und sie eigentlich total verkonfiguriert sein müsste *), läuft sie immer noch wie frisch installiert. - Da ich eine Neuinstallation schon mehrfach angegangen bin, habe ich den direkten Vergleich. Aber da die Testinstallation noch so gut läuft und ich immer wieder was neues entdecke und ausprobiere, verwerfe ich es dann wieder.

*) in BS kaputt-optimieren bin ich sehr gut: Wie soll man die Grenzen ermitteln, wenn man sie nicht überschreitet? ;-)

Zur Sicherung nutze ich "rsync -vaxH", mehrstufig per Hardlinks (--link-dest=).

Außerdem habe ich eine Kopie meines Produktivsystems auf einer ext. SSD (mit per LUKS verschlüsselter Home-Partition, da die auch Kontoauszüge usw. enthält), um es überall booten zu können, um dort auch meine gewohnten Tools und Arbeitsumgebung zu haben: Vorbei ist die Zeit, dass wenn ein Bekannter Probleme hat, ich sagen musste "Zuhause könnte ich…", weil ihm benötigte Tools fehlen oder sein PC nicht mal mehr bootet. :-)

Gruß,

Andreas
 

andy_m4

Commodore
Dabei seit
Aug. 2015
Beiträge
4.114
Für mich gilt, Stillstand ist Rückschritt
Kann man so sehen. Wobei es auch Dinge gibt die ausentwickelt sind und wo zumindest kaum noch was hinzu kommt. Und dann gibts natürlich auch noch den Fortschritt um des Fortschritts willen, wo zwar etwas anders gemacht wird und von mir aus punktuell sogar besser aber man letztlich nur alte Probleme gegen Neue tauscht.

Und im Linux-Ökosystem herrscht halt so eine gewisse Geschäftigkeit. Es gibt so eine Tendenz die sich ablesen lässt. Sobald irgendwas fertig ist und einen ausgereiften Zustand erreicht hat und gut funktioniert, wird angefangen sich mit dem Nachfolger zu beschäftigen. So hast Du eigentlich nie irgendwie ein stabilen Zustand weil es ist immer eine Baustelle.
Gut. Das ist jetzt sehr überspitzt formuliert und gilt sicher nicht überall. Aber eine Grundtendenz ist das schon. Und aus Entwicklersicht ist das auch total nachvollziehbar. Für viele Entwickler ist es halt spannender an was Neuem zu arbeiten als irgendwie alte Sachen zu pflegen. Man darf nicht vergessen. Der Open-Source-Bereich wird immer noch von sehr vielen Freiwilligen getragen. Und wenn man etwas freiwillig tut, sucht man sich natürlich eher Aufgaben, die einem Spaß machen.

Linux hatte vom Start weg eher so den Charakter einer Spielwiese. Ein Umfeld in dem sich Nerds austoben können. Inzwischen ist Linux im Business angekommen und man ist dann natürlich auch seriöser geworden bzw. wurden dann halt unliebsame Aufgaben auch von bezahlten Entwicklern erledigt. Aber der Grundtenor ist halt doch noch ziemlich stark von diesem Spielwiesencharakter bestimmt.

Ich möchte das auch gar nicht werten in gut oder schlecht. Aber es lässt sich nicht von der Hand weisen, das es so ist.

Runit hat den großen Vorteil, dass es nicht als Wolleiermilchsau konzipiert ist: Es ist schlank, übersichtlich und sehr leicht nachvollziebar.
Ich glaube, ein eher modularer Ansatz hätte auch systemd gutgetan. Möglichst viel zu wollen ist eines der größten Problem von systemd.

Es ist schon seit Jahren ausgereift, es ändert sich nichts gravierendes mehr
Wie? Ich denke Stillstand ist Rückschritt? :-)

Aber das ist noch auf unbestimmbar verschoben, da es bei Artix so schon sehr viel zu entdecken und ausprobieren gibt, dass ich mich schon ziemlich verzettelt habe
Ich bin ja immer kein Freund von diesen abgeleiteten Distributionen. Wenn, dann nehme ich lieber das Original. Als im Falle von Artix halt Arch Linux. Und insbesondere in Deinem Fall, wo Du ja viel lernen möchtest, wäre Arch Linux doch eigentlich besser. Weil die sind ziemlich gut dokumentiert.

Ich kenne jetzt Artix-Linux nicht. Gut möglich, das es da ähnlich ist (und man auch weite Teile der Arch Doku übernehmen kann) und das der ausschlaggebende Punkt für Dich war, das es besser darin ist alternative Init-Systeme zu unterstützen.


in BS kaputt-optimieren bin ich sehr gut: Wie soll man die Grenzen ermitteln, wenn man sie nicht überschreitet? ;-)
Im Idealfall fummelt man ja auch nicht einfach an irgendwelchen Einstellungen rum und guckt was passiert, sondern liest die Doku und weiß dann auch welche Änderung welches Ergebnis bringt. Aber ich verstehe, was Du meinst. :-)

Wie dem auch sei: Danke für den umfangreichen Einblick in Deine persönliche Artix-Welt.
 

Caramon2

Cadet 4th Year
Dabei seit
Jan. 2004
Beiträge
90
Und dann gibts natürlich auch noch den Fortschritt um des Fortschritts willen, wo zwar etwas anders gemacht wird und von mir aus punktuell sogar besser aber man letztlich nur alte Probleme gegen Neue tauscht.
Ich bastle auch ständig an meinen Systemen: Einerseits bin ich in solchen Sachen etwas perfektionistisch und will es bestmöglich haben, andererseits aber auch, weil ich so auf neue Ideen und Ansatzpunkte komme, die dann zu wirklichen Verbesserungen führen. - Besonders durch meinen Vater habe ich gelernt vieles zu hinterfragen und anders zu sehen, da er oft Probleme mit für mich schon lange Selbstverständliches hatte: Statt "das ist eben so", überlege ich jetzt eher "muss das wirklich so sein".

Z. B. den Doppelklick: Wie oft wird der nicht angenommen, weil die Maus währenddessen leicht verrutscht (besonders bei meinem Vater)? - Also wozu überhaupt einen Doppelklick? In Menüs, Schnellstart, Links im Browser und vor allen bei Handys und Tablets wird alles mit einem Klick/Tipp gestartet/geöffnet, wieso muss also auf dem PC-Desktop da unbedingt ein Doppelklick dazu nötig sein?

Nachdem ich das bei Linux und Windows abgeschaltet habe, kann ich *) damit viel flüssiger arbeiten. - Bei Solus hat das übrigens auch jemand erkannt, da es inzwischen standardmäßig keinen Doppelklick mehr nutzt.

*) nach erstaunlich kurzer Eingewöhnung, da ich es ja von Handy, Tablet, Menüs, Browser, usw. schon lange gewohnt war
Wie? Ich denke Stillstand ist Rückschritt? :-)
Ein weiser Mann hat mal gesagt: "Wobei es auch Dinge gibt die ausentwickelt sind und wo zumindest kaum noch was hinzu kommt." ;-)

Ein Init-System sollte nur ein Init-System sein: Praktisch die Tür zum OS.

Eine Tür öffne ich vorzugsweise mit einem einfachen, seit Jahrhunderten bewährten Türdrücker und nicht mit einem verschnörkelten, mit haufenweise unnützen Firlefanz behängten und kaum noch handhabbaren Mode-Accessoire.

Klar, Otto Normalo bekommt davon nichts mit, Hauptsache das BS bootet, aber wenn ich z. B. das regelmäßige trimmen nicht mehr per "mv /etc/cron.weekly/fstrim /etc/cron.daily" von wöchentlich auf täglich ändern kann, sondern sogar Google brauche, um herauszufinden, ob überhaupt noch getrimmt wird und das dann aufwändig in einer tief im System versteckten Textdatei ändern muss, hört es für mich auf. - Das war bei LinuxMint 18.3->19.

Übrigens: Als ich mich mit Solus beschäftigt habe, wollte ich das auf die für LM 19 ermittelte Art ändern, aber da musste ich erst wieder suchen, da die Textdatei an anderer Stelle versteckt war: Das ich also noch nicht mal einheitlich!
Ich bin ja immer kein Freund von diesen abgeleiteten Distributionen. Wenn, dann nehme ich lieber das Original. Als im Falle von Artix halt Arch Linux. Und insbesondere in Deinem Fall, wo Du ja viel lernen möchtest, wäre Arch Linux doch eigentlich besser. Weil die sind ziemlich gut dokumentiert.
Arch nutzt systemd.

Außerdem komme ich mit der Text-Modus-Installation noch nicht klar, weshalb ich höchstens ein anderes Arch-Derivat nutzen könnte. Die habe ich mit auch angesehen, allen voran natürlich Manjaro, da es standardmäßig schon Xfce nutzt und deren Webseite auch einen sehr professionellen Eindruck macht, aber neben dem, dass es mir viel zu zugemüllt ist, ist es mir unter der Haube zu sehe vermurkst: So bootet es nur mit dem eigenen Grub (womit "update-grub" bei mehreren parallelen Installationen sehr viel länger als bei allen anderen Distributionen braucht): Bootet man es mit dem Grub einer anderen Distribution (sogar wenn das auch ein Arch-Derivat ist!), gibt es eine Kernel-Panik. Pamac hängt sich ständig auf, wenn man mehreres in einem Rutsch installieren will, dann gibt es oft nach dem booten für ca. 2 Min. 100% CPU-Last auf einem Kern, usw. - Manjaro würde ich nicht mal nutzen wollen, wenn ich dafür bezahlt würde.

Ich habe übrigens extra ein reines (älteres) AMD-System und benötige keine proprietären Treiber: Mir werden auch bei Manjaro nicht mal welche angeboten.
Ich kenne jetzt Artix-Linux nicht. Gut möglich, das es da ähnlich ist (und man auch weite Teile der Arch Doku übernehmen kann) und das der ausschlaggebende Punkt für Dich war, das es besser darin ist alternative Init-Systeme zu unterstützen.
Artix nutzt erst seit kurzer Zeit die Arch-Qellen nur noch optional: Ich benötige sie aber, da es in den Artix-Quellen z. B. weder Opera noch Sigil gibt. Die Arch-Qellen zu nutzen ist kein Problem: Wie shinXdxd oben geschrieben hat, ist das bei Artix sauber umgesetzt. Auch das AUR lässt sich weit überwiegend unter Artix nutzen und aufs Arch-Wiki greife ich oft zurück: Bis eben auf systemd lässt sich das uneingeschränkt übernehmen. - Die systemd-Kommandos in klar verständliche Befehlszeilen zu enträtseln sehe ich als Herausforderung. ;-)

Ich hatte vor übrigens, ein Arch-Xfce parallel zu installieren, um gegentesten zu können, ob Fehler auch schon dort auftreten, so dass ich die besser direkt im Arch-Forum melde **), aber auf meinem PC hing es sich beim initialisieren der GUI immer auf. Auch noch nach mehreren Aktualisierungen, also habe ich es geblkdiscardet: Das sehe ich mir später nochmal an, wenn ich Artix besser kenne.

Das betraf nur mein PC: Die selbst Installation (auf ext. SSD) bootete auf dem noch etwas älteren AMD-PC bei meiner Mutter problemlos ins GUI und auf beiden PCs ließ es sich in KVM auch problemlos bis ins GUI booten.

**) z. B. als sich vor einigen Monaten ntfs nicht mehr per fstrim trimmen ließ und ich auch nach zwei Wochen noch nichts dazu im Internet finden konnte:

https://forum.archlinux.de/d/33838-fstrim-funktioniert-nicht-mehr-mit-ntfs

Im Idealfall fummelt man ja auch nicht einfach an irgendwelchen Einstellungen rum und guckt was passiert, sondern liest die Doku und weiß dann auch welche Änderung welches Ergebnis bringt. Aber ich verstehe, was Du meinst. :-)
Erst kommt natürlich die Doku, dann meine Optimierungen, da ich mir nicht vorschreiben lassen will, wie ich etwas zu handhaben habe: Ich denke lieber selbst.
Wie dem auch sei: Danke für den umfangreichen Einblick in Deine persönliche Artix-Welt.
Keine Ursache. Ich schreibe das hier nicht nur für dich, sondern nicht zuletzt auch, um später noch darauf zurückgreifen zu können.
 
Top