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...
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.