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

oh an damit es vollstänndig ist , ein kommentar von mir .

ich persoenlich bin sehr froh das es docker nicht auf free/open bsd gibt.

docker ist für mich ein hyp der getrieben ist von software firmen und entwicklern , der normale admin , der im zweifel gerade mal eine
automations software im einsatz hat aber keine komplette ci umgebung .

nun kommt ein weiteres oekosystem um das er sich kümmern muss , monitoring , software updates , security ,customizing .

wenn sich dann ein teil aus dem okosystem verabschiedet , z.b. release wechsel einer verwendeten library und und dem
lieferanten des docker image das egal ist weil seine software ja leuft , hast du ein security loch erster güte im system.

docker ist fuer kunden ein blackbox , was dann mit "aus den augen , aus dem sinn" betrachtet wird, ein super GAU fuer jeden
der nur einwenig die sicherheits , bzw die dsgvo brille anhat.

ich merke das ja auch schon an meinen 2-3 jails , sie laufen , und ich kümmer mich nicht drum , bzw weit weniger als um den host.
ich sehe durchaus vorteile für docker , aber sie liegen aus schliesslich im bereich der software entwicklung und ggf sofware
( vertrieb / distribution ).

FreeBSD / OpenBSD bieten vorteile , gerade im bereich " wir haben mal drueber nach gedacht " linux ist fuer mich viel
zuviel chaos und Anarchie , jeder macht was er will , und das wird dann innovation verkauft .

unix mag zwar alt sein aber , die zugrunde liegenden ideen und gedanken sind wichtiger und moderner den je ,
man muss nicht jeden hyp mit gehen , wenn man selbst schon eine lösung hat .

im übrigen ist die ganze diskussion in ein flamewar "freebsd vs linux" geworden , dazu nur eins,
wenn jemand linux nutzen will soll er es bitte machen , hier ist ein bsdforum .

die diskussion darum ist müssig , und boring weil die meisten wissen warum sie ein BSD lieber verwenden als linux
und wollen nicht bekehrt werden.

holger
 
ein BSD lieber verwenden als linux
und wollen nicht bekehrt werden.
Jo! Ich hatte erst vor einiger Zeit eine Situation, wo ich ein Ubuntu 20.04 installiert hatte und danach aus Gewissens- und Bequemlichkeitsgründen doch wieder mein GhostBSD genommen hab. Da weiss man was man hat und es ist alles überschaubar und strukturiert.
Auf einem Firmenlaptop läuft es jetzt auch schon seit Wochen und bleibt auch drauf.

Ich finde diese Snaps bei Ubuntu mittlerweile nicht gut, denn es gibt wieder Abhängigkeiten. Wenn Flatpak genauso ist (was ich nicht hoffe) dann ist das Konzept fürn A.... in meinen Augen.

Auch wieder das Ding mit mehreren Ansätzen: Snap, Flatpak, AppImage.

Das nerft einfach nur! Und hin und wieder startet eine App nicht weil doch wieder eine Abhängigkeit fehlt. Alles schon erlebt.

Nein, da fühlt es sich tatsächlich angenehmer an, meine ganzen gecachten pkgs zu sichern, für den Fall der Fälle und gut ist.

Ja und und ich finde das Konzept von FreeBSD super und modern! Es ist einfach, performant und klein (FreeBSD ohne Desktop).
 
Wenn ich den Verlauf der Diskussion hier mitverfolge, so scheint mir, als gäbe es eine gewisse Diskrepanz zwischen Deskop und Server bzw kommerzieller Verwendung.

Ich kann das ja nicht persönlcih einschätzen, aber wenn die zahlenmäsige Verwendung von FreeBSD in Unternehmen tendenziell am schwinden ist, steht die doch passable Tauglichkeit als Desktop-System dem entgegen.

Es gibt einige Interessante Desktop-Derivate/Distributionen, die durch die teilweise NVIDIA-GraKa Unerstützung durchaus Potenzial für grössere Verbreitung böte.

Klar, wie auch auf Desktop, gibt es auch bei Server-Anwendung gewisse Dinge nicht, aber bei FreeBSD steht man unter den BSDs" doch ganz gut da. Auch an beinahe-fertigen Sicherheitslösungen mangelt es nicht , denke man an TrustetBSD oder HardenedBSD.

Was ich nicht ganz verstehe, sind so Sachen wie das Theater um Dokker etc.
Besonders im kommerziellen Umfeld ist es doch alles andere als unüblich, mehrere Betriebssysteme zu fahren.
Und wenn dieser Aspekt nun doch von grosser Bedeutung ist, wären es m.M. doch eher CMS-Anwendungen als Entwicklerwerzeuge. In der heutigen Datenbank -und Netzwerk-lastigen IT-Umgebungen müssten es doch andere Ursachen sein.

Aber i.d.R. wird ja heisser gekocht, als gegessen und vlt ist das eher ein regionales Phänomen.
In Deutschland sind natürlich einige IT-Giganten sehr präsent. Schon klar, dass die versucht sind, Unternehmen mit konditionell atraktiven Angeboten zu gewinnen.
 
steht die doch passable Tauglichkeit als Desktop-System dem entgegen.
Passabel würd ich das nicht mal nennen. GhostBSD 20.04 erkennt jetzt zB automatisch die Hardware und bootet in den passenden Grafikmodus. Vorher konnte bzw musste man das selbst auswählen. Gut, falls man doch mal nicht weiss was drin steckt.
Auch sonst gibt GBSD einen guten Desktop ab. Mehraufwand im Vgl. zu Linux:

User anlegen/bearbeiten und Festplattenmanagement per Command-Line

Hin und wieder mal Einträge in den Configs (zB für Joystick Support) vornehmen. Das wars.
 
docker ist für mich ein hyp der getrieben ist von software firmen und entwicklern , der normale admin , der im zweifel gerade mal eine automations software im einsatz hat aber keine komplette ci umgebung .

Für solche Unternehmen ist die Wahl des Betriebssystems aber auch kein differenzierender Faktor.

wenn jemand linux nutzen will soll er es bitte machen , hier ist ein bsdforum .

Das ist jedem Einzelnen unbenommen. Beim Unternehmenseinsatz gibt es halt noch ein paar Faktoren mehr als die rein individuelle Vorliebe und die Tauglichkeit des isolierten Einzelplatzeinsatzes.

Wenn ich den Verlauf der Diskussion hier mitverfolge, so scheint mir, als gäbe es eine gewisse Diskrepanz zwischen Deskop und Server bzw kommerzieller Verwendung.

Korrekt. Ich hab den Desktop-Bereich in Unternehmen ziemlich ausgeblendet. Dort dominiert sowieso Windows (wg. Microsoft Office, Active Directory, Gruppenrichtlinien etc.). Macs sind teilweise auch noch ganz präsent. Danach wird es sehr überschaubar.

Ich kann das ja nicht persönlcih einschätzen, aber wenn die zahlenmäsige Verwendung von FreeBSD in Unternehmen tendenziell am schwinden ist, steht die doch passable Tauglichkeit als Desktop-System dem entgegen.

"Passabel" reicht leider nicht, um gegen die Platzhirsche Windows und Mac anzukommen. FreeBSD müsste hier ja schon enorme Vorteile bieten, allein schon um gegen den Faktor Trägheit anzukommen.

Es gibt einige Interessante Desktop-Derivate/Distributionen, die durch die teilweise NVIDIA-GraKa Unerstützung durchaus Potenzial für grössere Verbreitung böte.

Die wenigsten Unternehmensrechner haben dedizierte Grafikkarten. Intels in die CPU integrierte GPU ist hier die mit Abstand meistgenutzte Grafikkarte.

Besonders im kommerziellen Umfeld ist es doch alles andere als unüblich, mehrere Betriebssysteme zu fahren.

Man möchte den Zoo aber trotzdem möglichst klein halten. Zurecht fragt man sich, warum man neben Windows/Mainframe/iSeries/Mac auch noch mehrere Unix-Betriebssysteme hat.

Nach dem faktischen Todesstoß für Solaris, der Stagnation bei AIX und dem Trend hin zu Open Source stellt sich dann in vielen Fällen die Frage: Linux oder FreeBSD? Vor- und Nachteile? Was bietet das eine, was das jeweils andere nicht kann?

Und wenn dieser Aspekt nun doch von grosser Bedeutung ist, wären es m.M. doch eher CMS-Anwendungen als Entwicklerwerzeuge.

Magst du die besondere Bedeutung von CMS-Anwendungen aus deiner Sicht erläutern? :)

In der heutigen Datenbank -und Netzwerk-lastigen IT-Umgebungen müssten es doch andere Ursachen sein.

In meiner Wahrnehmung und Erfahrung bei Unternehmen: wenn ich heutzutage die Software meiner Kerndomäne möglichst flexibel, effizient und effektiv entwicklen, testen und betreiben möchte, lande ich fast immer bei Containern und dem dazugehörigen Ökosystem.

Das sind natürlich Aufgabenstellungen weit jenseits der Welt des heimeligen Rechnereinsatzes, aber auch Anforderungen, an denen sich ein professionelles Unix messen lassen muss.

Aber i.d.R. wird ja heisser gekocht, als gegessen und vlt ist das eher ein regionales Phänomen.

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. :(
 
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. :(
Wir, ich mache Firmwareentwicklung für Industriehardware, sind voll im Microsoft Lock-In. Unsere Dokumente liegen auf OneDrive, unser Code in der Azure Cloud. CI und Hosting über Azure DevOps (das ist so etwas wie github in schlecht). Kommunikation über MS Teams und Outlook.

Wir müssen uns keine Sorgen über Industriespionage machen, wir liefern direkt frei Haus. :ugly:
 
Auch wenn die *BSD-Familie seine Stärken und Swächen hat: Es ist für mich persönlich immer noch angenehmer als Linux. Vorallem weil dort alles aus einem Guss kommt und es dort strukturiert zugeht. Es ist auch nicht in gefühlt Millionen Distributionen fragmentiert wie bei Linux.
 
Die Betrachtung greift für meinen Geschmack zu kurz
Ja. Wenn man sie isoliert betrachtet, dann schon.

Aber meine Aussage war ja: Komplexität reduzieren
Wenn durch Abstraktion etc. Komplexität hinzukommt, dann diese möglichst klein halten.

Auf den Container übertragen:
Du hast eine Anwendung X. Tust jetzt noch Containerkomplexität hinzu. Die Anwendung kann dadurch nicht mehr als vorher. Das einzige was Du gewinnst ist, das Du Anwendung X besser in Deine beschissene Umgebung integriert kriegst. Anstatt die beschissene Umgebung zu repaireren, machst Du aber Container.

Es gibt natürlich Szenarien wo das Sinn macht. Und Du kannst natürlich auch (völlig berechtigterweise) sagen: Ja. Die Umgebung und Systeme sind beschissen, aber andere haben wir nicht und ich muss mit dem Leben was ich in der Praxis vorfinde und kann nicht alles gerade biegen.

Das ist auch vollkommen verständlich. Ändert aber nichts daran, das diese Lösung dann trotzdem suboptimal ist. Sie kann für den Augenblick pragmatisch sein. Aber sie ist eben nicht gut.

Man muss ja auch ganz klar sagen, das vieles an Konzepten welche wir heute haben aus der Computerhistorie stammt. Zu Anfang ging es ja weniger darum etwas besonders sicher oder etwas besonders fehlerfrei zu haben, sondern den Kram überhaupt zum laufen zu kriegen. Früher ja dann oft auch noch unter dem Druck arg begrenzter Hardwareressourcen. Und vieles aus der Zeit überdauert halt bis heute.

Container machen Automation deutlich leichter (siehe unten).
Nein. Tun sie nicht. Den Eindruck hast Du nur. Ja. Sie machen den umgang mit beschissener Software einfacher. Und es gibt so viele beeschissene Software. Darum sind sie so erfolgreich.

Bessere wäre es natürlich gute Software zu haben bzw. die beschissene Software reparieren zu können. In der Praxis ist das aber nicht immer so einfach. Da hat man oftmals weder die Möglichkeit (Quelltext) und/oder nicht die Ressourcen.

Kurzfristig können da natürlich Container helfen. Auf lange Sicht führt das nur zu mehr Komplexität (bei schlechter Komplexität-Nutzung-Ratio) und damit zu Problemen.

Anders gesagt: Du hast jetzt Probleme die Du billig lösen willst und verschiebst diese Lösung aber in die Zukunft.

Und es ist ja auch nicht so, das ein solches Vorgehen nicht verständlich ist. Niemand weiß halt, was die Zukunft bringt. Und es bringt mir auch wenig wenn ich jetzt schon richtig Zeit in eine Lösung investiere, aber die mir dann halt fehlt um z.B. mein Produkt auf den Markt zu bringen und Einnahmen zu generieren.

Mir ist schon klar, das all dies nicht so einfach ist und es auch Nebenbedingungen gibt, denen man unterworfen ist. Das ändert aber nichts daran, das vieles aus technischer Sicht eine schlechte Lösung ist und das, wenn ich nicht gut aufpasse, mir irgendwann auf die Füße fallen kann. Und auch unweigerlich wird. Deshalb sollte man den Aspekt nicht wegignorieren.

Willkommen in der Welt der menschlichen Natur. Abseits der Software läuft es ganz ähnlich, wenn ich meinen Freunden abseits der IT glauben schenken darf.
Ja. Aber das macht es ja nicht besser.

Das Phänomen ist mir bestens vertraut - leider. Die Menschen wirst du nicht ändern, du kannst sie höchstens behutsam mit der Geschwindigkeit eines Gletschers in eine Richtung bewegen.
Ich denke, bei vielen Sachen stimmen wir durchaus und grundsätzlich überein. Sowohl was solche Sachen angeht als auch die technische Seite.

Bei Reibungsflächen wie Container mag auch eine Rolle spielen, das wir uns die Sache aus unterschiedlichen Perspektiven anschauen.
Um noch mal bei dem Container-Beispiel zu bleiben: Wenn man sich das hier und jetzt anschaut, sicherlich ne Lösung.
In der langfristigen Perspektive ein weiterer Baustein auf dem ohnehin schon hohen Technologiestapel. Das ist der Aspekt, den ich so eher betrachte.

Allein der Hardware-Bedarf und die Turnaround-Zeiten sind mit VMs deutlich größer als mit Containern
Ich wollte Container auch - um Gottes willen - nicht durch VMs ersetzt haben. Da ist das Komplexitätsproblem ja noch schlimmer.

An der Stelle sei nochmals gesagt das ich Container keinesfalls kritisch sehe. Sondern als durchaus nützliche Technologie. Ich sehe halt nur das Problem, das sie 1.überall eingesetzt wird und auch da wo es nicht nötig wäre
2.sie versucht lediglich vorhandene Probleme zu übertünchen ohne sie wirklich zu lösen

Deswegen habe ich mich ganz auf die Technik konzentriert und Marketing ausgeklammert, um dem sonst hier üblichen Argument vorzubeugen, die größere Verbreitung von Linux denn FreeBSD in Unternehmen würde ausschließlich an Faktoren wie Marketing liegen.
Ok. Und nur um Missverständnissen vorzubeugen:
Mir gings jetzt nicht darum die Argumentationskette aufzuziehen, das man Container nicht braucht und deshalb deren fehlen in FreeBSD halb so wild ist.
Ich wollte lediglich meine Kritik an solchen Technologien ansich anbringen bzw. genauer gesagt: Dessen oftmals nicht ganz durchdachter Einsatz.

Es erhöht die Produktivität. Die Fürsprecher für DevOps kommen viel aus der Entwickler-Ecke, weil die keinen Bock mehr haben, von einer Betriebsabteilung abhängig zu sein, die keine API hat.
Das ist aber eher eine Sache der Organisation. Das Problem ist ja, Devs und Ops haben ja teilweise auch gegenläufige Perspektiven auf die Sache, die aus ihrer Sicht auch berechtigt sind. Wenn die Ops weg fallen und die Devs deshalb alleine das machen können, was sie für richtig halten, dann muss das das Ergebnis nicht unbedingt verbessern. :-)

Aus dem Grund haben wir ja auch unabhängige Tester und lassen nicht (nur) die Devs selber testen. Die finden die Devs auch nervig. Und die hätten sicher nix gegen, wenn die wegrationalisiert würden.

Ich glaube nicht, dass es überall so ist - aber es wird für meinen Eindruck anteilig besser. Wir bauen heute natürlich wesentlich mehr Software als früher, die wesentlich häufiger am Netzwerk bzw. Internet hängt
Schwer zu sagen.
Die Anzahl echter Angriffe auf Software finde ich auch noch relativ moderat. Woran das liegt, darüber kann man natürlich spekulieren.
Meine Theorie ist ja, solange es reicht Leuten Phishing-Mails mit Fragen nach Passwörtern oder Anhängen a-la jolie_naked.jpg.exe funktionieren, macht sich niemand die Mühe Sicherheitslücken auszunutzen. Kann man natürlich auch anders interpretieren. Das sozusagen die hohe Anzahl solcher Mails belegt, das die Software sicher ist und man deshalb über sowas gehen muss. :-)

Aber wir wissen halt auch vieles nicht. Man weiß nicht gesichert, wieviel Angriffe über welche Wege geschehen und welche davon erfolgreich sind und welche nicht. Und selbst wenn was rauskommt, dann steht dahinter eine vermutlich sehr viel größere Dunkelziffer.

Themen wie Testabdeckung oder statische Code-Analyse waren vor 1015 Jahren Randerscheinungen; heute sind sie auf breiter(er) Front im Einsatz.
Also klar. Es hat sich etwas gebessert. Nur wächst halt die Komplexität mit die all die Vorteile die man theoretisch hätte wieder auffrisst.
Wie schon gesagt. Auf irgendwelche Bugs in Software trifft man dauernd. Das war früher weniger. Gut. Vielleicht guckt man auf die Vergangenheit etwas verklärt und hat das deshalb nicht mehr so im Gedächtnis. Aber selbst bei einem genauso viel hätte ich ja nicht wirklich was gewonnen.

Aber wie gesagt. Anhand solcher subjektiven Sichtweisen zu diskutieren ist schwierig. Und objektive Daten dazu haben wir nicht.

Ich finde aber schon, dass sie auch ein wenig aus dem Ruder läuft. Denn die Komplexität und Fehlermöglichkeiten von Programmiersprachen und die Abläufe diverser Entwicklungen beziehen sich nicht unbedingt auf FreeBSD.
Genau. Ist über den Tellerrand hinaus geblickt. :-)

Am Beispiel Docker wird erklärt, dass FreeBSD eine Entwicklung verschläft und genau an diesem Beispiel wird auch hinterfragt, ob das nicht sinnvoll sein kann und Docker (wie gesagt, als hervorstechendes Beispiel) eigentlich auch nicht wirklich gebraucht wird.
Nein. So wollte ich das nicht verstanden wissen.
Ich hoffe, dies wurde mit diesem Posting klarer.

Das kann eine Motivation sein, es gibt aber auch andere.
Gut. Apple hat natürlich eher gehofft, das sie davon profitieren. In der Weise, das sich ein paar Entwickler finden die da mitmachen und Apple das dann in ihr MacOS einbauen können. :-)

Keiner hat CUPS geforked oder ne Alternative gebaut. Kann also nicht so schlimm gewesen sein, oder?
Ich weiß nicht mehr, was das Problem war und wie es gelöst wurde. Ich habe lediglich darauf hingewiesen, das es eines gab oder gibt.

"Passabel" reicht leider nicht, um gegen die Platzhirsche Windows und Mac anzukommen. FreeBSD müsste hier ja schon enorme Vorteile bieten, allein schon um gegen den Faktor Trägheit anzukommen.
Gegen Windows spricht eigentlich hauptsächlich die Schadsoftwareproblematik. Mit Windows will man eigentlich nicht ins Internet. :-)
 
@Andy_m4
Du hast eine Anwendung X. Tust jetzt noch Containerkomplexität hinzu. Die Anwendung kann dadurch nicht mehr als vorher. Das einzige was Du gewinnst ist, das Du Anwendung X besser in Deine beschissene Umgebung integriert kriegst. Anstatt die beschissene Umgebung zu reparieren, machst Du aber Container.

Du schreibst hier jetzt schon das dritte oder vierte mal wie schlecht Container doch sind aber du machst genau den gleichen Fehler wieder 1000 andere auch! Container sind nicht dafür gedacht, alte monolithische Anwendungen darin zu verpacken! Das Zauberwort heisst: "Microservices architecture" und dafür müssen die Anwendungen i.d.R. neu geschrieben werden von Grund auf, da sie diese Ansprüche nicht erfüllen können. 1 Prozess pro Container. Anwendungen werden in X Container aufgespaltet und von diesen können dann auch wiederum 10 oder 100 gleichzeitig auf einem Cluster laufen. Das die Container "stateless" laufen sollten, davon gehe ich per default aus. All das kannst du nur mit Software machen, die von Grund-auf so ein Design hat sonst ist das alles meist ein Pfusch (Bastel). Und noch etwas: Genau hie ist auch der Unterschied zu Jails oder LXC/D. Dort kann man nicht einfach einen Prozess in einer Jail starten. Es gibt meist in komplettes Init welches gestartet wird.
 
Und noch etwas: Genau hie ist auch der Unterschied zu Jails oder LXC/D. Dort kann man nicht einfach einen Prozess in einer Jail starten. Es gibt meist in komplettes Init welches gestartet wird.

Aber genau das muss Docker auf Fremdarchitekturen machen. Die Container erwarten einen vollständigen Linux-Kernel. Das funktioniert dann nur, wenn das Fremd-OS die Container auf virtualisierte Linuxe loslässt. Siehe Docker für Win oder Mac, wo man LinuxKit ISOs findet, die dann über die jeweiligen Hypervisor-Lösungen gestartet werden.
Docker an sich ist eben nicht Plattformneutral entwickelt worden.
 
Genau hie ist auch der Unterschied zu Jails oder LXC/D. Dort kann man nicht einfach einen Prozess in einer Jail starten. Es gibt meist in komplettes Init welches gestartet wird.
:confused:
Also ein init sollte nie in einem Jail laufen, ich bezweifle, dass das überhaupt gehen würde – init gibt es genau einmal im laufenden System. Natürlich kannst du ein Jail quasi als "userspace-vm" starten mittels /etc/rc – musst du aber nicht, du kannst genausogut einen einzelnen Prozess drin starten.
 
Grundsätzlich ist jail() erst einmal nur ein Syscall und das jail(8) Userlandtool, sowie die zugehörige libjail sind lediglich Wrapper darum. Man kann daraus viel mehr machen, als nur weitere vollwertige Userland-Instanzen auf dem gleichen Kernel bauen. Meine In-House Software ist z.B. "selbstjailent" (das Wort hab ich mir gerade ausgedacht). Sie startet, liest aus dem Dateisystem was sie braucht, generiert in einem in der Konfiguration angegebenen Arbeitsverzeichnis einige Unterverzeichnisse, erstellt ein Jail in dieses Arbeitsverzeichnis und forkt sich darein. Also ein chroot auf Steroiden.
 
Weil die Zeiten vorbei sind, in denen Windows sicherheitstechnisch ein "schweizer Käse" war.
Hm. Komisch. Dann bilde ich mir solche Sachen wie die Ransomware-Attacken der letzten Jahre wohl nur ein.

Übrigens hab ich gar nicht gesagt, das Windows löchrig ist. Ich habe nur festgestellt, das Windows oft angegriffen wird (was sicher auch seiner Verbreitung geschuldet ist).
Ihr müsst mal lesen, was da steht und nicht so viel reininterpretieren und dann eure Kritik gegen eure Interpretation schreiben.
 
Zuletzt bearbeitet:
Du schreibst hier jetzt schon das dritte oder vierte mal wie schlecht Container doch sind
Tue ich nicht. Ich schreib eher darüber, das Container gerne auch mal missbräuchlich verwendet werden.
Lesen hilft. ;-)

Zauberwort heisst: "Microservices architecture" und dafür müssen die Anwendungen i.d.R. neu geschrieben werden von Grund auf, da sie diese Ansprüche nicht erfüllen können.

Ah. Das nächste Hypewort. Aber ja. Ich versteh schon. ;-)

1 Prozess pro Container.
Wozu brauch ich dann genau Container? Prozesse sind eh schon voneinander isoliert.
Und durch Benutzer-Accounts hab ich auch ne Isolierung auf Dateisystemebene.

Und wenn ich mir dann auch so die Praxis anschaue und z.B. mal auf Docker-Hub gehe
https://hub.docker.com/
Da finde ich Images für Postgres, mysql, ubuntu!!!
Das müssen diese tollen Microservices sein von denen Du redest. Aber auf gar kein Fall normale Programme die lediglich in Container verpackt sind. :-)

Genau hie ist auch der Unterschied zu Jails oder LXC/D.
Du weißt schon, das Du Äpfel mit Birnen vergleichst?
Jails etc. sind auf einem ganz anderen Layer angesiedelt als Docker und Co.
Docker hat ursprünglich auch mal LXC benutzt, wenn ich mich richtig entsinne.
Meine In-House Software ist z.B. "selbstjailent" (das Wort hab ich mir gerade ausgedacht). Sie startet, liest aus dem Dateisystem was sie braucht, generiert in einem in der Konfiguration angegebenen Arbeitsverzeichnis einige Unterverzeichnisse, erstellt ein Jail in dieses Arbeitsverzeichnis und forkt sich darein. Also ein chroot auf Steroiden.
Finde ich ne coole Sache.
Und "selbstjailent" sollte in den Duden aufgenommen werden. :-)
 
Da meine Fragen im Offtopic Wald untergetaucht sind. Versuche ich noch einmal.
Da die Unterstützung der Softwareentwickler eine Mangelware bei *BSD ist, stehe ich nun vor einer schwierigen Entscheidung. Bei FreeBSD bleiben oder doch leider zu Linux wechseln.
Das Problem sind schlicht die fehlende Unterstützung der Anwendungen für FreeBSD.
Performance ist von großer Bedeutung, daher die Lösungen à la Virtualbox und Co. sortiere ich schon mal aus und wechsle dann doch lieber zu Linux. Die Erlösung wäre mMn. eine LinuxJail oder ein Linuxemulator oder etwas dergleichen, was nicht Ressourcenhungrig ist, lightweight und die Installation bzw. Start der Anwendungen keine Glückssache ist.
Skalierbarkeit ist auch ein seh wichtiges Thema, etwas wie Kubernetes oder Docker Swarm, nur halt mit Jails :D. Aber ich würde erst das Hauptproblem mit Linuxanwendungen lösen.

Natürlich wäre der leichteste und der schnellste Weg einfach zu Linux zu switchen und gut ist, aber so schnell will ich nicht aufgeben und mich von FreeBSD zu trennen. Bitte, teilt eure Erfahrungen hier. Das ist mMn. aktuell die einzige Lösung FreeBSD für breite Massen interessanter zu machen. Ich finde es sehr schade, dass FreeBSD immer öfter nur als eine OS für die Firewall angesehen wird, als ein kleines Zwischending und nicht mehr, was für ganz kleine und einfachste Aufgaben verwendet wird. Wobei FreeBSD ein riesiges Potenzial besitzt und jedes andere OS wegpusten könnte.
 
Die Erlösung wäre mMn. eine LinuxJail oder ein Linuxemulator oder etwas dergleichen, was nicht Ressourcenhungrig ist, lightweight
Hast Du doch. Über den Linuxulator.
Der ist auch "gut genug" für die allermeisten Linux-Anwendungen.
Ich glaube, die wirkliche Hürde ist nicht die fehlende grundlegende Technik, sondern eher das drum herum was darauf aufbaut. Man kann nicht einfach ein apt-get oder yum etc. machen, wie bei Linux-Distributionen üblich. Das macht es eher mühselig damit umzugehen.

Ein ähnliches Problem hast Du ja auch im Container-Bereich. Die grundsätzliche Technologie ist da (Jails). Es fehlt halt an Highlevel-Tools wie Docker und oben drauf von mir aus noch Kubernetes.
Als Ersatz für Docker gibt es BastilleBSD. Nützt Dir natürlich nur begrenzt etwas, wenn der Rest der Welt mit Docker hantiert. Aber um Deine eigene FreeBSD-Umgebung damit zu versorgen, dafür kannst Du es natürlich nehmen.

Natürlich wäre der leichteste und der schnellste Weg einfach zu Linux zu switchen und gut ist
Lustigerweise ists bei mir genau andersrum. Da sind die Rechner eher von Linux nach (Free)BSD gegangen als umgekehrt.

Wobei FreeBSD ein riesiges Potenzial besitzt und jedes andere OS wegpusten könnte.
Wegpusten weiß ich jetzt nicht. Aber man braucht sich hinter der Konkurrenz nicht unbedingt zu verstecken. Vor allem wenn man vergleicht, wieviel Manpower es im BSD-Bereich gibt im Gegensatz zu anderen Systemen.
 
Wozu brauch ich dann genau Container? Prozesse sind eh schon voneinander isoliert.

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?

Und durch Benutzer-Accounts hab ich auch ne Isolierung auf Dateisystemebene.

Naja:
Code:
[erni]$ touch /tmp/hello.txt
[bert]$ touch /tmp/hello.txt
touch: cannot touch '/tmp/hello.txt': Permission denied
Da geht noch was.

Das müssen diese tollen Microservices sein von denen Du redest. Aber auf gar kein Fall normale Programme die lediglich in Container verpackt sind. :-)

Das eine schließt das andere nicht aus. Alltägliches Beispiel aus meiner Praxis:

Ein Unternehmen betreibst seine Server seit Jahr und Tag mit Ubuntu. Die selbstentwickelte 08/15-Webanwendung läuft in einem Container mit Ubuntu 18.04 LTS als Unterbau, das selbstentwickelte Backend auf 16.04 LTS.

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.

Die benötigte Open-Source-Datenbank gibt es leider nicht in der von allen Teams benötigten Version im Paketmanagement von Ubuntu. Kein Problem, jedes Team kann selber das von Datenbank-Entwicklern komplett durchgetestete, offizielle Container-Image mit Alpine Linux (das 8 MB Platz braucht) als Unterbau nehmen.

Die 3 Container-Images (Frontend, Backend, Datenbank) können überall lokal in wenigen Sekunden hochfahren und sind trivial untereinander verbunden, ohne dass man irgendwie mit Netzwerkkonfiguration hantieren müsste. Der Overhead sind wenige Megabyte RAM.

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.

Lastabhängig werden automatisch zusätzliche Container-Instanzen gestartet und gestoppt.

Das Ganze kann man in eigenen Rechenzentren betreiben oder man sucht sich einen Anbieter raus (global oder ausschließlich in Deutschland), der die Container-Plattform betreibt. Man lädt dann nur noch die Container-Images hoch und steuert das Deployment via API - oder händisch, wer mag.

Lassen wir mal den Linux-spezifischen Kram wie 3rd-Party-Software weg: 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. 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. Ansonsten wird die Zahl der in Produktion Container nutzenden Entwickler wieder etwas größer.

Natürlich wäre der leichteste und der schnellste Weg einfach zu Linux zu switchen und gut ist, aber so schnell will ich nicht aufgeben und mich von FreeBSD zu trennen.

Als Softwareentwickler habe ich auch FreeBSD jahrelang als universelle Entwicklungsplattform genutzt, d.h. alle interessanten Neuerungen der Softwareentwicklung mit FreeBSD als Unterbau erforscht. Damals war Linux auch noch in seiner Sturm-und-Drang-Phase und so stabil wie ein 16-jähriger beim ersten ordentlichen Suff. ;)

Inzwischen sind viele Jahre ins Land gezogen. Für breit aufgestellte Softwareentwickler geht unter FreeBSD einfach dermaßen viel bescheiden bis überhaupt nicht, dass man sich irgendwann mal die Sinnfrage stellt. Jedesmal aufs Neue eine Linux-VM starten müssen oder bei anderen Themen in 9 von 10 Fällen in vermeidbare Probleme laufen - muss das sein?!

Zwischendurch ärgere ich mich auch hinreichend über Linux, bei pacman vs. yum vs. dnf vs. apt-get und dem halben Dutzend unterschiedlichen Netzwerk-Managern. Ich finde es angenehm, dass ich bei FreeBSD seit den 90ern wenig dazulernen musste - aber ich bin nicht Softwareentwickler geworden, weil ich nichts dazulernen will.

So, genug ausgeheult und gejammert, lassen wir Zahlen sprechen - die Ergebnis des StackOverflow Surveys in der Kategorie Professional Developers' Primary Operating Systems:
  • 46,3% Windows
  • 29,2% MacOS
  • 25,3% Linux
  • 0,1% BSD
Bei den Hobby-Entwicklern ist es ebenfalls 0,1% BSD.

Bitte, teilt eure Erfahrungen hier. Das ist mMn. aktuell die einzige Lösung FreeBSD für breite Massen interessanter zu machen.

Ich glaube, mit ein paar geteilten Erfahrungen ist es nicht getan. FreeBSD müsste an vielen Fronten nach- und vorlegen, um attraktiver zu werden, nicht nur für die breite Masse.

Ich finde es sehr schade, dass FreeBSD immer öfter nur als eine OS für die Firewall angesehen wird, als ein kleines Zwischending und nicht mehr, was für ganz kleine und einfachste Aufgaben verwendet wird.

Firewall? Das ist doch OpenBSD. :D

FreeBSD war jahrelang die Referenz für freie Server-Betriebssysteme, speziell mit ZFS im Unterbau. Nach einer gewissen Stagnationsphase muss es sich nun seine Lorbeeren wieder erkämpfen. Es wird in den kommenden Jahren viele Solaris- und AIX-Ablösungen geben, bei denen sich FreeBSD als Old-School-Unix profilieren könnte. Dafür müsste aber für mein Dafürhalten einiges geschehen.

Wobei FreeBSD ein riesiges Potenzial besitzt und jedes andere OS wegpusten könnte.

Aktuell läuft FreeBSD Gefahr, ein ewiges Talent zu werden.
 
Zurück
Oben