FreeBSD 15 erhält optional einen grafischen Installer

"Wir wollen neuere ZFS Features".
bei ZFS weiß ichs nicht, ich war davon ausgegangen, dass die Entwicklung auf Linux und FreeBSD relativ einhergeht, das schließt aber nicht aus, dass es nich doch irgendwann Features nur auf Linux gibt;

Weiß jemand um was es da im Detail geht? Ist das der limitierende Faktor bei deren Projekt?
ein großes Thema waren und sind bei TrueNAS ja die Apps bzw bei Core "Plugins" genannt - auf jails basierend;
das wurde bei Scale auf Docker/k8s geändert - allerdings mit eigenen Anpassungen, nichts ist vanilla

Die Plugins sind bei Core mittels jails nie richtig aus dem Start weggekommen, wollens jetzt bei Scale mit Docker/Kubernetes aus dem Vollen schöpfen - und begeben sich m.E. damit in eine Support-Hölle, da sie jede App erst noch selber in die Hand nehmen und auf ihre Art verbiegen (müssen) um sie an ihr System anzupassen; ich wage zu behaupten dass ihnen das irgendwann mal spätestens bei nem Update mit der einen oder anderen App um die Ohren fliegen wird, aber ich schau immer mal wieder die neue Entwicklung an.
 
ich war davon ausgegangen, dass die Entwicklung auf Linux und FreeBSD relativ einhergeht
Ja. Das klappt ganz gut.
Das zeigt auch ein Blick ins jeweilige Repository:
OpenZFS: https://github.com/openzfs/zfs/blob/master/META
main-Repo bei FreeBSD: https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/META

Das aktuelle stabile Release für Linux ist 2.2.4 -> https://zfsonlinux.org/
Das für das kommende FreeBSD 14.1 auch: https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/META?h=releng/14.1

begeben sich m.E. damit in eine Support-Hölle, da sie jede App erst noch selber in die Hand nehmen und auf ihre Art verbiegen (müssen) um sie an ihr System anzupassen
Sich um die "Apps" kümmern müssen sie auch schon jetzt. Nur das sie da noch sehr viel mehr selbst machen müssen, weils nicht so viele etablierten Tools und Vorgehensweisen gibt wie bei Docker-Containern.
Außerdem gibt man den Usern die Möglichkeit in die Hand einfacher Container ins System zu bringen.

Ist schon ein bisschen tragisch, das FreeBSD bei den Containern so ein bisschen abgehängt scheint. Immerhin hat man ja mit Jails schon relativ lange eine gute Grundlage, um App-Container zu bauen. Und Tools wie Bastille greifen das ja auch auf.
Im Grunde könnte man mit Jails sicher auch Docker-kompatiblen Container-Support bauen. Ich weiß nicht, woran es da konkret gerade hängt. Ich spekuliere mal ein wenig umher, ohne mich damit näher beschäftigt zu haben (vielleicht kann jemand was dazu sagen):

  • Einfach nur ne Docker-Runtime zu haben ist nicht genug. Viele fertige Docker-Images sind auf Linux ausgelegt und wenn man sich so ein fertiges Images holt, läuft man in Probleme da die "Apps" Linux-Spezialitäten verwenden.
  • Einige Linux-Techniken die Docker selbst benutzt, lassen sich mit Jails vielleicht nicht so wirklich nachbauen?
  • Docker fußt sehr auf layered-filesystems. Ich weiß aus eigener Erfahrung, das das unionfs welches FreeBSD bietet so die ein oder anderen Problemchen hat, ums mal vorsichtig auszudrücken (aber unionfs soll ja jetzt wohl mal angegangen werden).

ich wage zu behaupten dass ihnen das irgendwann mal spätestens bei nem Update mit der einen oder anderen App um die Ohren fliegen wird
Sagen wir mal so: Wenn sich viele an der Entwicklung von irgendwas beteiligen hast Du natürlich immer den Vorteil, das Du halt viele Ressourcen hast. Du hast aber gleichzeitig auch immer den Nachteil das Du Dir ein "Viele-Köche-verderben-den-Brei"-Effekt einfängst. Weil Du dann eher mal was drin haben kannst, was Dir Deine Sachen kaputt macht.
 
Müssten sie - tun sie aber nicht mehr (für Core), das dümpelt auf irgend nem Stand dahin und ist quasi tot.
Wie auch immer. Mein Argument war ja, das Ihnen hier das umschwenken auf die Linux-Basis keine Nachteile (eher sogar Vorteile) beschert.
Das für ist es ohne Belang, ob die sich da jetzt noch drum kümmern oder es schon aufgegeben haben.

Habens auch irgendwo mal geschrieben, dass sie sich da nur noch auf Scale konzentrieren.
Ja. Das hast Du doch selbst sehr schön verlinkt. :-)
 
13
Wie auch immer. Mein Argument war ja, das Ihnen hier das umschwenken auf die Linux-Basis keine Nachteile (eher sogar Vorteile) beschert.
Das für ist es ohne Belang, ob die sich da jetzt noch drum kümmern oder es schon aufgegeben haben.
naja, eigentlich supporten sie Core ja noch...
das mit den nicht mehr gewarteten Plugins mißfiel einigen
wobei es grade bei solchen "Filer-Betriebssystemen" ja grundsätzlich zwei Lager gibt - die einen die "nur nen Filer" wollen und die anderen bei denen der Filer zusätzlich noch alles mögliche machen soll

da siehste mal.... :ugly:
 
Ist schon ein bisschen tragisch, das FreeBSD bei den Containern so ein bisschen abgehängt scheint. Immerhin hat man ja mit Jails schon relativ lange eine gute Grundlage, um App-Container zu bauen. Und Tools wie Bastille greifen das ja auch auf.
Im Grunde könnte man mit Jails sicher auch Docker-kompatiblen Container-Support bauen. Ich weiß nicht, woran es da konkret gerade hängt. Ich spekuliere mal ein wenig umher, ohne mich damit näher beschäftigt zu haben (vielleicht kann jemand was dazu sagen):

  • Einfach nur ne Docker-Runtime zu haben ist nicht genug. Viele fertige Docker-Images sind auf Linux ausgelegt und wenn man sich so ein fertiges Images holt, läuft man in Probleme da die "Apps" Linux-Spezialitäten verwenden.
  • Einige Linux-Techniken die Docker selbst benutzt, lassen sich mit Jails vielleicht nicht so wirklich nachbauen?
  • Docker fußt sehr auf layered-filesystems. Ich weiß aus eigener Erfahrung, das das unionfs welches FreeBSD bietet so die ein oder anderen Problemchen hat, ums mal vorsichtig auszudrücken (aber unionfs soll ja jetzt wohl mal angegangen werden).
Meiner Beobachtung nach waren das letztendlich zwei Probleme: Einmal fehlendes Interesse. Es konnten zwar über Jahre viele Leute sehr lautstark schreien, dass sie gerne eine OCI Container Runtime hätten, aber immer wenn es darum ging etwas in die Richtung zu implementieren war es plötzlich ganz still. Es gab durchaus Ansätze und zumindest mit runj - https://github.com/samuelkarp/runj - auch eine belastbare Grundlage, auf der man hätte aufsetzen können, aber es hat sich halt nie eine Gruppe Interessierter gefunden, die sich dort engagiert hätte. Um dort besser zu werden, gibt es inzwischen die FreeBSD Enterprise Working Group - https://wiki.freebsd.org/EnterpriseWorkingGroup - die allerdings noch immer händeringend Leute sucht, die nicht nur reden, sondern auch bereit sind sich zu engagieren.

Das andere Problem ist, was du schon ansprichst und woran z.B. auch Microsoft mit ihrer OCI-Implementierung teilweise gescheitert ist. Das OCI Container Ökosystem ist zu 110% gegen Linux gebaut und viel zu viele Entwickler in dem Bereich haben mal so gar kein Verständnis dafür, dass es noch andere Systeme gibt. Und, das ist jetzt gemein, wahrscheinlich auch gar nicht die Fähigkeiten. Ich bin bereit drum zu wetten, dass in dem Moment, wo es eine OCI Runtime für FreeBSD gibt, dass Geheul losgeht, dass ein Großteil der Container aus irgendwelchen fischigen öffentlichen Registries gar nicht oder nur mit Einschränkungen unter dem Linuxulator laufen.
 
die allerdings noch immer händeringend Leute sucht, die nicht nur reden, sondern auch bereit sind sich zu engagieren.
Womit sich der Kreis schließt und wir wieder bei dem Thema sind, „wie bekomme ich (junge) Leute ran“.

Ich dachte aber tatsächlich, dass der eine oder andere FreeBSD Entwickler auch in diesem Forum unterwegs ist und sich meine (und andere) Posts zu Herzen nimmt. Denn dann könnte er FreeBSD nach meinen Vorstellungen mitgestalten und wäre überrascht über den plötzlichen bahnbrechenden Erfolg.
 
Es konnten zwar über Jahre viele Leute sehr lautstark schreien, dass sie gerne eine OCI Container Runtime hätten, aber immer wenn es darum ging etwas in die Richtung zu implementieren war es plötzlich ganz still.
Ja. Ein bekanntes Problem.

runj hatte ich tatsächlich auch schon mal am Rande mitbekommen. Wobei ich selbst mich weniger für OCI interessiere. Wenn, dann eher mittelbar. In der Wirkung, das es die FreeBSD-Plattform attraktiver machen könnte, wovon ein Projekt ja i.d.R. insgesamt profitiert.
Was mich wirklich interessiert ist diese unionfs-Geschichte. Da hab ich auch Lust zu, Zeit zu investieren.

Um dort besser zu werden, gibt es inzwischen die FreeBSD Enterprise Working Group
Ja. Die Mailingliste ist auch eher ... übersichtlich.

auch Microsoft mit ihrer OCI-Implementierung teilweise gescheitert ist.
Es entbehrt ja nicht einer gewissen Ironie. Da ja lange Zeit die Beschwerden (vor allem aus dem Linux-Umfeld) Richtung Microsoft kam, das die sich nicht an Standards halten und inkompatibel zum Rest der Welt sind und nu selbst zum Opfer werden.

Ich bin bereit drum zu wetten, dass in dem Moment, wo es eine OCI Runtime für FreeBSD gibt, dass Geheul losgeht
Das wäre auch meine Vermutung. Weshalb ich mir vom OCI-Support alleine auch noch gar nicht unbedingt so übermäßig viel verspreche.

Denn dann könnte er FreeBSD nach meinen Vorstellungen mitgestalten und wäre überrascht über den plötzlichen bahnbrechenden Erfolg.
Ja. :-)
Die sollten echt mehr auf Dich hören. Bisher haben Deine Vorschläge noch jedes Projekt zum Erfolg geführt. :-)

und wir wieder bei dem Thema sind, „wie bekomme ich (junge) Leute ran
Das ist eben nicht so einfach, wenn man nur begrenzt Ressourcen hat.
Da steht man vor der Wahl: Investiere ich die, um anstehende Problemfelder zu beackern (inkl. Sachen die ich selbst brauche) oder investiere ich die, um Attraktivität zu steigern in der Hoffnung darüber mehr Ressourcen heranzuziehen.
Diese Entscheidung ist ja nicht trivial. Vor allem da ja das bearbeiten von Problemfeldern ja auch teilweise notwendig ist für die Attraktivität.

Es ist also ein bisschen komplexer und nicht allein mit "Da müsste man mehr machen" oder "Ein Standard-Desktop wäre cool" zu erschlagen.
 
Villeicht als ergänzung - ich wechsel gerade aus technischen gründen privat bei 2 Serversachen von OpenBSD auf Archlinux

Ah, interessant. Ich habe vor einigen Jahren meinen allerersten privaten Server aus Jugendzeit (um nicht zu sagen Kindheit), ein Debian-System durch OpenBSD ersetzt. Arch hab ich am Server noch nie verwendet. Darf ich neugierig sein und nach den technischen Gründen fragen? Also sowohl von OpenBSD weg als auch warum Arch, wenn du Debian lieber hast?

Ich mach sonst privat wenn ich Linux nutze eher Debian, gerade auch auf dem Desktop. Ich bin durchaus 20 Jahre konsolenerfahrne, mag den OpenBSD installer auch sehr gerne.
Also wie geschrieben habe ich mit Debian begonnen. Ich war da persönlich nie ein riesiger Fan von Debian und Debian-basierten Systemen gewesen. Habe Debian und Ubuntu einfach am Anfang mal probiert und dann Ubuntu am Anfang und danach halt immer wieder beruflich weil alle so tun als gäbe es nichts anderes. Aber hab auch nichts gegen Debian sonst, ist nur nicht meins. Bin mit apt nie ganz warm geworden und das zerteilen von Paketen und so. Aber wie gesagt, soll nicht irgendwie vorwurfsvoll sein. Man sieht ja, dass viele gut damit fahren.

Aber unter Arch vermisse ich die einfache und meist auch schnelle Installationsgui von Debian, gerade jetzt ganz akut. Ich installier halt nicht jeden Tag X mal arch sondern ... alle paar Jahre, da ist es für mich sehr nett wie die Debian etwas an die Hand genommen zu werden.
Ich muss gestehen es ist ewig her, dass ich irgendwas mit einem Installer installiert habe. Ich hab ein 15+ Jahre altes Arch, BSDs kommen meist per Image wohin, also seien es Server, Raspberry Pis oder sonst was. Aber ich fand damals den Debian-Installer sicher nicht schlecht, find auch den von FreeBSD und DragonFly nicht schlecht, genausowenig wie von OpenBSD oder der von NetBSD (der ist sogar ziemlich cool, hab den mal in Action mit schlechter Internetverbindung aber "aus dem Internet" installieren verwendet und mit retries und so hat das schon was). Ich weiß nur es gab auch immer mal wieder Linux-Installer die Sachen zerschossen haben, also Entweder Partitionen oder beim Upgrade mal, usw.

Der grafische Installer für FreeBSD hat mich nur an den (alten?) von SuSE denken lassen. Nachdem das das Go To Desktop-Linux meines Vaters ist habe ich den ab und zu mal gesehen und mal mir deshalb eben aus damit schön übersichtliche komplexe Installationen zu machen. Also komplex im Sinne von dem was eh schon geht, aber halt mit mehr Infos dazu, quasi eine eingebaute Doku und zusätzlich vielleicht wenn man zum Beispiel was mit Packages auswählen hat, dass man keine Ahnung das Desktop-Environment oder das Logo als Bild drin haben kann. Und wenn da eben viel konfiguriert werden kann dann eben eine Übersicht am Ende wo ich einfach was anklicken kann wenn ich mich doch anders entscheide. Bei SuSE war das eben glaub ich so. Ist halt netter als zwischen Screens zu wechseln oder sich zumindest weit mti Tastatur bewegen zu müssen.

Für mich tut's wie gesagt auch ein OpenBSD Installer und bin eben wegen Gentoo und Arch-Geschichte sicher nicht wählerisch. Arch hatte ja früher noch so nen schonen minimalen Intaller. Gentoo hatte mal einen der auch bei ziemlich vielen Leuten damals jegliches andere System verspeist hat bei Multi-Boot-Systemen.

Ich glaub nur das Wichtigste ist Systeme nicht nach ihren Installern zu beurteilen. Den verwendet man im besten Fall nicht regelmäßig. Find's immer witzig wenn es irgendwo ein "Review" zu einem OS/einer Distro gibt und das hört nach der Installation auf. Aber auch schon deshalb ewig mehr keins gelesen. Bin mittlerweile generell ziemlicher Review-Banause, auch bei Filmen, Spielen, etc. Hoffe das klingt nicht zu schlimm, aber gefühlt sind Leute die ihre Zeit mit Reviews verfassen verbringen meist nicht die Hellsten. Und leider auch nicht Leute, die Trailer, etc. machen. Ist zu oft passiert, dass ich genau das gegenteil von dem was im Review oder Trailer gesagt wurde bekommen habe. Drum muss man Zeug halt leider immer selbst anschauen, wenn man ein Bild davon haben möchte. Sei es ein OS oder ein Kinofilm.

Okay, jetzt bin ich aber abgedriftet. Hoffe das nimmt mir keiner übel.

Das aktuelle stabile Release für Linux ist 2.2.4 -> https://zfsonlinux.org/
Das für das kommende FreeBSD 14.1 auch: https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/META?h=releng/14.1

Heißt das dann, die haben gelogen oder heißt das die waren treibende Kraft und da wird sich in Zukunft weniger tun?
 
Zurück
Oben