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

Das groesste Manko ist der fehlende Docker support
Was mich aber ein wenig verwundert. Vielleicht hat sich das schon jemand angesehen. So wie ich das verstehe ist das unter macOS so, dass dort einfach ein xhyve, das auf bhyve passiert hochgezogen wird und die Sachen dann da reingemappt werden. Gibt's da triftige Gründe, dass das unter FreeBSD nicht genau so klappt. Wie gesagt, hab's mir selbst noch nicht angeschaut, aber vielleicht weiß jemand mehr dazu? Hätte jetzt mal naiv erwartet, dass das Diff zur macOS-Lösung oder das nachbauen dieser Lösung nicht allzu riesig wäre.

Klar, das wäre noch immer nicht was was Linux entspricht, aber für viele Anwendungsfälle, vor allem wenn es bloß um Entwicklung ginge wäre das eine Option.

Hat da jemand Einblick?
 
Hi @Athaba, Deine Erläuterungen habe ich auch schon ganz ähnlich so mit Debain und Ubuntu erfahren :-) Und was Docker angeht - nett gesagt: es wird als Allheilmittel gepriesen, ist aber oft nur eine Verlagerung von Problemen in eine andere Ebene :-) VG Norbert
 
Übrigens gibt es einen Docker "Ansatz" für FreeBSD - pkg search docker :-) so ähnlich wie unter Mac oder Windows...
 
@Athaba Nein das ist genau so wie du sagst ABER da sind wir wieder beim bekannten Problem. Docker macht das nicht für FreeBSD, weil der Mark 0.001% gross ist und von der FreeBSD Seite, sieht sich auch kein Entwickler genötigt das zu machen, weil es gibt ja Jails. Das ist zumindest mein Eindruck.

@bsd4me Man muss unterscheiden, für was Docker eigentlich entwickelt wurde und für was alles es heute missbraucht wird. In einen Docker Container gehört genau eine ausführbare Datei. Damit macht das alles auch Sinn. Schlechte Beispiele sind z.B. Nextcloud. Die Packen einen Webserver, PHP etc, in den Container. Da hat man das Konzept nicht verstanden (Liegt zum Teil natürlich auch an der Programmiersprache. Mit Go wäre das nicht passiert....).
 
Go kenne ich noch nicht - vielleicht mag schön, da reinzuschauen und meine Liste an Programmiersprachen zu erweitern (Cobol, Fortran, Pascal, Modula2, Assembler, Java, C, C++,Perl, PL/I etc) :-) :-) Wobei Java bisher mein Favorit ist und ich mind. 10 Jahre damit entwickelt habe...
 
@bsd4me Man muss unterscheiden, für was Docker eigentlich entwickelt wurde und für was alles es heute missbraucht wird. In einen Docker Container gehört genau eine ausführbare Datei. Damit macht das alles auch Sinn. Schlechte Beispiele sind z.B. Nextcloud. Die Packen einen Webserver, PHP etc, in den Container. Da hat man das Konzept nicht verstanden (Liegt zum Teil natürlich auch an der Programmiersprache. Mit Go wäre das nicht passiert....).
Na ja, diese Aussage halte ich jetzt auch für etwas kurzsichtig. Wenn das Ziel ist ein einziges Package auszuliefern und als Vehikel dafür nutzt man Container, dann würde ich ohne weiteren Kontext erstmal unterstellen dass das am Ziel vorbei gedacht ist.

Ich kenne jetzt diese Nextcloud Container nicht aber das klingt erstmal nach genau dem richtigen Usecase - eine Anwendung die ein komplexes Deployment hat aber genau einen Prozess benötigt (oder einen sauberen, zusammenhängenden Process-Tree erzeugt) so zu Packagen dass das immer wieder reproduzierbar ist - und wenn du mehrere Prozesse benötigst dann packst du das halt nicht in Compose (oder eben K8S wenn man die Fähigkeiten benötigt).
 
In einen Docker Container gehört genau eine ausführbare Datei.
Naja, und alles andere was dein Programm braucht, wie /dev/random usw. Und weil es halt Arbeit ist, sich anzuschauen was wirklich gebraucht wird, wird stattdessen halt die komplette Distribution in den Container gepackt. So ist zwar alles größer und alles braucht länger, aber dafür hat man später keine Scherereien mehr wenn festgestellt wird dass Java halt doch noch /dev/fd braucht, oder so. Manche sollen sogar so weit gehen und im Container ein init-system starten, falls das containerisierte Program system() aufruft um Kind-Prozesse zu starten, die dann eventuell nicht aufgeräumt werden…
Schlechte Beispiele sind z.B. Nextcloud. Die Packen einen Webserver, PHP etc, in den Container.
Die machen das vermutlich einmal, weil das kleinteilige Paketmanagement moderner Skriptsprachen gelinde gesagt lästig ist, und zum anderen weil die Nutzer der Container vermutlich keine Lust haben, 5 Container via docker-compose oder ähnlichen Werkzeugen zu starten, sondern nur einen einzelnen Befehl absetzen wollen. Und den Nextclout-Leuten erspart es den Support, wenn mal wieder jemand die falschen Abhängigkeiten verwendet hat.

Ich sehe das für mich so: Container dienen der Isolation. Was aber von wem isoliert wird hängt vom jeweiligen Anwendungsfall ab :)
 
Die machen das vermutlich einmal, weil das kleinteilige Paketmanagement moderner Skriptsprachen gelinde gesagt lästig ist, und zum anderen weil die Nutzer der Container vermutlich keine Lust haben, 5 Container via docker-compose oder ähnlichen Werkzeugen zu starten, sondern nur einen einzelnen Befehl absetzen wollen. :)
Das ist eine gute etwas tiefere Ausführung auf emine Argumentationskette im vorherigen Post. Compose kann man natürlich durch ein Script Wrappen - just saying - aber das Paketmanagement ist hier ein issue. Das Sprach-Paketmanagement ist ja das eine hier, aber die Probleme kommen denke ich vor allem wenn da dann noch Distributions-Paketmanagement reinspielt und du unterschiedliche Distributionen nativ unterstützen willst... na ja... viel Glück damit.
Init-Systeme in Containern finde ich grundsätzlich nicht gut weil es den API-Promise der mir durch den Contaier gegeben wird oft bricht - taucht mein Prozess ab dann soll das auch der Container tun und nicht durch einen Init-Prozess gefangen werden, es kann aber in wenigen Use-Cases zumindest zum Zweck des Zombie Reaping Sinn machen.
 
Schlechte Beispiele sind z.B. Nextcloud. Die Packen einen Webserver, PHP etc, in den Container. Da hat man das Konzept nicht verstanden (Liegt zum Teil natürlich auch an der Programmiersprache. Mit Go wäre das nicht passiert....).

Huh? https://hub.docker.com/_/nextcloud

Base version - FPM

Code:
version: '2'

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud:fpm
    restart: always
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

  web:
    image: nginx
    restart: always
    ports:
      - 8080:80
    links:
      - app
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    volumes_from:
      - app
 
Ich hab nicht gesagt, dass es das nicht gibt. Ich selber verwende auch die fpm Variante. Diese ist aber ja nicht der Standard. Wie auch immer. Docker ist ja eh tot. Daher macht es auch keinen Sinn bei FreeBSD.

PS: links ist ein legacy feature und sollte nicht mehr verwendet werden
 
Ich mach mich hier auch mal unbeliebt, war Debian vor 10 Jahren noch ganz gruselig verwende ich es seit 4,5 Jahren oder so Privat auf dem Desktop und beruflich auf ein paar kleineren Servern und bin eigentlich ganz angetan.

Das liegt imho vor allem dadrann das man seine Hausaufgaben bei den Packages gemacht hat und die eigentlich sehr gut verwenden kann, gebastel mit externen repos ist imho nur noch in spezialfällen nötig (Oder wenn man wie ich in 2 fällen google-chrome oder teamviewer braucht)

Und wers etwas aktueller mag kann mit Testing eine art "Rolling Release" im weiteren sinne fahren.
 
Ich bin am überlegen, meinen Debian-Server für verschiedene Dienste auf FreeBSD umzustellen. Eine unbedingte Notwendigkeit besteht allerdings nicht - noch nicht.
 
Mit fast 25 Jahren Linux ist man ja auch ein Gewohnheitstier, auch wenn die Umstellung keine wirkliche Hürde ist. Angefangen habe ich mit Suse Linux 5.3 :)
 
Ich bin vor etwas über 20 Jahren mit Linux angefangen, erst suse und debian glaub ich, dann hatte ich Slackware probiert, aber alle hatten auf dem alten Rechner vom Schrott (Pentium 90!) Probleme mit dem Sound was aber der Haupteinsatzzweck sein sollte - bei OpenBSD gings direkt was mir den einstieg enorm erleichtert hat. Hach Nochstalgie.

Seit dem ist viel Zeit vergangen und ich hab in der Linux-Welt mal mehr mal weniger intensiv viel ausprobiert, momentan hänge ich seit ner verhältnismäßig langen Zeit bei Debian und wenn das nicht so passt nehme ich Archlinux.

Suse insb. in der Sonderform SLES aber nicht nur ist seit 2009 aus beruflichen gründen mein persönlicher Alptraum (Wobei da nicht Suse direkt Schuld hatte)
 
Im Ernst: Ich finde das sehr leicht nachvollziehbare rc-system von OpenBSD (und vermutlich auch von FreeBSD) als enorm angenehm und für mich auch "am besten" - im Linux-Umfeld hat in "meinen" Szenarien, insbesondere bei Debian, der wechsel auf systemd eher Stabitlität und Vorteile gebracht zu haben.
Wobei man sagen muss das bei Linux der Leidensdruck viel größer war. Das rc-System war schon ein Fortschritt zu dem klassischen Init-IV was bei Linux üblich war. Insofern kann ich schon nachvollziehen das neue Lösungen da auf so fruchtbaren Boden fielen. Und viele der Ideen die in systemd Einzug gefunden haben sind ja auch gar nicht so schlecht.

ALSA wurde 1998 eingeführt
Wie gesagt. Bei FreeBSD wurde das Soundsystem sukzessive verbessert. ALSA wurde eingeführt als suboptimale Lösung und seitdem wird daran auf höheren Layern herumgebastelt.

Ich finde z.B. Pipewire auch eines der besten Open Source Projekte der letzten Jahre.
Da sag ich ja auch nix gegen. Nur ist das wie gesagt gefühlt ne Dauerbaustelle.

Also, naja, magst du mal nicht in den 90ern rumgraben?
Ja. Du hast nicht ganz Unrecht. Aber es liegt natürlich auch in der Natur der Sache. Wenn ich darüber spreche wie lang Features halten und wie gut die sich in der Praxis bewähren kann ich natürlich nix aus den letzten Jahren nehmen, wo man das ja noch gar nicht sieht und/oder richtig abschätzen kann

Und weiter "naja", Jails wurden auch vor 20 Jahren eingeführt und haben sich seitdem auch nur marginal weiterentwickelt
Naja. Die Möglichkeiten mit Jails von vor 20 Jahren erscheinen sich doch erheblich von denen von heute (ich sag nur mal VNET). So marginal kann die Entwicklung also nicht gewesen sein. Sie war halt evolutionär. Man warf nicht weg was man schon hatte, sondern entwickelte es sinnvoll weiter.

und es fehlt vorne und hinten an Features.
Was fehlt Dir denn?

Das was dort durch den Linux Kernel gegangen ist, ist ja auch nicht weg, es wurde einfach nur immer weiterentwickelt und ist jetzt ein enorm flexibles Werkzeug, was vielerorts nicht mehr wegzudenken ist. Nicht nur containerd / Docker, sondern auch Dinge wie Flatpak oder die neue Steam Runtime. Um nur ein paar zu nennen. Das sind ja alles keine separaten Systeme, sondern basieren alle auf den gleichen Kern-Features,
Naja. Es gab schon ein paar Vorgänger zu den heute üblichen Kernel-Features dazu. Ich erinnere nur mal an LinuxVServer und Ähnliches.
Und in darüberliegende Schichten setzt sich das ja auch fort. Flatpak ist da ein gutes Beispiel. Wir haben nicht nur Flatpak sondern auch Snappy und Docker. Es gibt also nicht nur ein Container-System, sondern viele die sich auch teilweise gar nicht so großartig unterscheiden. Das ist was ich meine. Du hast nicht eine Lösung, sondern mehrere mit denen Du Dich herumschlagen musst. Das hat natürlich auf der anderen Seite auch Vorteile. Du kannst Dir eben viel besser für dein spezifischen Anwendungsfall etwas rauspicken als wenn Du eine große Lösung hast die versucht alles zu erschlagen aber wo Du dann auch viel mitschleppen musst was Du evtl. gar nicht brauchst.

Hast aber halt mehrere Lösungen was auch schnell mal unbequem werden kann. Bei FreeBSD stolpere ich da nur an einer Stelle wirklich drüber. Nämlich beim Paketfilter. Da hat FreeBSD ja 3 Implementierungen (von denen aber IPFilter zum Glück quasi gar nicht mehr genutzt wird). Und dann hast Du halt das Problem, das darauf aufsetzende Tools wie z.B. backlistd nur mit der pf zusammenarbeiten. Andere Tools nutzen eben die ipfw. Und das ist dann halt blöd. Bei FreeBSD hat man das zum Glück nur an einer Stelle. Bei Linux gibts halt mehrere solcher konurrierenden Lösungen wo Du dann potentiell in Ärger läufst.

Apropos Firewalls. Da gabs ja unter Linux auch schon einige Änderungen. Erst hatten wir ipfwadm. Dann kam ipchains. Dann iptables (was zugebenermaßen etwas länger gehalten hat). Jetzt haben wir nftables.

Und das sind auch alles keine chroots, sie haben in der Regel kein Init-System. Das sind Applikations-Container. Bietet FreeBSD meiner Erfahrung nach nicht.
Du brauchst auch bei Jails kein komplettes System inkl. init und allem. Du kannst das auch als reinen Applikationscontainer nutzen und packst nur das rein, was Du an Libs usw. brauchst.

Sorry, aber Debian kann nicht mal im Ansatz mithalten. Die Pakete sind nicht nur deutlich weniger, und ja Dinge, die man braucht. Sie sind auch für gewöhnlich komplett out of date, selbst wenn man unstable Branches nutzt.
Naja. Ich sprach ja nur von Größenordnungen. Man könnte versuchen das spaßenshalber mal zu quantifizieren. Ist aber eher nicht so einfach.

Und was soll unnützer Kram in dem Zusammenhang sein? Es wird sich niemand den Aufwand machen ein Port zu maintainen, ohne einen Nutzen zu haben
Was man braucht und was man nicht braucht ist selbstredend eine individuelle Entscheidung.
Was ich damit sagen wollte ist, das es mir wenig nützt wenn es für ein System 100 Mrd. Packages gibt wenn 2 nicht dabei sind die ich brauche.

und FreeBSD ist ziemlich aktiv darin obsolete Pakete zu entfernen.
Das machsts ja eher schlechter. Klar hab ich dann keine Gammelsoftware aber es gibt ja möglicherweise individuelle Use-Cases wo man dann doch noch drauf angewiesen ist. Und wenn die dann nicht mehr da ist, dann ists ungünstig.

Zudem hat Debian eine Geschichte darin Dinge kaputtzupatchen und das betrifft nicht nur RNGs. Immer mal wieder funktioniert von Debian gepatchte Software nicht und teilweise ist das auch der Grund warum man als Projekt dann extra ein Repository anlegt, damit man Software in einer halbwegs aktuellen Version und wie sie gedacht ist nutzen kann. Das wird auch getan, damit man als Softwareprojekt nicht von debianspezifischen Bug-Reports geflutet wird. Ist ja ganz üblich, dass da dann steht man solle entweder deren Repository nutzen oder selbst kompilieren bevor man einen Bug reported, eben damit nicht was aufkommt, was seit mehreren Jahren gefixed ist oder einfach ein Bug im Debian-Paket ist.
Da ist was dran. :-)

Das ist definitiv ein Grund dafür dass Docker als das Allheilmittel gepriesen wird. Damit umgeht man die Probleme des Paketmanagers komplett, hat aktuelle Software, die so verwendet werden kann, wie vom Maintainer gedacht und man hat keine Probleme, dass die hälfte des Systems aus uralten Libraries besteht und deshalb erst wieder nichts richtig funktioniert.
Was viele immer vergessen das das halt auch ne Kehrseite hat. Du musst halt die Container pflegen. In der Praxis kommt es auch gerne mal zu Problemen weil dann im Container irgendeine verwundbare Lib ist.
Ja. Container helfen das Deployment zu vereinfachen. Aber man sollte die Implikationen nicht aus dem Blick verlieren.

Übrigens gibt es einen Docker "Ansatz" für FreeBSD
Es gibt auch "systemeigene" Projekte die sich dem Container-Thema (also natürlich mit Jails als Basis) widmen:
BastilleBSD und pot.

Und wers etwas aktueller mag kann mit Testing eine art "Rolling Release" im weiteren sinne fahren.
Wobei man bei testing aufpassen muss. Frisch geschnürte Pakete landen ja in unstable und werden üblicherweise nach ein paar Tagen (wenn man "gesehen" hat, das das Paket nicht ganz offensichtlich was kaputt macht) nach testing verschoben.
Das ist natürlich ein Problem bei z.B: Security-Bugs. Die gefixte Version ist zeitnah nur in stable und unstable drin. Wenn Du testing fährst läufst Du mitunter tagelang verwundbar rum.
 
Wie gesagt. Bei FreeBSD wurde das Soundsystem sukzessive verbessert. ALSA wurde eingeführt als suboptimale Lösung und seitdem wird daran auf höheren Layern herumgebastelt.
Da sag ich ja auch nix gegen. Nur ist das wie gesagt gefühlt ne Dauerbaustelle.
Ja. Du hast nicht ganz Unrecht. Aber es liegt natürlich auch in der Natur der Sache. Wenn ich darüber spreche wie lang Features halten und wie gut die sich in der Praxis bewähren kann ich natürlich nix aus den letzten Jahren nehmen, wo man das ja noch gar nicht sieht und/oder richtig abschätzen kann
Naja. Die Möglichkeiten mit Jails von vor 20 Jahren erscheinen sich doch erheblich von denen von heute (ich sag nur mal VNET). So marginal kann die Entwicklung also nicht gewesen sein. Sie war halt evolutionär. Man warf nicht weg was man schon hatte, sondern entwickelte es sinnvoll weiter.
Was fehlt Dir denn?
Naja. Es gab schon ein paar Vorgänger zu den heute üblichen Kernel-Features dazu. Ich erinnere nur mal an LinuxVServer und Ähnliches.
Und in darüberliegende Schichten setzt sich das ja auch fort. Flatpak ist da ein gutes Beispiel. Wir haben nicht nur Flatpak sondern auch Snappy und Docker.

Was genau ist denn an ALSA denn nun suboptimal? Und was macht FreeBSDs OSS besser? Dass man Userspace Audio-Services nimmt ist ja nun keine reine Linux-Erfindung. Das machen Windows und macOS auch so, weil man eben vielerlei Probleme diesbezüglich eben im Userspace erschlägt. Gerade was so Dinge wie Bluetooth Audio, Audio-Sharing zwischen Anwendungen bzw. Routing allgemein. Auch das Handling unterschiedlicher, paralleler Audio-Ein/Ausgaben mit unterschliedlichen Auflösungen etc. pp. Oder auch das Abspielen von Ton von unterschiedlichen Anwendungen auf unterschiedlichen Ausgabegeräten und die Umschaltung dessen "on-the-fly".

FreeBSD Jails sind im Grunde einfach nur OS-Container. Richte ich eines ein, verhält es sich im Grunde wie eine separate Installation die ich selbst pflegen muss, als wäre es eine eigenständige Installation. Klar gibt es da auch eine Tonne 3rd-Party Tools (was ja böse ist, nicht? Warum nicht ein gutes? ;) ), die einem dort mal recht mal schlecht Arbeit abnehmen, aber im Grunde bleibt's dabei. Dinge wie ezjails sind mir schon oft genug um die Ohren geflogen. Alles was ich zur Erleichterung haben will (im Grunde eben den Applikations-Container) muss ich mir selbst zusammenschrauben. Dazu kommen natürlich noch allgemein FreeBSD Schnitzer wie dass man das Basissystem nicht mit pkg updaten kann, sondern dazu eben das ultra-mega langsame freebsd-update nehmen "muss", wenn ich nicht gerade aus den Sourcen compilieren möchte. Ich saß letztens einen ganzen Tag daran eine handvoll FreeBSD-Jails zu aktualisieren, eben weil das alles soo langsam ist, wenn man schlicht nach Handbuch vorgeht.

Ansonsten sind Dinge wie Flatpak, Docker und Snap eben mitnichten alles separate Technologien. Sie basieren alle auf den gleichen Kernel-Subsystemen und sind nunmal eben in ihren Anwendungsfällen unterschiedlich. Flatpak packt GUI Anwendungen in Container, in einer Sandbox mit wohldefinierten Schnittstellen nach außen für erhöhte Sicherheit. Also ähnlich wie Anwendungen in Android und iOS. Docker hat da ganz andere Ziele und eine GUI Anwendung anzuzeigen ist so von Haus aus gar nicht vorgesehen. Es wäre komplett sinnlos hier eine eierlegende Wollmilchsau zu bauen. Ich finde es auch echt albern hier auf Dingen rumzureiten die aus Kernel 2.4 oder 2.6 Zeiten stammen.

Ich sehe FreeBSDs ultralangsame, konservative Entwicklungsweise eben nicht als Vorteil an. Klar, wenn man an den Sachen nichts ändert, geht auch nichts kaputt, aber es gibt eben halt auch kein Fortschritt. Und darum fühle ich mich bei der FreeBSD-Administrator um ein paar Jahrzehnte zurückversetzt in die Zeit wo Packetmanager noch der neue heiße scheiß war. Also die halbgare Dauerbaustelle von FreeBSD ;) Und es ist eben nicht so, dass in FreeBSD alles toll ist und einfach nur immer toller wird. Die Dinge sind teils einfach uralt, überholt und schlecht gepflegt und statt dass man mal ordentlich aufräumt wird einfach weiter dran rumgeschraubt, damit es noch halbwegs funktioniert.
 
und von der FreeBSD Seite, sieht sich auch kein Entwickler genötigt das zu machen, weil es gibt ja Jails.
Wobei die Argumentation ja nicht wirklich passt, da Jails auf einer anderen Ebene anzusiedeln sind wie Docker. Jails sind ja quasi System-primitive. Das Äquivalent zu Docker wäre sowas wie BastilleBSD. Jails ist ja eher sowas wie LXC bei Linux.

Was genau ist denn an ALSA denn nun suboptimal? Und was macht FreeBSDs OSS besser?
Wie gesagt. Unter Linux ist Sound gefühlt ne Dauerbaustelle. Ich hab nun schon recht lange Linux im Einsatz und irgendwas ist irgendwo immer.

FreeBSD Jails sind im Grunde einfach nur OS-Container. Richte ich eines ein, verhält es sich im Grunde wie eine separate Installation die ich selbst pflegen muss, als wäre es eine eigenständige Installation.
Das kann man so machen, muss man aber nicht. In ein chroot kannst Du natürlich auch ne komplette Installation reinlegen. Musst Du aber nicht.

Wie gesagt. Es ist kein Problem nur eine einzelne Applikation da rein zu legen. Es sind eigentlich nur zwei Dinge etwas tricky. Herauszufinden was die Applikation überhaupt an Dateien/Verzeichnissen braucht (das lässt sich sogar noch halbautomatisiert herausfinden) und welche Rechte sie bezüglich des Host-Systems haben will. Aber das Problem hast Du immer bei isolierenden Container-Technologien. Das ist nix Jails-Spezielles.

Klar gibt es da auch eine Tonne 3rd-Party Tools (was ja böse ist, nicht? Warum nicht ein gutes? ;) ), die einem dort mal recht mal schlecht Arbeit abnehmen,
Ja. Ich bin selbst kein Fan von den diversen 3rd-Party-Tools und meide sie.

Dinge wie ezjails sind mir schon oft genug um die Ohren geflogen
Ja. ezjail ist da ein passendes Beispiel. Und besonders viel Pflege hat das Tool in den letzten Jahren auch nicht bekommen (um nicht zu sagen: Es ist tot, Jim ;)).
Umso tragischer ist es, das es sogar immer noch im Handbuch im Jails-Kapitel prominent platziert ist.

Aber:
Man verliert auch nicht wirklich viel, wenn man darauf verzichtet.

Dazu kommen natürlich noch allgemein FreeBSD Schnitzer wie dass man das Basissystem nicht mit pkg updaten kann,
Mit PkgBase kannst Du inzwischen pkg nehmen. Allerdings gibt es (soweit ich weiß) keinen offiziellen Mirror, so das Du selbst ein Repository vorhalten musst.

sondern dazu eben das ultra-mega langsame freebsd-update nehmen muss, wenn ich nicht gerade aus den Sourcen compilieren möchte.
Ja. Das stimmt. Es ist langsam. In der Praxis ist das aber häufig nicht wirklich ein Problem. Zumindest ich sitze nicht die ganze Zeit vor dem Rechner und gucke freebsd-update zu, bis es fertig ist. Aber das handhabt ja jeder anders. ;-)

Ansonsten sind Dinge wie Flatpak, Docker und Snap eben mitnichten alles separate Technologien.
Doch. Sind sie.

Sie basieren alle auf den gleichen Kernel-Subsystemen
Das hab ich auch nicht bestritten.

Es wäre komplett sinnlos hier eine eierlegende Wollmilchsau zu bauen
Ja. Wie schon gesagt. Wie man es auch macht hat man immer Vor- und Nachteile. Von daher ist es eben ungünstig wenn man pauschal von dies ist besser als das spricht wenn man nicht das Szenario dazu skizziert.

Ich sehe FreeBSDs ultralangsame, konservative Entwicklungsweise eben nicht als Vorteil an. Klar, wenn man an den Sachen nichts ändert, geht auch nichts kaputt, aber es gibt eben halt auch kein Fortschritt.
Langsame/konserative Entwicklung ist ja kein Argument ansich. Es gibt eigentlich nur ein wirklich wichtiges Kritierium: Wie gut erfüllt Ein System oder Programm meine konkreten Anforderungen.

Und ja klar hat FreeBSD seine Probleme. Da will ich auch nix wegdiskutieren. Aber es ist ja nun auch nicht so, das andere Systeme problemfrei sind. Und ja. Manchmal ist die Entwicklung vielleicht zu behäbig.

Und Weiterentwicklung/Neuerungen sind auch nicht per se ein Vorteil. Ich hab z.B. noch ne alte Mikrowelle. Die hat zwei Knöpfe. Einen für die Leistung. Einen für die Zeit. Ein Freund von mir hat ne ultra-moderne Mikrowelle mit dutzenden von Knöpfen (ohne Bedienungsanleitung kriegst Du das Ding nicht an).
Wenn ich mal ne Tasse Milch warm machen will stell ich die rein, dreh ein bisschen am Zeitknopf das es auf ca. eine Minute steht und dann geht es auch schon los. Der Freund braucht gefühlt Minuten bis er seine moderne Mirkowelle überhaupt erst mal programmiert hat.

Das erinnert mich so ein bisschen an ifconfig vs. ip ip kann auch mehr als der klassische ifconfig-Befehl. Aber in 99,9% der Fälle rufe ich einfach nur ifconfig ohne Parameter auf, um zu gucken welche Netzwerkschnittstellen sind da und wie sind die konfiguriert.

Und es ist eben nicht so, dass in FreeBSD alles toll ist und einfach nur immer toller wird.
Ich würde das selbst auch gar nicht so sagen. Es ist halt eine Frage der Philosopie. Und auch hier hast Du immer das Problem das damit nicht nur Vorteile einhergehen, sondern auch Nachteile. Wenn also eine Technologie lange überlebt dann hat das natürlich den Vorteil das Du Dich nicht mit Neuem vertraut machen musst und das Du auf Bewährtes setzen kannst. Es hat aber natürlich auch den Nachteil das bestimmte Dinge im Design (was Du immer irgendwo haben wirst weil man mit Features Erfahrungen sammelt oder/und weil sich im Laufe der Zeit die Anforderungen ändern oder neue Dinge hinzukommen) nicht (so ohne Weiteres) fixen lassen.
 
Weil dann ein paar Kommentare kamen wg. Debian vs FreeBSD. Nur um's klarzustellen. Debian einsetzen ist ganz okay, und hab nichts dagegen. Mir ging's lediglich darum meinen Punkt bzgl. Packages darzustellen. Vielleicht deckt sich das gar nicht mit euch. Und grundlos Systeme umstellen ist ja auch eher eine schlechte Idee.

Bin nur bei den Paketen immer ein bisschen perplex, weil ich eher denken würde, dass es da keinen triftigen Grund gibt, dass bei hunderten Linux-Distributionen nichts ähnliches gibt und man eben auf Grund der Nutzerzahlen das anders erwarten würde. Einzige Erklärung die ich habe ist, dass es eben so viele Distributionen gibt. Ich glaube Gentoo zur Blütezeit mal rangekommen, als es generell noch weniger größere Distributionen gab. Kann mir auch vorstellen, dass das "als gesamtes OS betrachten" auch ein wenig dazu führt, dass es eine größere Überlappung von Leute die an FreeBSD selbst und Ports arbeiten, während das bei Linux stärker aufgeteilt erscheint. Auch kommt man zumindest im Vergleich einfacher rein (mal von Arch mit AUR abgesehen).

Aber das wird OT. Wollte nur klarstellen, dass ich absolut nichts gegen Linux oder Debian im speziellen habe, sondern dass das mit den FreeBSD ports/packages einfach sehr überraschend ist. Also dass ich echt öfters mal genau deshalb zu FreeBSD gegriffen habe, obwohl das eigentlich kein direkt OS-Feature ist und noch dazu die Community kleiner ist als bei Linux. Und der Ports-Tree auf Grund der Eigenschaften ein "Feature" ist, das aber nirgends angepriesen wird.


Zu Docker und FreeBSD. Ich glaube, dass die FreeBSD-Alternativen sehr einsatzzweck-abhängig sind. Auf Linux ist es für die einen das Ding mit dem sie ihr Kubernetes oder Nomad verwenden, für die anderen der Weg mit dem sie schnell mal Software die sie auf GitHub gefunden haben testen (also mit Docker Compose), quasi "Live CD für Software", für wieder andere ist es das Ding mit dem Entwickler ihre Software über den Zaun werfen, damit es keine "Works for Me"-Momente gibt, für wieder andere ist es das Ding um quasi ein statische Binary zu erzeugen, wenn sie Python/Perl/Ruby/Node.js/... verwenden, und für wieder andere das Ding mit dem sie schauen, dass was sie da gebaut haben nicht nur unter ihrem Windows oder macOS funktioniert.

Bastille, pot, etc. sind sehr auf FreeBSD zugeschnitten und der Use Case in einer Firma, wenn manche Leute Windows, andere Linux und andere macOS haben das quasi zu vereinheitlichen und auf dem Server laufen zu lassen fällt mit den meisten Lösungen absolut flach. Deshalb glaube ich eben, dass die Allround-Lösung wohl ein bhyve-Docker wäre, quasi das macOS-Docker - mit allen Nachteilen die das natürlich mit sich bringt.
 
Wobei die Argumentation ja nicht wirklich passt, da Jails auf einer anderen Ebene anzusiedeln sind wie Docker. Jails sind ja quasi System-primitive. Das Äquivalent zu Docker wäre sowas wie BastilleBSD. Jails ist ja eher sowas wie LXC bei Linux.
Ja das ist sicher richtig. Man sollte auch aufhören von Docker zu reden, weil das eben auch nur eine Variante ist. Mit Podman [1] oder Nerdctl [2] gibts da weit bessere Tools.

Was mich dabei im Kontext viel mehr "nervt" ist die nicht vorhandene Reaktion von dem FreeBSD Projekt allgemein. Es gibt nichts was auch nur in die gleiche Richtung, offiziell von FreeBSD promotet wird. Warum? Docker kam mit der Idee 2013, Kubernetes 2015. Sah man das Potenzial nicht oder ist es ihnen einfach egal?

[1] https://podman.io
[2] https://github.com/containerd/nerdctl
 
Zu Docker und FreeBSD.
Man muss halt gucken, für was man Container einsetzen will. Geht es darum Programme mit ihren Abhängigkeiten zusammenzupacken um die dann zu verteilen dann geht das sowohl unter Docker-kompatiblen Systemen als auch unter FreeBSD.

Allerdings gibts dabei halt noch einen weiteren Aspekt. Nämlich das man einen Standard hat was wiederum dazu führt, das man (zahlreiche und ausgereifte) Tools hat die man dafür benutzen kann.
Und das halt Upstream-Projekte unabhängig von Distributionsrepositories und installierten Paketen ihr Programm zur Verfügung stellen können und die funktionieren dann auch überall. Inzwischen ja sogar Plattformübergreifend, wenngleich nda natürlich mit Virtuellen Maschinen getrickst wird was ja auch sehr in die Richtung geht wie Du es mit Deinem "bhyve-Docker" andeutest.

Und das ist es eben, falls Lösungen wie Docker (bzw. besser gesagt: OCI-Container) so attraktiv und wichtig heutzutage macht.

Was mich dabei im Kontext viel mehr "nervt" ist die nicht vorhandene Reaktion von dem FreeBSD Projekt allgemein.
[...]
Sah man das Potenzial nicht oder ist es ihnen einfach egal?
Ich weiß jetzt nicht, was die "offizielle" Erklärung dafür ist aber es gibt natürlich ein paar Sachen die man als Vermutung heranziehen könnte.
Erstens gibts ja Jails auf den basierend man relativ leicht Container bauen kann. Es war also nicht unbedingt dringender Bedarf da (wie gesagt: der Vorteil von Docker bzw. OCI-Containern liegt ja nicht nur darin das man Programme "containen" kann, sondern das dies gleichzeitig auch ein Standard ist).

Gleichzeitig ist es aber auch nicht so einfach Docker zu portieren da dies eben auf Linux-Features angewiesen ist. Was man allenfalls machen könnte ist eine Docker bzw. OCI-kompatiblen Service zu bauen. Aber auch das reicht ja nicht. Auch die in den Containern gepackten Programme als Solches haben mehr oder weniger direkte Abhängigkeiten von Linux.
Klar sind das alles Probleme die man in den Griff kriegen kann. Aber das ist halt mit Arbeit verbunden. Und die muss sich erst mal jemand machen.

Und ich weiß ja nicht, wie ihr euch das so vorstellt. Das FreeBSD ein schickes Headquarter hat und da sitzen dann halt die ganzen vielen FreeBSD-Leute drin die nur darauf warten das irgendwie mal ne Mail eintrudelt mit nem schicken Vorschlag a-la "Wir bräuchten OCI-Container-Support. Könntet ihr da mal was machen?" und dann beraten die darüber und geben das dann ggf. in die Programmier-Abteilung rüber und die setzen das mal eben in ein, zwei Monaten um was der Vorstand beschlossen hat.

Aber so ist es ja nicht. Von daher ist schon der ganze Ansatz a-la "Die FreeBSD-Leute müssten dazu was sagen." oder "Wollen die bei FreeBSD kein Docker?" vollkommen verkehrt.
Wenn Du Docker-Support haben willst dann steht es Dir frei (ganz im Sinne des Open-Source- / Mitmach-Gedankens) dies zu implementieren und z.B. als Port zur Verfügung zu stellen bzw. Dich an dem was bereits da ist dranzuhängen und das zu unterstützen. Da wird niemand Dir sagen "Das wollen/brauchen wir aber nicht".
 
Aber so ist es ja nicht. Von daher ist schon der ganze Ansatz a-la "Die FreeBSD-Leute müssten dazu was sagen." oder "Wollen die bei FreeBSD kein Docker?" vollkommen verkehrt.
Wenn Du Docker-Support haben willst dann steht es Dir frei (ganz im Sinne des Open-Source- / Mitmach-Gedankens) dies zu implementieren und z.B. als Port zur Verfügung zu stellen bzw. Dich an dem was bereits da ist dranzuhängen und das zu unterstützen. Da wird niemand Dir sagen "Das wollen/brauchen wir aber nicht".

Ich finde das ist gar kein schlechter Punkt. Ihr seid doch glauch ich 4 Leute hier die sich Docker wünschen und auch Programmieren können - schnappt euch doch ne Tastatur und legt los?

Das ist ja son bisschen das OpenBSD Motto - gefällt dir was nicht? Schnapp dir ne Tastatur!

Ansonsten ist mein Post zu der "Docker" Frage um die sich mal wieder erstaunlich viel dreht noch immer recht aktuell. Ich könnte noch immer 100 IT-Leute bei uns im Firmenumfeld Fragen und nur 3-10 haben davon überhaupt schonmal gehört. Ihr seid da in einem sehr speziellen Bereich unterwegs.
 
Ansonsten ist mein Post zu der "Docker" Frage um die sich mal wieder erstaunlich viel dreht noch immer recht aktuell. Ich könnte noch immer 100 IT-Leute bei uns im Firmenumfeld Fragen und nur 3-10 haben davon überhaupt schonmal gehört. Ihr seid da in einem sehr speziellen Bereich unterwegs.
Das glaube ich eher nicht. Selbst in meinem Umfeld tauchte Docker, Kubernetes bzw. OpenShift schon vor langer Zeit auf. Beispielsweise liefert Coremedia (CMS im Behörden- und Regierungsumfeld) seinen Kram auf Wunsch mittels Docker.
Allerdings sehe ich die Sache recht pragmatisch, benötige ich Docker o.ä. kommt nen Ubuntu oder gleich CoreOS zum Einsatz, baue ich nen Storageserver nehme ich FreeBSD. Für Application und/oder DB-Server nehme ich Oracel Linux/FreeBSD oder sogar Solaris.
Für mich ist das OS nun verfi.... Werkzeug, welches seinen Dienst zu verrichten hat.

Auf dem Desktop läuft bei mir alles. Angefangen bei WIndows 10, weiter mit Ubuntu über MacOS (Mac Mini M1) und ab und an wage ich mal nen BSD.
Die vor und Nachteile wurden schon vorwärts und rückwärts diskutiert, nen Konsens wird sich da nie finden lassen. :-)
 
schnappt euch doch ne Tastatur und legt los?
Man kann noch ergänzend dazu sagen, das ist ja jetzt auch nicht etwas (Open)BSD-spezifisches. Das ist bei anderen Open-Source-Projekten i.d.R. ja auch so.
Docker für Linux ist ja auch nicht vom Himmel gefallen, sondern da hat sich irgendwann mal irgendwer hingesetzt und sich gesagt: 'Hier ist ein Problem das ich gerne soundso lösen möchte.'

Allerdings gibt es natürlich Gründe warum dies nicht oder nicht immer geschieht. Und ich bleib jetzt einfach mal bei Docker aber denkt euch das eher als Platzhalter für ne beliebige Technologie/Programm. Derjenige der Docker benutzt hat nicht unbedingt auch das Know-How ein docker-artiges System zu implementieren (das dürfte sogar meistens der Fall sein). Klar kann man sich das alles zurecht organisieren und so aber mal mit "einfach selber in die Tasten hauen" ist es ja oft nicht getan.

Außerdem ist es ja auch immer eine Frage des Kosten-Nutzen-Verhältnisses. Und viele haben eh Linux-Rechner irgendwo rumstehen und Linux-Know-How ist ebenso häufig da und dann stellt sich halt die Frage: "Implementiere ich Docker für xBSD (was auch nicht mal eben an einem Nachmittag erledigt ist) oder pack ich den Kram einfach auf dem Linux-Rechner der daneben steht."
Und selbst wenn man jetzt sagt: xBSD wäre aber besser. Es zählt ja häufig gar nicht die beste Lösung. Es wird ja häufig irgendwas hingefrickelt und Hauptsache es ist gut genug. Klappert zwar überall und man muss auch öfter mal ein Reboot machen aber funktioniert doch irgendwie. Das ist halt so der Geist der vorherrscht und das ist auch keine neue Erkenntnis. Microsoft hat damit jahrelang gut verdient. :-)
 
Ich finde das ist gar kein schlechter Punkt. Ihr seid doch glauch ich 4 Leute hier die sich Docker wünschen und auch Programmieren können - schnappt euch doch ne Tastatur und legt los?

Das ist ja son bisschen das OpenBSD Motto - gefällt dir was nicht? Schnapp dir ne Tastatur!

Das ist doch so ein schwachsinns Totschlagargument. Ich kann auch etwas kritisieren, ohne es selbst gleich besser machen zu können. Vorallem in einem Thread wo es eben auch genau um solche Schwächen geht.

Ansonsten ist mein Post zu der "Docker" Frage um die sich mal wieder erstaunlich viel dreht noch immer recht aktuell. Ich könnte noch immer 100 IT-Leute bei uns im Firmenumfeld Fragen und nur 3-10 haben davon überhaupt schonmal gehört. Ihr seid da in einem sehr speziellen Bereich unterwegs.

Das wirft Fragen über den Zustand eurer IT auf :D

Ganz ehrlich, selbst wenn man das Container Zeug nicht braucht, erwarte ich doch von jedem ITler, dass er halbwegs regelmäßig IT News konsumiert und mal ne Fachzeitschrift überfliegt, bzw. sich im Austausch mit anderen Kollegen der IT befindet. Wer da nicht halbwegs ne Vorstellung von Containern hat, hat seinen Job verfehlt.

Ich zumindest kenne kein Unternehmen (und wir betreuen sicher an die 20, +Partner, +Dienstleister, ..) die keine Container einsetzen. Bei manchen ist das erst die letzten Jahre im kommen, manche übertreiben es und meinen alles müsse man mit Containern erschlagen, aber niemand setzt absolut keine ein.
 
Zurück
Oben