Docker auf FreeBSD portiert

Ich hasse das. Wozu immer Linux unter FreeBSD nachbauen? Das ist doch sinnlos wie ein Kropf. Entweder ich will Linux, dann nehm ich Linux, oder ich will kein Linux, dann will ich das nicht "hintenrum" wieder untergejubelt bekommen. FreeBSD sollte ein eigenständiges System bleiben/werden. Mit Lumina gibt es ja schon ein vielversprechendes Projekt für einen Desktop. Das muss weiter ausgebaut werden, statt immer mehr "Linux-Kompatibilitäts-Scheiss" einzubauen. Die Resourcen sind verschwendet und sollten lieber auf ein eigenständiges System verwendet werden.
 
Man muss da unterscheiden. FreeBSD hat mit Jails einen sehr mächtigen Containermechanismus im Kernel und ins Basissystem integriert. Docker ist nun im Kern ein System, was einmal einen Containermechanismus für Linux implementiert. Früher kam dafür LXC zum Einsatz, inzwischen nutzen sie wohl eine eigene Implementierung. Beide basieren im Kern auf cgroups. cgroups sind ein mächtiges Werkzeug, aber nur so lala für Container geeignet. Daher bietet Docker, genauso wie andere Containermechnismen für Linux, beispielsweise keine wirkliche Prozessisolation, von Dingen wie Ressourcenmanagement und weiteren Dingen ganz zu schweigen. Aber Docker ist noch mehr. Denn Docker bietet ein komplexes Managementsystem, was FreeBSD so nicht hat. Die "Images" können weitgehend automatisiert erstellt, über zentrale Repositories verteilt werden und so weiter. Das ist schon sehr nett. Die Dockerportierung auf FreeBSD stellt diese Dinge auch FreeBSD zur Verfügung.

ABER: Ich denke, es kommt zu spät. Denn einmal flaut der Containerhype unter Linux schon wieder ganz stark ab. Man spricht nur noch wenig darüber, die Nachteile der Implementierungen sind in den Fokus gerückt, etc. Es gab da vor einiger Zeit von der C't diese Umfrage, wonach nur ca. 2% der Linux nutzenden Firmen auch Container nutzen und der Rest weitgehend kein Interesse daran hat. Man bleibt lieber bei klassischen Hypervisoren, die inzwischen auch nicht mehr so viel Overhead haben. Anwendungen zu paketieren ist gut und schön, aber auch eine Wartungshölle. Außerdem haben Paketmanager (wenn korrekt genutzt) das Problem schon vor 20 Jahren gelöst. Das soll aber nicht heißen, dass Container im Linux-Sinne verschwinden werden. Sie haben ihre Berechtigung und werden daher auch ihre Nische finden. Aber das große nächste Dinge werden sie eher nicht. Zumindest nicht, solange Linux nicht ähnlich wie FreeBSD oder Solaris eine bessere Integration in Kernel und System bietet.
Dazu kommt, dass Docker die erste Implementierung war. Inzwischen gibt es weitere, die Dinge wie Sicherheit einfach bedeutend besser machen und daher Docker in den letzten Monaten an den Rand gedrängt haben. Besonders ist da die Application Container Specification zu nennen, was wie der Name schon sagt nur eine Spezifikation ist. Die kann dann jeder implementieren und hat dabei sogar recht große Freiheiten. CoreOS basiert beispielsweise darauf, Red Hat rührt auch dran rum und mit Jetpack gibt es schon lange eine gute FreeBSD-Implementierung.
 
Ich sehe trotzdem keinen Sinn darin, finde es verschwendete Entwickler-Resourcen. Ich würde liebend gerne FreeBSD auf meinem Laptop einsetzen, kann es aber nicht, weil es zuviele Probleme damit gibt (z.B. Suspend/Resume funktioniert mit FreeBSD 11 immer noch nicht zuverlässig). Es ärgert mich kollossal wenn ich sehe wieviel Energie in solch sinnloses Zeug gesteckt wird, und die Basics nichtmal brauchbar funktionieren :-(
 
Nun, es ist ein Freiwilligenprojekt und stark unterschiedliche Bereiche. Wer Docker auf FreeBSD portiert, hat wahrscheinlich wenig Interesse oder nicht einmal die Fähigkeiten für Low-Level-Krams wie Suspend.
 
Eine Alternative zu solchen Dingen ist auch Vagrant, welches auf VirtualBox basiert und unter FreeBSD schon länger funktioniert. Das ist ganz nett, wenn man identische Systeme haben will und nachdem es komplett virtualisiert ist ist es relativ systemunabhängig, was ganz nett sein kann, wenn zum Beispiel ein paar Leute an einem System bauen, das man dann einfach deployen kann. Ist auch ganz nett, wenn man sich mit Dingen, wie Konfigurationsmanagement befassen will.

Ich glaube Docker kann schon sinnvoll sein, aber wie alles wo es viel Hype gibt wird es leider zum Großteil für Sachen verwendet wo es wenig bis gar keinen Sinn macht. Ein anderes Problem ist, dass da große Deployments von Nicht-Sysadmins gemacht werden, die dann komplett unsicher sind, Ressourcen verschwenden, etc. Das hat irgendwie was von Wordpress installieren und dann eine Spam-Schleuder zu haben. Ich glaube da wird es auch mal ein paar Docker-Botnets geben.

Was FreeBSD und verschwendete Ressourcen angeht: Ich glaube nicht, dass sie verschwendet sind. Zum einen ist das einfach von Leuten, die Lust hatten das zu machen und nicht etwas anderes, zum Anderen sollte man die Seiteneffekte bei solchen Projekten nicht unterschätzen. Kann mir gut vorstellen, dass da auch einige Dinge abfallen, die sich generell positiv auf Jails, etc. auswirken. Vielleicht stoßen sie auch auf Bugs von Go auf FreeBSD und solche Dinge.
 
Man darf halt Docker und Co. nicht mit VMs verwechseln. Docker wird häufig auch falsch verwendet. Typischerweise enthält ein Docker-Container nur das was die darin zu laufende Anwendung benötigt. Also kein komplettes Betriebssystem wie es gerne immer wieder angelegt wird (aka einfach Ubuntu Standard komplett reinpacken).

Ich finde an Docker und Co. gut, dass man mit dem Einrichten dieser automatisch eine zwangsweise funktionierende Dokumentation des ganzen hat (außer man benutzt Docker eben falsch). Dort steht halt drin, was installiert wird, wie es konfiguriert wird, eben was zum "Standard" angepasst wurde.

Bei einer VM.... joahr, fröhliches Suchen was über die Jahre so geändert wurde und was nicht. Klar kann man eine VM ebenso automatisch einrichten, aber bei Docker ist es eben gar nicht anders vorgesehen.

Implementierungsschwächen und Co mal dahingestellt. Das Konzept an sich finde ich recht gut.
 
JochenF schrieb:
Ich hasse das. Wozu immer Linux unter FreeBSD nachbauen? Das ist doch sinnlos wie ein Kropf. Entweder ich will Linux, dann nehm ich Linux, oder ich will kein Linux, dann will ich das nicht "hintenrum" wieder untergejubelt bekommen. FreeBSD sollte ein eigenständiges System bleiben/werden. Mit Lumina gibt es ja schon ein vielversprechendes Projekt für einen Desktop. Das muss weiter ausgebaut werden, statt immer mehr "Linux-Kompatibilitäts-Scheiss" einzubauen. Die Resourcen sind verschwendet und sollten lieber auf ein eigenständiges System verwendet werden.
Zum Vergrößern anklicken....

Sehe ich aehnlich... dieses "Linux-geschiss" (verzeihung, wenn zu ordinaer)
betrachte ich ebenfalls als Verschwendung kostbarerer Ressourcen. :-(.

Ich denke, mittelfristig bis langfristig, bedarf es in der Industrie eines
stabilen unixoiden Workstationproduktes (analog vergangener Zeiten
wie bei SunOS). Lumina hat in Wechselwirkung mit devd(8) echtes
Potential sowas zu erreichen.

Da ich denke, dass mit einem GNU/Linux basierten Desktop, die
nach feindlicher Uebernahme von SUN Microsystems durch Oracle
entstandene Versorgungsluecke bzgl. Integration von unixoiden
Workstations (welche bspw. mit Anwendungen von SCADA Systemen
ueber Mediation Devices disseminierte Informationen verarbeiten)
in Industrieanlagen, Kraftwerken, etc... nicht kompensiert werden
kann bzw. (langfristig) wird.

Desktop Systeme werden nicht nur zur BueKo verwendet, sondern
stellen oftmals eine Projektionsflaeche fuer In-House Applikationen
seitens Betreiber von Industrieanlagen dar. *klugscheiss*.

*rofl* ... man stelle sich mal vor S*stemD crasht Workstation
zum Ansteuern von SPS fuer Sequencing Batch Reactor in
Klaerwerk.

O. k. das war jetzt etwas boese... Spass beiseite (obwohl nicht witzig)... :-).

Frage an die erfahrenen Entwickler hier:

In welchen Code-Sektionen oder Softwarekomponenten bzgl.
"Low-Level-Krams wie Suspend" oder aehnlicher "Fruechte"
kann ich mich "einlesen"???

Da ich momentan sehr viel Zeit (und Nerven) besitze, um mich
bzgl. dieser problematik einarbeiten zu koennen bzw. erklaere
ich mich bereit einen bescheidenen und konstruktiven Beitrag zu
leisten (denn mir geht dieses Suspend-Resume-digsbums sowie
diese sich entwickelnde GNU/Linux-Monokultur auf den Sack).
 
Die Rede von den vermeintlich "verschwendeten Resourcen" ist angesiedelt in Vorstellungen die aus dem technisch-ökonomischen Denken stammen in dem Menschen eben "Resourcen" sind die im Sinne einer vorab definierten Zielsetzung optimal eingesetzt und abgeschöpft werden sollen. So funktioniert nun einemal die Open-Source Welt nicht, - glücklicherweise möchte ich sagen! Da machen die Leute einfach das was sie interessiert und was sie können, so sinnvoll oder auch nicht das anderen erscheinen mag. Und es ist durchaus nicht gesagt dass das technisch-ökonomisch Denk- und Handlungsmodell dem überlegen ist. Die biologische Evolution funktioniert z.B. ganz anders: Da gibt es eine enorme Verschwendung von Resourcen in dem alle nur möglichen Varianten auspropbiert werden und eben die am besten angepaßten überleben (nicht die "fittesten" übrigens wie die vermeintlichen "Mehrleister" dieser Welt das gerne verstehen).

Das Anti-Linux-Gerede erinnert mich ebenfalls an ein biologisches Phänomen, nämlich dem der vermeintlichen Überlegenheit der Rassereinheit. Den Ideologen der Rassereinheit ist es inzwischen gelungen eine Vielzahl von domestizierten Tierarten (Hunde, Katzen Schweine, Kühe etc) derart auf dem Hund zu bringen dass sie nur noch mit massiver ärztliche Hilfe und dem Einsatz beträchtlicher Resourcen weiter bestehn können. Gesunde Populationen zeichnen siche dagegen durch eine hohe genetische Varianz aus die sie weitmöglichst resistent macht gegen die Unbilden dieser Welt. Und auch manche seltsame Tiere und Pflanzen werden in den ökologischen Nischen überleben.

Mit all dem ist natürlich nicht gesagt dass es nicht Sinnvoll ist das Suspend/Resume Problem von FreeBSD zu lösen oder auch einen eigenständigen BSD-Desktop zu entwickeln der hoffentlich besser ist als andere und nicht nur ein Abklatsch des nun einmal üblichen. Aber auch darüber kann man unterschiedlicher Meinung sein und unterschiedliches ausprobieren. Genau diese Unterschiede machen die Essenz von Open-Source aus: Am Ende wird sich das durchsetzen was sich praktisch und faktisch bewährt.

In diesem Sinne und mit Mao: Laßt hunderte Blüten blühen ! Mit oder ohne Dogger, unter Linux oder welchem BSD auch immer... :rolleyes:

Peter
 
Fantastisch... :-).

Ich muss selbstkritisch zugeben, dass da bei mir (etwas) der
chauvinistische Gaul durchgegangen ist.

rubricanis schrieb:
Mit all dem ist natürlich nicht gesagt dass es nicht Sinnvoll ist das Suspend/Resume Problem von FreeBSD zu lösen
Zum Vergrößern anklicken....

Nun wo muss ich denn nun ansetzen, um etwas beizutragen zu koennen, um zu helfen das besagte Problem zu loesen???
 
das.chaos schrieb:
Nun wo muss ich denn nun ansetzen, um etwas beizutragen zu koennen, um zu helfen das besagte Problem zu loesen???
Zum Vergrößern anklicken....
Keine Ahnung, vermutlich kein einfaches Thema. Ich würde vermutlich zunächst im Inet recherchieren, mir den Code anschauen und evtl. einige Bücher lesen. Und ich würde die Finger davon lassen wenn es meine Kenntnisse allzu sehr übersteigt und mir was einfacheres suchen...:cool:
 
rubricanis schrieb:
... mir den Code anschauen ...
Zum Vergrößern anklicken....

Das meinte ich mit meiner Frage... welche Code-basis??? Die von X oder ist es
vom OS oder von ${WM} bzw. ${DE}??? Bzw. url auf ein Repository???

Definitiv ist das bestimmt eine sehr komplizierte Sache bzw. Neuland... mmmh
will mir halt einen Ueberblick verschaffen ob ich es kapiere bzw. die Problematik
verstehe(n kann).

Vermutlicherweise wird das zu hoch fuer mich sein bzw. zu kompliziert sein.

Mehr oder weniger geht es mir hierbei um die Befriedigung meiner Neugierde. :-).
 
Suspend/Resume ist ein echt hartes Gebiet. Das ist nicht nur Software. Klar, der Kernel muss im Prinzip erst mal alles richtig von seiner Seite aus machen.

Aber dann kommt die Hardware dazwischen. Ein mal auf Software-Ebene der Treiber und ein mal auf Hardware-Ebene die Firmware. Ich habe selbst nicht nachgesehen, aber ich würde stark vermuten, dass der Linux-Kernel voll mit Ausnahmebehandlung ist.

Und die braucht FreeBSD schlicht und ergreifend auch.
 
Meiner Erfahrung nach lassen sich 99% aller Suspend/Resume-Probleme unter FreeBSD in 3 Kategorien unterteilen:
  • Ärger mit der Hardware selbst. Solange man in diesem innersten Kreis Notebook-Hardware (Intel-NIC, Intel-WLAN, Intel-HDA, etc.) bleibt, klappt das meist.
  • Fehlende Resume/Suspend-Methoden in den Treiber. Gerade Serverkomponenten und alte Hardware hat oft keine Treiberunterstützung für Suspend und den folgenden Resume. Dann greifen generische Methoden, die sichern nicht den ganzen Hardware-State und die Hardware bleibt im undefinierten Zustand zurück.
  • Der absolute Großteil von Problemen geht allerdings auf Grafikkarten zurück. Grafikkarten, die nicht sauber reinitialisieren. Grafikkarten, die zwar reinitialisieren, aber kein Bild mehr geben. Grafikkarten die sich aufhängen und die CPU mit in den Tod reißen.
Wenn man konkrete Probleme debuggen will ist daher der erste Schritt, die GPU auszuschließen. Beispielweise einfach zu testen, ob man nach dem Resume trotz schwarzem per SSH auf die Maschine kommt und eine mp3-Datei abspielen kann. Es gibt auch das "debug.acpi.resume_beep"-Sysctl, was einen unangenehmen Piepton ausgibt, sobald der Resume startet und damit aufhört, wenn der Kernel den Resume für beendet erklärt. Hört er nie auf zu piepen, ist er hängen geblieben.
Im nächsten Schritt sollte man dann sicherstellen, ob die genutzten Treiber entsprechende Suspend- und Resume-Routinen haben. Oft sind die leider nicht einfach zu implementieren, das Hersteller solche Fragen in ihrer Doku ausklammern. Sofern es überhaupt welche gibt. Da kann man beispielsweise einmal schauen, ob Linux entsprechenden Code hat und sich die auszuführenden Aktionen abgucken. Da setzt auch der dritte Punkt an. Schauen, ob Linux für die hängende Hardware due schon von -Nuke- genannten Quirks hat.
 
Wow... nach etwas Einlesen... *rotfl* ... das ist echt ein harter Brocken!!!
Diese Problematik ist (fast) als Form von Weisser Folter zu betrachten.

Mal wieder was gelernt, aber diese Herausforderung ist zu schaffen,
bzw. jetzt weiss ich was ich langfristig lernen muss, um tatsaechlich
bzgl. "Suspend-Resume" eine Konstruktiven Beitrag zu leisten.

Last but not least, will ich definitiv meine Arbeitskraft dem FreeBSD
Projekt bzw. den *BSD Projekten zur Verfuegung stellen. Weil, ich
will endlich auch mal was zurueckgeben, statt nur nehmen.
 
Fange besser im Userland an, nicht im Kernel. Der Kernel ist gnadenlos, da wahnsinnig komplex und absolut keine Fehler verzeihend. Schaue mal hier: https://wiki.freebsd.org/GoogleCodeIn/2014Tasks Und etwas allgemeiner hier: https://wiki.freebsd.org/IdeasPage Da sind recht kompakte, beherrschbare Userland-Aufgaben bei. Bevor du anfängst solltest du aber auf freebsd-current@ einmal nachfragen, ob die Aufgabe noch offen ist.

Nachtrag: Bug Reports ohne Eigentümer (gehören dann meist freebsd-bugs@freebsd.org oder einer themenspezifischen Mailingliste) sind auch immer gerne genommen. Da könnte ich diese schöne Liste bieten: https://bugs.freebsd.org/bugzilla/b...335&product=Base System&query_format=advanced
 
Aaaahhh... fantastisch. Danke fuer die urls. Werde definitv im Userspace anfangen!!!

Yamagi schrieb:
Der Kernel ist gnadenlos, da wahnsinnig komplex und absolut keine Fehler verzeihend.
Zum Vergrößern anklicken....

Stimmt... :D habe schon fantastische Systemcrashes produziert bzw. seit geraumer Zeit schiesse
ich mich (testweise) auf den Netzwerkprotokolstapel ein.

O. a. Link soll kein SEO sein (falls es doch als erscheinen vermag, dann bitte url loeschen), das Repository
ist nur eine Spielerei (da tonnenweise Fehler enthalten sind und Andere koennen es definitiv besser als ich),
um Strukturen von KPI / API von FreeBSD (teilweise) zu verstehen.
 
rubricanis schrieb:
Die biologische Evolution funktioniert z.B. ganz anders: Da gibt es eine enorme Verschwendung von Resourcen in dem alle nur möglichen Varianten auspropbiert werden und eben die am besten angepaßten überleben (nicht die "fittesten" übrigens wie die vermeintlichen "Mehrleister" dieser Welt das gerne verstehen).
Zum Vergrößern anklicken....
Hier möchte ich mal kurz klug scheißen und anmerken, dass Fit Englisch für angepasst ist.
 
Das ist natürlich richtig! Im deutschen hat "fitt" aber einige andere Konnotationen und wird eher in Richtung leistungsfähig, stark etc verstanden was allzu oft zu fragwürdigen Interpretationen des alten Darwin geführt hat und immer noch führt. In diesem Sinne war das gemeint, - was du sicherlich auch so verstanden hast.
 
Ich gehe da eh von einem Übertragungsfehler aus. Good old Darwin meinte bestimmt "Survival of the fattest" :p - also ganz im Sinne der Pizza-Distributoren...
 
Das kann durchaus so sein! ;) Gute Futterverwerter hatten in Hungerzeiten bessere Überlebenschancen dank einer angefressenen Plautze. Da zehren wir immer noch von. Nur fehlt es inzwischen an den Hungerzeiten ...:)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben