Was gibt es Vorteile von freien UnixOSen gegenüber Linux?

Container??? Es existiert doch die Moeglichkeit "Soft-appliances" per Cloudabi zu realisieren, oder uebersehe ich da etwas?

CloudABI erfordert Anpassungen aus Source-Ebene, d.h. man kann nicht einfach existierende Software nehmen und containerisieren.

Zumal Stand heute nur C/C++, Python und Rust unterstützt werden, und selbst verbreitete Programmiersprachen wie JavaScript, Java oder Ruby nicht unterstützt werden. Von einer ordentlichen Container-Lösung ist das noch meilenweit entfernt...
 
Hast du mal durchgerechnet, was der Betrieb eines Pentium 4-M o.ä. an Stromkosten verursacht? Der Pentium 4 war selbst in der Mobilvariante unglaublich ineffizient und hatte einen enorm hohen Leerlaufverbrauch.

Es handelt sich um einen Intel Core Duo T2250.

Und ob Arch-Linux wirklich in der Stabilität mit FreeBSD mithalten kann, da melde ich mal leise Zweifel an wegen der bereits genannten Punkte.

Kann man allgemein sagen, dass FreeBSD stabiler ist als Linux?

Zum Thema Docker: Wenn ich den Artikel dazu richtig verstanden habe, ist das etwas, was FreeBSD mit Jails schon vor 15 Jahren konnte und damit seiner Zeit weit voraus war.
 
Es handelt sich um einen Intel Core Duo T2250.

Kann man allgemein sagen, dass FreeBSD stabiler ist als Linux?
Ich finde die Frage etwas unglücklich formuliert, vielleicht sollte es eher heißen:
Sofern beide Systeme eigene Workflows einigermaßen abdecken, ist dann FreeBSD aus Stabilitätsgründen vor zu ziehen?
Da würde ich mittlerweile sagen: Wenn der Distributor seine Sachen gut macht und der Nutzer nicht unbedarft Dinge macht, die unter der Distribution ungünstig sind, unterscheiden sich hinsichtlich der Stabilität FreeBSD und Linux nicht großartig voneinander.
Ich kann da nur aus eigenen Erfahrungen berichten beim privaten Nutzen von FreeBSD und Linux im Heimbereich.
Seit zig Monaten hat mein Vater ein OpenSUSE 15 laufen, als distributionsfremdes Paket ist nur Turboprint installiert und für die Nvidia-Grafik das Nvidia-Community Repo aktiviert. Sonst ist es von der Verwendung verschiedener Repos sehr konservativ gehalten und es werden nur distributionseigene Sachen installiert. Das System hat schon viele Aktualisierungen per Fernwartung bekommen, es läuft und läuft und ist einfach nicht kaputt zu bekommen, auch die Anwendungen laufen stabil.
Ich habe zu Hause seit Erscheinen von FreeBSD 12 diese Version auf meinem Desktop laufen. Das System wird mit freebsd-update aktuell gehalten, als Repo dient latest, ich habe schon zahlreiche Aktualisierungen durchgeführt. Und das System läuft und läuft und ist einfach nicht kaputt zu bekommen, auch die Anwendungen laufen stabil. :D
Ähnlich ist es mit dem FreeBSD 11.2 auf dem PC meiner Frau.
Auf einem Mini-PC läuft bei uns als Printserver-System samt Turboprint zuverlässig ein Devuan, auf einem anderen Mini-Pc läuft als Multimedia-System mit Openboxen und Tint2 samt Kodi ein Devuan. Auch damit haben wir keine Schwierigkeiten, die Systeme laufen und machen, was wir wollen.
 
Zuletzt bearbeitet von einem Moderator:
Meiner bescheidenen Erfahrung nach ist Stabilität im Sinne von "funktioniert wie es soll" vor allem von zwei Dingen abhängig. In erster Linie wie neu eine Funktion ist. Neue Funktionen sind einfach prinzipbedingt nicht so ausgereift wie Funktionen, die bereits seit Jahren entwickelt und genutzt werden und entsprechend verstanden sind. Und wie viel eine Funktion eingesetzt wird. Ich habe über die Jahre in so vieler Software - darunter auch alle großen Betriebsysteme bzw. Distributionen - teilweise hanebüchene Fehler gefunden, nur weil ich es mal gewagt habe die ausgetretenen Pfade, auf denen sich 90% der Anwender bewegen, zu verlassen. Oft kommen beide Punkte zusammen.

Bei Betriebssystemen und Distributionen ist es dann auch dann stark davon abhängig, wie man im Einzelfall mit Neuerungen umgeht. Merged man ungesehen jedes neue Upstream-Release? Nutzt man stumpf überalterte Versionen weiter und redet sich ein, dass sie auf magische Art fehlerfreier wird? Vertraut man dem Upstream und übernimmt seine Releases oder patcht man selbst noch dran herum? Hat man überhaupt die Qualifikation für so ein Herumpatchen?

Daraus folgt, dass man für jeden Einsatzzweck selbst eine Abwägung finden muss. Will ich ein System, was ohne große Änderungen über Jahre läuft und bin ich bereit dafür auch seit Jahren gelöste Probleme in kauf zu nehmen? Will ich das Neuste vom Neusten, auch wenn ich durch ungetestete Funktionen Ärger bekomme? Oder vielleicht etwas dazwischen? Daher ist es sehr schwer eine Aussage wie "X ist stabiler als Y" zu teffen, solange nicht klar ist, was mit "Stabilität" überhaupt gemeint ist, bzw. welche Kompromisse man bereit ist einzugehen.
 
Es ist auch eigentlich nicht die feine englische Art, Systeme derart zu vergleichen auch wenn man das selbst seine Erfahrungen bei gleicher Konfiguration und ähnlichen Versionen der Software hat.
Wahrscheinlich ist das Beste, einfach sich über die Art und Weise der Entwicklung, den Fokus und den globalen Einsatz der einzelnen Programme und Systeme zu informieren.
Untern Strich, ist *BSD, *BSD und *Linux ist *Linux usw. Sie ähneln sich in der Ausstattung, Verzeichnishierarchie usw. trotzdem sind es verschiedene Systeme.
Im wesentlichen fällt auf, das BSD nach dem Prinzip, "Schuster bleib bei deinen Leisten verfährt", somit bei bewährten und stabilen bleiben soll, selbst wenn die Manpower schnelle Modifikationen zulässt, entwickeln sich die BSD's eher in Richtung Bewährtes.
Linux ist ähnlich motiviert, geht aber schneller in die vollen wenn es um neue Technologien geht und ernstzunehmde Änderungen an den Funktionsweisen.
Und neu ist neu, und eben nicht das erprobte zich mal überarbeitete.

Das beste System/Netzwerk fährt man sowieso mit beiden, das ist aus meiner Sicht klare Tatsache.
 
Zum Thema Docker: Wenn ich den Artikel dazu richtig verstanden habe, ist das etwas, was FreeBSD mit Jails schon vor 15 Jahren konnte und damit seiner Zeit weit voraus war.

Das dachte ich auch - bis ich Docker ausprobiert habe. Trotz null Erfahrung mit Docker habe ich in wenigen Stunden Setups zum Laufen bekommen, für die ich mit Jails Tage gebraucht hatte - trotz jahrelanger Erfahrung damit.

Anschließend habe ich mir die fortgeschrittenen Möglichkeiten von Docker samt Ökosystem angeschaut und gemerkt, dass ich nicht den Hauch eines Schimmers einer Ahnung hatte, wie weit Docker Jails voraus ist und welche Möglichkeiten es eröffnet.

Diese Erfahrung ist inzwischen einige Jahre her und der Abstand ist noch größer geworden. In Bezug auf Verteilung, Setup und Betrieb von Anwendungen spielt Docker in einer komplett anderen Liga als Jails. Wer einmal eine Container-Plattform in Aktion erlebt hat, kann sich den Schritt zurück zu Jails nicht mehr vorstellen.
 
Das dachte ich auch - bis ich Docker ausprobiert habe. Trotz null Erfahrung mit Docker habe ich in wenigen Stunden Setups zum Laufen bekommen, für die ich mit Jails Tage gebraucht hatte - trotz jahrelanger Erfahrung damit.
Und nun hast Du mich neugierig gemacht und ich habe mich bereits eingelesen. Sieht sehr gut aus und scheint mir eine ernsthafte Alternative zu alternativen VM wie Virtualbox oder anderen Hyperviser zu sein. Kaum overhead und schnelle Lernkurve.
 
Und nun hast Du mich neugierig gemacht und ich habe mich bereits eingelesen. Sieht sehr gut aus und scheint mir eine ernsthafte Alternative zu alternativen VM wie Virtualbox oder anderen Hyperviser zu sein. Kaum overhead und schnelle Lernkurve.

NEIN. Docker ist keine alternative für VMs, Docker dient der virtualisierung von einzelnen Anwendungen. Wenn du einen Dockercontainer als alternative zu einer VM betrachtest gehst du es zu 99% schon falsch an, und es kommt nur arbeitsintensiver, unsicherer und unperformanter Müll dabei raus.
Um mit Docker spass zu haben musst du dich auf die Konzepte die es mitbringt einlassen, dazu gehört u.A. das ein Container immer beliebig erzeugt und zerstört werden kann, soblad du beginnst IM Container irgendwelche persistenten Daten zu speichern bekommst du große Probleme und bringst dich um alle Vorteile, die das Docker (*Container) Ökosystem bringt. Um mehrere Dienste zu einer Einheit zusammen zu bringen hast du dann einen Pod aus mehreren einzelnen Containern.

*Docker ist eigentlich nur eine Verwaltungsmöglichkeit, Rhel7 bietet z.b. Podman als direktes Replacement.
 
@medV2, danke für die Aufklärung. Dann ist das nichts für mich, persistente Daten sind mir wichtig. Da ich dies las, dachte ich, das es doch geht:

Volumes verstehen und verwalten

Und ja, das habe ich mittlerweile kapiert, geht auch aus meinen Recherchen hervor, Docker ist natürlich keine Virtuelle Maschine. So, zumindest scheint sich hier unter FreeBSD niemand ernsthaft damit zu beschäftigen. Die meisten ziehen wohl Jails vor ....:)

Werde hier nicht weiter posten, weil es sonst zu sehr OT wird. Trotzdem Danke!
 
Persistente Daten sind natürlich im Docker-Ökosystem dabei, aber eben nicht IM Container, sondern über Volumes, Datenbanken, Webservices, ...
Aber das erfordert alles Planung. Worauf ich hinaus wollte, Docker ist kein dropin-replacement für eine VM.
 
Docker ist kein dropin-replacement für eine VM.
Und das habe ich jetzt begriffen.:rolleyes: Ging aber auch aus meinen Recherchen hervor. Was mir gefällt, das Docker doch ziemlich gut dokumentiert ist und es viele HowTo's im Netz gibt. Podman hingegen eher spärlich, aber da kann man ja wahrscheinlich auf die Doku von RedHat zurückgreifen. Ansonsten ist Podman ja (fast) Befehls kompatibel, nur es läuft kein Daemon, was sicherlich wiederum Resourcen spart. Was ich hier poste, gibt nur meine ersten Eindrücke wieder, es erhebt natürlich keinen Anspruch auf Vollkommenheit, da ich mit beiden Containersystemen erst am Anfang stehe. Dementsprechend ist auch mein WIssensstand eher theoretischer Natur, jetzt kommt die Praxis, denn es interessiert mich schon.
 
Ohne dass das jetzt nach Kapitalismuskritik oder so klingen soll. Die BSDs haben derzeit einen starken Vorteil dadurch, dass Entscheidungen nicht rein nach "wie vermarkte ich das System am Besten" getroffen werden. Das ist derzeit etwas, was echt an der Linuxwelt nervt, vor allem im Serverbereich.

Entscheidungen werde häufig danach getroffen was gerade hipp ist (zumindest bei den Großen). Das führt zu einem alles abnicken und zu den bekannten "Instabilitäten", wenn man mal wirklich ein Release upgraded. Gefühlt macht das in der Linuxwelt außerhalb von Rolling Release Distributionen niemand mehr. Da wird einfach neu installiert, was sich ja auch darauf Einfluss hat, dass in der Serverwelt alle Arten von "mal schnell verwenden und dann wegwerfen" (Cloud Computing im Groben) der klassische Anwendungsfall ist. So etwas wie sich zu freuen, dass man ein System hat wo man ein Problem debuggen kann gibt es kaum.

Das was vor einigen Jahren noch die große Errungenschaft war, Probleme zu ignorieren und Services einfach still neu zu starten passiert jetzt auf Container/VM-Basis, sowohl in kleinen, als auch großen Unternehmen. Im Grunde kann es mir da recht sein, weil sich damit auch gut Geld verdienen lässt, wenn jemand genau damit Probleme hat (man sehe sich die Gehälter von DevOps und die Kosten für Clouds und Lösungen damit die auch gut funktionieren an).


Anders und mit einem Augenzwinkern schafft die Linuxwelt gerade massiv Arbeitsplätze und Umsatz, vor allem in der IT-Branche selbst.

Es wäre wohl nett mal eine Studie darüber zu machen wie so das Verhältnis von IT-Ausgaben und Einnahmen bei BSD vs Linux ist. Ich glaube da würde man ganz gut abschneiden.

Nur umgekehrt ist das nicht so. Ich glaube als BSDler verdient man im DevOps/SRE/Sysadmin-Bereich im Schnitt wohl etwas weniger. Bzw. ist das nur ein Eindruck, also wie beim obigen Absatz eher was, falls mal jemand eine Studie dazu machen will. Ich kann mir andererseits gut vorstellen, dass man wenn man sich die bestbezahlten Bereich wohl wieder ziemlich nahe ist.
 
Die BSDs haben derzeit einen starken Vorteil dadurch, dass Entscheidungen nicht rein nach "wie vermarkte ich das System am Besten" getroffen werden. Das ist derzeit etwas, was echt an der Linuxwelt nervt, vor allem im Serverbereich.

Konkretes Beispiel?

Da wird einfach neu installiert, was sich ja auch darauf Einfluss hat, dass in der Serverwelt alle Arten von "mal schnell verwenden und dann wegwerfen" (Cloud Computing im Groben) der klassische Anwendungsfall ist.

Warum sich mit den Problemen eines Release-Upgrades rumschlagen, wenn man problems via Infrastructure as Code jederzeit einen definierten und versionierten Stand erzeugen kann? Es ermöglicht einen deutlich einfacheren, reibungsfreieren und ausfallsicheren Betrieb.

So etwas wie sich zu freuen, dass man ein System hat wo man ein Problem debuggen kann gibt es kaum.

Während Kollege A noch vermeidbare Probleme diagnostiziert, kümmert sich Kollege B bereits um die Weiterentwicklung der IT-Landschaft. ;)

Das was vor einigen Jahren noch die große Errungenschaft war, Probleme zu ignorieren und Services einfach still neu zu starten passiert jetzt auf Container/VM-Basis, sowohl in kleinen, als auch großen Unternehmen.

Der Ansatz ist aus der Erkenntnis gestanden, dass man 100% Fehlerfreiheit und Ausfallsicherheit bei einzelnen Komponenten - sowohl Software als auch Hardware - niemals erreichen kann. Also macht man daraus eine Tugend und bereitet seine IT darauf vor, dass jede Komponente jederzeit ausfallen kann. Das Ergebnis gibt dem Ansatz recht.

Im Grunde kann es mir da recht sein, weil sich damit auch gut Geld verdienen lässt, wenn jemand genau damit Probleme hat (man sehe sich die Gehälter von DevOps und die Kosten für Clouds und Lösungen damit die auch gut funktionieren an).

Entscheidend ist der Mehrwert, den eine Lösung bringt:
  • Was ist es mir wert, wenn meine Kollegen ihre Arbeitszeit in Weiterentwicklung statt in Wartung stecken können?
  • Was ist es mir wert, wenn ich bei der Umsetzung meiner Anforderungen nicht von meiner veralteten IT ausgebremst werde?
  • Was ist es mir wert, wenn ich jederzeit binnen Minuten komplette Kopien meiner IT-Landschaft als Testumgebung(en) erzeugen und wieder abbauen kann und ich so eine höhere Zuverlässigkeit erreiche?
  • Was ist es mir wert, wenn ich durch eine höhere Flexibilität mehr Umsatz machen kann?
Deswegen wird momentan Geld in DevOps und Cloud-Lösungen investiert: es lohnt sich für die Unternehmen.

Anders und mit einem Augenzwinkern schafft die Linuxwelt gerade massiv Arbeitsplätze und Umsatz, vor allem in der IT-Branche selbst.

Die meisten Unternehmen sind in zunehmenden Maße auf Gedeih und Verderb auf eine funktionierende, flexible und leistungsfähige IT angewiesen. Mit IT-Prozessen aus dem vergangenem Jahrtausend ist man dem nicht gewachsen.

Es wäre wohl nett mal eine Studie darüber zu machen wie so das Verhältnis von IT-Ausgaben und Einnahmen bei BSD vs Linux ist. Ich glaube da würde man ganz gut abschneiden.

Welche Faktoren willst du konkret beleuchten?

Nur umgekehrt ist das nicht so. Ich glaube als BSDler verdient man im DevOps/SRE/Sysadmin-Bereich im Schnitt wohl etwas weniger. Bzw. ist das nur ein Eindruck, also wie beim obigen Absatz eher was, falls mal jemand eine Studie dazu machen will. Ich kann mir andererseits gut vorstellen, dass man wenn man sich die bestbezahlten Bereich wohl wieder ziemlich nahe ist.

Im Bereich Administration bzw. DevOps gibt es zumindest im deutschsprachigen Raum für BSD zu wenig und zu kleine Arbeitgeber (dito Auftraggeber). Das bringt einen ganzen Rattenschwanz an Problemen mit sich, von denen die schlechtere Bezahlung nur eines ist.

Die interessanten Projekte - sowohl thematisch als auch finanziell - finden momentan häufig auf Basis von Container-Plattformen statt (Docker, Kubernetes etc.), dort ist BSD leider komplett außen vor.
 
Hier wurde viel gesagt und ich habe nur eine Seite überflogen, habe aber eine Meinung zum Thema und gehe nun einfach die Gefahr ein, dass es bereits gesagt wurde:

Vorteile der BSDs gegenüber Linux, hier gehe ich nur auf OpenBSD ein:
OpenBSD hat ein unglaublich breites Portfolio and Werkzeugen, die mit strukturierten Fehlermeldung eine Anwendung bei Fehlverhalten abstürzen lassen, dies ist keinesfalls stabil oder "sicherer", aber für Testzwecke ein unglaublich schickes Werkzeug, was ich bei Linux so nie erleben durfte!
 
Konkretes Beispiel?
Schau dich um. Zig Distributionen, alle werben mit dem selben.


Warum sich mit den Problemen eines Release-Upgrades rumschlagen, wenn man problems via Infrastructure as Code jederzeit einen definierten und versionierten Stand erzeugen kann?
Geht mir nicht um Release Upgrades und Infrastructure as Code ist nichts neues, sondern lediglich zu einem Buzzword verkommen.

Mir geht's darum, dass Leute Probleme nicht lösen, sondern ein ständiges neu starten als Fix gesehen wird. Die 90er oder frühen 2000er also wieder zurück Sinn in der man einfach mal neu startet, anstatt Fehler auszubügeln.

Es ermöglicht einen deutlich einfacheren, reibungsfreieren und ausfallsicheren Betrieb.

Hahaha. Deshalb verdient man als DevOp in großen DevoOps-Teams so gut, selbst als Junior. Weil alles so reibungsfrei und ausfallsicher läuft.

Während Kollege A noch vermeidbare Probleme diagnostiziert, kümmert sich Kollege B bereits um die Weiterentwicklung der IT-Landschaft. ;)
Vermeidbare Probleme, wie?

Der Ansatz ist aus der Erkenntnis gestanden, dass man 100% Fehlerfreiheit und Ausfallsicherheit bei einzelnen Komponenten - sowohl Software als auch Hardware - niemals erreichen kann. Also macht man daraus eine Tugend und bereitet seine IT darauf vor, dass jede Komponente jederzeit ausfallen kann. Das Ergebnis gibt dem Ansatz recht.
Und was hat das jetzt mit dem zu tun was ich geschrieben hab?


Entscheidend ist der Mehrwert, den eine Lösung bringt:
  • Was ist es mir wert, wenn meine Kollegen ihre Arbeitszeit in Weiterentwicklung statt in Wartung stecken können?
  • Was ist es mir wert, wenn ich bei der Umsetzung meiner Anforderungen nicht von meiner veralteten IT ausgebremst werde?
  • Was ist es mir wert, wenn ich jederzeit binnen Minuten komplette Kopien meiner IT-Landschaft als Testumgebung(en) erzeugen und wieder abbauen kann und ich so eine höhere Zuverlässigkeit erreiche?
  • Was ist es mir wert, wenn ich durch eine höhere Flexibilität mehr Umsatz machen kann?
Deswegen wird momentan Geld in DevOps und Cloud-Lösungen investiert: es lohnt sich für die Unternehmen.
Ich weiß, das ist die stetige Behauptung. Ist aber in der Realität einfach nicht so.

Vor ein paar Jahren hat man einen Junior gehabt, im einfachen Fall oder ein paar Leute, die sich hauptsächlich damit beschäftigt haben, dass sie sich aus dem Job automatisieren. Da war's dann einigermaßen normal, dass man schaut , dass man auch Sachen so baut, dass man möglichst einen Fallback hat, dass man keinen Vendor Lock-In hat, dass man wenn es mal Probleme hat, ein zwei Tasten drückt und das System läuft wo anders, wie es auch bisher gelaufen ist. Konfiguration anständig zu verwalten, Dinge zu automatisieren, Failover und Skalierung hat ja nicht Amazon erfunden. Da hat man das halt nicht Infrastucture as Code sondern eben seinen Job genannt.

Im Vergleich dazu hat man heute so schöne Sachen, wo das Rad neu erfunden wird, wo man nette Probleme hat, wie dass die API von Google oder Amazon mal wieder Schwachsinn zurück liefert, dass vor einigen Jahren noch triviale Probleme ungelöste Probleme hat, dass selbst Amazon teilweise erst nach Jahren mitbekommt, dass sie bei ein paar Rechnern auf die Updates vergessen haben, einfach weil die zur Ausnahme mal gut funktioniert haben, auf der die ach so sichere Cloud läuft. Die sind ja auch auf magische Weise von Rowhammer, Spectre und Bugs in Xen oder KVM nicht betroffen.

Oh und dafür dass sie den Leuten VMs mit weniger Garantien zur Verfügung stellen verlangen sie ein zigfaches im Vergleich zu klassischen VMs.

Als DevOp/SRE/Sysadmin darf man jetzt wenn man die Dinge einigermaßen ernst nimmt raten, ob die Virtualisierung ein Grund für ein bestimmtes Verhalten ist. Das kontern die Cloudanbierter dann damit dass sie dir garantieren dass nur deine VM dort läuft und dir zusätzlichen Support verkaufen, zu natürlich noch höheren Preisen, damit du ihnen Bugs zu finden. Und schau dir mal an wie schnell sich das gerade entwickelt und wie die Komplexität steigt. Da so zu tun, als wäre das Ding bugrfree, da meintest du ja gerade dass das unrealistisch ist. Und ja, ich stoße regelmäßig auf 500er und Fehlverhalten, bei den Großen.

Virtualisierung ist auch nichts neues. Gab's auch schon länger. War halt bis vor dem Cloud-Boom noch die "billige Version". Oder man hat es eben selbst gemacht und konnte Dinge eben auch debuggen.

Ich finde es ein wenig übel wenn so getan wird als wären die positiven Sachen, wo es in letzter Zeit mehr Bewusstsein gibt (dass man seine Konfiguration auch versioniert, dass man Snapshots von Zuständen haben können will, dass man Lösungen zu Failover braucht, dass man Dinge automatisieren will, dass man Systeme sauber trennen wollte, CI/CD ist auch nichts neues) dem Vorhandensein von Leuten und Unternehmen zuschreibt, die hauptsächlich in Managermagazinen und auf Golfplätzen werben. Hätte fast nach einer Verschwörungstheorie geklungen, wenn ich's nicht aus erster Hand hätte.

Was man macht ist das neu erfinden des Vendor-Lockins. Ja, es gibt gute Entwicklungen. Das Beste an der ganzen Sache ist, dass Leute geradezu gezwungen werden Dinge anständig zu machen und nicht ständig alles neu zu machen. Aber das liegt null an so Dingen, wie Docker und schon garnicht an so etwas wie Azure, AWS oder GCP. Okay, es liegt vielleicht ein bisschen daran, dass die ganze Szene drum rum den Sysadmins ein paar Buzzwords zum Vermakten gegeben hat, für die früher nie Zeit war, dass Leute sich ein wenig am Riehmen reißen und State von Logik trennen, weil sie Cloudprovider zwingen.

Aber wenn man sich jetzt sagen wir mal Docker ansieht. Leute verwenden das in der Hoffnung, dass sie damit magisch Probleme lösen, die sie nicht haben. Dann gab's mit so Schönheiten wie Docker Swarm noch mehr Probleme und zusammen mit anderen Shortcomings, die das System neu aufgebracht hat werden jetzt mit Kubernetes und Nomad, die eigentlich aus anderen Gründen geschaffen wurden darum rumgefrickelt. Teilweise wird es dann so richtig sinnbefreit genutzt, und man startet einen physikalischen Server, auf dem man eine virtuelle Maschiene startet, auf dem man eine Docker-Instanz startet indem man ein statisches Binary ausführt, wo man dann dem Container mit der virtuellen Maschiene und im Extremfal Zugriff und Abhängigkeiten darauf auf die phsyikalische Maschiene gibt, aber anstatt das Unsinn zu nenen sagt der DevOp ohne Sysadmin-Experience jetzt das wäre damit Cloud Native. Noch besser wird es wenn dann geglaubt wird dass irgendwas in dem Setup dazu führt, als würde es von sich aus Maintenance reduzieren.

Ist generll eine lustige Sache, wenn Leute glauben, nur weil sie auf ihrem Ubuntu noch ein Ubuntu in einem Container starten dass damit die Infrastruktur irgendwie besser wäere. Ist aber so.

Die meisten Unternehmen sind in zunehmenden Maße auf Gedeih und Verderb auf eine funktionierende, flexible und leistungsfähige IT angewiesen. Mit IT-Prozessen aus dem vergangenem Jahrtausend ist man dem nicht gewachsen.
Ich bin dafür, dass wir weiter gehen und ich bin froh darüber was sich in den letzten zehn Jahren getan hat, aber wir gehen gerade als Industrie in eine Richtung wo wir die Fehler der 90er und frühen 2000er in einem viel größeren Maße wiederholen. Wir bauen gerade vendor lockins wo Amazon zum neuen Microsoft wird, nur dass man dann nicht mal einfach schnell umschwenken kann, wo wir so richtig dicke Layers von Over-Engineering betreiben, gerade jetzt wo gerade weite Teile der Branche begonnen haben dass simple Systeme ihre Vorteile haben übertragen wir genau den Fehler auf die Infrastruktur und während es mich einerseits freut, dass solche Themen ernst genommen werden, zerhauen wir uns das mit einer riesigen Welle an primär durch Marketing gesteuerte Entwicklungen wo's einfach nur darum geht dass Amazon oder Google drauf steht, was Leute dazu bringt deren Services zu nutzen. Im Endeffekt nehmen sich die Open Source Software die stabil und gut läuft, bieten sie gehosted an, eben weil sie nicht "Could Native" sind (weil's eben nicht nur irgendein stateless Binary ist sondern sagen wir mal eine SQL-Datenbank) oder Dinge, die schon seit Jahrezehnten gut funktionionieren (zum Beispiel der Bereich E-Mail oder Monitoring), vermarkten den Teuer, Unternehmen haben keine Infrastruktur mehr und Code der nur "Cloud Native", also nur auf Infrastruktur von einzlenen Marktteilnehmern wirklich funktioniert.

Klar, es gibt da ein paar Lichtblicke, zum Beispiel bei dem was Hashicorp so anstellt, wo scheinbar einigermaßen darauf geachtet wird, dass man nicht alles auf einen Anbieter setzen muss oder gar seine eigene Infrastruktur nutzen kann, aber der Großteil des Marktes ist gerade dabei alles wo nicht Docker, Azure, Google oder Amazon drauf steht als legacy zu bezeichnen und trocken zu legen und das wird genau den Fortschritt, den wir für moderne Systeme brauchen ausbremsen.

Es läuft und ich kenne mittlerweile große Amazon-Kunden, die das Problem haben, dass sie wenn sie von Amazon weg wollen würden einfach nicht die Möglichkeit haben das schneller zu tun als Amazon das will, einfach weil die Daten dort sind oder weil wenn die weggehen würden mal wegen deren API-Limits Monate brauchen würden um die Infrastruktur dort abzubauen. Ist echt mittlerweile ein Problem, dass da Job Queues gebaut werden müssen nur um Ressourcen abzubauen, nur weil es eine Umstellung gibt und Amazon würde sich selbst damit schaden wenn sie das effizienter gestalten würden. Da gehen ganz gute Beträge Tag für Tag rein.

Welche Faktoren willst du konkret beleuchten?
Natürlich ist das nicht trivial, aber Infrastruktur und Mitarbeiter die sich da drum kümmern im Vergleich zu dadurch entstehende Einnahmen.


Im Bereich Administration bzw. DevOps gibt es zumindest im deutschsprachigen Raum für BSD zu wenig und zu kleine Arbeitgeber (dito Auftraggeber). Das bringt einen ganzen Rattenschwanz an Problemen mit sich, von denen die schlechtere Bezahlung nur eines ist.

Gibt aber im deutsprachigen Raum auch ein paar größere Unternehmen, die auf BSD setzen und zwar mit großer Infrastruktur. Je nach dem was du im Sinn hast.

Bei mir ist es gerade so, dass ich ein paar Sachen mit BSD mache, die laufen halt und dann jeder Hilfe und "DevOps" für die macht-alles-besser-stabiler-einfacher Cloud braucht. Da wird dann im Vergleich zu "läuft einfach" Lösungen sehr gut bezahlt und gibt immer was zu tun. Oft ist das so in die Richtung "toll meine Entwickler können mit Dockerfiles vieles selbst entscheiden" und für Dev-Setups funktioniert das auch gut, aber sobald das dann in Production geht sieht man auch, dass vieles im Ecosystem nicht so production ready ist, wie gerne getan wird. Und ich weiß auch von ein paar größeren die deshalb wirklich wieder wegmigrieren bzw. sich vieles selbst zusammenbauen oder das planen. Das Problem ist einfach, dass die alle paar Jahre oder Monate auf was umgestiegen sind, was angeblich die Kinderkrankheiten von Docker beseitigt und der richtige und die langfristige Lösung ist, aber einfach gemerkt haben, dass das Problem immer nur verschoben wird und man ist dann halt mit eigenen Sachen doch etwas flexibler, als wie wenn man statt mit dem eigentlichen Produkt ständig mit der Infrastrur beschäftigt ist.

Und was viele im Endeffekt wirklich wollen ist, dass es anständige Prozesse gibt, dass sie Infrastruktur schnell aufsetzen können (geht auch mit guten alten Images), dass man das was jetzt als Infrastructure as Code bezeichnet wird, aber einfach nur Automatisierung ist über die man auch drüber schauen kann, das muss nicht das letzte Tool sein, das muss auch nicht so ehacktein paar hinge aus halb-deklarativen Lösungen sein (wie oft habe ich Ansible gesehen, das im Endeffekt einfach dafür sorgt, dass wo ein Shell-Script abläuft) . Ja, es ist gut, dass es sowas wie etcd und consul gibt, sich Leute über Configuration Management Gedanken machen, auch es da gerade die große Ernüchterung gibt, dass es da nicht das einfache Tool gibt, das alle Probleme löst. Das sind die guten Entwicklungen.

Mies ist halt, dass wir Monokulturen bauen, wo es nur noch einen Weg gibt um Sachen zu machen, dass es gefühlt unbedingt eine Art Geschichtsunterricht an Unis braucht, weil vieles neu erfunden wird, was genau so scheitert, wie das um die Jahrtausendwende schon in der Windowswelt gescheitert ist, oft muss ich zugeben aber auch einfach viel wiederholt wird, weil Dinge in der Theorie besser klingen, aber im laufenden Betrieb nur Kopfschmerzen bringen. Da setzt auch Marketingspeech ein. Also, wenn man sagt das ist Serverless und man so tut als wäre da wirklich kein Server und wenn man so tut als wäre Infrastruktur perfekt und fehlerfrei nur weil sie von einem großen Anbieter ist, weil sich der deklarive Ansatz für vieles am Anfang richtig anhört, man aber erst in der Praxis festellt, dass das Problem dass man lösen will doch nicht einfach nur ein Zustand ist, oder weil man mit den ganzen Statless-Sachen vergisst, dass State nicht nur in Datenbanken und Files existiert. Vielleicht als wichtigsten Punkt wird so getan als wären hinter all den Layern an Abstraktion keine Computer und normale Software, Betriebssysteme und Prozesse, wehsalb man nicht alles über Bord werfen sollte was man inden letzten 60 Jahren an codeifizierter Erahrung gewonnen hat.

Oder anders gesagt finde ich es gut, dass sich die Dinge in bestimmte Richtungen bewegen und man endlich begriffen hat, dass man auch Infrastruktur als echten Teil von Projekten sieht und man damit vieles ersparen kann und das auch nicht komplziert sein muss (siehe Dockerfile), aber nur weil man das verstanden hat heißt das nicht, dass zum einen die jetztige Implementierung die beste ist, noch, dass man deshalb alles vergessen und ignorieren muss was davor da war bzw. halt dann oft von Cloud Anbietern zur Verfügung gestellt wird, weil man sonst die Fehler blind wiederholt, man sich also im Kreis dreht, anstatt dass man voranschreitet.

Die interessanten Projekte - sowohl thematisch als auch finanziell - finden momentan häufig auf Basis von Container-Plattformen statt (Docker, Kubernetes etc.), dort ist BSD leider komplett außen vor.

Finanziell am Jobmarkt sind Docker und Kubernetes allemal, spannend naja. Zumindest ich fühl mich manchmal als wäre ich effektiv eine Art Tech-Sales-Person für Google oder Amazon. Es gibt einfach manchmal krass falsche Ansichten. Und es gibt diese Artikel in Managermagazinen wirklich und ein guter Freund von mir ist ein CEO eines Unternehmens. Die machen eine App, die recht gut funktioniert und es gibt halt diese Networking-Events und der hat mir erzählt, dass sich so die Buzzwords, wie "Cloud" mittlerweile wirklich zu so einer Art Statussymbol entwickelt hat. Also wenn man ein DevOps-Team oder mehrere hat, die sich um die Cloud kümmern das an sich schon einges an Prestige bringt (wie eine Yacht herzeigen eben).

Und dann hat man eben so Headlines darüber, wie alle unsichere Dockre Container in riesigen Massen verwenden und ich persönlich immer wieder recht deutlich sehe, dass DevOps mit über 90k Jahreseinkommen sehr wenig Ahnung von Systemen haben bzw. generell was die da machen. Dazu gibt es häufig die Annahme, dass Dinge einfach so sicherwähren, weil halt Cloud oder dass Probleme die man nicht auf den ersten Blick sieht oder wo man nicht sieht wie sie sich zusammenbrauen überhaupt nicht existieren. Man verlässt sich halt blind darauf, dass das was in dem Beispiel im Tutorial alles ist was man wissen und beachten muss, weil bestimmten Themen nach Abstraktionen nicht mehr hervortreten.

Ich hatte übrigens mitterweile das Vergnügen DevOps-Interviews zu machen Da gibt's echt Leute, die kaum basic Shell Commands können (ich rede von so Dingen, wie, dass es top gibt), aber Buzzwords in Sätze packen können ohne Ende. Schlussendlich haben die eine Karriere hinter sich, wo sie halt alle zwei, drei Monate den Job gewechselt haben und immer die Commands aus Tutorials kopiert haben und scheinbar schnell genug weg waren um den Untergang nicht mitansehen zu müssen.

Und nochmal zu den Fehlern. Cloud wird ja korrekt als Teuer angesehen, aber was ich bei meinem letzten Post geschrieben habe meinte ich wirklich so. Ich habe vor zehn Jahren oder so mal die wahre Geschichte gehabt von einem Service wo ohne Neustart wirklich nur einer oder eine Hand voll von Requests funktioniert haben dann crashte es und wurde neu gestartet. Wäre ein trivialer fix gewesen und man hätte ein paar Server weniger gebraucht um die mieße Performance zu kompensieren, wenn ständig alles neu startet. Später habe ich dann genau das Selbe gesehen nur dass das dann zu einem kompletten Niederreißen der VM geführt hat. Das Schöne an der Sache war, dass damit auch jeglicher Ansatzpunkt weshalb der Fehler auftrat mit zerstört wurde. Wenn wir jetzt also weil die Anforderungen wachsen den Umstieg von blind Prozsesse neu starten zu blind Server neu starten haben, was machen wir dann wenn wir der Meinung sind wir brauchen den nächsten Layer an Abstraktion?

Zuguterletzt noch ein anderes Thema, das außenvor geblieben ist. Wenn man sich eingehender mit den Themen beschäftigt warum Unternehmen die Cloud verwenden, dann ist der häufigste Grund eigentlich, dass sie statische Binaries und ein gutes Buildsystem und Deployment wollen. Für gewöhnlich ensteht das Buildsystem und das Deployment im Zuge der Umstellung und statt lediglich ein statisches Binary zu nehmen nimmt man einen ganzen Container. Alles andere was dabei mitgebracht wird ist streng genommen kompletter Overhead, also mehr Ausgaben für die Infrastuktur als solche und mehr Zeitaufwand von Mitarbeitern.

Ich mache wenn ich für BSD was bauen will, was in die Richtung von dem geht, was ich daus der Arbeit mit Linux kenne meist so, dass ich zunächst mit dem Bau beginne aber drauf komme, dass ich eigentlich etwas will was ohnehin schon prima funktioniert. So etwas wie Jail Configs, statt Docker Files oder teils auch ganz andere Sachen. Ab und zu wird aus "wäre cool das unter BSD auch zu haben" ein "ich muss mal was bauen um das unter Linux hinzubekommen".

Natürlich gibt es da Ausnahmen, auch will ich keinesfalls so tun, als gäbe es nicht das Eine oder Andere was man sich abschauen könnte, aber vieles was FreeBSD noch vor ein oder zwei Jahren unbedingt haben musste gilt schon wieder als outdated und "falsch".

Da genieße ich das auch ein wenig als Filter, dass ich garnicht erst in Versuchung komme. Es gibt einfach vieles was mir dadurch privat oder auch für mein eigenes Unternehmen erspart geblieben ist. Und gab ja einige gewaltige Reinfälle. Um Docker Swarm machen die größten Dockerfans mitterlweile einen ziemlichen Bogen, was sicher auch teilweise der Grund für den Aufschwung anderer Tools ist.

Ich hoffe es gibt in der Branche möglichst Bald eine Post-Hype-Phase in diesem Bereich, wo Dinge bis auf dort wo sie Sinn machen zuückgebaut werden und wo man vieles von dem oben genannten aus einem tatsächen Grund, der nicht nur "weil es hipp und modern ist und alle so machen" ist. Ich behaupte mal da schon die ersten Ansätze dafür zu erkennen.

Auch wenn man sicher gut verdienen kann wenn man mit Hypes mitschwimmt wäre es cool wenn der Industriezweig wieder auf den Boden der Tatsachen zurückkehrt und nicht so tut als wäre das ausführen eines Docker Containers die einzig richtige und mögliche Art einen Prozess zu starten oder AWS zu nutzen die einzige Art skalierende Services zu schreiben und um Infrastuktur zu kodifizieren. Es ist ja nicht so als hätte es vor 10 Jahren keine großen Websites gegeben oder als wäre alles städnig down gewesen. Auch bekommt man selbst physische Server für gewöhnlich innerhalb von Minuten.

Sorry, ich bin da etwas abgedriftet, aber wenn man nicht darauf angewiesen ist, dass die Welt BSD nutzt, sondern man es einfach für eigene Sachen oder in einem Unternehmen das es nutzt einen fixen Platz hat, dann ist es manchmal schön an einen Ort zu sein, wo man sich nicht wie ein Versuchskaninchen für Software und Services zu sein, die oft selbst nicht wissen, was sie sein wollen.

Oder vielleicht bin ich der Einzige, der auf simple Lösungen, die man auch vernünftig debuggen kann Wet legt.
 
Mir fehlt gerade ein bisschen der Bezug, was das jetzt alles konkret mit Linux <-> BSD zu tun hat. Sicherlich nicht falsch was du sagst, aber das hat ja nun konkret nichts mit Docker im Speziellen zu tun, oder Linux oder BSD.
Nach deiner Erklärung müsste man auch bhyve und Jails wieder aus FreeBSD entfernen, weil sie prinzipiell ebenso die Dinge ermöglichen, die du jetzt konkret kritisierst. Die sind auch ohne deine "wie vermarkte ich das System am Besten"-Behauptung entstanden.

Ich erkenne hier halt nichts, was die BSDs hier konzeptionell besser machen, außer, dass in der Praxis kaum jemand BSD benutzt und somit es auch prinzipiell weniger schlechte Beispiele gibt.
 
Ja, du hast recht. Sorry.

Mir ging's eigentlich ursprünglich um die Herangehensweise. Das liegt aber jetzt nicht am Technischen, sondern daran, dass die BSDs derzeit nicht wirklich von einem Unternehmen dominiert werden.

Zum Vergleich: In der Linuxwelt gibt es Ubuntu, das eigentlich alles dominiert (mit CentOS/RedHat knapp dahinter), aber in der Dockerwelt ist zum Beispiel Apline weit verbreitet, weil es simpel, leicht und gut strukturiert ist. Das ist ein Projekt was nicht, wie Ubuntu von einem Unternehmen dominiert wird das damit in weiterer Folge Geld machen will.

Bei den BSDs hast du bei FreeBSD viele Unternehmen, darunter auch sehr kleine, neben ein paar Großen (wenn man sich die Zusammenstellung der Sponsored By bei Commits und die Donations ansieht).

Bei NetBSD, DragonFly und OpenBSD hast du quasi niemanden dahinter.

Zum Vergleich kannst du auch die Reaktionen ansehen, wenn jemand fragt "Warum sollte ich X nutzen?". Da gibt's halt bei manchen Linux-Distributionen einen regelrechten Werbevortrag.

Und auch wenn das kein technischer Vorteil ist, hat es doch Auswirkungen auf die professionelle Nutzung, weil einfach gesagt wird was Mist ist.

Das hat man unter Linux halt nur wenn man da wirklich nur den Kernel nimmt und in Communities die eher Randgruppen-Erscheinungen sind.

Und deshalb bin ich da ein wenig (viel :o) auf Cloud und Co. abgeschweift. Die Frage nach der Sinnhaftigkeit wird häufig übersprungen oder mit "weil es modern ist" oder "weil es alle machen" - wobei das ehrlich gesagt auch ein wenig übertrieben dargestellt wird. Ja, wenn du dir Jobs die bei über 80k im Jahr beginnen ansiehst, dann wird du Ubuntu, CentOS, Cloud, etc. sehen. Wenn du dir aber Unternehmen ansiehst, die einfach nur groß und erfolgreich sind relativiert sich das schon wieder. Und da hat meine Behauptung angesetzt, dass das Einkommen pro sagen wir mal IT Ressource (Ausgaben für technische Infrastruktur und technische Mitarbeiter) womöglich unter den BSDs sogar auf einem höherem Niveau ist.

Du hast in dem ganzen Sektor auch einfach viel Hype. Dadurch ergibt sich auch abstruse Bezahlung für Linux-Jobs, was natürlich auf Kosten geht, aber so zu tun, als wäre BSD (derzeit) komplett abgehängt, oder als wäre es Absurd da ein Unternehmen drauf auzubauen ist auch Unsinn. Gibt auch verhältnismäßig junge Unternehmen (Trivago, WhatsApp, ...) die da erfolgreich drauf setzen. Groß und klein und nicht nur in Bereichen wo GPL ein Problem wäre.

Es gibt auch genug Leute, die da nicht wirklich aus Überzeugung mit den Tools arbeiten. Wenn man von so Startup-Events und Konferenzen wo sich häufig eher Junior-Leute rumtreiben dann trifft man doch einige Leute, die auch offen erzählen, dass sie wissen dass sie eigentlich Unfug machen, aber das eben das ist was die Firma/der Jobmarkt will und nicht jeder hat Lust deshalb ein eigenes Projekt zu starten. Macht auch keinen Sinn. Ob ein Unternehmen erfolgreich ist hängt meist recht wenig von der IT ab, selbst in der Tech-Startup-Szene und auch wenn deine Kunden eher technischer Natur sind spielen da häufig andere Faktoren die größere Rolle. Außerdem - man mag es kaum glauben - sind manche ganz gerne Angestellte.

Ich würde also sagen, dass man mit Linux eindeutig besser verdient gerade, man da aber auf Grund von Hypes und schaffen von großer Komplexität in vielen Bereichen häufig mit BSDs oder Linux, das auf Simplizität setzt meiner Meinung nach besser fährt.

Auch machen hybride Ansätze mitunter Sinn. Ich verwende gerne FreeBSD wenn ich was stabiles mit aktueller Software brauche. Da sieht's in der Linuxwelt echt mager aus. Du hast die Wahl zwischen kompletter Instabilität oder CentOS/Ubuntu/Debian mit Software, die schon ein paar Jahre auf dem Rücken hat, wenn du den Standard-Package-Manger verwendest und nicht selbst installieren oder Third Party Repos verwenden willst. Außerdem gibt's glaube ich keine Linux-Distribution mit so vielen (funktionierenden) Packages. Oh und dass nicht alles mit Patches die vom Software-Author nicht vorgesehen übersät ist ist mitunter auch ein Vorteil.

Und ganz triest sieht's in der Linuxwelt aus, wenn ich dann noch eine aktuelle Version einer Software mit einer aktuellen Abhängigkeit will. Da gibt's dann halt Docker, Snaps und Co. als Hacks. Viel Spaß, wenn es dann ein paar komplexere Fälle gibt. Dann kann schon ein ganzes Team daran arbeiten einen grausigen Hack, der mit dem nächsten Update in die Luft fliegt zu bauen.

Ich sage nicht, dass das mit den BSDs ausgeschlossen ist, aber das ist für mich einer der größten Gründe ein BSD zu nutzen, wo das eher seltener der Fall ist.

Auch wenn ständig über's Package Managemnt geflucht wird, sehe ich das als zumindest einen der größten Vorteile derzeit und in ca. den letzen 10 Jahren. Das einzige Mal wo's da ein wenig rauher war war 9.1. Ich glaube da war die Umstellung auf pkgng. Und ich glaube da gab's auch ein Infrasturktur-Problem oder so. Das war auch mitten in einer größeren Umstellung von Linux auf BSD in einem Unternehmen, indem ich damals gearbeitet habe und trotzdem war das Erfolg genug, dass dann entschieden wurde auch andere Systeme umzustellen. Aber ich drifte wieder ab.


tl;dr: Package Management, Simplizität, Aktualität gepaart mit Stabilität sind Vorteile die man zumindest bei den großen/weiter verbreiteten Linux Distributionen kaum bekommt. Frage mich da schon länger was da der Grund dafür ist. Das hat ja nicht viel mit dem Kernel zu tun, höchstens mit dem Basis-System und dessen Trennung, aber so etwas wie "core packages" gibt es ja auch in der Linuxwelt, wenn auch nicht so stark.
 
Bei den BSDs hast du bei FreeBSD viele Unternehmen, darunter auch sehr kleine, neben ein paar Großen (wenn man sich die Zusammenstellung der Sponsored By bei Commits und die Donations ansieht).

Es gibt aber auch genügend FreeBSD-Distributionen, sofern das jetzt das Argument war. Würde sogar so weit gehen zu sagen, dass mehr Privat-Leute FreeBSD in Form von FreeNAS und Co. laufen haben, als FreeBSD selbst.

Du hast die Wahl zwischen kompletter Instabilität oder CentOS/Ubuntu/Debian mit Software, die schon ein paar Jahre auf dem Rücken hat
[...]
Und ganz triest sieht's in der Linuxwelt aus, wenn ich dann noch eine aktuelle Version einer Software mit einer aktuellen Abhängigkeit will.

Auf der einen Seite ist es "komplette Instabilität", auf der anderen Seite ist aktuelle Software mit aktuellen Abhängigkeiten aber wieder OK? :D
Auch wenn immer wieder was anderes behauptet wird: Ein Gentoo/ArchLinux mit linux-lts als Kernel ist von FreeBSD nicht allzu weit entfernt was Software-Stabilität angeht. Das Bisschen was FreeBSD "feature-freezed" ist im Vergleich zu den Ports kaum der Rede wert. Quarterly Pakete in FreeBSD sind auch mehr ein Workaround, weil Ports gerne mal kaputt gehen und man dann lieber irgendwas anbieten möchte, als in dem Moment gar nichts. Deswegen fährt auch kaum eine Linux-Distribution so eine harte Core / Packages Teilung, weil sie praktisch kaum Vorteile bringt.

Da gibt's dann halt Docker, Snaps und Co. als Hacks.

Snaps und Co. sind auch nicht mehr Hack als die Installation eines Dienstes in einer FreeBSD Jail. Niemand zwingt dich dazu, es ist aber trotzdem eine gute Idee es zu tun.

Dinge wie Snaps, Flatpak und Co. entstehen nicht, weil das Linux Paketmanagement kaputt ist, oder die Distributionen entgegen der Entwickler handeln. Diese Dinge entstehen, weil es als Entwickler schwer ist, eine von mir getestete Version an den Nutzer zu bringen. Das ist unter FreeBSD nicht anders. Nebenbei gibt's noch eine Tonne andere Gründe, wie z.B. Sicherheit und einfachere "per-app" Rollbacks.

Ich würde Dinge nicht verfrüht als "Hype" abtun, sondern einmal genau betrachten welche Probleme eigentlich genau gelöst werden sollen. Viele dieser Probleme hat FreeBSD genauso und letztendlich kommt hier FreeBSD dann auch auf ähnliche Lösungen. Und mit Clouds hat das alles eher weniger zu tun.

Und außerdem: Es wird immer wieder kritisiert, dass es unter Linux so viel Wildwuchs und wenig Einheitlichkeit gibt, aber auf der anderen Seite werden entsprechende Vereinheitlichungen immer wieder als eine Art Monopol verunglimpft. Irgendwann muss man sich halt mal klar werden, was man kritisieren möchte.
 
Und außerdem: Es wird immer wieder kritisiert, dass es unter Linux so viel Wildwuchs und wenig Einheitlichkeit gibt, aber auf der anderen Seite werden entsprechende Vereinheitlichungen immer wieder als eine Art Monopol verunglimpft. Irgendwann muss man sich halt mal klar werden, was man kritisieren möchte.

Hallo @-Nuke-

vorab: Ich kann nur aus der Perspektive eines Privatnutzers sprechen - was im kommerziellen Bereich und dem Einsatz von Linux/BSD/Unix angeht, davon habe ich keine Ahnung, finde es aber sehr spannend, Beiträge von Leuten zu lesen, die damit beruflich zu tun haben.

Was nun den Wildwuchs angeht: Warum kocht z.B. jede Distribution ihr eigenes Süppchen, um den vollen Hostnamen der Maschine fest zu legen? Bei PCLOS habe ich heraus gefunden, dass man in /etc/sysconfig/network was ändern muss, unter Debian ist es /etc/networking, unter OpenSUSE ist es wieder wo anders? Das nervt einfach. Das ach so tolle systemd wurde einem gerne mit drastisch verkürzten Bootzeiten schmackhaft gemacht: Aber warum schafft es ein kleines Entwicklerteam um Texstar, was zudem auf das olle Initsystem SysV setzt, das PCLOS in drei Sekunden durchbootet, während man beim tollen systemd unter OpenSUSE (die nun systemd von Anfang an sehr gut im Griff hatten und auch haben) mittlerweile fast einer Minute warten darf?
Ich glaube, die Kritik im Hinblick auf Monopolismus geht bei Linux gar nicht in die Richtung, dass etwas distributionsübergreifend vereinheitlicht wird - es wäre zum Teil sogar schön (siehe mein Beispiel mit dem Hostnamen), sondern eher dahin, dass andere OSS Systeme verdrängt werden. Nun kann man natürlich auch den Entwicklern rund um FreeBSD daran eine Mitschuld geben - aber mal ernsthaft: Es setzt sich nicht immer das technisch bessere System durch (VHS ist ein gutes Beispiel dafür).
Und nur weil etwas im kommerziellen Umfeld hipp ist, heißt das noch lange nicht, dass es dafür irgendwelche rationalen Gründe geben muss.
 
Warum kocht z.B. jede Distribution ihr eigenes Süppchen, um den vollen Hostnamen der Maschine fest zu legen?
Weil sie verschiedene Lösungen nutzen, um den FQDN festzulegen.

Und dass PCLinuxOS schneller bootet als OpenSUSE hat sicher auch andere Gründe als der genutzte Init-Prozess. Wenn du hier einen Vergleich ziehen möchtest, solltest du die gleiche Distribution mit der gleichen Konfiguration verwenden.
 
Hallo,

folgendes mag wie ein Rant klingen, es ist aber nicht so gemeint ... und ich gebe zu, auch noch etwas genervt zu sein von PCLOS, was sich bisher standhaft weigert, einen neuen Hostnamen auf meiner Testinstallation anzunehmen ...
holgerw hat gesagt.:

Warum kocht z.B. jede Distribution ihr eigenes Süppchen, um den vollen Hostnamen der Maschine fest zu legen?
Weil sie verschiedene Lösungen nutzen, um den FQDN festzulegen.
Du beantwortest meine Frage "Warum kocht z.B. jede Distribution ihr eigenes Süppchen, um den vollen Hostnamen der Maschine fest zu legen?", was ja reformuliert nix anderes heißt wie "Warum nutzen Distributionen verschiedene Ansätze, um den Hostnamen festzulegen" mit einem "Weil sie verschiedene Lösungen nutzen". Hmmm ....

Folgendes ist für mich wirklich übelster Wildwuchs, der mit richtiger Vielfalt wohl kaum etwas zu tun hat, ich bitte das kleine kurze Vorgeschichten-OffTopic zu entschuldigen:

Ich hatte ja eigentlich mit dem ansonsten sehr performanten PCLOS vor, das mal auf unserem HTPC-System mit Intel Gemini Lake zu probieren, es ist im Gegensatz zu Devuan dort nämlich schon kodi 18 und auch der neueste Kernel 5.0.7 zu haben, der nochmal deutliche Verbesserungen verspricht, was Performance auch in Sachen GPUs angeht. Ich habe es auf einer zweiten SSD neben FreeBSD testweise installiert. Aber es ist mir nach zig Anläufen immer noch nicht gelungen, den Rechnernamen von localhost auf meinen Wunschnamen zu ändern.
Bei der Recherche dazu gibt es diverse Angebote zu diversen Distributionen - achso und PCLOS ist ein Derviat von Mandrake, was ein Derivat von Redhat ist aber Slackware hat da auch noch was mit zu tun - um den Hostnamen zu ändern:

/etc/HOSTNAME
/etc/hostname
/etc/hosts
/etc/sysconfig/network ... oder was hätten's denn gerne??? :)

Oder vielleicht in mehreren Dateien gleichzeitig den Namen ändern?

Nichts fruchtet, und nach jedem Neustart grinst mich am Prompt das localhost an. Davon abgesehen, dass es eventuell ein Bug bei PCLOS ist: Das sind dann die verschiedenen Lösungen verschiedener Distributionen und deren verschiedener Derivate ... für was noch gleich? Für die Banalität, einer Maschine permanent einen Namen zu verpassen. :)

Und dass PCLinuxOS schneller bootet als OpenSUSE hat sicher auch andere Gründe als der genutzte Init-Prozess. Wenn du hier einen Vergleich ziehen möchtest, solltest du die gleiche Distribution mit der gleichen Konfiguration verwenden.
Mit einem aktuellen Debian samt systemd und einem sehr schlanken Desktopsystem, was an das PCLOS mit lxde nahe heran kommt, bekomme ich auch deutlich längere Bootzeiten hin. Und bei beiden werden Sachen wie cupsd, sshd und weiteres während des Bootens aktiviert. Allerdings kann bei Debian hinzu kommen, dass da "Running Start/Stop jobs" noch herum nerven und den Boot bzw. Shutdown u.U. um 3 Minuten verzögern können.

Mir persönlich ist eine längere Bootzeit eh wurscht, wäre mir die sehr wichtig, hätte ich kein FreeBSD auf verschiedenen Maschinen bei uns zu Hause.

Aber das sollte auch lediglich ein Beispiel dafür sein, dass um verschiedene IT-Bereiche auch viel Marketing (was für mich ein Synonym dafür ist, Dingen Sachen zuzuschreiben, die sie gar nicht haben) eine Rolle spielt und gleichzeitig werden andere Sachen schlecht geredet. Noch zu den Zeiten, als ich kein fbsd kannte und nur Linux nutzte, wurde gerade mit dem schnelleren Booten massivst geworben seitens der Fans von systemd, das ging einher mit diversen theoretischen Erläuterungen rund um den Bootprozess .... und die Ernüchterung kommt dann, wenn man z.B. ein Linuxexoten wie Void mit runit oder wie gesagt ein aktuelles PCLOS mit dem alten init startet (natürlich tut man den Entwicklern von systemd unrecht, die Vorzüge, die dieses Initsystem sicherlich auch hat, nur auf Bootzeiten zu reduzieren). Aber der Konzern RH will Init-System B haben und letztendlich hat dann jedes Linux init-B zu haben, auch nicht-kommerzielle Distributionen wie Debian, um die Fans gerne noch ein wenig basisdemokratische Folklore machen, machen das nach, was ein Konzern vorgibt, wollen sie nicht in die Exotennische gedrängt werden. Und Gründe für solche Entscheidungen wie für so Manches im kommerziellen Umfeld sind eine Mischung aus Technik, guter Werbung, Marketing (also schlechter Werbung), irrationalem Hype, marktradikaler Ideologie und weitere Nettigkeiten, die mit den Sachen oft nur noch am Rande zu tun haben.

Und nebenbei bemerkt: Ich nutze privat beide Systeme und mag beide überhaupt nicht gegeneinander ausspielen - und wünsche gerade dem GNU/Linux, dass seine Entwicklungen nicht zu sehr zwischen die Räder von oben skizzierten nicht sachbezogenen Aspekten geraten und es letztendlich dadurch entgegen den ursprünglichen Intentionen seiner Entwickler kaputt gemacht wird.

Bei FreeBSD hingegen sehe ich da keine große Gefahr.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben