Interesse an FreeBSD rückläufig? Schwächen und Stärken von FreeBSD.

Gute Frage. Es hätte mich sehr gefreut, wenn mehr Leute ihre Erfahrungen und Beobachtungen aus der professionellen IT beigesteuert hätten. Es macht aber schon stutzig, dass hier im Forum keiner eine BSD-Positivmeldung aus dem eigenen Umfeld beisteuern konnte. :(

so ganz stimmt das nicht, ich habe hier am Lehrstuhl etliche BSD Server laufen. Sie tun es seit Jahren sehr gut. Nur manchmal fehlen ein paar Linux spezifische Sachen. Trotzdem: ich arbeite gerne mit BSD, kann es vergleichen mit Linux. Der Unterscheid ist zwischen BMW und Mercedes - beide fahren schnell :) Naja, ich finde BSD wesentlich einfacher zu handhaben. Und ich werde es nicht so schnell aufgeben. Auch wenn viele mich nicht verstehen - aber so ist das im Bioinformatik Bereich: oft quick and dirty... Aber setze mal einen Linux Server und einen BSD Server auf. Bei Linux hatte ich auf einem Supermicro Server es vor etwa 2 Jahren aufgegben 18.04 zu installieren, bin bei 16.04 hängengeblieben. Vorher lief FreeBSD ohne Probleme drauf... Ich musste es tun, weil Chef das so wollte. BSD = Besonders Super Designed ;-) VG, Norbert
 
Magst du ein paar Beispiele nennen?

Innovation mit Augenmaß. Linux hat vorgelegt; jetzt kann man aus dem Linux-Wildwuchs und dessen Erfahrungen lernen. Die Vorteile von FreeBSD nutzen und perfekt integrierte Software bereitstellen, die alles unter Linux existierende in den Schatten stellt, weil man aus 5 unterschiedlichen Linux-Implementierungen lernen konnte und sie aus einer Hand liefern kann.

Auf dem Desktop eine massentaugliche Desktop-Lösung so gut unterstützen und integrieren, dass Linux mit systemd/Wayland/Gnome blass wird vor Neid.

Für Entwickler: sicherstellen, dass jedes populäre Entwickler-Tool jederzeit problemlos auf FreeBSD läuft. Den FreeBSD-Code endlich auf ein modernes Versionsverwaltungssystem umstellen und Subversion aufs Altenteil schicken.

Im Bereich Container: Jails so nahtlos und komfortabel ins Basissystem einfügen, dass Docker unter Linux im Vergleich dazu an Frankenstein erinnert. Dafür sorgen, dass Kubernetes diese Lösung betreiben kann.

Im Server-Bereich: bhyve zur Produktionsreife bringen. Ein simples Automatisierungstool wie Ansible so gut unterstützen, dass der FreeBSD-Support die Referenzimplementierung wird. Mehr Bereitschaft, bei Major-Releases Altlasten aus dem Basissystem zu entfernen und durch moderne Alternativen zu ersetzen (ich sage nur NTP).
 
@Azazyel - da gebe ich dir recht;
... und vor allem: Spiele! Spiele, Spiele, Spiele!
Die Verfügbarkeit einer OS Plattform als Spieleplattform bringt ein OS unheimlich voran, wie wir am Beispiel Windows gut sehen können... so gut wie jeder schimpfte über Windows - aber so gut wie jeder hatte es zum zocken daheim... Teilweise musste ich damals mit meinen entzündeten Admin-Augen in den 2000er Jahren auch auf etlichen Firmen-Laptops mitansehen, dass gezockt wurde; gut, wer möchte es den Road-Warriors abends im Hotel verwehren; 2 Laptops mitschleppen ist halt doof (und Sales darf sich eh alles erlauben, die bringen ja das Geld in die Firma, die IT gibts ja nur aus, wer will da so doofe Regeln von IT einhalten ...)

Noch besser wäre, wenn sich BSD als "Plattform für alles" empfehlen könnte - du willst Docker? Installier den Docker-ulator; Du willst das Windows-Dev-Tool laufen lassen? Installier den Win-ulator, und dann deine IDE... usw usf.
Allen gemein sollte sein, dass BSD als Unterbau läuft, und die DevOps munter ihre Docker-Container laufen lassen können, die Devs die Compiler/IDEs usw, die Sekretärinnen den Bürokram; dann wären wir da, wo BSD alle glücklich macht...


hier am Lehrstuhl etliche BSD Server laufen. Sie tun es seit Jahren sehr gut. Nur manchmal fehlen ein paar Linux spezifische Sachen.

da fallen mir spontan 3 Dinge auf: Lehrstuhl, Server, es fehlen Linux-spezifische Sachen

Lehrstuhl:
In der Industrie hat man (meist) strikte Vorgaben in Bezug auf was auf Servern installiert wird, BSD ist meist nicht darunter (außer, man arbeitet grade bei Netflix, oder der Firmen-Boss bzw der CTO ist selber Nerd und hält viel von BSD, ich hab von beiden Typen noch keinen solchen getroffen);
Akademische Einrichtungen sind hier freier in der Auswahl - was dann ggf wieder zu lustigem Wildwuchs oder Support-Problemen führt, aber das ist eine andere Geschichte;

Server:
Genau, Server - aber nicht Desktop; warum ist das so? Fehlt BSD was für den jeweiligen Einsatzzweck auf dem Desktop?

Linux-spezifische Sachen:
Siehe die Frage bei Server oben?
 
Läuft wie vorausgesehen. Eigentlich läuft der ix-Krempel total supi, aber die ganzen Dumpfbacken da draußen, wo immer draußen sein möge, die verstehen das alles nicht.
Na ja, da mag das ein oder andere nicht so laufen wie unter dem propidingsbums System, aber dafür ist man ja frei. Frei stundenlang und tagelang zu basteln was der tumbe MS-Blödel in fünf Minuten hin bekommt. Aber, daß ist ja auch nur ein Dödel, der versteht einfach nicht die moralische Komponente in diesem System. Dödel, DAU, eben!

Die IT-Elite!
 
Flatpak hat Single File Bundles und create-usb, d.h. die Offline-Paketinstallation geht problemlos. Statt wie bei Apple eine dmg-Datei kopiert man halt eine flatpak-Datei auf den Rechner und installiert sie, auch ohne Internetverbindung.
So problemlos geht das wohl nicht. Hast du das schon mal gemacht? Muss ich das Flatpak erst auf den Rechner installieren oder mir ein Repo anlegen?

Falls du das schon mal gemacht hast kannst du mir ja vielleicht helfen und anhand vom Beispiel https://flathub.org/apps/details/net.scribus.Scribus sagen, wie ich daraus ein Offline-Paket mache. :D
 
Falls du das schon mal gemacht hast kannst du mir ja vielleicht helfen und anhand vom Beispiel https://flathub.org/apps/details/net.scribus.Scribus sagen, wie ich daraus ein Offline-Paket mache. :D

Für eine einzelne Applikation ist build-bundle am einfachsten:
Code:
flatpak install net.scribus.Scribus
flatpak build-bundle /var/lib/flatpak/repo /tmp/scribus.flatpak net.scribus.Scribus
flatpak uninstall net.scribus.Scribus
flatpak uninstall --unused # wer noch aufräumen will
Auf der Zielmaschine reicht dann ein flatpak install /tmp/scribus.flatpak

Falls man einen kompletten Offline-Mirror für viele Pakete erstellen möchte, lohnt sich die etwas kompliziertere Variante mit create-usb, bei der die Anleitung gemäß https://unix.stackexchange.com/a/541583 bei mir unter Arch Linux problemlos funktioniert hat.

Den dort erwähnten Schritt für https://flathub.org/repo/flathub.flatpakrepo musste ich nicht extra ausführen, weil das Repo auf allen bei mir vorhandenen Desktop-Distributionen (Arch Linux, Fedora, Ubuntu) schon passend voreingestellt war - das sind aber auch alles neueste Versionen. Falls der Offline-Rechner nicht in Laufreichweite steht und nicht mehr ganz taufrisch ist, würde ich die Datei sicherheitshalber mal mitnehmen - für den Fall der Fälle.
 
Zuletzt bearbeitet:
Was wären - um auf den Thread-Titel einzugehen - somit im Jahr 2020 die Stärken von FreeBSD?

Wenn man die Thread-Beiträge so liest, müsste man als neutraler Außenstehender FreeBSD gegenüber fast annehmen, FreeBSD könnte nicht mehr punkten, gegenüber einem Linux - was z.B. Docker kann und Docker doch jetzt der heiße Scheiss ist, usw usf?
 
Ich teste lokal zwei Anwendungen:

Anwendung X in Prozess A möchte auf Port 8080 lauschen.
Anwendung Y in Prozess B möchte auf Port 8080 lauschen.

Wie kann ich anwendungsunabhängig Prozess B auf Port 8081 lauschen lassen?
Sockets werden ja an IP-Adressen gebunden. Würdest Du beide auf 1.2.3.4:8080 binden würde es nicht funktionieren. Bei einem Conntect wüsste das System ja gar nicht, zu welchen Prozess es "connecten" soll.

Du brauchst also zwei IP-Adressen.

Das ist übrigens bei "Container-Technologie" nicht anders.

Dein praktisches Problem hier ist vermutlich eher: Du willst dem Prozess nicht explizit sagen müssen, das er 1.2.3.4 nutzen soll, sondern er soll sich einfach an die IP-Adresse binden, die er "sieht" oder die im zugeordnet ist.
Salopp gesagt: das in der Konfig der beiden Anwendungen nur
listen *.8080
steht und trotzdem Prozess A auf 1.2.3.4:8080 lauscht und Prozess B auf 1.2.3.5:8080

Kann man z.B. unter Linux machen mit Network Namespaces (was anderes macht Docker & Co letztlich auch nicht). Der Jails-Mechanismus unter FreeBSD bietet ja was ähnliches.


Naja:

[erni]$ touch /tmp/hello.txt
[bert]$ touch /tmp/hello.txt
touch: cannot touch '/tmp/hello.txt': Permission denied

Da geht noch was.
Du beschreibst genau das Problem, von dem ich die ganze Zeit schreibe. Eine Anwendung hat halt möglichst nicht in ein globales Verzeichnis zu schreiben. Leider machen das viele.
Und jetzt kommen wir zu dem Punkt, über den ich schon mehrmals schrieb:
Statt jetzt das Programm mal gerade zu ziehen, machen wir ein Container drum herum. Um die freidrehende Anwendung unter Kontrolle zu kriegen.
Ganz großes Kino.

Richtig wäre es natürlich, wenn die Anwendung eben nicht in globale Verzeichnisse schreiben würde. Sondern in ihr eigenes. So ein bisschen kennt man das ja auch von typischen Desktop-Anwendungen wie Browser. Die packen ihren Cache standmäßig ja auch nicht nach /tmp/ oder /var/tmp/, sondern in das Homeverzeichnis des ausführenden Nutzers.

Das eine schließt das andere nicht aus.
Sag das nicht mir, sondern meinem Vorredner. Der hat ja behauptet, Docker sei für Microservices gedacht.

Alltägliches Beispiel aus meiner Praxis
Wo Du grad wieder Praxis erwähnst. Hier auch noch mal ein wunderschönes Beispiel, wie "toll" der Einsatz von Docker in der Praxis "funktioniert":
https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

So läuft das nämlich dann in der Praxis. Die Leute laden sich Docker-Images weil sie damit ja gleich losstarten können. Und da stellt sich raus, die sind "ab Werk" schon alle voller Security-Bugs.

Die Leute, die blind solche Images einsetzen ohne sie zu fixen werden dann sicherlich auch mit der gleichen "Sorgfalt" ihre Anwendung pflegen, die sie drauf packen.

Leider brauchst das Backend inzwischen branchenspezifische Software, die nur auf CentOS läuft. Also packt man das Backend in ein Container-Image, das auf CentOS aufbaut. Es läuft dank Containern problemlos auf jedem Server.
Was ich immer wieder geschrieben hab. Die Leute benutzen kaputte Anwendungen und um das dann doch noch irgendwie hinzubiegen, werden dann Container benutzt.

Ähm ja. Es ist eine Lösung. Aber natürlich alles andere als eine gute Lösung. Genau das, was ich oben schon schrieb. Danke für Deine Bestätigungen.

Für einen Lasttest kann man auf den Servern binnen Sekunden auch mal 100 Container parallel hochfahren und ebenso schnell wieder entsorgen.


Haargenau dieselben Images, bestens getestet, laufen dann in Produktion hochverfügbar und Rechenzentrums-übergreifend. Die Container-Plattform sorgt dafür, dass selbst bei Komplettausfall eines der Rechenzentren der Betrieb nahtlos weitergeht, ohne dass man spezielle Failover-Mechanismen für jede Anwendung bauen müsste.

Das sind alles Dinge, die ich unter Automatisierung sehen würde. Und dagegen hab ich nie was gesagt. Siehe meine alten Beiträge.


Das Problem ist: Docker macht ja nicht nur Automatisierung. Sonst wäre ja alles gut. Aber Docker macht noch mehr.

Plus die Tatsache das die Leute offenbar mit Docker nicht umgehen können.

Letztlich löst damit Docker keines Deiner Probleme wirklich. Hier und da gibt es ja sinnvolle Anwendungsfälle wo das total gut ist. Und man kann sicher auch das ein oder andere Problem Workaround-mäßig in den Griff kriegen als schnelle pragmatische Lösung. In vielen Fällen ist es aber keine Lösung, sondern lediglich die Übertünchung von schlechtem Software-Design. Am Ende hast Du Deine Probleme potentiell noch und eine Menge Komplexität oben drauf, weil jetzt noch Docker und Co mit laufen muss.


ich wüsste Stand heute keine Möglichkeit, wie ich obiges Beispiel einer 08/15-Anwendung so trivial auf FreeBSD abbilden könnte wie auf Linux.
Du willst unbedingt ne Linux vs. FreeBSD Geschichte draus machen. :-)
Mir gehts primär um Kritik um den Ist-Zustand. Übrigens: Der Ist-Zustand ist auch bei FreeBSD nicht wirklich gut.
Anyway. Da Du so darauf drängst, werde ich dazu auch ein paar Worte verlieren. :-)

Sofern das ähnlich komfortabel und produktionsreif mit Jails abbilden kann - ich wüsste da ein paar Unternehmen, die viel Geld in die Hand zahlen würden, um nicht nach Linux migrieren zu müssen.
Ich muss vorneweg sagen, das ich relativ wenig Erfahrungen mit höherleveligen Toools a-la Bastille, iocage, ezjail, cbsd und wie sie alle heißen habe. Ich nehme im Umgang mit Jails im Wesentlichen die jail-Kommandos die bei FreeBSD halt mit dabei sind.

Und ja, ich nutze auch die Vorteile von Automation und hab mir dafür auch kleinere Tools geschrieben.
Aus meiner Sicht spricht nichts dagegen die von Dir beschriebenen Aufgaben auch mit Jails umzusetzen. Klar. Man wird (wie ich) sich ein paar Sachen basteln müssen, um den Komfort zu kriegen. Aber das lässt sich meines Erachtens mit überschaubaren Aufwand realisieren. Und wenn eine Firma sogar bereit ist VIEL Geld in die Hand zu nehmen, sollten Sie da nicht auf ernsthafte Probleme treffen. Einige Sachen bekommen sie auch schon durch vorhandene Projekte gelöst. Da könnte man ansetzen.

Daher bin ich jetzt etwas unsicher, warum die Firmen das nicht einfach machen. Vielleicht wollen die ja eher doch Docker auf FreeBSD, so dass sie gleich auf vorhandene Ressourcen (fertige Images, Tools die ihrerseits auf Docker aufsetzen, Cloud-Anbieter etc.) zugreifen können.

So, genug ausgeheult und gejammert, lassen wir Zahlen sprechen - die Ergebnis des StackOverflow Surveys in der Kategorie Professional Developers' Primary Operating Systems:
Danach sollten wir wohl nicht Linux, sondern Windows machen.
Gut, das wir das mal geklärt haben. :-)

Innovation mit Augenmaß. Linux hat vorgelegt; jetzt kann man aus dem Linux-Wildwuchs und dessen Erfahrungen lernen.
Naja. Ein typisches Beispiel von "wir haben von anderen gelernt" wäre bhyve.
Von anderen gelernt heißt aber auch, man hat später angefangen. Und dann beschwerst Du Dich ja, warum man noch nicht so weit ist wie alle anderen.


Auf dem Desktop eine massentaugliche Desktop-Lösung so gut unterstützen und integrieren, dass Linux mit systemd/Wayland/Gnome blass wird vor Neid.
Ja. Im Desktop-Bereich ließe sich sicher mehr tun.

Für Entwickler: sicherstellen, dass jedes populäre Entwickler-Tool jederzeit problemlos auf FreeBSD läuft.
Das wäre eigentlich Aufgabe der Entwickler der Tools. Ich verstehe ja auch nicht, warum es heutzutage noch immer noch ein Problem zu sein scheint seine Software plattformübergreifend zu entwickeln.

Dem Problem wird sich übrigens auch im Prinzip angenommen. Nämlich mit dem Ports-System. Das soll ja gerade dafür sorgen, das sich Software nach FreeBSD portieren lässt (daher ja auch der Name Ports).

Den FreeBSD-Code endlich auf ein modernes Versionsverwaltungssystem umstellen und Subversion aufs Altenteil schicken.
Subversion ist per se ja kein schlechtes Versionskontrollsystem. Die Problematik liegt eher darin, das die meisten GIT sprechen. Daher wird GIT nicht mehr unbedingt nur dann eingesetzt, wenn es sich gut eignet, sondern eben weil die halbe Welt GIT einsetzt.

Oder welchen Grund sollte es denn noch geben von Subversion wegzukommen?

Mehr Bereitschaft, bei Major-Releases Altlasten aus dem Basissystem zu entfernen und durch moderne Alternativen zu ersetzen (ich sage nur NTP).
Mag in dem Fall sogar sinnvoll sein. Aber über innovativ vs. konservativ lässt sich natürlich trefflich streiten. Beides hat seine Vor- und Nachteile.

Zum speziellen Fall NTP: Ist ja nun nicht so, das es extrem schwierig ist ntpd aus FreeBSD rauszuwerfen und stattdessen z.B: chrony einzusetzen.
Ob man das jetzt auch per default im Basissystem macht finde ich jetzt nicht sonderlich kriegsentscheidend.
Man passt eh Vieles im System an. Und wenn man das multipliziert braucht, übernimmt man es halt auf seine übrigen System-Instanzen.

Ansonsten ist bei solchen Dingen, die man verbessern müsste auch immer die Frage: Wer soll es machen?
Es kommt immer etwas unglücklich rüber wenn man Sachen quasi fordert aber selbst den Hintern nicht hoch bekommt auch mal was zu machen.
Open Source lebt nun mal vom mitmachen. Sonst kann man genauso gut auch ein proprietäres System nehmen. Da muss man auch mit leben was der Hersteller vorsieht.
Solange alle nur jammern, wie schlimm es angeblich ist, ist letztlich niemanden geholfen.
Also weniger lamentieren. Mehr machen.

damals mit meinen entzündeten Admin-Augen in den 2000er Jahren auch auf etlichen Firmen-Laptops mitansehen, dass gezockt wurde
Da würde ich als Admin aber auch doof gucken, wenn irgendwer auf dem Firmenlaptop (womöglich noch mit Firmendaten) ein eh schon beliebtes Angriffsziel wie Windows durch irgendwelche Spiele (die ja gern auch nen eklig systemeingreifenden Kopierschutz hatten/haben und damit weitere Probleme/Sicherheitslöcher schaffen) eingesaut werden.

Sorry, aber genau solche Leute verursachen viele IT-Probleme.
Solche Leute würden von mir was auf die Finger kriegen.

2 Laptops mitschleppen ist halt doof
Ja. Mega-anstregend.
Was wird so ein Business-Laptop wiegen? Nicht wirklich mehr als 2kg. Zwei davon sind quasi gar nicht zu bewältigen. *Augenroll*

Installier den Win-ulator, und dann deine IDE... usw usf.
Gibts doch. In Form von WINE.

Was wären - um auf den Thread-Titel einzugehen - somit im Jahr 2020 die Stärken von FreeBSD?
Die sollten doch allgemein bekannt sein. :-)
Ich kann Dir aber trotzdem sagen, wo ich die Vorteile sehe.

  • Dokumentation. Die ist bei FreeBSD wirklich gut im Vergleich zu .... na sagen wir mal Linux (im Sinne vom Linux-Umfeld). Auch wenn Linux aufgeholt hat hat man häufig noch Projekte, wo es keine aktuelle Doku gibt. Ich hab auch manchmal das Gefühl, in dem Umfeld wird sehr "agil" entwickelt. :-)
    So nach dem Motto: Wir basteln erst mal unsere Software. Doku machen wir später. Und da lieber neue Features eingebaut werden als Doku geschrieben, kommt die Doku nie oder ist auf einen suboptimalen Stand.
    Das kann man natürlich nicht verallgemeinern. Aber die Mentalität geht da öfter gerne mal in die Richtung.
    Und Doku finde ich essentiell. Etwas was nicht dokumentiert ist ist quasi nicht vorhanden. Und komm mir jetzt keiner mit "Du kannst doch in den Source-Code gucken". Das ersetzt keine Doku. Wer so argumentiert, hat den Sinn einer Dokumentation nicht verstanden.
  • Einfachheit
    ist aber ausbaufähig. Vieles ist noch unnötig kompliziert. Warum z.B. Konfigurationsdateien in unterschiedlichen Formaten daher kommen lässt sich aus der Historie begründen aber nicht mit Vernunft.
    Solche Sachen sind aber noch alle harmlos gegenüber das, was einem in anderen Systemen begegnet.
  • ZFS
    Ähm ja. ZFS gibt es auch für Linux. Bei FreeBSD ist es aber deutlich besser ins System integriert. Andere Features von FreeBSD nutzen ZFS
    Wo wir gerade beim Thema sind: Boot Environments
  • Kein systemd ;-)
  • Security
    Vor allem gibts hier ne zentrale Anlaufstelle für Security-Bugs. Großer Pluspunkt.
    Und die Security-Features von FreeBSD müssen sich auch nicht hinter der Konkurrenz verstecken
  • Lizenz :-)
Docker kann und Docker doch jetzt der heiße Scheiss ist
Die mangelnde Docker-Verfügbarkeit ist sicher ein Nachteil von FreeBSD. Insbesondere wenn man in die Beliebtheitsskala guckt. Die Leute wollen es (Sinn oder Unsinn außen vorgelassen), also musst Du so was bieten.
 
Der Thread wird ja ganz schön lang :) Ist auch ok - ein bisschen Senf möchte ich trotzdem (nochmals) dazu geben :) Nunja, es ist sehr schade, dass die Verbreitung von *BSD doch wesentlich schwächer ist als von Linux. Es würde mir reichen, wenn die Beliebtheitsskala sich auf 5 Prozent im Server- und auch im Desktopbereich erhöhen würde. Ein Beispiel: ich besuchte gestern einen Freund, mit einem Win10 PC. Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows :)) laufen lässt, erscheinen nur 40GB dabon genutzt. Keine Ahnung warum. Auch ist es immer wiede erstaulich, wie gerade Windows Leute die PC Begriffe durcheinanderschmeissen. Manchmal ist es so als würde man über Dübel reden, wenn man ein Auto zusammenbauen würde ;-) Tja, viele Leute beschwereren sich über die Komplexität von *BSD. Hat man aber ein Problem auf einer anderen Platform (auch z.B. bei Apple), ist die Analyse und Behebung oftmals sehr kompliziertert. Es ist ja alles nutzerfreundlich verborgen :) Ich weiss, der Normalsterbliche weiss vieles nicht (muss er auch nicht), und wenn meine Mama (die ja schon über 80 ist) mal eine mail schreiben würde, würde ich über alle Fehler hinwegsehen :) Ein hoch auf BSD! Prost (heute abend) :) Norbert
 
Plus die Tatsache das die Leute offenbar mit Docker nicht umgehen können.

"Die Leute" können auch nicht mit BSD umgehen. Sollen wir deswegen jetzt auf BSD verzichten? ;)

Container-Workflows sind in vielen Unternehmen etabliert und laufen dort reibungslos ab. Dort werden aber sowohl zur Build- als auch zur Laufzeit die Container auf ihre Sicherheit überprüft.

Ich muss vorneweg sagen, das ich relativ wenig Erfahrungen mit höherleveligen Toools a-la Bastille, iocage, ezjail, cbsd und wie sie alle heißen habe. Ich nehme im Umgang mit Jails im Wesentlichen die jail-Kommandos die bei FreeBSD halt mit dabei sind.

Ich erzähle in meinen Erfahrungsberichten auch von Bereichen, in denen Tools wie Bastille eher low-level und am Anfang der Kette sind sind. Die ganze Magie passiert ja erst danach. :)

Aber das lässt sich meines Erachtens mit überschaubaren Aufwand realisieren. Und wenn eine Firma sogar bereit ist VIEL Geld in die Hand zu nehmen, sollten Sie da nicht auf ernsthafte Probleme treffen. Einige Sachen bekommen sie auch schon durch vorhandene Projekte gelöst. Da könnte man ansetzen.

Daher bin ich jetzt etwas unsicher, warum die Firmen das nicht einfach machen.

Wir reden trotz alledem von mehreren Teams, vielen Millionen Euro und einem langen Zeitraum bis zur Produktionsreife - zumal man erstmal die Köpfe haben muss, Entwickler wachsen nicht auf Bäumen.

Es besteht auch die Gefahr, dass man anschließend ganz alleine mit seiner Lösung auf weiter Flur steht, weil bis zur Produktionsreife der Rest der Unternehmen mit vergleichbaren Anfordungen schon wegmigriert ist. Deswegen gibt es jetzt Firmen mit FreeBSD, die wie ein Reh im Scheinwerferlicht stehen und nicht wissen wohin.

Vielleicht wollen die ja eher doch Docker auf FreeBSD, so dass sie gleich auf vorhandene Ressourcen (fertige Images, Tools die ihrerseits auf Docker aufsetzen, Cloud-Anbieter etc.) zugreifen können.

Es muss nicht Docker sein - Docker Hub ist zwar nett, aber mehr schmuckes Beiwerk und Spielwiese. Die Firmen wollen den Workflow und den einfachen Betrieb, den Docker, Kubernetes und das Ökosystem darum ermöglichen. Inzwischen gibt es auch einige Entwicklungs-Tools, die nativ auf Containern aufsetzen.

Naja. Ein typisches Beispiel von "wir haben von anderen gelernt" wäre bhyve.
Von anderen gelernt heißt aber auch, man hat später angefangen. Und dann beschwerst Du Dich ja, warum man noch nicht so weit ist wie alle anderen.

Xen ist von 2003, KVM von 2007, bhyve von 2013. Die Idee ist, dass man von den Vorgängern lernt und dann auch besser und schneller vorwärts kommt. Xen und KVM waren 7 Jahre nach ihrem ersten Release längst produktionsreif.

Oder welchen Grund sollte es denn noch geben von Subversion wegzukommen?

Das zentralisierte Modell (Server down - nix geht), das bescheidene Branching und die Unmöglichkeit, ohne Netzwerkverbindung zum zentralen Server zu committen?

Ansonsten ist bei solchen Dingen, die man verbessern müsste auch immer die Frage: Wer soll es machen?

Wir reden hier leider auch nicht von Dingen, die ein kleines und motiviertes Team in einem verregneten November macht. Der Rückstand ist halt an vielen Fronten über die Jahre arg gewachsen.


Interessanterweise ist das der Grund, und nicht die Technik, warum die Netflix-Appliances auf FreeBSD laufen. Die gesamte restliche Anwendungslandschaft von Netflix läuft in Linux-Containern - soviel zum Thema, warum sowas auf FreeBSD nützlich wäre...
 
Magst du die besondere Bedeutung von CMS-Anwendungen aus deiner Sicht erläutern?

Eine "besondere Bedeutung darin sehe ich, im Aspekt "Was bieten Firmen ihren Kunden überhaupt", also im technischen Sinne IT betreffend. Das sind (auch physische) Produkte, Dienstleistungen und generell Inhalte. Und CSM bietet sowohl intern wie auch also extern eine Plattform dafür.
Der Anwendungsbereich für genrell ContentSysteme ist ja riesig und unerschöpflich. Ich kann mir schon vorstellen, dass die wirtschaftliche Bedeutung davon jener von ERP usw gleicht.

Wir unterhalten uns hier ja vorwiegend über technische Aspekte, aber ich glaube weniger, dass alleinig diese schlussendlich die Entwicklung ausmachen. Container hin oder her . . Auf der anderen Seite ist es typisch, dass solche Dinge technisch Tätige wie Devs' und Ops; eher interessiert.

Es ist ja grundsätzlich kein neues Phänomen, dass Betriebssysteme bis hin zum Quasimonopol bevorzugt werden und andere trotz mindestens qualitativ gleichstehender Technik, beinahe oder gar ganz verschwinden.

Angesichts der Menge die an Software inkl OS gebraucht wird - und zwar zunehemend - eigentlich doch paradox.

Frage nebenbei : wer von hier hat noch ein Blackberry (OS10) -oder Symbian-Smartphone und hatte irgendwer mal eines der letzten Generation?
Warum man keines hatte, kann möglicherweise prinzipiell die selbe Ursache haben, wie sich eine Firma gegen FreeBSD entscheidet.

Eine Ursache kann sehr subtil und muss keineswegs spektakulär sein.
Ich glaube nicht, dass das grosse Kopfschütteln ausbrechen würde, würde hier ein Haufen Entscheidungsträger von Firmen mitlesen.

Selbst da wo man im eigenen Leben "Entscheidungsträger" ist, entscheidet man doch allzuoft aus profanen Beweggründen.
Nicht nur OS, oder tolle Anwenderprogramme sind auf solche Weise verschwunden, sondern m.E. gar ganze Technologien. Ein Teil davon gehört zum üblichen Verlauf des technischen Fortschritts, ein Teil aber auch nicht. Und so einer liegt hier vor.
Schlussendlich ist das Ganze eine Mischung aus Details und Strukturen.
Wen die Technik da ist und auch gut ist, dann liegt einer der Ursachen vlt doch eher an den Strukturen.
Und ich halte es auch für möglich, dass solche Entwicklungen zyklisch sind und sich über-regional etwas unterscheiden.

Ob jemand in 50 Jahren noch von Windows oder Unix spricht?
 
Ein Beispiel: ich besuchte gestern einen Freund, mit einem Win10 PC. Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows :)) laufen lässt, erscheinen nur 40GB dabon genutzt. Keine Ahnung warum.

Das Werkzeug DU (Disk Usage) gibt es auch unter Windows, ja, aber, daß habe ich noch nicht erlebt/gesehen. Also, wenn das stimmt, dann ist da was oberfaul. Entweder taugt das Werkzeug nichts, oder da gibt es einen Haufen versteckter Dateien.

Aber so etwas gibt es vom System her nicht.
 
Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows :)) laufen lässt, erscheinen nur 40GB dabon genutzt. Keine Ahnung warum.
Snapshots, auf Endnutzer-Windowsen meist in Form von Sicherungspunkten. Dazu versteckte Systemdateien, unter anderem die hiperfil.sys für den Ruhezustand.
 
Moin,

also was FreeBSD schon seit Jahren fehlt sind ordentliche bootstrapping optionen.

Nehmen wir einfach mal das aufsetzten (Unattended) einer Virtuellen FreeBSD Machine in irgend einem Hypervisor:

1.) PXE Boot:
PXE mit TFTP ist einfach OUT.
Klar kann man iPXE mit http umsetzten. Es sollte aber mit FreeBSD Boardmitteln machbar sein.

2.) Init
Da fehlt es bei FreeBSD komplett an einer Lösung.
Und Cloud-init läuft einfach nicht Ordentlich mit FreeBSD.
Aber man hätte hier auch eine einfache Variante bauen können.
Scripte sind auf Dauer keine Lösung (auch bsdinstall ist nur ein Shell Script), weil die keiner Pflegt.

3.) Bhyve
Selbst mit Bhyve hab ich keine ordentlich Bootstrapping option für FreeBSD VM's out of the box.
(Thema: Metadata Store pro VM)

Gerne würde ich dazu mal updates hören und mich freuen wenn sich hier etwas getan hat in der letzten Zeit.
 
Ganz allgemein (und gegen niemanden speziell hier gerichtet) finde ich aber dieses "FreeBSD müsste" doch immer etwas problematisch. FreeBSD ist ein Open Source Projekt, was sich bis auf 3 angestellte Entwickler der FreeBSD Foundation ausschließlich freiwillige Arbeit stützt. Freiwillig im Sinne von Unternehmen, die FreeBSD nutzen und Entwicklungszeit spenden, dazu eben Hobbyisten. Unternehmen entwickeln in Bereichen, die ihnen Vorteile bringen und Hobbyisten im Rahmen ihrer Interessen. Das funktioniert meist ganz gut, aber wenn man etwa Spezielles will, kommt man nicht darum herum es selbst zu machen oder eine Bounty auszuschreiben. Und das Selbstmachen ist oft gar nicht schwer, es muss nicht einmal zwingend Code sein. Nehmen wir mal Bhyve, da es oben genannt wurde meine letzte Runde FreeBSD-Beiträge vor allem dort war:
  • Bhyve ist rein funktional inzwischen fast vollständig. Es fehlen vor allem Kleinigkeiten und Komfortfeatures, die sind aber meist schnell implementiert. Ich brauche Bhyve im Moment zum Beispiel für Windows-Gäste auf billigen Intel-Desktop-CPUs. Da war es im wahrsten Sinne des Wortes kacklahm. Das Problem zu analysieren (fehlendes TPR Shadowing, da für Xeons nicht relevant) hat mich ungefähr 4 Stunden Arbeit gekostet. Im Intel Architecture Manual nachzulesen und es in Bhyve zu implementieren noch mal zwei Stunden. Da Review war tatsächlich sogar mehr Aufwand, als die Implementierung.
    Einen einfachen Identifier durch die SMBIOS-ID in die VM zu injizieren, wäre auch eine Sache von 20 Zeilen und vielleicht einer halben Stunde. Ab damit in den Bhyve-Umbrella auf https://reviews.freebsd.org/ und die Sache ist in ein paar Wochen durch. Oft kann es sich auf helfen in die auf Bhyve aufbauenden Projekte wie ACRN (https://projectacrn.org/) zu schauen, sie haben teilweise interessante Dinge bereits implementiert, die man mit wenig Aufwand zurückportieren kann.
  • Aber auch wenn man nicht programmieren will oder kann, kann man mit solchen Wünschen herantreten. Gerade bei eher kleinen Dingen ist die Wahrscheinlichkeit erhört zu werden doch sehr groß. Beispielsweise lagen zwischen dem Wunsch VMs beim Herunterfahren des Gasts automatisch zu zerstören und der Implementierung keine 48Stunden. Dafür gibt es die freebsd-virtualization@freebsd.org Liste, es gibt den sehr freundlichen und hilfsbereiten #bhyve Channel auf Freenode und es findet alle 14 Tage eine Telefonkonferenz zwischen Bhyve-Nutzern und Entwicklern statt. Für eine Einladung einfach Michael Dexter anschreiben. Die Konferenz rotiert in Sachen Uhrzeit immer etwas, um allen Zeitzonen die Chance zur Teilnahme zu geben.
 
hi

was ist an dem FreeBSD init so verkehrt , der ist mir 1000x als alles das was bei den meisten linux distrbutionen ,
aktuell verwendet wird.

und das man die installation nicht automatisieren kann , oder schlecht , kann man ändern , falls nötig.

Holger
 
hi

was ist an dem FreeBSD init so verkehrt , der ist mir 1000x als alles das was bei den meisten linux distrbutionen ,
aktuell verwendet wird.

und das man die installation nicht automatisieren kann , oder schlecht , kann man ändern , falls nötig.

Holger

Am FreeBSD init und auch sonst ist nix verkehrt.
Und natürlich kann man den init ändern. Ich hab auch schon Unattended installations mit FreeBSD über PXE boot und bsdinstaller gemacht. Leider ist das aber Aufwändig und schlecht zu Pflegen.

Mir geht es nicht ums Blamen, sondern es bezieht sich auf den Topic warum ein Interesse an FreeBSD rückläufig sein könnte.
Wenn ein OS nicht aktuelle Techniken (vergleichbar zum Mainstream) beherrscht, dann ist die Kosten/Nutzen Rechnung für Unternehmen sehr einfach.
Und FreeBSD spielt in den Clouds für viele Unternehmen (aus Nutzersicht) keine Rolle mehr (VM's, Container, K8, ...). Ich denke der Zug ist abgefahren. Eventuell kommt FreeBSD noch im Backend zum Einsatz.
 
"Die Leute" können auch nicht mit BSD umgehen. Sollen wir deswegen jetzt auf BSD verzichten?
Sehr witzig. :-)
Aber Du weißt sicher, was ich meine.
Ums mal salopp zu formulieren, wenn die Leute mit BSD nicht umgehen können, kriegen sie damit auch nichts zustande. Mit Containern kriegen sie trotzdem was ans laufen, das ist dann aber buggy und/oder mit Sicherheitslücken durchsetzt.

Das spricht nicht gegen Container ansich. Das bedeutet, das bessere Tools nicht automatisch zu besseren, sondern manchmal sogar zu schlechteren Ergebnissen führen. Hatten wir aber eigentlich alles schon mal.

Container-Workflows sind in vielen Unternehmen etabliert und laufen dort reibungslos ab. Dort werden aber sowohl zur Build- als auch zur Laufzeit die Container auf ihre Sicherheit überprüft.

Gibt sicherlich auch Vorzeigeprojekte oder Leute die es richtig machen.

Im allgemeinen ist die IT aber in Firmen in einem eher schlechten Zustand.

Und da wird dann sowas wie Docker und Co eingesetzt um die Probleme zu lösen. Und das ist das was ich sehe und was ich auch anprangere. Und nicht die handvoll Firmen die es richtig machen.

Ich erzähle in meinen Erfahrungsberichten auch von Bereichen, in denen Tools wie Bastille eher low-level und am Anfang der Kette sind sind. Die ganze Magie passiert ja erst danach.
Wie gesagt. Ich kenne mich da nicht aus. Ich wundere mich nur, das einerseits angeblich so viel Geld dafür da sein soll für FreeBSD Lösungen zu entwickeln, andererseits Projekte wie Bastille und Co dann noch nicht weiter sind.

Wir reden trotz alledem von mehreren Teams, vielen Millionen Euro und einem langen Zeitraum bis zur Produktionsreife - zumal man erstmal die Köpfe haben muss, Entwickler wachsen nicht auf Bäumen.
Jaja. Der allseits beliebte Fachkräftemangel.
Komisch ist nur, das man davon als Entwickler immer nix merkt, sobald es an Gehaltsverhandlungen geht. :-)

Es besteht auch die Gefahr, dass man anschließend ganz alleine mit seiner Lösung auf weiter Flur steht, weil bis zur Produktionsreife der Rest der Unternehmen mit vergleichbaren Anfordungen schon wegmigriert ist. Deswegen gibt es jetzt Firmen mit FreeBSD, die wie ein Reh im Scheinwerferlicht stehen und nicht wissen wohin.
Man kann sich ja auch zusammentun.

Das zentralisierte Modell (Server down - nix geht), das bescheidene Branching und die Unmöglichkeit, ohne Netzwerkverbindung zum zentralen Server zu committen?
Falls Du es noch nicht wusstest: Bei GIT kann man bei Netzwerkausfall auch nix zum Server commiten. Oder wie kriegst Du ohne Netz Dein Kram nach github und Co.?
Sorry, aber das sind doch herbeigedichtete Probleme.

Es gibt ganz sicher gute Gründe für GIT. Keine Frage. Aber ein pauschales "Subversion ist veraltet und GIT in allen Belangen überlegen" ist doch totaler Quatsch. Und das Du keine konkreten Punkte nennen konntest, sollte Dir da zu denken geben. :-)
 
Ums mal salopp zu formulieren, wenn die Leute mit BSD nicht umgehen können, kriegen sie damit auch nichts zustande.

Die Einstiegshürde in BSD - mal abgesehen von der Bekanntheit beim unbedarften Publikum - ist jetzt nicht nennenswert höher als bei bei z.B. Ubuntu Server. Installer mit Defaultwerten durchklicken und hinterher hast du eine nackte Shell.

Umgekehrt hatten wir hier schon altgediente BSD-Nutzer im Forum, die im Brustton des Stolzes berichtet haben, wie sie mit ihren komplett ungepatchten Solaris-Installationen im World Wide Web unterwegs sind und auch nach dem Hinweis auf den Faktor Security kein Problembewusstsein entwickelt haben.

Mit Containern kriegen sie trotzdem was ans laufen, das ist dann aber buggy und/oder mit Sicherheitslücken durchsetzt.

Derselbe Anwender hätte alternativ eine Sammlung niemals aktualisierter FreeBSD-Packages auf seinem System - zumal er auf Linux-Seite zuerst bei z.B. den Ubuntu Packages landen würde. Derselbe Anwender würde ja schon daran scheitern, seine Container als Service zum Laufen zu kriegen. :ugly:

Im allgemeinen ist die IT aber in Firmen in einem eher schlechten Zustand.

Ich hätte eher auf eine Gauss'sche Verteilungskurve getippt, wobei man sich über die Mitte streiten kann. ;)

Und da wird dann sowas wie Docker und Co eingesetzt um die Probleme zu lösen. Und das ist das was ich sehe und was ich auch anprangere. Und nicht die handvoll Firmen die es richtig machen.

Die Firmen, die ihre IT nicht im Griff haben, lassen meistens von vornherein die Finger von Docker & Co. - deren Admins und Entwickler haben nämlich null Bock auf neues Zeug. Die sind froh, wenn alles so bleibt wie es ist und nach Möglichkeit niemals irgendeine Form von Innovation gibt.

Wie gesagt. Ich kenne mich da nicht aus. Ich wundere mich nur, das einerseits angeblich so viel Geld dafür da sein soll für FreeBSD Lösungen zu entwickeln, andererseits Projekte wie Bastille und Co dann noch nicht weiter sind.

Aus meiner persönlichen Erfahrung ohne Anspruch auf Allgemeingültigkeit: Unternehmen mit FreeBSD als Server-Plattform sind jetzt nicht unbedingt - Ausnahmen bestätigen die Regel - an der Speerspitze der IT-Entwicklung unterwegs. Dort geht es eher gemächlich zu, frei nach dem Motto "never change a running system" und "keine Experimente".

Es hat schon einen Schock wie COVID-19 gebraucht, um aus der gewohnten Trägheit zu erwachen. Jetzt sieht man mit Erstaunen, wie die Konkurrenz mit neumodischen Methoden wie "DevOps" und neumodischer Technik wie "Containern" in (für die alte Garde) Rekordzeit auf geänderte Rahmenbedingungen reagieren kann (vgl. mein Erfahrungsbericht hier im Forum).

Jaja. Der allseits beliebte Fachkräftemangel.
Komisch ist nur, das man davon als Entwickler immer nix merkt, sobald es an Gehaltsverhandlungen geht. :-)

Zumindest im Süden der Republik kann man sich nicht beschweren. Man wird als Entwickler aktiv umworben und die Firmen wissen den Wechsel schon schmackhaft zu machen. :D

Man kann sich ja auch zusammentun.

Dafür bräuchten die Unternehmen die Kontakte. Erfahrungsgemäß sind die FreeBSD-Verfechter nicht unbedingt die, die bei den einschlägigen IT-Community-Veranstaltungen überrepräsentiert sind, auf denen man einen Erstkontakt für die Zusammenarbeit herstellen könnte.

Falls Du es noch nicht wusstest: Bei GIT kann man bei Netzwerkausfall auch nix zum Server commiten. Oder wie kriegst Du ohne Netz Dein Kram nach github und Co.?

Bei Git sind commit und push zwei unterschiedliche Aktionen. Subversion macht immer beides unzertrennbar mittels commit.

Mit Git kann man problemlos offline eine Familienpackung Commits in ein lokales Repository machen und - sobald man wieder Netz hat - am Ende das Gesamtwerk zu einem anderen Repository (z.B. GitHub) übertragen. So hat man eine schön nachvollziehbare Commit-Historie mit kleinen Änderungen fürs Review und keinen Big-Bang-Mega-Commit, dessen Änderungen keine Sau mehr nachvollziehen kann.

Es gibt ganz sicher gute Gründe für GIT. Keine Frage. Aber ein pauschales "Subversion ist veraltet und GIT in allen Belangen überlegen" ist doch totaler Quatsch.

Korrekt, die Aussage ist aber auch nirgendwo hier gefallen. Beides hat wie immer seine jeweiligen Vor- und Nachteile.

Meine Aussage war nebst meinem Exkurs über die Nachteile von Subversion im Vergleich zu einem DVCS (egal ob mercurial, git o.ä.) folgender Punkt für das Gedeihen von FreeBSD:
Den FreeBSD-Code endlich auf ein modernes Versionsverwaltungssystem umstellen und Subversion aufs Altenteil schicken.

Hintergrund meiner Aussage? Der "FreeBSD Survey 2019" der FreeBSD Foundation, Frage 14.
Auf Platz 1 der Antworten auf den zu ergänzenden Satz "I would contribute to FreeBSD more if the FreeBSD Project" steht: "Transitioned to using git"!

Wenn die zentrale FreeBSD-Community den Wechsel von Subversion zu Git als wichtigste Änderung überhaupt für mehr Beiträge zu FreeBSD sieht, nehme ich das natürlich in die Liste der aus meiner Sicht sinnvollen Änderungen im FreeBSD-Umfeld auf.

Obige Umfrageergebnisse findet man auf Seite 30 sowie 49f.: https://wiki.freebsd.org/DevSummit/...o=get&target=core.10+BSDCan+Status+Update.pdf

Mehr Infos gibt es bei der Aufzeichnung der Präsentation der Ergebnisse.

Und das Du keine konkreten Punkte nennen konntest, sollte Dir da zu denken geben. :-)

Ich wollte eine ausufernde Diskussion über Versionsverwaltungssysteme vermeiden, zumal alle relevanten Kandidaten auf allen relevanten Betriebssystemen laufen und es für den Einsatz von FreeBSD keinen Unterschied macht, wenngleich für die Beiträge zu FreeBSD.

Für eine umfangreiche Diskussion über die Vor- und Nachteile von CVCS vs. DVCS, Subversion vs. Git, Files vs. Objects als Grundlage und vieles mehr bin ich natürlich immer zu haben. Dafür kannst du gerne einen neuen Thread aufmachen. :)

Cloud-init ist jetzt was und inwieweit steht das in Beziehung zu einem Init-System wie rc?

Ich darf die Homepage von cloud-init zitieren:
Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization. It is supported across all major public cloud providers, provisioning systems for private cloud infrastructure, and bare-metal installations.

Cloud instances are initialized from a disk image and instance data:
  • Cloud metadata
  • User data (optional)
  • Vendor data (optional)
Cloud-init will identify the cloud it is running on during boot, read any provided metadata from the cloud and initialize the system accordingly. This may involve setting up the network and storage devices to configuring SSH access key and many other aspects of a system. Later on the cloud-init will also parse and process any optional user or vendor data that was passed to the instance.
Das ist in so ziemlich jedem modernen Rechenzentrum der Welt Standard, egal ob selbst- oder fremdbetrieben. Bei Interesse ist dieses 7-minütige Video einen Blick wert.

Was hat das mit rc zu tun? In diesem dynamischen Umfeld ist es sehr vorteilhaft, ein Init-System mit einem guten Management für notwendige und optionale Abhängigkeiten sowie einer exzellenten Reaktionsmöglichkeit auf Events zu haben. Um es vorsichtig zu formulieren: FreeBSDs rc hat seine Stärken mehr in eher statischen Umgebungen.

Bei Interesse kann ich weiter ausholen - mehr will ich aber eigentlich gar nicht schreiben, sonst sind wir sofort bei der endlosen Diskussion rund um Init-Systeme... :o
 
Zuletzt bearbeitet:
Hast du Erfahrungen jüngeren Datums mit cloud-init und FreeBSD? Mein letzter Anlauf ist ein paar Jahre her, da musste man noch alle Images selber basteln und der Support in cloud-init war noch sehr rudimentär.

Hi Azazyel,

ich hatte vor ca. 4-5 Jahren mal Cloud-init auf FreeBSD getestet, irgend wann war der Port dann auch Broken.
Bis jetzt hab ich es nicht wieder getestet.
 
Zurück
Oben