Nur so aus Neugier: Welche Gründe gibt es, um OpenBSD zu nehmen?

[Yamagi]

Jeder Admin - und ich komme da wirklich viel rum, da ich nunmal in nem IT Consulting Unternehmen arbeite, arbeitet mitlerweile gern mit systemd. Bei der Umstellung haben einige geflucht, einfach weil sie neues Wissen lernen mussten (vorallem die ältern...). Aber wenn man das mal hat, ist die Arbeit deutlich angenehmer.

Wobei man sehen muss, dass in der Linux-Welt eigentlich niemand etwas gegen die Konzepte von systemd hatte. Das SysV-Init, was schon 1986 überholt war, weg musste, war auch weitgehend unumstritten. Das Problem lag eher darin, dass systemd in den ersten Jahren eine grottenschlechte Implementierung hatte. Es war eine undurchdachte Bugwüste, die an vielen Stellen zu viel Ärger machte. Das sagen wir mal soziopathische Verhalten des damaligen Projektleiters und dessen Tendenz auf valide Kritik mit Arschloch-Verhalten (sorry) zu reagieren, machte das nicht besser. Inzwischen hat systemd aber eine große, diverse Entwickler-Community und wurde praktisch nochmal vollständig reimplementiert. Es funktioniert nun einfach, macht unauffällig das, was soll und damit hat sich viele Kritik überholt.

 

[medV2]

Wobei man sehen muss, dass in der Linux-Welt eigentlich niemand etwas gegen die Konzepte von systemd hatte. Das SysV-Init, was schon 1986 überholt war, weg musste, war auch weitgehend unumstritten. Das Problem lag eher darin, dass systemd in den ersten Jahren eine grottenschlechte Implementierung hatte. Es war eine undurchdachte Bugwüste, die an vielen Stellen zu viel Ärger machte. Das sagen wir mal soziopathische Verhalten des damaligen Projektleiters und dessen Tendenz auf valide Kritik mit Arschloch-Verhalten (sorry) zu reagieren, machte das nicht besser. Inzwischen hat systemd aber eine große, diverse Entwickler-Community und wurde praktisch nochmal vollständig reimplementiert. Es funktioniert nun einfach, macht unauffällig das, was soll und damit hat sich viele Kritik überholt.

Was die Anfänge betifft (und auch das Verhalten von Poettering) gebe ich dir absolut recht. Allerdings war es zu Beginn auch nur in den bleeding edge-Distros, auf den Server/LTS Distros war es lange nicht und mit denen würde ich generell *BSDs vergleichen. RHEL 5 Jahre nach Release, Debian noch später um ein paar Beispiele zu nennen. Ähnlich wars mit Pulseaudio damals, grottiger Release in den bleeding edge Distros, aber als es zu den Serverdistros kam, war es durchaus schon ausgereift. Wer nicht basteln will, nimmt halt -LTS das galt früher noch mehr als heute.

 

[Andy_m4]

viele User und speziell Admins empfinden den Umgang mit systemd als positiv und wollen keinesfalls zurück zu SysVinit und Konsorten.

Gut. Besser als Sys-IV-Init zu sein ist ja nun auch keine Kunst. Da könnte ich vermutlich sogar Chat-GPT bauftragen und da würde ein besseres Init-System hinten rausfallen. :-)
Und ja. systemd steht einem im Alltag nicht groß um Weg herum und macht seinen Job. Zum Ärgernis wird es aber gerne mal dann, wenn es Probleme gibt. Wenn beispielsweise ein Service man die den Sekundenzähler sieht und als Timeout aber no limit und solche Späße. Stumpfe Systeme a-la Sys-IV-Init kümmern sich nicht darum und booten trotzdem durch und dann hat man zwar kein vollständig hochgefahrenes System, aber aber es ist dann oftmals immerhin so weit da, das man dann eingreifen und Dinge fixen kann. Ist aber alles nichts Dramatisches.

Und um jetzt mal wieder zurück zu den BSDs zu kommen. Ich finde das rc-System eigentlich ok. Ja. Es mag in die Jahre gekommen sein. Aber es ist von angenehmer Simplizität und Robustheit. Und es macht einem auch keine Probleme.

Insofern würde ich sagen, ich hab kein direktes Problem mit systemd. Ich hab aber auch kein Problem damit rc-init zu verwenden und denk dabei auch nicht die ganze Zeit "Oh wie fehlt mir systemd".

Das ist Microsofts freundlicher Hinweis darauf, dass man in die Cloud kommen sollte.

Wo es dann aber auch nicht richtig funktioniert. Früher war ja immer Microsofts Ausrede wenn was geplatzt ist, das Exchange nicht richtig eingerichtet wurde. Und selbst die zieht jetzt nicht mehr. :-)

 

[Yamagi]

Und um jetzt mal wieder zurück zu den BSDs zu kommen. Ich finde das rc-System eigentlich ok. Ja. Es mag in die Jahre gekommen sein. Aber es ist von angenehmer Simplizität und Robustheit.

OpenBSD weiß ich manegls Erfahrung nicht, aber unter FreeBSD hat das dortige rcng in den letzten Jahren einige schöne Features bekommen. Ich sage nur transparente Service Jails.

 

[Andy_m4]

Ich sage nur transparente Service Jails.

Ja. Das ist echt nett und ne unkomplizierte Möglichkeit Daemons einzusperren.
(wers nicht kennt: Im Handbuch gibts einen Abschnitt dazu -> HB / Service Jails)

 

[Andy_m4]

Bei der Umstellung haben einige geflucht, einfach weil sie neues Wissen lernen mussten (vorallem die ältern...). Aber wenn man das mal hat, ist die Arbeit deutlich angenehmer.

Ja. Umlernen ist ja das eine. Aber an manchen Stellen ists auch einfach nur doof.

systemctl hat ja die Syntax:
systemctl cmd servicename

Das klassische service (wie man es z.B. auch unter FreeBSD hat)
service servicename cmd

Und Letzteres finde ich angenehmer. Weil bei mir ist das so, das ich häufig den Fall hab, das ich z.B. mal ein Daemon checke mit
service dhcpd status
wenn ich jetzt sehe, der läuft nicht dann brauch ich nur die Pfeil hoch taste drücken, dann den nicht benötigten Teil von "status" "wegbackspacen" und da das "start" hinschreiben und fertig. Beim systemctl-Pendant muss ich erst irgendwie am servicename vorbeipfeiltasten, um dann das cmd ändern zu können.

Und solche Sachen ärgern mich immer. Also nicht nur, das ich mich an die umgekehrte Reihenfolge gewöhnen musste und auch nach wie vor daran denken muss, wenn ich mit anderen Init-Systemen konfrontiert bin, dann ist es auch noch in der Handhabung effektiv schlechter.

Vor allem weil man ja an anderer Stelle auch versucht Gewohnheitsnutzer mitzunehmen.
Das journalctl -f den Parameter mit -f bezeichnet hat ja vor allem den Grund, weil bisher die Leute tail -f /var/log/messages gemacht haben.

btw: Ich weiß nicht, wie es bei anderen Distributionen ist, aber bei Debian hat man nach wie vor als Alternative ein service-Befehl der sich auch ähnlich verhält wie früher und dann aber auf systemd wirkt.

 

[CommanderZed]

Bei OpenBSDs ist es ja auch rcctl cmd servicename

Ansonsten kann ich allen vorrednern nur zustimmen, systemd war anfangs sicher sehr problematisch, inzwischen läuft das bei mir eigentlich sehr unauffällig. Ich hab schon selbst kleinere unit files geschrieben für zeug wo ich was selbst gebastelt hab (qemu zvms .B.) und das funktioniert alles ganz fluffig.

Manche kommandos find ich weniger nachvollziehbar (gerade beim journal z.B.)
Ein problem das ich unter debian mit dem isc-dhcp-server hatte, hab ich z.B. unter Archlinux nicht, ich glaube da war dann z.B. auch Debian gebastel drinn. Das muss man ja uach immer irgendwie mit einbeziehen, das Probleme auch distributionsspezfisch sein können.

Seit ein paar Monaten arbeite ich für ein Bastelprojekt viel mit systemd-networkd - ein Progrämmchen um Netzwerkkonfigurationen zu erstellen als alternative für die vielfältigen Linux-Alternativen und das funktionert bei einfachen aber gerade auch komplexeren, ineinander verwobenen Interfaces sehr gut - z.B. besser als der elendige NetworkManager (Auch wenn der inzwischen dtl. gereifter ist - fan werde ich da aber wohl nie)

 

[medV2]

Und Letzteres finde ich angenehmer. Weil bei mir ist das so, das ich häufig den Fall hab, das ich z.B. mal ein Daemon checke mit
service dhcpd status
wenn ich jetzt sehe, der läuft nicht dann brauch ich nur die Pfeil hoch taste drücken, dann den nicht benötigten Teil von "status" "wegbackspacen" und da das "start" hinschreiben und fertig. Beim systemctl-Pendant muss ich erst irgendwie am servicename vorbeipfeiltasten, um dann das cmd ändern zu können.

Ich könnte jetzt natürlich sagen, dass systemd automatisch checks durchführt, und sich automatisch darum kümmert, das ein Service neu gestartet wird, wenn er stirbt (setzt natürlich ein ordentliches Unit-File für den Service vorraus)

Ich könnte aber auch erklären, dass so halt die Autocompletion besser funktioniert. systemctl reload ANFANGSBUCHSTABE zeigt mir andere Services an als systemctl restart ANFANGSBUCHSTABE, nämlich nur jene, bei denen reload möglich ist. Setzt natürlich auch wieder korrektes Unitfile vorraus

Aber ja am Anfang hats mich auch genervt und ich habs 100 mal falsch rum geschrieben

 

[Andy_m4]

für die vielfältigen Linux-Alternativen

Das finde ich übrigens auch super nervig bei Linux. Das Du für vieles Dutzende von Lösungen hast. Insbesondere, weil es leicht passieren kann, das auch mal mehrere gleichzeitig aktiv sind (mit entsprechenden Nebenwirkungen) weil irgendwelche Abhängigkeiten erfüllt werden.
Das man selbst bei grundlegenden Sachen die es auch schon ewig gibt nicht mal schafft einen Standard zu einigen, ist echt nervig.

Bei OpenBSDs ist es ja auch rcctl cmd servicename

Ja. Schlimm. Jetzt wissen wir wenigstens, wo die das her haben.

Spoiler: Aber man kann ja abhelfen :-)

#!/bin/sh

# service.sh - Imitiert das service Kommando und konvertiert zu rcctl für OpenBSD
# rcctl(8) https://man.openbsd.org/rcctl

# Überprüfen, ob ein Servicename angegeben wurde
if [ "$#" -lt 1 ]; then
    echo "Usage: $0 <service|ls> [<command>]"
    echo "Commands: check, configtest, reload, restart, start, stop, disable, enable, order"
    echo "List options: all, failed, off, on, rogue, started, stopped"
    exit 1
fi

SERVICE="$1"
COMMAND="$2"

# Überprüfen, ob der erste Parameter "ls" ist
if [ "$SERVICE" = "ls" ]; then
    case "$COMMAND" in
        all|failed|off|on|rogue|started|stopped)
            rcctl ls "$COMMAND"
            ;;
        "")
            # Wenn kein spezifischer List-Befehl angegeben ist, alle Dienste auflisten
            rcctl ls
            ;;
        *)
            echo "Unbekannte List-Option: $COMMAND"
            echo "Erlaubte Optionen: all, failed, off, on, rogue, started, stopped"
            exit 1
            ;;
    esac
else
    case "$COMMAND" in
        check|configtest|reload|restart|start|stop|disable|enable|order)
            rcctl "$COMMAND" "$SERVICE"
            ;;
        *)
            echo "Unbekannter Befehl: $COMMAND"
            echo "Erlaubte Befehle: check, configtest, reload, restart, start, stop, disable, enable, order"
            exit 1
            ;;
    esac
fi

Ich könnte jetzt natürlich sagen, dass systemd automatisch checks durchführt, und sich automatisch darum kümmert, das ein Service neu gestartet wird, wenn er stirbt (setzt natürlich ein ordentliches Unit-File für den Service vorraus)

Ja. Das war ja auch nur ein Beispiel. Ist mir auch nur aufgefallen, das ich bei administrativen Arbeiten viel häufiger in Verlegenheit bin bei Befehlsrückholungen das cmd zu ändern als den servicename.

Ich könnte aber auch erklären, dass so halt die Autocompletion besser funktioniert. systemctl reload ANFANGSBUCHSTABE zeigt mir andere Services an als systemctl restart ANFANGSBUCHSTABE, nämlich nur jene, bei denen reload möglich ist.

Das ist natürlich ein Punkt. Allerdings ist man bei systemd auch im viel stärkeren Maße darauf angewiesen, weil man hat üblicherweise deutlich mehr "Units" als man bei anderen Init-Systemen Services hat.
Da wirds dann auch schnell mal unübersichtlich und man ist dankbar für jedes "reduce".

Entscheidend ist das alles natürlich nicht. Aber das sind so Sachen, über die man so in der täglichen Arbeit stolpert.
Und man hat ja auf der anderen Seite ja auch Sachen die praktisch sind.

Zum Beispiel das systemctl status service auch gleich die aktuellsten zugehörigen Log-Einträge mit anzeigt.

Oder, um noch mal zu journalctl zurück zu kommen: einfach den -b Parameter angeben und schon hat man alle Meldungen seit dem letzten Boot ist halt sehr viel einfacher als das mit /var/log/messages hinzukriegen.

 

[CommanderZed]

Das finde ich übrigens auch super nervig bei Linux. Das Du für vieles Dutzende von Lösungen hast. Insbesondere, weil es leicht passieren kann, das auch mal mehrere gleichzeitig aktiv sind (mit entsprechenden Nebenwirkungen) weil irgendwelche Abhängigkeiten erfüllt werden.

Ja, das empfinde ich auch teilweise so. Ich verwende ja primär arch und debian und arch bietet da gefühlt viel mehr kontrolle, zumal da ähnlich zu *BSD der default auch fast immer "abgeschaltet" ist selbst wenn mans installiert.

Und oft ist keine der Lösungen so richtig gut und ich hab das Gefühl so "Individuelle Probleme von irgendjemand 2008" als start-motivation begonnen und alles andere dann immer mehr rangeflickt.

Das man selbst bei grundlegenden Sachen die es auch schon ewig gibt nicht mal schafft einen Standard zu einigen, ist echt nervig.


Ja. Schlimm. Jetzt wissen wir wenigstens, wo die das her haben.
"Aber man kann ja abhelfen :-)"]

Außer den FreeBSD Notebook zum sehr seltenen vertesten hab ich privat nur OpenBSD, Linux, Windows und beruflich Linux und Windows regelmäßig in der Hand. (Okay noch iOS und iPAD OS, seltener Android, aber die zähle ich mal nicht bei diesem Thema)

Systemd anstelle dieses Windows-Services-Quatsch würde mir glaub ich sogar ganz gut gefallen [/spoiler]

 

[midnight]

systemctl hat ja die Syntax:
systemctl cmd servicename

Das klassische service (wie man es z.B. auch unter FreeBSD hat)
service servicename cmd

Und Letzteres finde ich angenehmer. Weil bei mir ist das so, das ich häufig den Fall hab, das ich z.B. mal ein Daemon checke mit
service dhcpd status
wenn ich jetzt sehe, der läuft nicht dann brauch ich nur die Pfeil hoch taste drücken, dann den nicht benötigten Teil von "status" "wegbackspacen" und da das "start" hinschreiben und fertig. Beim systemctl-Pendant muss ich erst irgendwie am servicename vorbeipfeiltasten, um dann das cmd ändern zu können.

Wer nutzt denn die Pfeiltasten im Terminal.

Spass beiseite, das habe ich so noch nie betrachtet. Guter Punkt. Wobei die OpenBSD-Variante auch Vorteile hat. Man kann dann direkt mehrere Services gleichzeitig starten, stoppen oder neustarten:

# rcctl restart redis rspamd dovecot

Nochmal zum Thema Pfeiltasten: Die wenigsten User nutzen den vi-mode oder emacs-mode im Terminal, obwohl sie tagtaeglich diese Shortcuts im Editor verwenden. Das erstaunt mich immer wieder.

Beispiel vi-mode:

# rcctl stop nginx

Shortcut waere: ESC, jbdbi start und schon hat man ein # rcctl start nginx (j = Zeile hoch, b = Wort zurueck, bd = Wort zurueck loeschen, i = Edit mode)

Beispiel emacs-mode:

# rcctl stop nginx

Shortcut waere: Ctrl-p, Alt-b, Alt-backspace, start und schon hat man ein # rcctl start nginx (Ctrl-p = Zeile hoch, Alt-b = Wort zurueck, Alt-backspace = Wort zurueck loeschen)

Wenn man die Shortcuts aus seinem Editor gewohnt ist, denkt man da eigentlich nicht mehr darueber nach, sondern bewegt sich auf der Kommandozeile wie im Editor. Ob man nun 1 oder 2 Worte zurueckspringt ist da eigentlich nicht so wichtig. ;-)

emacs-mode ist meistens default. Das kann man mit set -o kontrollieren und mit set -o emacs bzw. set -o vi setzen.

 

[Andy_m4]

Systemd anstelle dieses Windows-Services-Quatsch würde mir glaub ich sogar ganz gut gefallen

Ja. Ich weiß gar nicht, ob Microsoft bei seinem Service Control Manager überhaupt mal was großartig dran gemacht hat seit den Windows NT Zeiten. Also jetzt jenseits von kleinen, inkrementellen Änderungen/Erweiterungen.
Vielleicht sollten wir mal svchost.exe fragen, was er davon hält. :-)

Was mich bei Windows immer mehr genervt hat war, das es ein User SYSTEM gibt der höher privilegiert ist als Administrator und dementsprechend auch selbst als Administrator Ressourcen auch nicht einfach mal so abschießen kann.
Dann noch dieses exclusive-lock und dessen exzessive Verwendung, was auch manchmal im Weg stand und ja auch den hohen Reboot-Bedarf von Windows beförderte (Mouse moved. Reboot to apply the change).

Wobei die OpenBSD-Variante auch Vorteile hat. Man kann dann direkt mehrere Services gleichzeitig starten, stoppen oder neustarten

Ja. Das stimmt. Nur hab ich den Fall, das ich das brauche, eher selten.
Und wenn ich so etwas irgendwie im Skript hab, mach ich halt ein

for s in service1 service2 service3
do
  service $s start
done

Ist nicht schön, aber geht.

Die wenigsten User nutzen den vi-mode oder emacs-mode im Terminal, obwohl sie tagtaeglich diese Shortcuts im Editor verwenden.

Naja. Ich bin jetzt kein vi-Nutzer. Außerdem ist das wieder Konfigurationssache. Und die Pfeiltasten und so was wie BACKSPACE funktioniert i.d.R. immer.

Aber ja. Beim eigenen Rechner kann man es natürlich so machen. Wobei ich dann für "Word-Skip" eher sowas wie Strg-Pfeil nehmen würde was dann auch konsistent zu üblichen Bedienstandards ist.
Aber ja. Für Leute, die vi/emacs-User sind ist das natürlich ein möglicher Weg um dann eine konsistente Bedienung auch im Terminal zu haben.

 

[Yamagi]

Das mit der Shell ist sowieso so ein Trauerspiel... Es wundert mich immer wieder, wie unbeholfen selbst sehr erfahrene Admins mit 20 Jahren Erfahrung sind, wenn es um effiziente Nutzung der Shell geht. Nicht nur mit dem Command Line Editor, sondern auch mit Dingen wie History, Globbing, Redirections, Substitutionen, etc.

 

[medV2]

Das finde ich übrigens auch super nervig bei Linux. Das Du für vieles Dutzende von Lösungen hast. Insbesondere, weil es leicht passieren kann, das auch mal mehrere gleichzeitig aktiv sind (mit entsprechenden Nebenwirkungen) weil irgendwelche Abhängigkeiten erfüllt werden.
Das man selbst bei grundlegenden Sachen die es auch schon ewig gibt nicht mal schafft einen Standard zu einigen, ist echt nervig.

Ja, das empfinde ich auch teilweise so. Ich verwende ja primär arch und debian und arch bietet da gefühlt viel mehr kontrolle, zumal da ähnlich zu *BSD der default auch fast immer "abgeschaltet" ist selbst wenn mans installiert.

Und oft ist keine der Lösungen so richtig gut und ich hab das Gefühl so "Individuelle Probleme von irgendjemand 2008" als start-motivation begonnen und alles andere dann immer mehr rangeflickt.

Da bin ich eurer Meinung, deshalb nehme ich als Linux Server normal immer RHEL wenn es keine zwingenden Gründe für ein anderes System gibt. Da gibt es im Basissystem nur eine Lösung, alle Lösungen sind aufeinander abgestimmt und wirklich sehr gut dokumentiert. Ein Firewallsystem, ein Containersystem, eine Securityextension, ein NW Manager.
Unter Debian habe ich bei all diesen Dingen die Wahl von 2-4 verschiedenen Systemen. Ob die ineinander kompatibel, oder diese Kombination gut dokumentiert ist? Weiß man oft erst danach. Container funktionieren ootb zB nur mit firewalld oder legacy-IPT-Scripten und AppArmor (wobei letzteres nichts im Bezug auf Container schützt), nicht aber mit UFW oder SELinux. Dokumentationen gehen idr. auf docker ein, wobei podman mitlerweile Industriestandard ist.

 

[double-p]

<insert xkcd "Standards">

 

[jmt]

Da bin ich eurer Meinung, deshalb nehme ich als Linux Server normal immer RHEL wenn es keine zwingenden Gründe für ein anderes System gibt. Da gibt es im Basissystem nur eine Lösung, alle Lösungen sind aufeinander abgestimmt und wirklich sehr gut dokumentiert. Ein Firewallsystem, ein Containersystem, eine Securityextension, ein NW Manager.
Unter Debian habe ich bei all diesen Dingen die Wahl von 2-4 verschiedenen Systemen. Ob die ineinander kompatibel, oder diese Kombination gut dokumentiert ist? Weiß man oft erst danach. Container funktionieren ootb zB nur mit firewalld oder legacy-IPT-Scripten und AppArmor (wobei letzteres nichts im Bezug auf Container schützt), nicht aber mit UFW oder SELinux. Dokumentationen gehen idr. auf docker ein, wobei podman mitlerweile Industriestandard ist.

Ich bin ja "nur" Entwickler, aber bei den mir bekannten RHEL Systemen sind alle Pakete immer so grotten alt. Das macht mit RHEL extrem unsympatisch.

 

[medV2]

Ich bin ja "nur" Entwickler, aber bei den mir bekannten RHEL Systemen sind alle Pakete immer so grotten alt. Das macht mit RHEL extrem unsympatisch.

RHEL hat seit Version 7 sogenannte AppStreams. Da werden für ausgewählte Pakete - zB Interpreter, Tools wie DBs, Sprachen (Go, rust, ..) neue Versionen zu anderen Supportzeiten angeboten.

ZB installierst du auf einem aktuellem RHEL standardmäßig PGSQL 13.18, welche Standard ist und über die gesammte Lebenszeit von 10(+3) Jahren gemaintained wird (voraussichtlich), über AppStreams kannst du aber derzeit auch 15 und 16 installieren, mit jeweils nur 5 Jahren Support ab verfügbarkeit (ich nehme an ne V14 gabs da auch mal).

Oder NodeJS gibts in 18, 20 und 22. GCC Versionen, Python, php, .. alles ähnlich.

Das ist jetzt natürlich immer noch nicht bleeding edge - aber du bist keine 5 Jahre hinterher


edit

Achja, das gilt natürlich nicht nur für RHEL sondern auch für dessen Clone, zumindest von Oracle und Rocky weiß ich es, dass die dieses System auch haben.

 

[Andy_m4]

Unter Debian habe ich bei all diesen Dingen die Wahl von 2-4 verschiedenen Systemen.

Alles hat so seine Vor- und Nachteile. Das "aussuchen können" ermöglicht mir andererseits natürlich das zu nehmen, was für mich und meine Bedürfnisse am besten passt.

Das macht mit RHEL extrem unsympatisch.

Einerseits verstehe ich das. Man kann dann evtl. auch keine neueren Sachen einsetzen. Andererseits hast Du natürlich bei diesen Longterm-Systemen eben auch eine verlässliche Basis die sich nicht großartig ändert. Ansonsten wurde zu Applications Streams ja schon was gesagt. Und wenn man doch mal bestimmte Anforderungen hat, hat man ja immer noch die Container aus Ausweichmöglichkeit.

Anyway: Ich finds ja gut, das es beides gibt. Das es sowohl Systeme gibt die über biblische Zeiträume supported werden, als auch Systeme mit Paketen wo man die Wärme des Compilerdurchlaufs noch spürt.

 

[CommanderZed]

Ich finde diese LTS Systeme bieten unter bestimmten umständen schon sinnvolle sachen.
Son typisches Beispiel wäre für mich wenn ich eine kommerzielle Software habe auf die ich keinen einfluss habe und die halt bestimmte Versionen vorschreiben oder evtl. auch aus diesen Gründen ein OS. So ein gebilde ist ja sehr starr oft auch.

Tendenziell bin ich da aber kein fan von, auf der einen Seite hab ich beruflich da viel zu viel negatives erlebt mit, z.B. da neuere sachen reinzufrickeln wenn man die doch braucht (Mir war das OS vorgeschrieben, und es waren oft eher obskure sachen)

Zum anderne sorgt so etwas auch dafür das man unter den Motto "ich muss mich nichts neuen beschäftigen" die halt installiert und immer nur Updated, aber den ganzen Stack sonst nie wieder betrachtet. Und nach X Jahren muss man dann doch auf ne neuere Version (Entweder weil der Support doch ausläuft oder weil irgendwas das erfordert) und dann steht man vor einem Scherbenhaufen weil es meist garnicht möglich ist die riesigen Versionssionsspünge noch sinnvoll irgendwie nachzuvollziehen, es gibt sich gegenseitig bestärkende Fehler und liegt das Problem a jetzt an neuerung z oder an version y oder hängt es mit Problem B F G zusammen? Das führt oft dazu das man dann doch nicht updated und das Problem nur noch weiter verschärft.

Ein rolling release oder zumindest ein os mit etwas schnelleren Updatezyklen bieten da eine sehr viel sanftere Migration. Dadurch das sich nicht im zweifel viele hundert Pakete auf neue Major Releases aktualisiert haben sondern im idealfall nur 2 oder 3 kann man das Problem oft schnell eingrenzen und noch lösen. Beim nächsten größeren Update dann wieder, so das man immer nur "kleinere" und noch "überschaubare" und nicht "sich gegenseitig beeinflussende" dinge fixen muss.

Nicht falsch verstehen: Beides hat seine einsatzzwecke. Man sollte die vor-nachteile aber kennen bevor man auf eine LTS Distri setzt und sich entspannt zurück lehnt.

 

[cabriofahrer]

Und schon hat man ein komplettes und aktuelles Gnome 47 mit GDM. Das war jetzt keine Raketenwissenschaft. :-)

Das hat nicht viel mit meinem Statement zu tun, ich redete von LightDM und SDDM, nicht von GDM. Meine konkrete Erfahrung bezog sich dabei auch eher auf NetBSD, wobei ich lediglich in Erinnerung habe, dass es bei OpenBSD ähnlich aussieht.

Es gibt ein indianisches Sprichwort:

„Grosser Geist, bewahre mich davor, über einen Menschen zu urteilen, ehe ich nicht eine Meile in seinen Mokassins gegangen bin.“

Die Cowboys haben aber gewonnen und dominieren heute praktisch die Welt. Die paar Indianer, die noch übrig geblieben sind, leben meist in Reservaten. Was ich damit sagen will: Sprichwörter / Weisheiten von Leuten, die verloren haben, halte ich für wenig wertvoll. Ich will jetzt aber auch kein OT über die moralisch fragwürdige Geschichte der Amerikaner starten.

dann sagen wir auch nicht, dass FreeBSD eigentlich steinzeitlicher Schrott ist, weil sich dieses und jenes nicht mit einer GUI konfigurieren laesst.

Das war so auch nicht meine Aussage. Mit "steinzeitlich" meinte ich nur den Loginmanager, der wohl ein Fork von XDM ist, nicht das Betriebsystem.

Wozu braucht man einen Login-Manager? Also insbesondere wenn man den Rechner allein nutzt?
Also ich hab' kein und logge mich ganz normal ein und mach dann ein startx (was man sogar noch durchs login-Skript wegautomatisieren könnte).

Ein Loginmanager gehört für mich einfach zu einem kompletten Desktop dazu, Windows hat es ja auch. Auch, wenn man den Rechner allein nutzt, kann man vielleicht trotzdem mehrere Konten haben. Da hier und da auch Steam erwähnt wird: Da wird ja schließlich empfohlen, ein gesondertes Konto ohne wheel einzurichten. Damit hättest Du schon zwei Konten. Also wir brauchen wohl nicht darüber zu diskutieren, dass es einfacher und schöner ist, wenn X automatisch gestartet wird und man nur noch sein Passwort und einmal mit der Maus klicken muss.
Du kannst Dich aber natürlich gerne in der Konsole einloggen und danach startx eingeben. Aber wenn Du mehrere Windowmanager hast, musst Du auch schon wieder einen längeren Befehl eingeben, z.B. startx /usr/local/bin/fluxbox. Bei einem Loginmanager kannst Du aber bequem im Dropdown-Memu auswählen.

 

[CommanderZed]

Das war so auch nicht meine Aussage. Mit "steinzeitlich" meinte ich nur den Loginmanager, der wohl ein Fork von XDM ist, nicht das Betriebsystem.

Der aber sehr schlank ist und sehr gut funktioniert. Ich wechsel aber auch nicht meine DEs häufig. Und mehrere nutzer sind damit ja auch Problemfrei nötig.
Ich hab auch z.b. unter Arch den zu KDE gehörendne Manager und stell da einfach nie was drinn rum? Warum auch?

Du kannst Dich aber natürlich gerne in der Konsole einloggen und danach startx eingeben. Aber wenn Du mehrere Windowmanager hast, musst Du auch schon wieder einen längeren Befehl eingeben, z.B. startx /usr/local/bin/fluxbox. Bei einem Loginmanager kannst Du aber bequem im Dropdown-Memu auswählen.

Wenn das für dich ein "längerer Befehl" ist erklärt sich so einiges.
Und du auch nicht auf die idee kommst das man das Scripten kannst ist auch ... äh ...

 

[cabriofahrer]

Wenn das für dich ein "längerer Befehl" ist erklärt sich so einiges.
Und du auch nicht auf die idee kommst das man das Scripten kannst ist auch ... äh ...

Das Gleiche kann ich umgekehrt genauso behaupten. Und mit so einer Denkweise könnte man niemals irgendwelche Alltagsuser dazu bringen, irgendetwas anderes als Windows zu benutzen. Wenn man schon "freaky" genug ist, weil man BSD oder Linux verwendet, dann gibt es offenbar noch die Freaks unter den Freaks...

 

[CommanderZed]

Das Gleiche kann ich umgekehrt genauso behaupten. Und mit so einer Denkweise könnte man niemals irgendwelche Alltagsuser dazu bringen, irgendetwas anderes als Windows zu benutzen. Wenn man schon "freaky" genug ist, weil man BSD oder Linux verwendet, dann gibt es offenbar noch die Freaks unter den Freaks...

*BSD ist eindeutig nicht für Alltagsuser, Sorry wenn ich dir diese nachricht so brechen muss.

Ambitionierte Hobbyleute können das sicher nutzen wenn sie sich gut reingefuchst haben, aber kein BSD ist ein "Wald und Wiesen" Betriebsystem wie Windows, MacOS, iOS oder Android.
Selbst etwas auf endanwender getrimmte Linux-Variante wie z.B. Ubuntu würde ich ein gewisses Level oberhalb von "Ich kann unfallfrei mich am Windows anmelden, kann aber kaum unfallfrei den Bildschirm vom PC unterscheiden" - was die mehrheit ausmacht - sehen.

Eigentlich ist das was ich bei dir (und andere) seit Jahren hier im Forum sehe eigentlich ne ziemlich gute bestätigung. Ambitionierte Hobbynutzer die sich etwas angelesen haben können es installieren, sobald es komplexer wird scheitern sie kläglich, oft schon hier in der Kommunikation, weil wichtige zusammenhänge garnicht verstanden werden.

 

[pit234a]

können es installieren, sobald es komplexer wird scheitern sie kläglich, oft schon hier in der Kommunikation, weil wichtige zusammenhänge garnicht verstanden werden.

das will ich aus meiner Sicht als Hobby-Nutzer bestätigen: so fühle ich mich laufend!

Die Cowboys haben aber gewonnen und dominieren heute praktisch die Welt.

ich finde grundsätzlich interessant, wie oft den alten Indianern irgendwelche Weisheiten untergeschoben werden. Nunja, bei den Cowboys hätte diese Weisheit vielleicht so gelautet:
'Never judge someone until you've walked a mile in his shoes. That way, when you do judge him, you're a mile away and you have his shoes.'

edit: habe ich eben erinnert, woher ich das habe:

Emo Philips​

 

[CommanderZed]

das will ich aus meiner Sicht als Hobby-Nutzer bestätigen: so fühle ich mich laufend!

Auch innerhalb der Hobbynutzer gibt es - natürlich - auch noch abstufungen. Und ich meinte tatsächlich das eher so als "level" - man kann auch wenn man das nur Hobbymäßig betreibt vom wissen her deutlich über jemanden sein der IT beruflich macht.

Mir viel nur kein besserer Begriff ein. Deine Posts zeugen auf jedenfall für mich meist von vorhandenen und vor allem strukturiert vorhanden Wissen.