TrueOS: Umstieg auf OpenRC vollzogen

[CrimsonKing]

Laut TrueOS-Blog ist damit der "Milestone 1" geschafft.
Andere BSDs tun sich bei solchen Entscheidungen ja durchaus etwas schwerer, wie es heißt.

 

[lme]

Ich sehe auch keinen Grund, von rc wegzugehen.

 

[KobRheTilla]

TrueOS folgt FreeBSD-CURRENT, wozu nutzen sie dann ein anderes rc? Das ist doch verschenkte Arbeitszeit, vor allem bei den Ports.

Rob

 

[CrimsonKing]

Das Übliche: Bootzeiten!!!1!

 

[Freigeist]

Bewegung ist für diese Frickelbude ALLES. Das Ziel ist NICHTS.

Was habe die schon alles in den Sand gesetzt! Man denke nur an das Corral-Desaster.

Gibt es wirklich hundert Nutzer von TrueOS? Ich wage es zu bezweifeln.

 

[holgerw]

Habe kürzlich mal wieder diesem System eine Chance gegeben, und kurzerhand mein Fujitsu E-Book mit Intel Quadcore, 4 GB Ram und Intelgrafik damit aufegesetzt.

- Ich weiß nicht, was die da machen: Der Lüfter des Notebooks lief ständig wie unter Vollast (unter FreeBSD 11 mit kde4 oder plasma5 herrscht angenehme Ruhe, ohne irgendwelche Tweaks meinerseits).
- Irritierend ist, dass man zu Beginn der Installation deutsch wählen kann, unter Xorg dann auch alles in deutsch ist, aber ohne X us-Layout. Gut, ich kann ja mit nem Editor in die /etc/rc.conf noch ein keymap=de reinpinseln.
- Das GUI für das Anlegen von Nutzern erlaubt nicht die UID 1000, sondern es geht mit 1001 los. (1000 ist allerdings auch für nix anderes in Nutzung). Ich kann dann mit pw groupadd und adduser das nach meinen Wünschen und passend zu unserem Heimnetzwerk konfigurieren.
- Gefallen hat mir das GUI für drahtlose Netzwerke

Es gab noch weiteres, was ich nur händisch mit einem Editor zu meiner Zufriedenheit einrichten konnte, und das nur dank meines (noch weiter ausbaufähigen) Hintergrundwissens zu FreeBSD, daher ist mir nicht ganz klar, auf welche Nutzer das Desktop-System TrueOS ausgerichtet ist.

Jedenfalls weiß ich dank TrueOS nun, welch ein kraftvolles Gebläse in meinem Notebook verbaut wurde

 

[Athaba]

Bin auch kein Fan von TrueOS, aber OpenRC ist recht nett und das als Option zu haben finde ich auch grundsätzlich nicht so schlimm. Auch in dem Hinblick, dass man sich Code teilt, der ursprünglich mal von so halben BSDlern gemacht wurde (für Gentoo, vor allem auch für die Gentoo/*BSD-Varianten). OpenRC ist schon größer, aber es ist jedenfalls kein Projekt, das entstanden ist, weil "Bootzeiten", sondern eher um ein BSD styyle rc.d-Style System auf Linux zu haben bzw. sogar um es auf FreeBSD mit dem Gentoo Ecosystem zu haben. Auch ist es nicht ganz ein anderes init, sondern eigentlich ein Aufsatz, also mehr wie ein Library/Framework dafür.

Mal unabhängig von Bootzeiten und TrueOS ist es jetzt mal nicht so schlecht das Selbe, wie Gentoo, Alpine Linux und viele Leute die kein systemd mögen (auch unter Arch zum Beispiel) zu nutzen, allein schon um Arbeit zu teilen. Wenn eine Software ein gutes OpenRC-Script hat und das vielleicht etwas komplexer ist, dann rennt das schnell mal auch auf allen anderen OpenRC-Systemen.

Ich bin ehrlich gesagt einigermaßen Fan von OpenRC (zumindest unter Linux. Ich freue mich immer, wenn ich über ein Alpine oder Gentoo mit OpenRC stolpere) und ich denke, dass es eine relativ gute Entwicklung aus der Idee von rc.d ist. Klar es gibt Design-Entscheidungen, die vielleicht nicht so dem entsprechen, was sich manche vorstellen, aber es ist wirklich keine schlechte Software. Sie ist größer, aber die 900KB sind finde ich jetzt nicht in Unsinn geflossen.

Bitte das nicht als Aufruf zu noch so einer Diskussion halten, aber nur weil es ja tatsächlich ist: Es ist ein großartiges Beispiel dafür, wie man einen großen Teil von den Dingen, systemd (dem Init-Teil davon) den Leuten verspricht hätte anders lösen können. Klar, es ist nicht das Selbe und die einen hier werden das gut finden, und die anderen Schlecht, aber wenn man sich so Sachen ansieht, die man vielleicht (ich weiß, da gibt's unterschiedliche Meinungen!) in einem init-System haben will, ist das OpenRC relativ vollständig und zeigt damit, dass das auch mit einem rc.d-style System recht gut funktioniert.

Ich finde es passt auch gut zu FreeBSD in der Hinsicht, dass sich sowas ähnliches sich auch aus dem FreeBSD Projekt heraus hätte entwickeln können, ähnlich wie sich das Ports-System ja weiter entwickelt, das Package-System, File Systems und da auch Design Decisions mit Vor- und Nachteilen entwickelt haben.

Es ist auch erstmal nicht schlecht, dass man anstatt einer Neu- oder Eigenimplementierung mal schaut, ob es nicht was gibt, was in die Richtung geht. Habt ihr den Talk zu OpenBSDs rc.d gesehen? Auch die haben sich OpenRC angesehen und jetzt nicht für schlecht gehalten, auch wenn sie sich dagegen entschieden haben, weil sie etwas viel minimalistischeres, deutlich minimalistischeres als FreeBSDs rc.d haben wollten und die Unterschiede zu OpenBSD sind deutlich größer, als die zu FreeBSD. Der Punkt wird im Talk als Grund angeführt, das sie es nicht genommen haben.

Also auch, wenn ich die Kritik an TrueOS und diversen Dingen die da raus kamen verstehe, würde ich das nicht als vergebens ansehen und auch OpenRC nicht als TrueOS-Projekt darstellen, weil sie Skripte für FreeBSD geschrieben haben. Ich glaube auch nicht, dass die Leute dahinter ihre Zeit ansonsten für weltbewegendes tolles für FreeBSD genutzt hätten.

Das soll jetzt nicht heißen, dass ich finde, dass FreeBSD das sofort übernehmen sollte, aber ich find's nicht schlecht, dass es die Option gibt und ich würde es nicht nur abweisen, weil es von TrueOS kommt, weil es Bootzeiten beschleunigen kann. Ich glaube auch Parallel Boot kann man sogar abstellen (bin mir aber jetzt nicht ganz sicher).

Worum's mir geht ist, dass OpenRC nicht so unterschiedlich von FreeBSDs rc.d ist, es Features hat, die man klarerweise für gut/schlecht halten kann (die aber auch optional sind) und es ist eben nicht so minimalistisch, aber das ist das derzeitige System in FreeBSD auch nicht.

Ich weiß auch, dass es vor Ewigkeiten (ich glaube das ist schon über 10 Jahre her) mal in der NetBSD Community Gedanken von Leuten gab, OpenRC zumindest als zweites System zu supporten. OpenRC lief glaube ich, und war über pkgsrc installierbar, wenn ich mich recht erinnere, aber es ist genau daran gescheitert, dass die Skripts nicht gemacht wurden. Bei NetBSD ist der Aufwand aber auch größer. Unter FreeBSD kann man so wie ich das verstanden habe fast mit Search and Replace arbeiten.

Sorry, das war jetzt ein wenig viel, aber ich glaube die Ablehnung hier basiert zu einem Teil darauf, dass vielleicht das eine oder andere hier erwähnte vielleicht nicht so bekannt ist.

Persönlich halte ich den interessantesten Punkt in der Möglichkeit Code wieder zu verwenden und auch darin, dass nicht alles in Richtung systemd/launchd läuft, sondern es da ein wenig Wettbewerb gibt. Rein von der Verwendung her bietet es einigen Komfort, aber da das jetzige System nicht so krass anders ist habe ich was die BSDs angeht jetzt auch nicht so den extremen Bedarf. Nur unter Linux ist es halt echt nett was zu haben, was (auch wenn die Commands mitunter anders sind) was näher an einem BSD und dessen Philosophie ist.