FreeBSD Zukunft - systemd, nosh, ...?

[darktrym]

Lumina ist definitiv nix BSD-zentrisches eher ein Projekt damit iXsystems ein Alleinstellungsmerkmal hat und mehr Marketing betreiben kann.
Die Codequalität ist furchtbar und der Support jenseits von FreeBSD bescheiden.
Das einzige was gut daran ist, man lernt viel die einzelnen Komponenten von Betriebssystemen besser zu integrieren.

 

[guru]

Wer Betriebssysteme oder Computer so benutzt, wie ich sie von klein auf kenne, und das sind doch nicht wenige, zeigt FreeBSD gegenüber Linux ein paar schöne Simplizitäten.

Ich bekomme einen Rahmen. Bei GNU/Linux kann man rigoros alles tauschen, man muss sich für diese Sicherheitsoption entscheiden, dafür dieses neue Paket vernachlässigen, man könnte beginnen, alles zu "zerbasteln" und auch als neuer Nutzer weiß man nicht, wo man Hand anlegen sollte ... und wo besser nicht. 25 Punkte sprechen für Arch Linux, bei Manjaro sind's nur 23 ... Dann stolpert man über ein brandneues Antergos mit dem und dem Installer, der alles für Anfänger leichter machen soll ... Ich folge auf Facebook einigen archnahen Gruppen, in denen das erste Linux genauso enthusiastisch gefeiert wird wie unerwartet blödsinnige Probleme verzweifelt gelöst - oder auch nicht - werden. GNU/Linux hab ich mir schon bei weitem öfter zerschossen als *BSD.

Der Standarduser mag es vielleicht angenehm finden (und zu dieser Gruppe zähle ich mich), ein System vor sich zu haben, das so ist wie's ist, mit dem man viel machen könnte (ich habe nur versuchsweise custom kernels kompiliert, benutze kaum/nie Ports, benutze eher alles, "wie's ist", abgesehen von kleinen Änderungen in /boot/loader.conf und so), aber wo man doch nur seine gewohnten Programme installiert und mit denen wie gewohnt arbeitet, ohne vorher rumzufuhrwerken. Kaufe ich ein Auto, stell' ich auch die Sitze ein und die Heizung aus und fahr los. Oldtimerfans gibt's, aber da zählen wenig Autofahrer dazu ... Meine Arbeit am Computer beschränkt sich in vielen Fällen Kommunikation via Chat, Mail, etc, Musikkonsum über Youtube oder Clementine, Lernen aus Unterlagen, Schreiben von Protokollen und Nachschlagen in Enzyklopädien, ab und an eine Runde Sauerbraten oder das Brennen einer CD für's Auto.

Ich halte den (verrufenen?) Ansatz, FreeBSD etwas zu popularisieren insofern für interessant, alsdass Menschen andere Sachen kennen lernen. Vielleicht kann es sich etablieren, es hat Vorteile gegenüber Windows (die auch Otto bemerkt), vielleicht kann das viel Frust (in der Gesellschaft ) sparen und motivierte Programmierer heranzüchten. Und wir profitierten von nativem Steam, vielleicht eines Tages Photoshop etc...?

Ich weiß bei FreeBSD, wie ich wo tun muss. pkg install kde vlc usw. Das schöner verpackt (analog zu pkg_mgr bei OpenBSD?) gleich vorweg angeboten, etwas aufgehübscht, könnte das Interesse an BSD wecken und vielleicht die Manpower erhöhen, sich um das Projekt gut zu kümmern. Das ist keine Annäherung an Windows, auch Mac, der C64, DOS, RISCOS etc. funktionieren nach dem Prinzip des definierten Rahmens. Auf die gute Ausnahme Linux will ich trotzdem nicht verzichten Wie seht Ihr das?

Es ist konservativ. Ich benutze "mein" FreeBSD, "mein" FreeBSD lässt mich nicht im Stich, was einmal geht, wird auch in 10 Jahren noch laufen. Gilt auch für OpenBSD, wie ich finde. NetBSD benutze ich zu wenig, um das sagen zu können.

Da arbeitet man ein paar Jahre lang, wird plötzlich 24, auf einmal ist die Pubertät vorbei, man will keinen Kernel mehr kompilieren, Gentoo wird zum "Naja, vielleicht irgendwann"-Abenteuer und plötzlich versteht man die Bequemlichkeit der älteren Familienmitglieder

 

[CrimsonKing]

was einmal geht, wird auch in 10 Jahren noch laufen.

Naja; gerade FreeBSD ist da m.E. durchaus experimentierfreudig. pkg_add ist ja auch raus.

 

[guru]

pkg_add ist ja auch raus.

Wenn das alles an im Alltag spürbaren Veränderungen war ...

 

[-Nuke-]

FreeBSD ist ein eher schlechtes Beispiel was Stabilität in der Benutzung angeht. Die ganze Umstellung auf PKG, die Umstellung von rc.conf auf jail.conf im Falle von Jails, diverse Änderungen in Flags und Parametern diverser Konfigurationen, die zukünftige Einführung von PkgBase, an sich ständige Umbauten in den Ports (aktuell: Flavors)...

Man wandert ziemlich häufig von einem deprecated Zustand in den nächsten deprecated Zustand. Man lese im entsprechenden Flavor-Thread wie schmerzvoll Umstellungen für Einige sind. Und hätte sich "damals" keiner gefunden der das alte portmaster auf den aktuellen Stand bringt, wäre es für einige noch viel schmerzvoller geworden. Es war nicht von Haus aus kompatibel.

Ich persönlich sehe das zwar nicht negativ, weil ich Fortschritte durchaus begrüße, aber die Reaktionen der Anderen hier im Forum lese ich ja selbst.

 

[CrimsonKing]

FreeBSD führt Flavors wenigstens nur stoßweise ein und stellt nicht gleich das ganze Ökosystem um. Obwohl ich mir sicherlich auch gewünscht hätte, die hätten mit etwas weniger kritischem als Python angefangen, von dem das halbe System abzuhängen scheint.

 

[Yamagi]

Ich sehe es so, dass man einen Mittelweg finden muss. Auf der einen Seite mag niemand Veränderungen, weshalb man sie vermeiden sollte, solange sie nicht zwingend notwendig sind oder einen großen Gewinn bringen. Auf der anderen Seite kann man die Zeit aber nicht anhalten, nur weil es immer jemanden gibt, den eine Veränderung gerade nicht passt. Denn dann kommt man niemals weiter.

Bezogen auf FreeBSD war der Wechsel von pkg_add zu pkg so eine zwingende Notwendigkeit. pkg_add war alleine durch die weitgehend fehlende Abhängigkeitsauflösung de facto unbenutzbar, da man auf ein konzeptionell komplett anderes System wechselte hatte es keinen großen Sinn irgendwie auf Biegen und Brechen das alte Interface weiterzuunterstützen. Alle 10 Jahre seine Scripte einmal anzupassen ist sicherlich auch nicht zu viel verlangt. Auf der anderen Seite herrscht bei den Ports inzwischen im vierten Jahr ein zumindest mich sehr nervender Prozess der dauerhaften Veränderung. Die Flavors sind da nur die aktuelle Spitze des Eisbergs. Was zumindest bei mir dazu geführt hat, dass ich einen Großteil meiner Ports zurückgegeben habe. Auch hier, gerne ab uns an mal einen größeren Umbau. Aber nicht bei jedem kleinen Update eine Grundsatzdiskussion darüber, wie denn ein Port in der jeweiligen Woche gerade mal auszusehen hat, weil es mal wieder schlecht kommunizierte und kaum dokumentierte Veränderungen gab.

 

[-Nuke-]

Flavors ist ja hauptsächlich durch Python eine Notwendigkeit. Einige wichtige Ports hängen von Python 2 ab, andere von Python 3. Leider ist das Port-System noch darauf ausgelegt "entweder/oder". Wer DEFAULT_VERSIONS+=python=3.6 setzt, der wird Probleme bekommen z.B. Samba zu bauen, weil es dann aufgrund langer Verkettungen dazu kommt, dass er py36-setuptools und py27-setuptools parallel installieren will. Das knallt, weil beide Ports versuchen /usr/local/bin/easy_install (ohne Version) einzurichten.

Eigentlich müsste man sich auf eine Python Version festlegen (bei FreeBSD ist das noch Python 2.7) und sämtliche Python3-Ports ausschließlich mit Versions-Nummer hinten dran installieren. Aber das kann das Port-System wohl noch nicht, wenn es das dann überhaupt können wird.

Linux-Distributionen kriegen es ja auch hin. ArchLinux z.B. setzt Python 3 als Standard und patcht Python2-only Sachen entsprechend um (Shebang auf python2 setzen, statt python). Im Fall von den python2-setuptools wird dann am Ende "rm "$pkgdir"/usr/bin/easy_install" ausgeführt. Die Projekte die noch eine harte Abhängigkeit an Python 2 haben sind nicht sehr zahlreich, aber leider ziemlich groß (z.B. LLVM, Samba, ...).

Somit kann der Anwender relativ schmerzfrei Python2 und Python3 parallel benutzen. KISS Prinzip eben. Bei FreeBSD kommt mir das leider alles ziemlich fett und aufwändig vor. Man will eben irgendwie alles mit einem großen Hammer erschlagen.

 

[Yamagi]

Bei FreeBSD kommt mir das leider alles ziemlich fett und aufwändig vor. Man will eben irgendwie alles mit einem großen Hammer erschlagen.

Das ist nun vielleicht gemein, aber ich habe bei den Ports seit längerem das Gefühl, dass einige Personen dort ihr ganz persönliches Luftschloss bauen. Das Portsystem an sich ist wahnsinnig kompliziert und wird mit jedem neuen Feature nur noch komplexer gemacht. Darum hat man eine Bürokratie gebaut, die jeden preußischen Beamten neidisch machen würde. Und im gleichen Atemzug beschwert man sich, dass niemand mehr mitspielen will, es immer weniger Committer und Port Maintainer gibt.

Man könnte einfach mal einen idiologiefreien Blick ins Linux-Lager werfen. Mein Vorschlag ist so schon seit längerem, habe ich auch schon mehrfach an anderen Stellen zur Diskussion gebracht: Schmeißt das ganze verdammte Port-Framework in den Müll. Die Ports sollten nur noch formale Beschreibungen ohne jegliche Programmlogik sein. Die Logik steckt im Package-Builder, der die formalen Beschreibungen parst. Wer sich einen Port zum Paket compilen will, muss sich dann halt den Package-Builder installieren. Das wäre für Port Maintainer von Vorteil, weil der Package-Builder eine saubere Umgebung bereit stellt und all die Probleme durch verharzte Hostsysteme wegfallen. Außerdem würde neue Funktionalität einfach im Package-Builder implementiert werden können, Änderungen an den Ports selbst wären nur noch selten oder sogar gar nicht mehr notwendig. Auch könnte man den Package-Builder in einer geeigneteren Sprache als den paar tausend Zeilen Makefile implementieren, aus dem das Port-Framework besteht.

Auf der Grundlage könnte man den ganzen ganzen Workflow ändern. Port Maintainer laden ihre Änderungen an Ports über ein Webinterface hoch. Ist der Maintainer neu, guckt über die ersten 5 oder so Einreichungen ein Committer rüber und klickt auf "freigeben". Hat er sich bewährt, fällt dieser Schritt weg, die Änderungen werden automatisch in ein "Testing"-Repo eingefügt und gebaut. Klappt der Bau und klickt innerhalb von 3 Tagen kein Nutzer auf "Hier gibt es ein Problem", migriert die Änderung automatisch ins normale "Latest"-Repo. Der Maintainer kann festlegen, ob sie nach weiteren 3 Tagen wieder automatisch in "Quarterly" migrieren. Das würde die Committer massiv entlasten und den Prozess wesentlich transparenter und zügiger machen, was sicher wiederum viele Nutzer begeistern würde auch mal Maintainer zu spielen.

Aber wie gesagt, mit solchen Vorschlägen braucht man gar nicht zu kommen. Ich habe es ein paar Mal versucht, mit wesentlich weniger radikalen Varianten und die Reaktion war jedes mal ein unfreundliches "Geh wo du wohnst!".

 

[Freigeist]

Es ist konservativ. Ich benutze "mein" FreeBSD, "mein" FreeBSD lässt mich nicht im Stich, was einmal geht, wird auch in 10 Jahren noch laufen.

Sehnsucht nach der Postkutsche?

FreeBSD sollte erst einmal mit Meltdown fertig werden. Dann können wir über "lässt mich nicht im Stich" reden.

 

[rubricanis]

Aber wie gesagt, mit solchen Vorschlägen braucht man gar nicht zu kommen. Ich habe es ein paar Mal versucht, mit wesentlich weniger radikalen Varianten und die Reaktion war jedes mal ein unfreundliches "Geh wo du wohnst!".

Vielleicht waren deine damaligen Vorschläge auch nicht radikal genug. Das ist die Kehrseite eines konservativen Blickes auf die Welt! ;-) Man bekommt halt nie etwas umsonst...

 

[Athaba]

Das Portsystem an sich ist wahnsinnig kompliziert und wird mit jedem neuen Feature nur noch komplexer gemacht. Darum hat man eine Bürokratie gebaut, die jeden preußischen Beamten neidisch machen würde. Und im gleichen Atemzug beschwert man sich, dass niemand mehr mitspielen will, es immer weniger Committer und Port Maintainer gibt.

Ich stimme zu was das Thema Komplexität angeht. Ich möchte aber auch hervorheben, dass das wenn ich es mit der Linuxwelt vergleiche eher auf der Tatsache basiert, dass die Komplexität von diversen Ports höher wird. Der Weg configure und make install funktioniert immer seltener. Der Unterschied den ich da eher sehe ist, dass man in der Linuxwelt für jeden "Port" (spec, PKGBUILD, etc.) das Rad komplett neu erfindet und ständig überall was bricht weil der Hack dann nicht mehr richtig funktioniert.

Ein anderer Punkt ist auch, dass sich die Komplexität teilweise nur verlagert. Vieles an Information ist nämlich eher Metadatenmäßig aufgebaut. Das beginnt so langsam mit pkg. Ich hätte nur ungern, dass die FreeBSD ports sich in eine Richtung entwickelt, wo jeder Port (oder halt das Spec dann) ein Problem das viele Leute haben ganz anders löst.

Zum Thema Port Maintainer: Stimmt das? FreeBSD hat für echt alles einen Port und die Ports sind aktuell und als jemand der auch gern Commit Messages liest sehe ich dass es sowohl einige Mentoren zu geben scheint, als auch, dass es coole Verbesserungen, wie Flavors gibt.

Ich habe ziemlich lange Arch Packages gemacht (mittlerweile nicht mehr, weil ich kaum noch dort unterwegs bin). Das System ist eher simpel, aber auch da fließt Komplexität ein und ständig bricht was und es gibt alle paar Monate einen neuen Standard wie man es richtig machen sollte, der auf viele Fälle nicht zutrifft und dann kommt's drauf an wie aktiv der Maintainer ist, ob er sich dran hält und welche Version von dem was gerade Best Practice ist eingehalten wird.

Das wird zwar besser, aber eher dadurch, dass man sich da etwas dem was FreeBSD macht annähert.

Ich bin mir nicht sicher, was du mit Bürokratie meinst, aber falls du damit meinst, dass dieses ganze Zeug, wie GH_user und so an Formulare erinnert, dann hat das den großen Vorteil, dass dann eine Verbesserung gleich auf alles zutrifft und gefühlt (ist ja glaube ich ohnehin eher subjektiv) eher weniger böse Überraschungen gibt.

Man könnte einfach mal einen idiologiefreien Blick ins Linux-Lager werfen. Mein Vorschlag ist so schon seit längerem, habe ich auch schon mehrfach an anderen Stellen zur Diskussion gebracht: Schmeißt das ganze verdammte Port-Framework in den Müll. Die Ports sollten nur noch formale Beschreibungen ohne jegliche Programmlogik sein. Die Logik steckt im Package-Builder, der die formalen Beschreibungen parst. Wer sich einen Port zum Paket compilen will, muss sich dann halt den Package-Builder installieren. Das wäre für Port Maintainer von Vorteil, weil der Package-Builder eine saubere Umgebung bereit stellt und all die Probleme durch verharzte Hostsysteme wegfallen. Außerdem würde neue Funktionalität einfach im Package-Builder implementiert werden können, Änderungen an den Ports selbst wären nur noch selten oder sogar gar nicht mehr notwendig. Auch könnte man den Package-Builder in einer geeigneteren Sprache als den paar tausend Zeilen Makefile implementieren, aus dem das Port-Framework besteht.

Ich glaube ich weiß worauf du hinaus willst. Die Sache ist nur, dass ich ständig Systeme die rein deklarativ und ohne Programmlogik sind im großen Stil zusammenbrechen und erst wieder irgendwo anders, meist viel hackiger Logik brauchen. Ja, ich habe auch lieber Sachen, wo ein deklarativer Ansatz möglich ist. Ich habe aber auch gesehen, wo es scheitert und wie es weitaus grausiger ist ein System, das theoretisch perfekt wäre einfach ständig auf Koalitionskurs mit der Realität ist. Ein System, das derart abhängig vom Rest der Welt ist und darauf keine wirkliche Auswirkung hat mit einer simplen Beschreibungssprache versehen zu wollen halte ich nicht für eine gute Idee. Das würde funktionieren, wenn Leute anständige Software, einheitliche Build Systeme und einfach saubere Projekte führen würden, oder da zumindest bei der großen Mehrheit der Fall wäre und sich vielleicht die Welt generell in diese Richtung bewegen würde. Das ist aber (leider) nicht der Fall.

Das Resultat ist eben, dass entweder die Komplexität verschoben wird und man so generisch werden muss, dass man zumindest erlaubt erst wieder mit Programmlogik reinzupfuschen oder man eine Beschreibungssprache braucht, die relativ schnell Turing Complete ist (oder nah dran) und mit der sich dann wirklich nur ein paar Leute auskennen, was wiederum zu Mangeln an Committern führt.

Da finde ich den Ansatz so etwas über eine Skriptsprache mit Ports, die möglichst deklarativ aussieht, wo das auch sinnvoll möglich ist (quasi alles was mit configure && make install, etc. funktioniert) den besseren Ansatz. Ich finde auch, dass er ziemlich gut funktioniert, wenn ich das nüchtern auch mit Linux-Systemen die ich grundsätzlich mag vergleiche. Ich brauche nicht ständig irgendwelche Third Party Repos zuschalten, nicht großartig dem package manager irgendwelche Configs übergeben (oder das irgendwie anders konfiguieren) oder irgendwelche Änderungen an den.. ich nenne es mal "Ports" (sprich das Pendant dafür) machen und mir potentiell relativ Mühsam ein eigenes Repo zuschalten. Für die Anzahl an Leuten, die dahinter steht würde ich Ports eigentlich als ziemlich gut bezeichnen. Selbiges würde ich über diverse andere Projekte nicht behaupten. Allerdings rede ich da von ein paar großen Systemen (RedHat, Arch, Debian), die ich so einigermaßen gut kenne. Die sind zwar nicht schlecht oder ähnliches, aber für das was da an Leuten dahinter steht kommen die glaube ich kaum ran. Es gibt sicher Projekte, wo das besser funktioniert. Auch würde ich sagen, dass Arch da wesentlich bessere Arbeit leistet als noch vor einigen Jahren (nicht nur was AUR betrifft!).

Auf der Grundlage könnte man den ganzen ganzen Workflow ändern. Port Maintainer laden ihre Änderungen an Ports über ein Webinterface hoch. Ist der Maintainer neu, guckt über die ersten 5 oder so Einreichungen ein Committer rüber und klickt auf "freigeben". Hat er sich bewährt, fällt dieser Schritt weg, die Änderungen werden automatisch in ein "Testing"-Repo eingefügt und gebaut. Klappt der Bau und klickt innerhalb von 3 Tagen kein Nutzer auf "Hier gibt es ein Problem", migriert die Änderung automatisch ins normale "Latest"-Repo. Der Maintainer kann festlegen, ob sie nach weiteren 3 Tagen wieder automatisch in "Quarterly" migrieren. Das würde die Committer massiv entlasten und den Prozess wesentlich transparenter und zügiger machen, was sicher wiederum viele Nutzer begeistern würde auch mal Maintainer zu spielen.

GitHub und Pull Requests könnten das auch leisten und man könnte wohl auch relativ einfach für einzelne Ports ein ähnliches System machen. Ich stimme zu, dass das System so wie es ist einigermaßen ineffizient ist, aber ich denke dass das mehr ein Problem des Prozesses ist, der bei einer Umstellung wohl auch von technischen Umstellungen profitieren würde, aber ich habe da meine Zweifel, dass man da mit rein (oder hauptsächlich) technischen Änderungen einen großen Wurf hinbekommt.

Aber wie gesagt, mit solchen Vorschlägen braucht man gar nicht zu kommen. Ich habe es ein paar Mal versucht, mit wesentlich weniger radikalen Varianten und die Reaktion war jedes mal ein unfreundliches "Geh wo du wohnst!".

Das lässt mich noch mehr denken, dass es generell ein eher menschliches Problem ist, als wirklich ein technisches. Ganz ehrlich macht mich die Community auch teilweise ziemlich unglücklich. Ich schreibe zwar nicht, aber lese durchaus auch mit. Leider sind mir mittlerweile ein paar Communities dadurch aufgefallen, dass sie zunächst nachwuchsfördernd auftreten, aber dann oftmal sehr reserviert ist, dass es teilweise zumindest stark an Statusdenken und Revier verteidigen erinnert. Das dürfte häufig auch vor allem von Leuten ausgehen, die noch nicht allzu lange in einer Community aktiv sind und sich quasi gerade erst die volle Mitgliedschaft (also Core Team, Commit Bit, etc.) erarbeitet haben.

Im Übrigen soll das da oben nicht heißen, dass ich denke es sei alles gut, perfekt oder bedürfe keiner Veränderung. Auch glaube ich, dass du das eher überschlagsartig beschrieben hast. Mir ging's vor allem darum zu sagen, dass auch wenn ich selbst denke, dass man Logik im besten Fall an vielen Orten raus halten soll und auch, dass viel zu wenig auf Trennung geachtet wird, man bei manchen Dingen eher einfährt. Ich habe das selbst ein paar mal gemacht und häufig hat es damit zu tun, dass man vergisst, wie weit weg die Welt (und hier ist es eben die gesamte Welt, weil Third Party) von einem Status ist. So etwas muss man irgendwie erzwingen können. Das geht dann eher einfach wenn man eine große Firma (Facebook, Apple, Google, ...) ist und Geld dahinter steckt. Ansonsten wird es schwierig. Und dann soll das ja auch noch Software unterstützen die so halb-tot ist. Ich sehe deshalb in dem Fall ein deklaratives System nicht funktionieren. Ich glaube da muss man eher einen Mittelweg finden und da ist die Tatsache, dass sich die Ports zumindest generell in eine Richtung entwickeln, die schon nah an simple Beschreibung kommt schon mal nicht schlecht.

Vielleicht wird vieles mit dem Ausbau von Lintern und ähnlichem besser. Da habe ich ehrlich gesagt schon Hoffnung, dass man dann für vieles kaum noch einen Unterschied hat außer ein paar kleine Hinweise, dass es doch Makefiles sind.[/QUOTE][/QUOTE]