Was gibt es Vorteile von freien UnixOSen gegenüber Linux?

Da fängt's schon an: in weniger als 5 Minuten ist lubuntu installiert, Debian lxde in ca. 10 Minuten (incl. Desktop ohne manuelle Anpassung von Konfigurationsdateien, LMDE ebenfalls in 10 Minuten, ebenso Fedore
Wie oft installierst Du denn? :-)
Die Installationszeit ist doch eher zu vernachlässigen. Ich hatte mal ein Debian-Desktop der ist über 10 Jahre gelaufen. Inwieweit hat es dann einen Effekt, wenn man irgendwie ne halbe Stunde einspart? :-)

Und sollte man doch neu installieren oder sowas, dann nimmt man die entsprechenden Einstellungen einfach mit. Ist ja nun gerade in UNIX-Umgebungen kein Hexenwerk.

Deshalb weiß ich immer nicht, warum viele Leute eine einfache/schnelle Installation so viel Bedeutung beimessen. Das ist ja wie ein Auto nach Farbe kaufen.

stabilität: ok, wobei ich als ich noch Debian stable als Hauptsystem hatte, mich an keinen einzigen freeze erinnern kann.
Na Stabilität heißt ja nicht nur freezes, sondern wie gut funktionieren Updates usw.
Debian ist da sicher ganz gut. Aber selbst da lief einiges nach Upgrades nicht unbedingt reibungslos weiter. Und wenn Du Pech hast, dann war es irgendwie ein Bug den keiner als wichtig einstuft und dann sitzt Du da jahrelang drauf (so mir mal passiert mit Bluetooth).

Welchen Anwendungsfall hast du für einen 13 Jahre alten Laptop?
13 Jahre sind ja nun heutzutage nicht mehr wirklich viel. Ist ja nicht mehr so wie früher, wo Hardware quasi unmittelbar nach dem Kauf schon quasi veraltet /zu langsam war.
Mit 13 Jahre alter Hardware kann man also durchaus noch viel anfangen.

Sicherheit: tut sich nicht viel. FreeBSD ist zwar nicht so verbreitet wie Linux, dafür bleiben evtl. Lücken eher unentdeckt bei FBSD.
Nimm HardenedBSD

Desktop : Linux im Vorteil
Kommt drauf an. Ich hab z.B. bewusst ein Desktop-Linux gegen ein FreeBSD-Desktop getauscht.
In den meisten Fällen kann man es aber vermutlich schon so sehen.

Server: FreeBSD meist im Vorteil
Kommt drauf an. :-)
Also ich sehe hier Linux nicht unbedingt schlechter aufgestellt.

? Was ist mit dem Punkt Sicherheit (Debian stable vs. Freebsd)?
Da würde ich eher FreeBSD vertrauen. Nicht das Debian einen schlechten Job macht. Aber Du hast halt viel altes Zeug drin was dann eben per se unsicherer ist, weil die bestimmte Security-Features dann einfach noch nicht haben.
Wobei man auch sagen muss, die meisten Angriffe sind erfolgreich bei Rechnern die einfach vorhandene Updates nicht eingespielt haben.

Und dann gibts ja noch User-Interaktion wie Social Engeneering. Dagegen hilft aber im Prinzip auch das beste System nicht. :-)

? Update: so einfach wie apt-get update && apt-get dist-upgrade
Sozusagen.
 
BSD-Vorteil 2: aus einem Guss
Hierzu folgendes:
Es ist sicherlich ein Vorteil gegenüber Linux, Kernel samt Basissystem (also systemnahes Userland) aus einem Guss zu haben.
Aber: Welcher selbst eingefleischter BSD-Nutzer arbeitet ausschließlich mit dem Basissystem?
Sobald mehr oder weniger sogenanntes Third-Party-Userland dazu kommt, relativiert sich dieser Vorteil gegenüber Linux.
Es ist dann nämlich auch entscheidend, in welchen Zustand solche Programme unter den jeweiligen Betriebsystemen sind.
Beispiel aus eigener Erfahrung: Ich habe mir aus Neugier mal OpenBSD installiert. Schön, super, alles ganz toll sicher etc. Aber ich brauche u.a. als eine Hauptanwendung audacity. Und dann kommt unter OpenBSD die Ernüchterung. Audacity wird als Third-Party-Software in einer derart alten Version zur Verfügung gestellt, dass ich nach kurzer Zeit mein OpenBSD Experiment beendet habe. Ich habe kein Interesse daran, hier auf Fehler zu stoßen, die ich unter Linux bzw. FreeBSD das letzte mal vor zig Jahren hatte und in aktuellen audacity-Versionen Schnee von vorvorgestern sind. Das spricht nun nicht gegen OpenBSD, sondern besagt lediglich, dass es für meine Workflows weniger geeignet ist.

Ich denke, folgende Vorgehensweise ist nicht schlecht, um nicht ins Schwimmen zu geraten bei der Entscheidungsfindung:
a) Du schauen, was Dir beim Arbeitem mit Deinem Betriebssystem wichtig ist. Und das sind nicht nur technische Aspekte, auch wenn einige das vielleicht meinen :)
b) Dann guckst Du, wie der Status Quo oft benötigter Programme bei den jeweiligen Opensource Systemen ist.
c) Meist bedeutet meiner Erfahrung nach: Je aktueller Third-Party-Userland an den Projekten, desto besser. Gut, es gibt leider auch Ausnahmen.

Was aber meines Erachtens auch noch ganz wichtig ist: Eine gewisse Experimentierfreude und ein Intereresse daran zu haben, ein *BSD auch mal kennen zu lernen.
Haltungen wie: Kurz angetestet und dann ein "Äh, da ist ja kaum was wie bei System xyz" sind da keine gute Voraussetzungen.

Besser und nachhaltiger finde ich da ein Darauf-Gespannt sein, was und wie ein *BSD anders macht als ein vertrautes Betriebsystem.
 
Aber: Welcher selbst eingefleischter BSD-Nutzer arbeitet ausschließlich mit dem Basissystem?
Vermutlich die Wenigsten. Aber das ist auch gar nicht der Punkt.

Der Punkt ist, dass das Basissystem eine stabile "Basis" bildet auf der man aufbauen kann. Die ist in der Regel zuverlässig und läuft immer.
Ein Package/Port kann immer mal kaputt sein. Aber dank funktionierenden Basis-System bist Du jederzeit in der Lage das wieder hinzubiegen.
 
Was ist denn an der Basis von FreeBSD 12 zuverlässiger und stabiler als z.B. an der Basis von Debian 9?
 
Was ist denn an der Basis von FreeBSD 12 zuverlässiger und stabiler als z.B. an der Basis von Debian 9?
Der große Unterschied zwischen dem Linux-Ökosystem und FreeBSD ist, bei FreeBSD kommen Kernel und System aus einer Hand.
Bei Linux muss der Distributor sozusagen das System selber zusammenstellen. Er nimmt den Linux-Kernel und andere Programme und macht daraus ein System.
Das ist bei Debian nicht anders als bei jeder anderen Linux-Distribution.

Natürlich achten die Distributoren auch darauf, das alles miteinander harmoniert und insbesondere wenn es wichtige Systemkomponenten sind wie glibc und grundlegende GNU-Tools.
Und natürlich können die auch patchen und müssen sich nicht mit dem zufrieden geben, was sie bekommen.
Deshalb will ich jetzt diesen Unterschied auch nicht überbewerten.

Wegdiskutieren kann man ihn aber auch nicht. Wenn schon der Upstream (der ja direkt in die Entwicklung involviert ist) dafür sorgt, dass alles harmoniert dann ist das schon was Anderes.
Vorteilhaft ist das insbesondere, wenn man FreeBSD als Rolling-Release fährt und quasi an stable oder head hängt, was als FreeBSD-Systementwickler ja ohnehin ein Muss ist oder auch wenn man z.B. auf allerneuste Treiber angewiesen ist.

Ohne Anspruch auf Repräsentativität aber selbst bei Debian ist es mir schon passiert, das ich ein Rescue-Medium brauchte um das System wieder zum laufen zu kriegen.
Bei FreeBSD hab ich das System bisher immer so wieder hingekriegt.

Übrigens: Lustig das Du mit Debian vergleichst. Die liefern ja uralte Pakete aus. Klar das die dann auch abgehangen und stabil sind. Und das vergleichst Du mit nem aktuellen FreeBSD.
Merkst selbst, oder? :-)
 
Welchen Anwendungsfall hast du für einen 13 Jahre alten Laptop?

Ist einfach an den Fernseher angeschlossen, um Kodi zu betreiben. Mit einem drahtlosen Keyboard und Maus kann ich dann bequem vom Sofa aus Kodi bedienen. Damit mache ich also meinen Fernseher zum Smart-TV. Und jetzt bitte nicht fragen, warum ich denn nicht direkt einen Smart-TV habe.
 
Ist einfach an den Fernseher angeschlossen, um Kodi zu betreiben. Mit einem drahtlosen Keyboard und Maus kann ich dann bequem vom Sofa aus Kodi bedienen. Damit mache ich also meinen Fernseher zum Smart-TV. Und jetzt bitte nicht fragen, warum ich denn nicht direkt einen Smart-TV habe.

Hast du mal durchgerechnet, was der Betrieb eines Pentium 4-M o.ä. an Stromkosten verursacht? Der Pentium 4 war selbst in der Mobilvariante unglaublich ineffizient und hatte einen enorm hohen Leerlaufverbrauch.

Ob solche exotische Einsatzzwecke den Aufwand der Pflege des 32-Bit-Supports rechtfertigen, sei mal dahingestellt.

Vorteilhaft ist das insbesondere, wenn man FreeBSD als Rolling-Release fährt und quasi an stable oder head hängt, was als FreeBSD-Systementwickler ja ohnehin ein Muss ist oder auch wenn man z.B. auf allerneuste Treiber angewiesen ist.

Dann sollte man aber den Vergleich von BSD & Co. gegen z.B. Arch Linux bemühen, bei dem viele der hier an Debian zurecht geäußerten Kritikpunkte wegfallen.
 
Und jetzt bitte nicht fragen, warum ich denn nicht direkt einen Smart-TV habe.
Das steht ja außer Frage. :-)

Hast du mal durchgerechnet, was der Betrieb eines Pentium 4-M o.ä. an Stromkosten verursacht?
Die Anschaffung eines Neugerätes muss sich dann aber auch erst mal amortisieren. Abgesehen davon, das es z.B. bei einer ökologischen Gesamtbetrachtung dann auch noch die Herstellung des Neugerätes und die Entsorgung des Altgerätes beachtet werden muss.

Ob solche exotische Einsatzzwecke den Aufwand der Pflege des 32-Bit-Supports rechtfertigen, sei mal dahingestellt.
Du kannst gerne Deine Beteiligung an der Pflege der 32-Bit-Version einstellen.
Wenn Du gar nicht beteiligt bist, würde ich Deine Aufregung nicht verstehen.

Dann sollte man aber den Vergleich von BSD & Co. gegen z.B. Arch Linux bemühen, bei dem viele der hier an Debian zurecht geäußerten Kritikpunkte wegfallen.
Ich hab den Vergleich mit Debian nicht angestellt.
Und ob Arch-Linux wirklich in der Stabilität mit FreeBSD mithalten kann, da melde ich mal leise Zweifel an wegen der bereits genannten Punkte.

Aber wie gesagt. Ich will das Thema auch gar nicht zu hoch aufhängen. Wer mit Arch (oder was auch immer) zufrieden ist und keine Probleme hat, für den lohnt sich sicher nicht unbedingt zu FreeBSD zu wechseln.
Letztlich geht es auch weniger um besser oder schlechter (das kann man generell sowieso nicht sagen). Es kann ja allenfalls darum gehen, was für mich und meine Anforderungen am ehesten geeignet ist. Und natürlich spielen da auch Erfahrungen und persönliche Vorlieben rein.
Es gibt halt kein one-size-fits-all.
 
Wenn Du gar nicht beteiligt bist, würde ich Deine Aufregung nicht verstehen.

Für mich als Nutzer der 64-Bit-Version reicht es nicht für einen Aufreger, betrifft mich aber trotzdem. Die Bereitstellung der 32-Bit-Version gibt es natürlich nicht umsonst, sondern verursacht in FreeBSD Aufwände nicht nur in der Entwicklung, sondern auch im Nachgang durch die erhöhte Komplexität in Pflege, Verwaltung, Tests etc. der unterschiedlichen Systeme. Ob FreeBSD die dicke Personaldecke hat, um solche Mehraufwände problemlos zu kompensieren, sei mal dahingestellt.

Seit Arch und Ubuntu nur noch 64-Bit-Systeme unterstützen, treaten auf beiden Distributionen gefühlt weniger Probleme auf, wohl weil die Maintainer nun ein System weniger pflegen müssen. Bei Arch war - vielleicht auch durch dessen dünnere Personaldecke - die größte Verbesserung zu verzeichnen.

Wenn ich mir meine persönlichen Erfahrungen mit Arch, Ubuntu, RHEL/CentOS und FreeBSD anschaue und vergleiche, hat (auch) FreeBSD noch Luft nach oben.
 
Ein Package/Port kann immer mal kaputt sein. Aber dank funktionierenden Basis-System bist Du jederzeit in der Lage das wieder hinzubiegen.
Bei meinem Beispiel geht es aber gar nicht darum, dass ein Port mal kaputt ist. Das audacity bei OpenBSD ist seit Jahren extremst veraltet und weist Fehler auf, die mir unter Linux und FreeBSD so seit zig neueren Versionen nicht mehr begegnen.

Der Punkt ist, dass das Basissystem eine stabile "Basis" bildet auf der man aufbauen kann.
Und das wird dann - bezogen auf mein Beispiel - zu einer sehr theoretisch-technischen Diskussion :) Man kann drauf aufbauen, aber wer ist denn "man"? Ein Anwender gewiss nicht, der muss nehmen, was ihm Committer bzw. Maintainer zur Verfügung stellen.

Dass unter FreeBSD mit einem pkg delete -af, gefolgt von einem Löschen des /usr/local-Ordners wieder ein sauberes Basis-System wie nach einer frischen Installation zu bekommen ist finde ich richtig klasse, darin sehe ich zum Beispiel den großen Vorteil dieses "aus einem Guss".
Ob diese Basis übrigens stabiler ist als ein im kommerziellen Umfeld eingesetzter Linuxkernel samt systemnaher Komponenten eines Redhat oder SuSE-Enterprise kann ich mangels IT-Wissens zwar nicht beurteilen, ich vermute da aber, dass bei FreeBSD auch nur "mit Wasser gekocht wird".
 
Der große Unterschied zwischen dem Linux-Ökosystem und FreeBSD ist, bei FreeBSD kommen Kernel und System aus einer Hand.

Mal davon abgesehen, dass FreeBSD die BSD-Äquivalente der GNU Tools nimmt, verwenden sowohl FreeBSD als auch Debian die gleichen Programme. Das OpenSSL von Debian ist das gleiche OpenSSL wie bei FreeBSD. Der ntpd von Debian ist auch der gleiche ntpd wie bei FreeBSD... usw. usw. Also wo ist hier der große Unterschied in der Zusammenstellung des Systems?

Übrigens: Lustig das Du mit Debian vergleichst.

Ich hätte auch Fedora, RedHat, SUSE, Ubuntu oder sonst was nehmen können. Hab nicht umsonst "z.B. Debian" geschrieben.

Die Frage ist weiterhin: Was macht die Zusammenstellung bei FreeBSD zuverlässiger bzw. stabiler? Sowohl Debian als auch FreeBSD frieren einfach zum Release eine bestimmte Version der Tools ein und liefern über den Release-Zeitraum nur noch Sicherheits-Updates.

Für mich ist dieses wiederkehrende Argument halt einfach praktisch eine Luftnummer. Und wenn irgendwann mal PkgBase vollständig bei FreeBSD eingeführt wird, dann ist der Unterschied nochmals wesentlich geringer. Dann ist das "stabile Basissystem" auch einfach nur ein extra Repository wie bei den meisten Linux-Distributionen auch.

Ich sehe halt einfach schlicht kein Argument oder Beispiel, wo es einen praktischen Unterschied zwischen den Systemen gibt. "Mir ist mal ein Debian kaputt gegangen" ist kein Argument. Mir fällt auch alle Nase lang der FreeBSD-Server auseinander und das Upgrade von 11.1 auf 11.2 war eine mittlere Katastrophe bei mir. Aber das sind halt Einzelfälle und keine Regel.
 
Dass unter FreeBSD mit einem pkg delete -af, gefolgt von einem Löschen des /usr/local-Ordners wieder ein sauberes Basis-System wie nach einer frischen Installation zu bekommen ist finde ich richtig klasse, darin sehe ich zum Beispiel den großen Vorteil dieses "aus einem Guss".

Kannst z.B. bei ArchLinux auch einfach nur alle Pakete löschen die nicht im Core-Repository sind. Alternativ alles was nicht Teil vom base-Metapaket ist. Bei Debian sind es alle Pakete mit einem "essential" Flag usw. usw.
 
Die Bereitstellung der 32-Bit-Version gibt es natürlich nicht umsonst, sondern verursacht in FreeBSD Aufwände nicht nur in der Entwicklung, sondern auch im Nachgang durch die erhöhte Komplexität in Pflege, Verwaltung, Tests etc. der unterschiedlichen Systeme. Ob FreeBSD die dicke Personaldecke hat, um solche Mehraufwände problemlos zu kompensieren, sei mal dahingestellt.
Wie dem auch sei. Die Leute, die die Arbeit machen müssen haben sich aus irgendeinen Grund dafür entschieden das zu tun. Ich traue denen mal zu, dass sie das nicht aus Jux und Dollerei machen sondern sich dabei was gedacht haben.

Man muss ja auch noch bedenken, das es neben x86 auch noch andere CPU-Architekturen gibt und da ist dann 32-Bit schon noch eher ein Thema.

Und jetzt kommst Du und Dir passt es nicht den den Kram, weil Du kein 32-Bit brauchst.
Kannst denen ja mal sagen, das die eigentlich kein 32-Bit mehr machen müssen. Mal sehen wie die Antwort aussieht. Und dann kannst Du Dir vielleicht erlauben darüber zu urteilen, ob das nötig ist oder nicht.

Seit Arch und Ubuntu nur noch 64-Bit-Systeme unterstützen, treaten auf beiden Distributionen gefühlt weniger Probleme auf
Ich weiß nicht, ob es daran liegt. Ich würde allein aus einer Korrelation noch keine Kausalität ableiten.

Und eigentlich ist die Bitbreite zumindest für Anwendungsprogramme i.d.R. irrelevant und Sache des Compilers.
Falls es doch ein Problem gibt, ist das ein Hinweis darauf das ein Datentyp falsch verwendet wurde kurz ein Hinweis auf ein Bug. Und wenn der entdeckt und gefixt wird, kann das nur gut sein.

hat (auch) FreeBSD noch Luft nach oben.
Jedes System hat noch Luft nach oben. :-)
 
Das audacity bei OpenBSD ist seit Jahren extremst veraltet und weist Fehler auf, die mir unter Linux und FreeBSD so seit zig neueren Versionen nicht mehr begegnen.
Mir ging es darum darzustellen, warum ein (stabiles, gepflegtes) Basis-System Sinn macht.

Also wo ist hier der große Unterschied in der Zusammenstellung des Systems?
Hab ich doch bereits gesagt. Im Linux-Ökosystem sind das alles unabhängige Projekte.
Das macht gewisse Sachen schwieriger. Zum Beispiel Bugs die im Userland als auch im Kernel gefixt werden müssen.
Oder wenn ein Feature eingebaut wird was Anpassungen beider Bereiche benötigt, dann können die FreeBSD-Leute das einfach machen. Wenn Du irgendein GNU-Tool oder ein anderes Programm hast und da was einbauen willst was eine Kerneländerung benötigt, dann musst Du erst mal bei Linus anklopfen und fragen, ob er das einbauen könnte.
Klar kannst Du Dank Open Source auch alles selbst in den Kernel patchen. Nur wenn eine neue Kernel-Version rauskommst bist Du wieder am patchen. Musst alles händisch nachziehen. Und wenn irgendwas aus dem Kernel rausfliegt worauf Dein Kernel-Patch angewiesen ist, dann hast Du halt Pech gehabt.
Nicht umsonst sind so viele Sachen darauf bedacht in den offiziellen Linux-Kernel aufgenommen zu werden.

Die Frage ist weiterhin: Was macht die Zusammenstellung bei FreeBSD zuverlässiger bzw. stabiler?
Habe ich bereits erklärt. Wenn Du mehr wissen willst, musst Du auch bezug darauf nehmen was ich bereits schrieb. Ich weiß sonst nicht, wo da das Verständnis fehlt und das hilft dann der Diskussion überhaupt nicht weiter.

Für mich ist dieses wiederkehrende Argument halt einfach praktisch eine Luftnummer. Und wenn irgendwann mal PkgBase vollständig bei FreeBSD eingeführt wird, dann ist der Unterschied nochmals wesentlich geringer.
PkgBase ändert nix daran, das die Sachen aus einer Hand kommen. Es ermöglicht nur eine Aufteilung des Basissystems damit man nicht immer das gesamte Basissystem installieren muss, obwohl man vielleicht nur einen Bruchteil davon braucht.

Irgendwie hab ich das Gefühl, Du verstehst die Argumentation nicht, auch wenn sie eigentlich recht simpel ist.
Um mal den allseits beliebten Autovergleich zu bemühen:
Bei den Linuxdistributoren ist das so, das die halt ein Auto bauen und dafür ein Motor von Opel nehmen, Bremsen von Fiat, das Getriebe von Peugeot usw.
Und bei FreeBSD bauen die den Motor selbst, das Getriebe selbst die Bremsen selbst usw.

In welchem Auto sind wohl die Teile tendenziell mehr aufeinander abgestimmt?

Für mich ist dieses wiederkehrende Argument halt einfach praktisch eine Luftnummer.
Wie schon gesagt, ich will das Ganze auch nicht zu hoch aufhängen. Wenn man das System "normal" benutzt (also im Sinne des Desktop-Normalanwenders) wird man meist auch keinen großen Unterschied merken.
Bist Du näher am System oder arbeitest Du intensiver damit, dann tritt das auch eher zutage.
Und natürlich bevorzugt an den Stellen, die eh in Bewegung sind (neue Features etc.).

"Mir ist mal ein Debian kaputt gegangen" ist kein Argument.
Ja. Einzelerfahrungen sind selten bis nie ein Argument.
Aber weil hier und da mal persönliche Erfahrungen herangezogen wurden, wollte ich auch mal einen zum Besten geben. :-)
 
Dass unter FreeBSD mit einem pkg delete -af, gefolgt von einem Löschen des /usr/local-Ordners wieder ein sauberes Basis-System wie nach einer frischen Installation zu bekommen ist finde ich richtig klasse, darin sehe ich zum Beispiel den großen Vorteil dieses "aus einem Guss".

Eine "frische Installation" sieht in meinem Arbeitsalltag ganz anders aus:
  • Alle Instanzen sind virtualisiert, d.h. die einzelne Installation ist sowieso völlig bedeutungslos (vgl. Pets vs. Cattle)
  • Händische Upgrades und Anpassungen gibt es sowieso nie - alle Anpassungen passieren versioniert via Configuration Management (z.B. Ansible, Puppet etc.)
  • Es werden keine Package-Upgrades durchgeführt, sondern ein neues Server-Image gebaut, gestartet, konfiguriert, provisioniert (d.h. auch alle benötigten Packages von Grund auf in der aktuellen bzw. benötigten Version installiert), automatisch getestet und bei Erfolg ausgespielt. Die alte Server-Instanz wird weggeschmissen, sie lässt sich aus dem Configuration Management sowieso immer wieder neu erzeugen.
Das ist inzwischen längst Stand der Technik und gut abgehangen. Deswegen erlebe ich keinerlei Vorteil durch das einheitliche BSD-Basissystem, auch wenn es an anderer Stelle Vorteile bringen mag.

Wie dem auch sei. Die Leute, die die Arbeit machen müssen haben sich aus irgendeinen Grund dafür entschieden das zu tun. Ich traue denen mal zu, dass sie das nicht aus Jux und Dollerei machen sondern sich dabei was gedacht haben.

In vielen Fällen wird etwas aus historischen Gründen mitgeschleift, was seine Bedeutung längst verloren hat. Der Ausbau bedeutet ja auch erstmal Arbeit, auch wenn sich die Arbeit recht schnell auszahlen könnte bzw. dürfte. Von den politischen Diskussionen ganz zu schweigen...

Und jetzt kommst Du und Dir passt es nicht den den Kram, weil Du kein 32-Bit brauchst.

Keineswegs. Mir ist der 32-Bit-Port im Grunde vollkommen egal.

Aus meiner Außenperspektive als Anwender und Softwareentwickler fällt mir nur auf, dass aus heutiger Sicht selbstverständliche Dinge wie Support für Container nach wie vor fehlen und dafür aus meiner Perspektive nicht mehr benötigte Dinge - die auch schon viele andere Betriebssysteme bzw. Distributionen rausgeworfen haben - nach wie vor mit entsprechendem Aufwand gepflegt werden.

Kannst denen ja mal sagen, das die eigentlich kein 32-Bit mehr machen müssen. Mal sehen wie die Antwort aussieht. Und dann kannst Du Dir vielleicht erlauben darüber zu urteilen, ob das nötig ist oder nicht.

Dafür möchte ich keine Zeit und Energie aufwenden. Leider habe ich aktuell auch nicht die Zeit und Muße, das Defizit bei FreeBSD selbst zu beheben. Mir bleibt wohl nur die Abstimmung mit den Füßen Richtung weiterem Ausbau der Linux-Monokultur. :(

Und natürlich bevorzugt an den Stellen, die eh in Bewegung sind (neue Features etc.).

Gerade deswegen hätte ich erwartet, dass FreeBSD im Bereich Container Linux schön längst ein- und überholt hätte. Im Cloud- und Containerumfeld sind viele Unternehmen fast völlig unabhängig von ihren existierenden IT-Landschaften gestartet und waren in der Wahl ihres Betriebssystems frei. Das hätte ein enormer Schub für das gesamte FreeBSD-Ökosystem werden können.
 
Hab ich doch bereits gesagt. Im Linux-Ökosystem sind das alles unabhängige Projekte.

Das macht es für FreeBSD einfacher ihre Userland-API/ABI zu brechen, aber das macht das Basissystem doch nicht zuverlässiger oder stabiler. Nochmal zum Verständnis: Es geht mir um die Aussage, dass es zuverlässiger/problemfreier/stabiler/... ist. Alles was du bisher dazu argumentiert hast, hatte damit relativ wenig zu tun, außer vielleicht theoretische Konstrukte, wo ich unten stehend nachfrage.

Das macht gewisse Sachen schwieriger. Zum Beispiel Bugs die im Userland als auch im Kernel gefixt werden müssen. [...]

Kennst du einen konkreten Fall, wo das das Problem ist/war?

Nicht umsonst sind so viele Sachen darauf bedacht in den offiziellen Linux-Kernel aufgenommen zu werden.

Der Linux-Kernel macht seine Userland API nicht kaputt. Wenn deine Anwendung mit Kernel 2.6 läuft, dann tut sie das mit 5.0 auch noch. Von daher verstehe ich hier das Argument um die Kernel-Patcherei nicht. Wenn es ein Bug gibt, gibt es relativ geringe Probleme diesen zu fixen. Wenn du was hinzufügen willst, dann geht das über die üblichen Prozesse. Auch FreeBSD nimmt nicht jeden Kernel-Patch einfach feuchtfröhlich entgegen. Ganz im Gegenteil sogar, es dauert teilweise ewig etwas neues in den FreeBSD Kernel zu bekommen.

Dass FreeBSD kein Linux ist, bedingt natürlich, dass es für äquivalente kernelnahe Konstrukte (Container, VMs, ...) andere Tools und Vorgehensweisen gibt. Aber wie das alles dazu führen soll, dass es zuverlässiger/problemfreier/stabiler/... ist, erschließt sich mir nicht.
 
Eine "frische Installation" sieht in meinem Arbeitsalltag ganz anders aus:
  • Alle Instanzen sind virtualisiert, d.h. die einzelne Installation ist sowieso völlig bedeutungslos (vgl. Pets vs. Cattle)
  • Händische Upgrades und Anpassungen gibt es sowieso nie - alle Anpassungen passieren versioniert via Configuration Management (z.B. Ansible, Puppet etc.)
  • Es werden keine Package-Upgrades durchgeführt, sondern ein neues Server-Image gebaut, gestartet, konfiguriert, provisioniert (d.h. auch alle benötigten Packages von Grund auf in der aktuellen bzw. benötigten Version installiert), automatisch getestet und bei Erfolg ausgespielt. Die alte Server-Instanz wird weggeschmissen, sie lässt sich aus dem Configuration Management sowieso immer wieder neu erzeugen.
Das ist inzwischen längst Stand der Technik und gut abgehangen. Deswegen erlebe ich keinerlei Vorteil durch das einheitliche BSD-Basissystem, auch wenn es an anderer Stelle Vorteile bringen mag.

Klar, Du redest von Deinem Workflow (Dein vermutlich beruflicher Arbeitsalltag mit Betriebssystemen im kommerziellen Umfeld mit einer entsprechenden Hardware- und Softwareausstattung, die sich wohl privat kaum jemand leisten kann), ich von den Workflows meiner Frau und mir im privaten Umfeld (kleines Heimnetzwerk mit ein paar Desktop-Systemen mit fbsd, einem Daten-NAS mit fbsd, einem Backup-Nas mit Debian und einem Multimedia-System mit Devuan).
Workflowabhängigkeit, darauf bezogene technische und auch nicht-technische Aspekte der einzelnen Anwender sind ja immer mit zu berücksichtigen, auch, wenn etwas als Vorteil bezeichnet wird.
 
Gerade deswegen hätte ich erwartet, dass FreeBSD im Bereich Container Linux schön längst ein- und überholt hätte. Im Cloud- und Containerumfeld sind viele Unternehmen fast völlig unabhängig von ihren existierenden IT-Landschaften gestartet und waren in der Wahl ihres Betriebssystems frei. Das hätte ein enormer Schub für das gesamte FreeBSD-Ökosystem werden können.

Ich glaube das grundlegende Problem ist, dass der FreeBSD Kernel nicht unbedingt aufwärtskompatibel ist, wenn es um Container geht. Das ist der Linux-Kernel im Detail auch nicht, aber derart kernelnahe Anwendungen sind in der Regel mit allen LTS Kerneln kompatibel oder auch älter. FreeBSD hingegen gibt keine Garantie, dass eine FreeBSD 12 Jail auf FreeBSD 11 funktioniert.

Somit würde das Verteilen von Jail-Images im Stil von Docker unter FreeBSD nur sehr limitiert funktionieren bzw. es gibt halt eine recht starke Abhängigkeit zwischen Host und Jail, was bei Docker praktisch nicht der Fall ist.
 
Mir bleibt wohl nur die Abstimmung mit den Füßen Richtung weiterem Ausbau der Linux-Monokultur. :(

Linux-Monokultur, schön, dass Dir das offenbar auch Unbehagen bereitet. Ich finde Monokulturen schlimmer, als das Nutzen auch proprietärer Software - für solch eine Position wird man von einigen auf Pro-Linux gegrillt :D
Was oftmals an Softwaremonopolisten aus dem Linuxlager kritisiert wird, wird im Bereich Opensource beim eigenen System in Kauf genommen und sogar verteidigt (oftmals mit einer gewissen Copyleft-Lizenz als Legitimation).

Okay, nun wird es zu sehr OffTopic.
 
Die Diskussion um FreeBSD/i386 wurde lange und ausführlich geführt. Das Ergebnis ist, dass es genügend Nutzer- und Entwicklerinteresse gibt, es zumindest über den FreeBSD 13.x Zyklus hinweg fortzuführen und man auch die entsprechende Arbeit investieren wird. Und teilweise auch schon hat; die drei leidigen und eng zusammenhängenden Hauptthemen 2GB/2GB-Split, PAE-Integration und Merge des pmap-Code zwischen i386 und amd64 sind in 13-CURRENT erledigt. Fraglich ist nur, ob man FreeBSD/i386 nicht auf TIER-2 hinabstufen wird, aber das muss man mal sehen.
Was zu FreeBSD 14.0 sein wird, kann man jetzt noch nicht sagen. Dann sind wir schon Mitte der 2020er, da wird die Welt schon wieder ganz anders aussehen. Vielleicht wird man dann FreeBSD/i386 wirklich fallen lassen oder man muss es aufgrund des dann schon in Sichtweit kommenden Jahr-2038-Problems inkompatibel brechen.
 
Linux-Monokultur, schön, dass Dir das offenbar auch Unbehagen bereitet.

Wenn ich mir so manche Aktionen und Untätigkeit im BSD-Umfeld anschaue: selbstgewähltes Schicksal. :ugly:

Workflowabhängigkeit, darauf bezogene technische und auch nicht-technische Aspekte der einzelnen Anwender sind ja immer mit zu berücksichtigen, auch, wenn etwas als Vorteil bezeichnet wird.

Korrekt. Ich wollte das einen gängigen Anwendungsfall beschreiben, dem man als Privatnutzer nicht begegnet, der aber Stand der Technik ist und auf breiter Fläche eingesetzt wird. Durch solche Kunden wird natürlich auch die Weiterentwicklung des Linux-Ökosystems finanziert. Manchmal sind die Diskussionen rund um die Vor- und Nachteile hier im Forum sehr heimelig. ;)

Der Großteil der Software für solche Anwendungsfälle ist Open Source und teilweise auch für den (Free)BSD-Heimgebrauch sehr empfehlenswert, z.B. lohnt sich Ansible schon ab dem ersten administrierten Rechner. Vieles davon ist für den Heimgebrauch aber auch absoluter Overkill.

Nachtrag: Alle die Docker oder etwas ähnliches für FreeBSD möchten, haben sicher den Call for Help zu Docker gesehen und sind schon eifrig dabei sich an dem Projekt zu beteiligen, oder? ;) - https://lists.freebsd.org/pipermail/freebsd-virtualization/2019-February/007218.html

Ich hatte den CfH noch nicht gesehen. Ohne Sourcecode wird die Hilfe aber auch schwierig. :(
 
Gerade deswegen hätte ich erwartet, dass FreeBSD im Bereich Container Linux schön längst ein- und überholt hätte. Im Cloud- und Containerumfeld sind viele Unternehmen fast völlig unabhängig von ihren existierenden IT-Landschaften gestartet und waren in der Wahl ihres Betriebssystems frei. Das hätte ein enormer Schub für das gesamte FreeBSD-Ökosystem werden können.

Container??? Es existiert doch die Moeglichkeit "Soft-appliances" per Cloudabi zu realisieren, oder uebersehe ich da etwas?
 
Korrekt. Ich wollte das einen gängigen Anwendungsfall beschreiben, dem man als Privatnutzer nicht begegnet, der aber Stand der Technik ist und auf breiter Fläche eingesetzt wird. Durch solche Kunden wird natürlich auch die Weiterentwicklung des Linux-Ökosystems finanziert. Manchmal sind die Diskussionen rund um die Vor- und Nachteile hier im Forum sehr heimelig. ;)

Aber daher finde ich es auch sehr wichtig, wenn hier solche Beiträge aus dem professionellen beruflichen Umfeld kommen. Denn unterschiedlicher Workflow heißt ja nicht nur, was die Leute daheim für unterschiedliche Anforderungen haben sondern OSS wird ja auch sehr umfangreich auf eine Weise verwendet, wie Du es beschreibst.

Davon abgesehen denke ich, dass bei aller Kritik an Linux, an sehr auf Linux ausgerichteter Software und seiner Entwicklung - ob nun überzogen oder berechtigt - dieses System ein gewaltiges Zugpferd im Bereich Opensource überhaupt darstellt, wovon natürlich auch *BSD-Anwender profitieren (können).

Wie vielleicht einige hier gelesen haben, hätte ich FreeBSD auch zu gerne auf dem Multimedia-System mit kodi eingesetzt (Intel Gemini Lake). Aber selbst die Implementierung der von Linux stammenden modernen Intelgrafikunterstützung (kmod-drm) hat hier nicht geholfen, FreeBSD ist multimedial für diese Architektur schlichtweg unbrauchbar und nun werkelt dort eben ein Devuan mit aktuellem 4.19er Kernel.
 
Zurück
Oben