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