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

Ferne ein FreeBSD zu installieren, ihm die nötigen Moudule und Konfigs zu servieren und dann darauf das virtuelle System zu installieren und fortan zu betreiben.
Nee. Ich meinte jetzt schon lokal. Also FreeBSD als normales Host-System und dann Windows-10 als Gastsystem.

Sozusagen bhyve als Desktop-Virtualisierer.

Wenn ich das lese, was danach folgt, dann scheint es schon schwer zu sein
Fast alles daraus nach Handbuch.

Die einzige Schwierigkeit sind eigentlich die genaue Vorgehensweise für Windows 10.

Letztlich ist es auch nicht wirklich sooo viel anders als bei VirtualBox. Man muss aber sagen, VirtualBox macht es dem Nutzer schon einfacher. Du hast ne grafische Oberfläche, die Dir die Einstellungen erleichtert. Du hast zur Einrichtung ein Assistenten und Einstellungsvorlagen für verschiedene Betriebssysteme.
Aber ich glaube da sind irgendwie Projekte am laufen. Zum Beispiel via libvirt

Mit dem installierten VB kann ich das ganz normal als Programm aus meinem Desktop heraus starten.
Kannst Du mit bhyve auch.

Für mich sieht es nicht so aus, als wenn das ein bhyve-typisches Szenario ist.
Das kann ich nicht beantworten. Im Handbuch ist ja eher die Virtualisierung von FreeBSD selbst und Linux beschrieben. Aber gehen tut natürlich mehr. :-)

... beendet und wieder gestartet werden kann, ohne jemals den Desktop mit FreeBSD als Host zu verlassen oder eine Arbeit unterbrechen zu müssen?
Genau.

Wie schon mal gesagt, fehlt mir der Antrieb, mich näher damit zu befassen, weil es eine FreeBSD-only Lösung ist und ich auch andere Systeme nutzen möchte und da jeweils die gleiche Virtualisierung haben möchte.
Das ist auch durchaus legitim. Bei mir ists halt genau umgekehrt. Ich nutze meine VMs die ich unter FreeBSD nutze auch wirklich nur unter FreeBSD. Daher liegt es halt nahe dann auch den FreeBSD-Virtualisierer zu nutzen. :-)

Könnte ich ein GUI zu bhyve auf meinem Desktop starten und dann irgendein System in meiner laufenden Desktop-Sitzung benutzen, Daten austauschen und dann wieder beenden und mit meinem FreeBSD-Desktop weiter arbeiten, bis ich mal wieder was in einem virtuellen OS machen möchte?
Also sowas wie VM-Suspend/Resume ist in Arbeit:
https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migration-using-bhyve

Im Standard-FreeBSD gehts aber (noch) nicht.
 
Moin zusammen,

meines Erachtens ist die mangelnde Medienpräsenz eine der großen Schwächen von FreeBSD. Man liest fast nichts darüber, ob und wie FreeBSD im Enterprise-Bereich eingesetzt wird. Solche Berichte dürfen nicht in irgendwelchen Foren oder Firmen-eigenen Webpräsenzen versteckt werden, sondern müssen raus zu den Verlagshäusern.

Schönen Tag noch
 
... sondern müssen raus zu den Verlagshäusern

Für FreeBSD wäre m.E. ein gewisser "Nerd-Level" notwendig, aber welches der heute verfügbaren EDV Magazine schreibt heute noch auf so einem Level?

Die c't und iX haben da leider sehr abgebaut übers letzte Jahrzehnt, rückblickend hatten die früher tiefergehende Artikel, auch zu Grundlagen, als heutzutage - oder man denke nur an die legendäre mc oder die 68000er.

Speziell zu Unix und den BSDs - Mir fällt da spontan das Magazin "freeX" ein, aber das wurde vor Jahren eingestellt; kennt das noch jemand hier bzw hatte das regelmäßig gelesen oder gar abonniert?

btw und nahezu komplett OT: Wer kennt hier noch die ELO oder die Elrad?
 
mangelnde Medienpräsenz eine der großen Schwächen von FreeBSD

Sehe ich genau nicht so. Guck dir doch das Normie-Internet an, als es massenkompatibel wurde. Wieviel % halten Facebook für DAS Internet? Oder google? Also zwei Internets zusammengeschlossen?
Es hat Störenfriede und Dummheit angezogen, was letzten Endes alles kaputt macht. In der Politik sitzen Entscheider, die keine Ahnung haben.

FreeBSD in DE ab morgen verboten, weil ist kein Windows und bestimmt rechts einzuordnen.

Und dann? ;)
 
Für FreeBSD wäre m.E. ein gewisser "Nerd-Level" notwendig, aber welches der heute verfügbaren EDV Magazine schreibt heute noch auf so einem Level?
Es müsste auf dem gleichen Level präsentiert werden wie Linux: von Nerd bis Enterprise.

Die c't und iX haben da leider sehr abgebaut übers letzte Jahrzehnt, rückblickend hatten die früher tiefergehende Artikel, auch zu Grundlagen, als heutzutage - oder man denke nur an die legendäre mc oder die 68000er.
Speziell zu Unix und den BSDs - Mir fällt da spontan das Magazin "freeX" ein, aber das wurde vor Jahren eingestellt; kennt das noch jemand hier bzw hatte das regelmäßig gelesen oder gar abonniert?
Ich melde mich da mal, ich habe alle Hefte einschließlich "toolbox"
btw und nahezu komplett OT: Wer kennt hier noch die ELO oder die Elrad?
Ich melde mich da auch mal und werfe noch die Elektor in den Ring.
 
Sehe ich genau nicht so. Guck dir doch das Normie-Internet an, als es massenkompatibel wurde. Wieviel % halten Facebook für DAS Internet? Oder google? Also zwei Internets zusammengeschlossen?
Es hat Störenfriede und Dummheit angezogen, was letzten Endes alles kaputt macht. In der Politik sitzen Entscheider, die keine Ahnung haben.
Neben Internet gibt es NOCH anderen Medien...
 
Ich stelle jetzt mal eine These auf, die auch nicht als Wertung zu verstehen ist, sondern eher als Gedankenanstoß.

FreeBSD ist als System so gut, weil es unter dem Radar segelt. Unter Linux hat man ja gerne mal diesen "Viele Köche verderben den Brei" Effekt. Jeder kennt es. Jeder benutzt es. Jeder versucht Einfluss auf die Entwicklung zu nehmen und auch irgendwie sein Zeug (und dann auch so schnell wie möglich; u.U. also auch, wenns noch nicht ausgereift ist) ins offizielle System zu kriegen.
Bei FreeBSD sind die Lösungen tendenziell überlegter. Was passt gut ins System. Was nützt möglichst Vielen. Man versucht möglichst nicht mehrere konkurrierende Lösungen die sich überschneiden zu bauen, sondern Eine die möglichst alle Bedürfnisse befriedigt.
Das die FreeBSD-Entwickler in Ruhe werkeln können ohne ständigen Druck von außen (den man automatisch hat, wenn ein System bekannt und viel benutzt ist), kann ja durchaus dem System zuträglich sein.
 
Das die FreeBSD-Entwickler in Ruhe werkeln können ohne ständigen Druck von außen (den man automatisch hat, wenn ein System bekannt und viel benutzt ist), kann ja durchaus dem System zuträglich sein.
Das ist ein zweischneidiges Schwert. Es muss genügend Interesse und genügend Entwickler geben die daran werkeln. Interesse am OS zieht ja auch Entwickler an. Zu kleine Niesche halte nicht für gut, es sei denn ich will keinen FreeBSD Desktop usw. sondern will es halt speziell für diese Aufgabe wofür es halt Sinn macht.
Aber wir haben doch Freude am Desktop und je mehr daran und damit arbeiten umso besser läuft es, umso mehr sind Dinge erprobt, getestet, umso eher Bugs und Lücken gefunden und behoben usw.
 
Zur "Toolbox", die startete mit dem Titel "Pascal". Ein prima Name, aber die Verantwortlichen meinten dann, zu viele Leser würden das mit der Programmiersprache Pascal verwechseln . . . :rolleyes: Diese Zeitschrift war wirklich gut, aber mit der Umbenennung schien auch die inhaltliche Qualität der Umbenennung in einen nichtssagenden Namen zu folgen.

Hier die erste und die letzte Ausgabe von Pascal:
Pascal-Erste+LetzteAusgabe.jpg
 
Das sieht doch schon Docker ziemlich ähnlich, oder?

Es geht schon mal in die richtige Richtung, es fehlt aber noch sehr viel: Why bother with Docker (on FreeBSD)?

Gerade hier würde ich mir eine schön integrierte Lösung von FreeBSD wünschen, wenn man schon Kernel und Userland in einer Hand hat.

Speziell zu Unix und den BSDs - Mir fällt da spontan das Magazin "freeX" ein, aber das wurde vor Jahren eingestellt; kennt das noch jemand hier bzw hatte das regelmäßig gelesen oder gar abonniert?

Ich hatte freeX im Abo. Inzwischen ist freeX im thematisch breiteren IT-Administrator aufgegangen. Dort findet man gelegentlich einen BSD-Artikel vor, sie sind aber selten geworden.

Es müsste auf dem gleichen Level präsentiert werden wie Linux: von Nerd bis Enterprise.

Netflix (der wohl bekannteste große FreeBSD-Nutzer mit ~6700 Mitarbeitern und ~20 Milliarden Euro Umsatz) hat erfreulicherweise ein prominentes Tech-Blog. Darauf findet man nur 2 Artikel zu FreeBSD und gleichzeitig 9 zu Linux und Containern.

Wie der geneigte Leser erfährt, setzt Netflix FreeBSD ausschließlich für die bei den ISPs stehenden CDN-Appliances ein. Abgesehen von den Appliances läuft alles unter Linux(-Containern). :eek:

Bei FreeBSD sind die Lösungen tendenziell überlegter. Was passt gut ins System. Was nützt möglichst Vielen. Man versucht möglichst nicht mehrere konkurrierende Lösungen die sich überschneiden zu bauen, sondern Eine die möglichst alle Bedürfnisse befriedigt.

Deswegen hat Linux mehrere Container-Implementierungen und FreeBSD gar keine. :ugly:

Das die FreeBSD-Entwickler in Ruhe werkeln können ohne ständigen Druck von außen (den man automatisch hat, wenn ein System bekannt und viel benutzt ist), kann ja durchaus dem System zuträglich sein.

Vielleicht geht es nur mir so: gefühlt war 2008/2009 mit der Einführung von ZFS der Zeitpunkt, als FreeBSD die Referenz der freien Unix-Systeme und Linux am Hinterherhecheln war. In Sachen Funktionalität, Stabilität und Konsistenz war FreeBSD unerreicht. :)

Inzwischen muss ich feststellen: so sehr ich die Konsistenz von FreeBSD nach wie vor schätze, in Sachen Stabilität hat Linux gleichgezogen und funktional ist es gehörig voraus - sowohl im Desktop- als auch im Server-Bereich.

Was mir Sorge macht ist der Umstand, dass ich bei einer zunehmenden Anzahl 08/15-Anwendungsfälle (die sich im Laufe der Zeit natürlich auch weiterentwickelt haben) feststellen muss: die lassen sich mit FreeBSD überhaupt nicht realisieren. :(

Aktuell vermisse ich bei aller Liebe zur ruhigen Entwicklung das Killerfeature, bei dem ich sagen würde: ja, das ist Linux weit voraus und setzt einen neuen Meilenstein in der Welt der freien Unixe. Die nahtlose Integration von Kernel und Userland aus einer Hand hat etwas hervorgebracht, was alles unter Linux existierende in den Schatten stellt.

Das möchte ich mal wieder erleben. Die Kritik an Lösungen unter Linux für viele zeitgenössische Anforderungen (egal ob es jetzt Wayland, Container, systemd oder was auch immer betrifft) mag oftmals berechtigt sein. Die Antwort darauf muss aber sein, eine bessere Lösung auf die Beine zu stellen - immerhin hatte man ~10 Jahre Zeit. Die Antwort sollte für meinen Geschmack nicht sein, sich in Unix-Nostalgie zu verlieren, die existierenden Anforderungen kleinzureden und ansonsten mit leeren Händen dazustehen. :grumble:

Es muss genügend Interesse und genügend Entwickler geben die daran werkeln. Interesse am OS zieht ja auch Entwickler an.

Aktuell würden FreeBSD gefühlt mehr Entwickler und mehr Innovation sehr gut tun. Die Zukunft wird nicht in Subversion committet. ;)

Zu kleine Niesche halte nicht für gut, es sei denn ich will keinen FreeBSD Desktop usw. sondern will es halt speziell für diese Aufgabe wofür es halt Sinn macht.

Korrekt. Das ist die entscheidende Frage: wo soll die Reise hingehen?

Will man ein General-Purpose-OS bleiben, muss sich einiges tun. Die Zeit ist nicht stehen geblieben, die Anforderungen haben sich weiterentwickelt und gefühlt überlässt man gerade eben Linux ziemlich kampflos das Feld.

Gibt man diesen Anspruch auf, dann kann FreeBSD mit Sicherheit bestens in seiner Nische noch viele viele Jahre bestehen, bevor es nach einer langen Phase der Stagnation IRIX und HP-UX Gesellschaft leistet. Falls FreeBSD sich von der Zukunft verabschiedet, würde ich mir aber vorher einen neuen Hafen suchen und schweren Herzens nach einem Vierteljahrhundert Abschied nehmen.
 
Die Antwort darauf muss aber sein, eine bessere Lösung auf die Beine zu stellen - immerhin hatte man ~10 Jahre Zeit.
Man muss aber dazu auch sagen, das in Linux massiv Ressourcen geflossen sind. Bei dem Geld was da so rein geht wäre es ja auch ein Wunder, wenn Linux nicht aufgeholt und von mir aus auch überholt hat.
Das soll jetzt auch keine Entschuldigung sein, sondern nur eine Feststellung.
Vielleicht ist ja der Linux-Ansatz der bessere. Dadurch das es in dem Ökosystem halt Konkurrenz gibt, treiben sich parallel aufgebaute Projekte auch auch gegenseitig voran.

Intuitiv würde man ja auch vermuten, das (Free)BSD eigentlich im kommerziellen Umfeld schon deshalb beliebter sein müsste, weil die Lizenz liberaler ist. Aber vielleicht ist auch das falsch gedacht, denn bei einer liberalen Lizenz tendieren Firmen evt. eher dazu Entwicklungen für sich zu behalten. Wer im Linux und GPL Umfeld mitspielen will, muss halt sein Kram doch irgendwie offen legen.

Möglicherweise wird es letztlich aber gar nicht durch die Innovationsgeschwindigkeit entschieden, sondern durch die Beherrschbarkeit des Systems. Je komplexer eine Software ist, desto schwieriger ist sie halt fehlerfrei zu halten. Und irgendwann kann es dann eben möglicherweise kippen.
Andererseits ist Linux auch to big to fail. Viele sind darauf angewiesen. Dementsprechend wird auch genug Geld da sein, mit dem man auf dieses Problem werfen kann.
Also kann man darauf nicht unbedingt "hoffen". :-)

Vielleicht sollte man die Sache auch anders betrachten und gar nicht erst versuchen mit Linux zu konkurrieren. In seinem Bereich ist Linux sehr erfolgreich und Linux hat auch ne Menge Manpower. Das sind denkbar schlechte Voraussetzungen um dann als echter Konkurrent zu bestehen.
Realistischerweise hat man da tatsächlich nur Chance in einer Nische, in der Linux vielleicht nicht so gut funktioniert.
 
hi

ich kenne auch noch elektor ,elo, freeX hatte ich im abo ebenso das foo magazin.
ich kennen auch noch die zeiten ,wo die CT schon alleine die dicke des heftes einen
mehr wert darstellte , da man nach gewicht bezahlt hat ;)

wieso hat FreeBSD keine Container lösung ?
jails sind ,technisch betrachtet , sogar besser als die üsprüngliche docker loesung
die ,aus der historie heraus, dem lxc bzw vserver thema entstanden ist.

holger
 
Ich würde sagen kein Betriebssystem hat auf Dauer eine Chance gegen Linux. Auch Microsoft hat das erkannt...
An Linux und -umgebung werkeln weltweit einfach zu viele.

Aber nochmal... Hut ab! Verglichen mit der vglb. kleinen Manpower laufen Free- und GhostBSD doch super!

Und wenn zB ZFS aufgrund lizenztechnischer Hinsicht besser in FreeBSD integriert ist und dort zuverlässiger läuft, ist das doch schon wieder ein Grund mehr es zu bevorzugen, wo das eben eine Rolle spielt.
Und noch was..: was hätten Apple, Sony & Co ohne FreeBSD genommen? Linux?
Gerade Apple und auch Sony könnten mal etwas Dankbarkeit zeigen und v.a. ersterer n hübsches Sümmchen springen lassen. Kam da je was seitens Apple?
Die sollten sich bewusst sein, ohne *BSD können sie sich ne neue Basis für ihre proprietären OSe suchen (oder dürfen selber an der alten rumwerkeln). Da sollte echt mal Wertschätzung a la WhatsApp Gründer kommen. Gerade Apple strotzt vor Geld, da tut ne Million nicht weh und öffnet Raum für neue Möglichkeiten die wiederum Apple zugute kommen (können).
 
Es geht schon mal in die richtige Richtung, es fehlt aber noch sehr viel: Why bother with Docker (on FreeBSD)?
Das überzeugt mich persönlich kein bisschen. Wenn man mal den Aspekt weglässt, einen fertigen "Linux Container" direkt auf FreeBSD laufen lassen zu können, dann ist da nichts mehr dabei, was ein aktuelles FreeBSD nicht auch ohne Docker kann. Ja, es ist nicht automatisiert. Man könnte hingehen und sich vieles selbst scripten, was gar nicht so aufwändig sein dürfte. Poudriere hat hier für den Anwendungsfall "ports bauen" (der sich natürlich z.B. nicht für virtuelles Netzwerk interessiert) schon eine nahezu perfekte Umsetzung. Bastille habe ich mir nicht angesehen, vielleicht bietet das schon sehr viel in genau dieser Hinsicht.

Was letztendlich gegenüber Docker "fehlt" ist, dass es eben "Docker ist" -- also ein Kompatibilitätsthema. Es fehlen keine "technischen Features", wohl aber komfortable Automatisierungen. Bei Docker liest man, dass man der Isolation nicht vertrauen sollte. Vielleicht wäre das bei einem "Docker für FreeBSD", das unter der Haube jails nutzt, besser.

Das soll nicht heißen, dass "Docker für FreeBSD" nicht nützlich sein könnte. Wenn es auf den nativen FreeBSD tools (ZFS, jails (+VIMAGE), pf) implementiert wird, ist es sicher eine nützliche Sache und hilft vor allem denjenigen, die auf anderen Plattformen sowieso schon mit Docker arbeiten. Ich widerspreche aber der Behauptung, dass "viel fehlt". Die technischen Features sind alle da (und das zum Teil schon sehr viel länger als auf anderen Plattformen) -- es ist nur nicht nutzbar "wie Docker".
 
Damit gewinnt man jedes Bullshitbingo!
Es fehlen die Begriffe Microservices, Blockchain, Machine-learning. So wie es jetzt ist, sieht es noch viel zu seriös aus. :-)

Hut ab! Verglichen mit der vglb. kleinen Manpower laufen Free- und GhostBSD doch super!
Das ist wohl richtig. Wenn das Geld bei Linux nur halb so effizient genutzt werden würde wie bei FreeBSD, müssten die eigentlich schon 50 Jahre weiter sein. :-)

. Ich widerspreche aber der Behauptung, dass "viel fehlt". Die technischen Features sind alle da (und das zum Teil schon sehr viel länger als auf anderen Plattformen) -- es ist nur nicht nutzbar "wie Docker".
Genau das ist aber das Problem.
Heute will keiner mehr groß was umsetzen müssen. Es muss alles Out-Of-Box funktionieren. Mit Batteries-included.
Die Kehrseite ist freilich, dass wenn die Einstiegshürden gering sind dann auch schnell Leute das Zeug benutzen, die eigentlich nicht wissen was "drunter" passiert. Das führt dann schnell zu lustigen Sicherheitspannen und Ähnlichem. :-)
 
Intuitiv würde man ja auch vermuten, das (Free)BSD eigentlich im kommerziellen Umfeld schon deshalb beliebter sein müsste, weil die Lizenz liberaler ist. Aber vielleicht ist auch das falsch gedacht, denn bei einer liberalen Lizenz tendieren Firmen evt. eher dazu Entwicklungen für sich zu behalten. Wer im Linux und GPL Umfeld mitspielen will, muss halt sein Kram doch irgendwie offen legen.

Wie fast alles hat auch "gratis vs. libre" seine Vor- und Nachteile.

Möglicherweise wird es letztlich aber gar nicht durch die Innovationsgeschwindigkeit entschieden, sondern durch die Beherrschbarkeit des Systems. Je komplexer eine Software ist, desto schwieriger ist sie halt fehlerfrei zu halten. Und irgendwann kann es dann eben möglicherweise kippen.

Zu Innovation gehört aber auch, aus den Erkenntnissen der Vergangenheit zu lernen, alte Zöpfe abzuschneiden und Neues einzuführen - auch um die Gesamtkomplexität des Systems zu reduzieren.

Andererseits ist Linux auch to big to fail. Viele sind darauf angewiesen. Dementsprechend wird auch genug Geld da sein, mit dem man auf dieses Problem werfen kann. Also kann man darauf nicht unbedingt "hoffen". :-)

In Linux fließen aber natürlich auch mehr Ressourcen, um die Qualität hochzuhalten; "software decay" ist dort natürlich ein deutlich geringeres Thema.

Linux hat auch schon früh zum Nachteil proprietärer Treiber und zu Gunsten von Refactoring - und damit der Qualität - die Kernel-ABI und In-Kernel-APIs als bewegliches Ziel deklariert.

Das überzeugt mich persönlich kein bisschen. Wenn man mal den Aspekt weglässt, einen fertigen "Linux Container" direkt auf FreeBSD laufen lassen zu können, dann ist da nichts mehr dabei, was ein aktuelles FreeBSD nicht auch ohne Docker kann.

Cool, das wusste ich noch gar nicht! Lassen wir mal die Linux-Kompatibilität weg und betrachten die FreeBSD-native Lösung folgenden 08/15-Anwendungsfalls. Zum Vergleich habe ich immer das Docker-Befehl angegeben (wer mag kann natürlich auch podman o.ä. nehmen), bei dem mir in vielen Fällen die Kenntnis des FreeBSD-Äquivalents fehlt.

Wie kann in denn ein gebautes Jail auf einem FreeBSD-12-Quellrechner in ein Image packen (docker save), in ein zentrales Repository schieben (docker push), auf einem FreeBSD-11-Zielrechner holen (docker pull) und dort ausführen (docker run)? Natürlich ohne auf dem Zielrechner etwas zu kompilieren oder aufwendig konfigurieren zu müssen, weil spätestens bei den Compile-Zeiten eines modernen Browsers möchte man nicht jedes Mal warten - das muss in Sekunden gehen.

Ach ja, ich würde auch noch gerne zwei Jails via Netzwerk verbinden (docker-compose), ohne mich zum Erstellungszeitpunkt der einzelnen Jails schon diesbezüglich festzulegen.

Praktisch sind auch mehrere Instanzen parallel auf unterschiedlichen Ports (docker run -p) ohne zusätzliche Konfiguration oder gar Anpassung der Software.

Das ganze sollte natürlich auch - Stand der Technik - per API remote gehen. Gerne via RESTful API, aber ich nehme alles, was keinen lokalen Login auf dem Zielrechner erfordert.

Ja, es ist nicht automatisiert.

Damit ist es zeitaufwändig, fehleranfällig, nicht reproduzierbar und lässt sich nicht in Continuous Integration einbinden, d.h. ein vernünftiger Produktionsbetrieb ist auch ausgeschlossen.

Es gibt ja für FreeBSD gute Ansätze wie pot, die zeigen, wohin die Reise gehen kann. Von der Einsatzreife, geschweige denn notwendigen Flexibilität, ist man auch damit aber (noch) weit entfernt, wenn man sie denn mit den vorhandenen Mitteln jemals erreicht.

Man könnte hingehen und sich vieles selbst scripten, was gar nicht so aufwändig sein dürfte.

Dann bin ich auf die Lösung gespannt. Die momentan vielleicht am weitesten fortgeschrittene FreeBSD-Lösung braucht aktuell 45 Shell-Scripts und hat noch einen weiten Weg vor sich. Die Remote-API fehlt uns aber immer noch.

Es fehlen keine "technischen Features", wohl aber komfortable Automatisierungen.

Vielleicht fehlen keine technischen Features - Docker läuft schließlich auch auf einem Linux-Kernel aus dem Jahre 2013. Wobei noch offen ist, inwieweit Jails alle anfallenden Anforderungen erfüllen können.

Solange kein passendes Tooling vorhanden ist, ist es aber nutzlos.

Bei Docker liest man, dass man der Isolation nicht vertrauen sollte. Vielleicht wäre das bei einem "Docker für FreeBSD", das unter der Haube jails nutzt, besser.

Die Zeiten, in der Linux-Container root-Rechte benötigt haben, sind schon lange vorbei. Das bereits im Produtionseinsatz befindliche podman (ein nahtloser Ersatz für Docker) läuft als einfacher User-Prozess.

Die technischen Features sind alle da (und das zum Teil schon sehr viel länger als auf anderen Plattformen) -- es ist nur nicht nutzbar "wie Docker".

In der Tat, Software sollte tatsächlich nutzbar sein. :)

Ich stosse immer mal auf Seiten wie diese:

https://www.bccourier.com/container...xie-docker-hub-rkt-oracle-solaris-lxd-coreos/

und immer wieder ist da von Solaris und auch FreeBSD die Rede...in Zusammenhang mit Wachstum.

Der Bericht ist leider nicht frei verfügbar - spätestens bei Solaris Zones würde ich von starkem Negativwachstum ausgehen... :ugly:

Heute will keiner mehr groß was umsetzen müssen. Es muss alles Out-Of-Box funktionieren. Mit Batteries-included.

Das ist auch gut so - wer will schon gelöste Probleme lösen müssen. Wir nutzen ja heutzutage auch E-Mail-Clients und verbinden uns nicht mehr mit Telnet zu E-Mail-Servern. Wir setzen unsere Texte nicht mehr von Hand. Wir automatisieren unsere IT-Infrastruktur anstatt alles von Hand zu pflegen.

Mit den freigewordenen Kapazitäten widmen wir uns dafür Aufgabenstellungen, die früher Science-Fiction waren.
 
Cool, das wusste ich noch gar nicht! Lassen wir mal die Linux-Kompatibilität weg und betrachten die FreeBSD-native Lösung folgenden 08/15-Anwendungsfalls. Zum Vergleich habe ich immer das Docker-Befehl angegeben (wer mag kann natürlich auch podman o.ä. nehmen), bei dem mir in vielen Fällen die Kenntnis des FreeBSD-Äquivalents fehlt.

Und spätestens jetzt solltest Du Dir Bastille ansehen. Ich habe mir das jetzt auf meine ToDo Liste gesetzt. Wenn die Linux-Kompatibilität wegfallen kann, ist das eventuell ein Ersatz,
 
Das provokative Gelaber ist mir zu blöd. Nur für den Fall, dass noch jemand eine Antwort erwartet haben sollte.
 
In Linux fließen aber natürlich auch mehr Ressourcen, um die Qualität hochzuhalten
Das ist zwar korrekt, hilft aber nicht zwangsläufig. Um eine Verdopplung von Komplexität zu beherrschen, musst Du halt das vierfache an Ressourcen aufwenden. Eine weitere Verdoppelung benötigt dann aber schon achtfache Ressourcen. Du kommst dann halt irgendwann in den Bereich, wo selbst große Ressourcenaufwendungen nur noch minimale Effekte erzielen.

Zu Innovation gehört aber auch, aus den Erkenntnissen der Vergangenheit zu lernen, alte Zöpfe abzuschneiden und Neues einzuführen - auch um die Gesamtkomplexität des Systems zu reduzieren.
Davon sehe ich aber nichts. Klar werden alte Zöpfe abgeschnitten. Du hast dafür aber größere neuere Zöpfe.

Das ist auch gut so - wer will schon gelöste Probleme lösen müssen.
Das ist korrekt. Nur ist die Frage, wie gut die Lösungen tatsächlich sind. Die Komplexität steigt mit den Anforderungen. Du kannst also das vergrößern von Komplexität sinnvollerweise nicht verhindern.
Worauf Du aber auchten kannst, ist die Komplexitätszuwach-Nutzenzuwachs-Quote. Und die ist heutzutage tendenziell eher schlecht.

Und das Ergebnis kannst Du ja jetzt schon überall bewundern anhand von Sicherheitslücken, auftretende Fehler und teilsweitreichenden Folgen. Eine massive Anfälligkeit gegenüber äußeren Einfüssen. Noch nie war unsere Zivilisation so verletzlich wie heute. Und künftig wird es eher schlechter als besser, weil noch mehr technisiert und computerisiert wird.

Richtig befeuert wird das noch mal durch (wieder) aktuelle Trends wie Machine-Learning. Da hast Du nicht mal mehr ein Programm, was Du irgendwie debuggen kannst. Du hast ein System, welches Du anlernst, von dem Du auch nicht mehr wirklich nachvollziehen kannst, wie und warum es funktioniert. Und ob es wirklich das gelernt hat, von dem Du wolltest das es das lernt.

Das ist nur noch ne Frage der Zeit, bis das uns alles richtig um die Ohren fliegt.
Ist ein bisschen so wie mit dem Klimawandel. Alle wissen, das es in die falsche Richtung läuft, aber keiner will wirklich was ändern und alle machen weiter wie bisher.
 
So provokativ finde ich das gar nicht. :-)
Man könnte sagen, das das ein oder andere vielleicht etwas überspitzt formuliert ist. Was man aber nicht sagen kann ist, das das "Gelaber" völlig substanzlos ist.
Ich habe wenig Toleranz gegenüber provokativer Stichelei. Ehrlich wäre, statt des Sarkasmus einfach zu schreiben "ja aber ich kann *das und das* nicht". Und dann wäre auch offensichtlich, dass das genau in die Kategorie fällt, dass es eben "nicht Docker ist", und keineswegs der Behauptung widerspricht, dass rein funktional alles da ist, auch wenn man so manche Automatisierung anders bauen müsste.
 
Zurück
Oben