Magst du ein paar Beispiele nennen?
Interesse an FreeBSD rückläufig? Schwächen und Stärken von FreeBSD.
- Ersteller satriani
- Erstellt am
bsd4me
Well-Known Member
Gute Frage. Es hätte mich sehr gefreut, wenn mehr Leute ihre Erfahrungen und Beobachtungen aus der professionellen IT beigesteuert hätten. Es macht aber schon stutzig, dass hier im Forum keiner eine BSD-Positivmeldung aus dem eigenen Umfeld beisteuern konnte.
so ganz stimmt das nicht, ich habe hier am Lehrstuhl etliche BSD Server laufen. Sie tun es seit Jahren sehr gut. Nur manchmal fehlen ein paar Linux spezifische Sachen. Trotzdem: ich arbeite gerne mit BSD, kann es vergleichen mit Linux. Der Unterscheid ist zwischen BMW und Mercedes - beide fahren schnell
Naja, ich finde BSD wesentlich einfacher zu handhaben. Und ich werde es nicht so schnell aufgeben. Auch wenn viele mich nicht verstehen - aber so ist das im Bioinformatik Bereich: oft quick and dirty... Aber setze mal einen Linux Server und einen BSD Server auf. Bei Linux hatte ich auf einem Supermicro Server es vor etwa 2 Jahren aufgegben 18.04 zu installieren, bin bei 16.04 hängengeblieben. Vorher lief FreeBSD ohne Probleme drauf... Ich musste es tun, weil Chef das so wollte. BSD = Besonders Super Designed ;-) VG, NorbertInnovation mit Augenmaß. Linux hat vorgelegt; jetzt kann man aus dem Linux-Wildwuchs und dessen Erfahrungen lernen. Die Vorteile von FreeBSD nutzen und perfekt integrierte Software bereitstellen, die alles unter Linux existierende in den Schatten stellt, weil man aus 5 unterschiedlichen Linux-Implementierungen lernen konnte und sie aus einer Hand liefern kann.
Auf dem Desktop eine massentaugliche Desktop-Lösung so gut unterstützen und integrieren, dass Linux mit systemd/Wayland/Gnome blass wird vor Neid.
Für Entwickler: sicherstellen, dass jedes populäre Entwickler-Tool jederzeit problemlos auf FreeBSD läuft. Den FreeBSD-Code endlich auf ein modernes Versionsverwaltungssystem umstellen und Subversion aufs Altenteil schicken.
Im Bereich Container: Jails so nahtlos und komfortabel ins Basissystem einfügen, dass Docker unter Linux im Vergleich dazu an Frankenstein erinnert. Dafür sorgen, dass Kubernetes diese Lösung betreiben kann.
Im Server-Bereich: bhyve zur Produktionsreife bringen. Ein simples Automatisierungstool wie Ansible so gut unterstützen, dass der FreeBSD-Support die Referenzimplementierung wird. Mehr Bereitschaft, bei Major-Releases Altlasten aus dem Basissystem zu entfernen und durch moderne Alternativen zu ersetzen (ich sage nur NTP).
turrican
Well-Known Member
@Azazyel - da gebe ich dir recht;
... und vor allem: Spiele! Spiele, Spiele, Spiele!
Die Verfügbarkeit einer OS Plattform als Spieleplattform bringt ein OS unheimlich voran, wie wir am Beispiel Windows gut sehen können... so gut wie jeder schimpfte über Windows - aber so gut wie jeder hatte es zum zocken daheim... Teilweise musste ich damals mit meinen entzündeten Admin-Augen in den 2000er Jahren auch auf etlichen Firmen-Laptops mitansehen, dass gezockt wurde; gut, wer möchte es den Road-Warriors abends im Hotel verwehren; 2 Laptops mitschleppen ist halt doof (und Sales darf sich eh alles erlauben, die bringen ja das Geld in die Firma, die IT gibts ja nur aus, wer will da so doofe Regeln von IT einhalten ...)
Noch besser wäre, wenn sich BSD als "Plattform für alles" empfehlen könnte - du willst Docker? Installier den Docker-ulator; Du willst das Windows-Dev-Tool laufen lassen? Installier den Win-ulator, und dann deine IDE... usw usf.
Allen gemein sollte sein, dass BSD als Unterbau läuft, und die DevOps munter ihre Docker-Container laufen lassen können, die Devs die Compiler/IDEs usw, die Sekretärinnen den Bürokram; dann wären wir da, wo BSD alle glücklich macht...
da fallen mir spontan 3 Dinge auf: Lehrstuhl, Server, es fehlen Linux-spezifische Sachen
Lehrstuhl:
In der Industrie hat man (meist) strikte Vorgaben in Bezug auf was auf Servern installiert wird, BSD ist meist nicht darunter (außer, man arbeitet grade bei Netflix, oder der Firmen-Boss bzw der CTO ist selber Nerd und hält viel von BSD, ich hab von beiden Typen noch keinen solchen getroffen);
Akademische Einrichtungen sind hier freier in der Auswahl - was dann ggf wieder zu lustigem Wildwuchs oder Support-Problemen führt, aber das ist eine andere Geschichte;
Server:
Genau, Server - aber nicht Desktop; warum ist das so? Fehlt BSD was für den jeweiligen Einsatzzweck auf dem Desktop?
Linux-spezifische Sachen:
Siehe die Frage bei Server oben?
... und vor allem: Spiele! Spiele, Spiele, Spiele!
Die Verfügbarkeit einer OS Plattform als Spieleplattform bringt ein OS unheimlich voran, wie wir am Beispiel Windows gut sehen können... so gut wie jeder schimpfte über Windows - aber so gut wie jeder hatte es zum zocken daheim... Teilweise musste ich damals mit meinen entzündeten Admin-Augen in den 2000er Jahren auch auf etlichen Firmen-Laptops mitansehen, dass gezockt wurde; gut, wer möchte es den Road-Warriors abends im Hotel verwehren; 2 Laptops mitschleppen ist halt doof (und Sales darf sich eh alles erlauben, die bringen ja das Geld in die Firma, die IT gibts ja nur aus, wer will da so doofe Regeln von IT einhalten ...)
Noch besser wäre, wenn sich BSD als "Plattform für alles" empfehlen könnte - du willst Docker? Installier den Docker-ulator; Du willst das Windows-Dev-Tool laufen lassen? Installier den Win-ulator, und dann deine IDE... usw usf.
Allen gemein sollte sein, dass BSD als Unterbau läuft, und die DevOps munter ihre Docker-Container laufen lassen können, die Devs die Compiler/IDEs usw, die Sekretärinnen den Bürokram; dann wären wir da, wo BSD alle glücklich macht...
da fallen mir spontan 3 Dinge auf: Lehrstuhl, Server, es fehlen Linux-spezifische Sachen
Lehrstuhl:
In der Industrie hat man (meist) strikte Vorgaben in Bezug auf was auf Servern installiert wird, BSD ist meist nicht darunter (außer, man arbeitet grade bei Netflix, oder der Firmen-Boss bzw der CTO ist selber Nerd und hält viel von BSD, ich hab von beiden Typen noch keinen solchen getroffen);
Akademische Einrichtungen sind hier freier in der Auswahl - was dann ggf wieder zu lustigem Wildwuchs oder Support-Problemen führt, aber das ist eine andere Geschichte;
Server:
Genau, Server - aber nicht Desktop; warum ist das so? Fehlt BSD was für den jeweiligen Einsatzzweck auf dem Desktop?
Linux-spezifische Sachen:
Siehe die Frage bei Server oben?
Idefixx
Well-Known Member
Läuft wie vorausgesehen. Eigentlich läuft der ix-Krempel total supi, aber die ganzen Dumpfbacken da draußen, wo immer draußen sein möge, die verstehen das alles nicht.
Na ja, da mag das ein oder andere nicht so laufen wie unter dem propidingsbums System, aber dafür ist man ja frei. Frei stundenlang und tagelang zu basteln was der tumbe MS-Blödel in fünf Minuten hin bekommt. Aber, daß ist ja auch nur ein Dödel, der versteht einfach nicht die moralische Komponente in diesem System. Dödel, DAU, eben!
Die IT-Elite!
Na ja, da mag das ein oder andere nicht so laufen wie unter dem propidingsbums System, aber dafür ist man ja frei. Frei stundenlang und tagelang zu basteln was der tumbe MS-Blödel in fünf Minuten hin bekommt. Aber, daß ist ja auch nur ein Dödel, der versteht einfach nicht die moralische Komponente in diesem System. Dödel, DAU, eben!
Die IT-Elite!
So problemlos geht das wohl nicht. Hast du das schon mal gemacht? Muss ich das Flatpak erst auf den Rechner installieren oder mir ein Repo anlegen?
Falls du das schon mal gemacht hast kannst du mir ja vielleicht helfen und anhand vom Beispiel https://flathub.org/apps/details/net.scribus.Scribus sagen, wie ich daraus ein Offline-Paket mache.
Falls du das schon mal gemacht hast kannst du mir ja vielleicht helfen und anhand vom Beispiel https://flathub.org/apps/details/net.scribus.Scribus sagen, wie ich daraus ein Offline-Paket mache.
Für eine einzelne Applikation ist build-bundle am einfachsten:
Code:
flatpak install net.scribus.Scribus
flatpak build-bundle /var/lib/flatpak/repo /tmp/scribus.flatpak net.scribus.Scribus
flatpak uninstall net.scribus.Scribus
flatpak uninstall --unused # wer noch aufräumen willflatpak install /tmp/scribus.flatpakFalls man einen kompletten Offline-Mirror für viele Pakete erstellen möchte, lohnt sich die etwas kompliziertere Variante mit create-usb, bei der die Anleitung gemäß https://unix.stackexchange.com/a/541583 bei mir unter Arch Linux problemlos funktioniert hat.
Den dort erwähnten Schritt für
https://flathub.org/repo/flathub.flatpakrepo musste ich nicht extra ausführen, weil das Repo auf allen bei mir vorhandenen Desktop-Distributionen (Arch Linux, Fedora, Ubuntu) schon passend voreingestellt war - das sind aber auch alles neueste Versionen. Falls der Offline-Rechner nicht in Laufreichweite steht und nicht mehr ganz taufrisch ist, würde ich die Datei sicherheitshalber mal mitnehmen - für den Fall der Fälle.
Zuletzt bearbeitet:
turrican
Well-Known Member
Was wären - um auf den Thread-Titel einzugehen - somit im Jahr 2020 die Stärken von FreeBSD?
Wenn man die Thread-Beiträge so liest, müsste man als neutraler Außenstehender FreeBSD gegenüber fast annehmen, FreeBSD könnte nicht mehr punkten, gegenüber einem Linux - was z.B. Docker kann und Docker doch jetzt der heiße Scheiss ist, usw usf?
Wenn man die Thread-Beiträge so liest, müsste man als neutraler Außenstehender FreeBSD gegenüber fast annehmen, FreeBSD könnte nicht mehr punkten, gegenüber einem Linux - was z.B. Docker kann und Docker doch jetzt der heiße Scheiss ist, usw usf?
Andy_m4
Well-Known Member
Sockets werden ja an IP-Adressen gebunden. Würdest Du beide auf 1.2.3.4:8080 binden würde es nicht funktionieren. Bei einem Conntect wüsste das System ja gar nicht, zu welchen Prozess es "connecten" soll.
Du brauchst also zwei IP-Adressen.
Das ist übrigens bei "Container-Technologie" nicht anders.
Dein praktisches Problem hier ist vermutlich eher: Du willst dem Prozess nicht explizit sagen müssen, das er 1.2.3.4 nutzen soll, sondern er soll sich einfach an die IP-Adresse binden, die er "sieht" oder die im zugeordnet ist.
Salopp gesagt: das in der Konfig der beiden Anwendungen nur
listen *.8080steht und trotzdem Prozess A auf 1.2.3.4:8080 lauscht und Prozess B auf 1.2.3.5:8080
Kann man z.B. unter Linux machen mit Network Namespaces (was anderes macht Docker & Co letztlich auch nicht). Der Jails-Mechanismus unter FreeBSD bietet ja was ähnliches.
Du beschreibst genau das Problem, von dem ich die ganze Zeit schreibe. Eine Anwendung hat halt möglichst nicht in ein globales Verzeichnis zu schreiben. Leider machen das viele.
Und jetzt kommen wir zu dem Punkt, über den ich schon mehrmals schrieb:
Statt jetzt das Programm mal gerade zu ziehen, machen wir ein Container drum herum. Um die freidrehende Anwendung unter Kontrolle zu kriegen.
Ganz großes Kino.
Richtig wäre es natürlich, wenn die Anwendung eben nicht in globale Verzeichnisse schreiben würde. Sondern in ihr eigenes. So ein bisschen kennt man das ja auch von typischen Desktop-Anwendungen wie Browser. Die packen ihren Cache standmäßig ja auch nicht nach /tmp/ oder /var/tmp/, sondern in das Homeverzeichnis des ausführenden Nutzers.
Sag das nicht mir, sondern meinem Vorredner. Der hat ja behauptet, Docker sei für Microservices gedacht.
Wo Du grad wieder Praxis erwähnst. Hier auch noch mal ein wunderschönes Beispiel, wie "toll" der Einsatz von Docker in der Praxis "funktioniert":
https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/
So läuft das nämlich dann in der Praxis. Die Leute laden sich Docker-Images weil sie damit ja gleich losstarten können. Und da stellt sich raus, die sind "ab Werk" schon alle voller Security-Bugs.
Die Leute, die blind solche Images einsetzen ohne sie zu fixen werden dann sicherlich auch mit der gleichen "Sorgfalt" ihre Anwendung pflegen, die sie drauf packen.
Was ich immer wieder geschrieben hab. Die Leute benutzen kaputte Anwendungen und um das dann doch noch irgendwie hinzubiegen, werden dann Container benutzt.
Ähm ja. Es ist eine Lösung. Aber natürlich alles andere als eine gute Lösung. Genau das, was ich oben schon schrieb. Danke für Deine Bestätigungen.
Das sind alles Dinge, die ich unter Automatisierung sehen würde. Und dagegen hab ich nie was gesagt. Siehe meine alten Beiträge.
Das Problem ist: Docker macht ja nicht nur Automatisierung. Sonst wäre ja alles gut. Aber Docker macht noch mehr.
Plus die Tatsache das die Leute offenbar mit Docker nicht umgehen können.
Letztlich löst damit Docker keines Deiner Probleme wirklich. Hier und da gibt es ja sinnvolle Anwendungsfälle wo das total gut ist. Und man kann sicher auch das ein oder andere Problem Workaround-mäßig in den Griff kriegen als schnelle pragmatische Lösung. In vielen Fällen ist es aber keine Lösung, sondern lediglich die Übertünchung von schlechtem Software-Design. Am Ende hast Du Deine Probleme potentiell noch und eine Menge Komplexität oben drauf, weil jetzt noch Docker und Co mit laufen muss.
Du willst unbedingt ne Linux vs. FreeBSD Geschichte draus machen. :-)
Mir gehts primär um Kritik um den Ist-Zustand. Übrigens: Der Ist-Zustand ist auch bei FreeBSD nicht wirklich gut.
Anyway. Da Du so darauf drängst, werde ich dazu auch ein paar Worte verlieren. :-)
Ich muss vorneweg sagen, das ich relativ wenig Erfahrungen mit höherleveligen Toools a-la Bastille, iocage, ezjail, cbsd und wie sie alle heißen habe. Ich nehme im Umgang mit Jails im Wesentlichen die jail-Kommandos die bei FreeBSD halt mit dabei sind.
Und ja, ich nutze auch die Vorteile von Automation und hab mir dafür auch kleinere Tools geschrieben.
Aus meiner Sicht spricht nichts dagegen die von Dir beschriebenen Aufgaben auch mit Jails umzusetzen. Klar. Man wird (wie ich) sich ein paar Sachen basteln müssen, um den Komfort zu kriegen. Aber das lässt sich meines Erachtens mit überschaubaren Aufwand realisieren. Und wenn eine Firma sogar bereit ist VIEL Geld in die Hand zu nehmen, sollten Sie da nicht auf ernsthafte Probleme treffen. Einige Sachen bekommen sie auch schon durch vorhandene Projekte gelöst. Da könnte man ansetzen.
Daher bin ich jetzt etwas unsicher, warum die Firmen das nicht einfach machen. Vielleicht wollen die ja eher doch Docker auf FreeBSD, so dass sie gleich auf vorhandene Ressourcen (fertige Images, Tools die ihrerseits auf Docker aufsetzen, Cloud-Anbieter etc.) zugreifen können.
Danach sollten wir wohl nicht Linux, sondern Windows machen.
Gut, das wir das mal geklärt haben. :-)
Naja. Ein typisches Beispiel von "wir haben von anderen gelernt" wäre bhyve.
Von anderen gelernt heißt aber auch, man hat später angefangen. Und dann beschwerst Du Dich ja, warum man noch nicht so weit ist wie alle anderen.
Ja. Im Desktop-Bereich ließe sich sicher mehr tun.
Das wäre eigentlich Aufgabe der Entwickler der Tools. Ich verstehe ja auch nicht, warum es heutzutage noch immer noch ein Problem zu sein scheint seine Software plattformübergreifend zu entwickeln.
Dem Problem wird sich übrigens auch im Prinzip angenommen. Nämlich mit dem Ports-System. Das soll ja gerade dafür sorgen, das sich Software nach FreeBSD portieren lässt (daher ja auch der Name Ports).
Subversion ist per se ja kein schlechtes Versionskontrollsystem. Die Problematik liegt eher darin, das die meisten GIT sprechen. Daher wird GIT nicht mehr unbedingt nur dann eingesetzt, wenn es sich gut eignet, sondern eben weil die halbe Welt GIT einsetzt.
Oder welchen Grund sollte es denn noch geben von Subversion wegzukommen?
Mag in dem Fall sogar sinnvoll sein. Aber über innovativ vs. konservativ lässt sich natürlich trefflich streiten. Beides hat seine Vor- und Nachteile.
Zum speziellen Fall NTP: Ist ja nun nicht so, das es extrem schwierig ist ntpd aus FreeBSD rauszuwerfen und stattdessen z.B: chrony einzusetzen.
Ob man das jetzt auch per default im Basissystem macht finde ich jetzt nicht sonderlich kriegsentscheidend.
Man passt eh Vieles im System an. Und wenn man das multipliziert braucht, übernimmt man es halt auf seine übrigen System-Instanzen.
Ansonsten ist bei solchen Dingen, die man verbessern müsste auch immer die Frage: Wer soll es machen?
Es kommt immer etwas unglücklich rüber wenn man Sachen quasi fordert aber selbst den Hintern nicht hoch bekommt auch mal was zu machen.
Open Source lebt nun mal vom mitmachen. Sonst kann man genauso gut auch ein proprietäres System nehmen. Da muss man auch mit leben was der Hersteller vorsieht.
Solange alle nur jammern, wie schlimm es angeblich ist, ist letztlich niemanden geholfen.
Also weniger lamentieren. Mehr machen.
Da würde ich als Admin aber auch doof gucken, wenn irgendwer auf dem Firmenlaptop (womöglich noch mit Firmendaten) ein eh schon beliebtes Angriffsziel wie Windows durch irgendwelche Spiele (die ja gern auch nen eklig systemeingreifenden Kopierschutz hatten/haben und damit weitere Probleme/Sicherheitslöcher schaffen) eingesaut werden.
Sorry, aber genau solche Leute verursachen viele IT-Probleme.
Solche Leute würden von mir was auf die Finger kriegen.
Ja. Mega-anstregend.
Was wird so ein Business-Laptop wiegen? Nicht wirklich mehr als 2kg. Zwei davon sind quasi gar nicht zu bewältigen. *Augenroll*
Gibts doch. In Form von WINE.
Die sollten doch allgemein bekannt sein. :-)
Ich kann Dir aber trotzdem sagen, wo ich die Vorteile sehe.
- Dokumentation. Die ist bei FreeBSD wirklich gut im Vergleich zu .... na sagen wir mal Linux (im Sinne vom Linux-Umfeld). Auch wenn Linux aufgeholt hat hat man häufig noch Projekte, wo es keine aktuelle Doku gibt. Ich hab auch manchmal das Gefühl, in dem Umfeld wird sehr "agil" entwickelt. :-)
So nach dem Motto: Wir basteln erst mal unsere Software. Doku machen wir später. Und da lieber neue Features eingebaut werden als Doku geschrieben, kommt die Doku nie oder ist auf einen suboptimalen Stand.
Das kann man natürlich nicht verallgemeinern. Aber die Mentalität geht da öfter gerne mal in die Richtung.
Und Doku finde ich essentiell. Etwas was nicht dokumentiert ist ist quasi nicht vorhanden. Und komm mir jetzt keiner mit "Du kannst doch in den Source-Code gucken". Das ersetzt keine Doku. Wer so argumentiert, hat den Sinn einer Dokumentation nicht verstanden. - Einfachheit
ist aber ausbaufähig. Vieles ist noch unnötig kompliziert. Warum z.B. Konfigurationsdateien in unterschiedlichen Formaten daher kommen lässt sich aus der Historie begründen aber nicht mit Vernunft.
Solche Sachen sind aber noch alle harmlos gegenüber das, was einem in anderen Systemen begegnet. - ZFS
Ähm ja. ZFS gibt es auch für Linux. Bei FreeBSD ist es aber deutlich besser ins System integriert. Andere Features von FreeBSD nutzen ZFS
Wo wir gerade beim Thema sind: Boot Environments - Kein systemd ;-)
- Security
Vor allem gibts hier ne zentrale Anlaufstelle für Security-Bugs. Großer Pluspunkt.
Und die Security-Features von FreeBSD müssen sich auch nicht hinter der Konkurrenz verstecken - Lizenz :-)
Die mangelnde Docker-Verfügbarkeit ist sicher ein Nachteil von FreeBSD. Insbesondere wenn man in die Beliebtheitsskala guckt. Die Leute wollen es (Sinn oder Unsinn außen vorgelassen), also musst Du so was bieten.
bsd4me
Well-Known Member
Der Thread wird ja ganz schön lang Ist auch ok - ein bisschen Senf möchte ich trotzdem (nochmals) dazu geben Nunja, es ist sehr schade, dass die Verbreitung von *BSD doch wesentlich schwächer ist als von Linux. Es würde mir reichen, wenn die Beliebtheitsskala sich auf 5 Prozent im Server- und auch im Desktopbereich erhöhen würde. Ein Beispiel: ich besuchte gestern einen Freund, mit einem Win10 PC. Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows ) laufen lässt, erscheinen nur 40GB dabon genutzt. Keine Ahnung warum. Auch ist es immer wiede erstaulich, wie gerade Windows Leute die PC Begriffe durcheinanderschmeissen. Manchmal ist es so als würde man über Dübel reden, wenn man ein Auto zusammenbauen würde ;-) Tja, viele Leute beschwereren sich über die Komplexität von *BSD. Hat man aber ein Problem auf einer anderen Platform (auch z.B. bei Apple), ist die Analyse und Behebung oftmals sehr kompliziertert. Es ist ja alles nutzerfreundlich verborgen Ich weiss, der Normalsterbliche weiss vieles nicht (muss er auch nicht), und wenn meine Mama (die ja schon über 80 ist) mal eine mail schreiben würde, würde ich über alle Fehler hinwegsehen Ein hoch auf BSD! Prost (heute abend) Norbert
Ist auch ok - ein bisschen Senf möchte ich trotzdem (nochmals) dazu geben Nunja, es ist sehr schade, dass die Verbreitung von *BSD doch wesentlich schwächer ist als von Linux. Es würde mir reichen, wenn die Beliebtheitsskala sich auf 5 Prozent im Server- und auch im Desktopbereich erhöhen würde. Ein Beispiel: ich besuchte gestern einen Freund, mit einem Win10 PC. Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows ) laufen lässt, erscheinen nur 40GB dabon genutzt. Keine Ahnung warum. Auch ist es immer wiede erstaulich, wie gerade Windows Leute die PC Begriffe durcheinanderschmeissen. Manchmal ist es so als würde man über Dübel reden, wenn man ein Auto zusammenbauen würde ;-) Tja, viele Leute beschwereren sich über die Komplexität von *BSD. Hat man aber ein Problem auf einer anderen Platform (auch z.B. bei Apple), ist die Analyse und Behebung oftmals sehr kompliziertert. Es ist ja alles nutzerfreundlich verborgen Ich weiss, der Normalsterbliche weiss vieles nicht (muss er auch nicht), und wenn meine Mama (die ja schon über 80 ist) mal eine mail schreiben würde, würde ich über alle Fehler hinwegsehen Ein hoch auf BSD! Prost (heute abend) Norbert"Die Leute" können auch nicht mit BSD umgehen. Sollen wir deswegen jetzt auf BSD verzichten?
Container-Workflows sind in vielen Unternehmen etabliert und laufen dort reibungslos ab. Dort werden aber sowohl zur Build- als auch zur Laufzeit die Container auf ihre Sicherheit überprüft.
Ich erzähle in meinen Erfahrungsberichten auch von Bereichen, in denen Tools wie Bastille eher low-level und am Anfang der Kette sind sind. Die ganze Magie passiert ja erst danach.
Wir reden trotz alledem von mehreren Teams, vielen Millionen Euro und einem langen Zeitraum bis zur Produktionsreife - zumal man erstmal die Köpfe haben muss, Entwickler wachsen nicht auf Bäumen.
Es besteht auch die Gefahr, dass man anschließend ganz alleine mit seiner Lösung auf weiter Flur steht, weil bis zur Produktionsreife der Rest der Unternehmen mit vergleichbaren Anfordungen schon wegmigriert ist. Deswegen gibt es jetzt Firmen mit FreeBSD, die wie ein Reh im Scheinwerferlicht stehen und nicht wissen wohin.
Es muss nicht Docker sein - Docker Hub ist zwar nett, aber mehr schmuckes Beiwerk und Spielwiese. Die Firmen wollen den Workflow und den einfachen Betrieb, den Docker, Kubernetes und das Ökosystem darum ermöglichen. Inzwischen gibt es auch einige Entwicklungs-Tools, die nativ auf Containern aufsetzen.
Xen ist von 2003, KVM von 2007, bhyve von 2013. Die Idee ist, dass man von den Vorgängern lernt und dann auch besser und schneller vorwärts kommt. Xen und KVM waren 7 Jahre nach ihrem ersten Release längst produktionsreif.
Das zentralisierte Modell (Server down - nix geht), das bescheidene Branching und die Unmöglichkeit, ohne Netzwerkverbindung zum zentralen Server zu committen?
Wir reden hier leider auch nicht von Dingen, die ein kleines und motiviertes Team in einem verregneten November macht. Der Rückstand ist halt an vielen Fronten über die Jahre arg gewachsen.
Interessanterweise ist das der Grund, und nicht die Technik, warum die Netflix-Appliances auf FreeBSD laufen. Die gesamte restliche Anwendungslandschaft von Netflix läuft in Linux-Containern - soviel zum Thema, warum sowas auf FreeBSD nützlich wäre...
abeginner
Well-Known Member
Eine "besondere Bedeutung darin sehe ich, im Aspekt "Was bieten Firmen ihren Kunden überhaupt", also im technischen Sinne IT betreffend. Das sind (auch physische) Produkte, Dienstleistungen und generell Inhalte. Und CSM bietet sowohl intern wie auch also extern eine Plattform dafür.
Der Anwendungsbereich für genrell ContentSysteme ist ja riesig und unerschöpflich. Ich kann mir schon vorstellen, dass die wirtschaftliche Bedeutung davon jener von ERP usw gleicht.
Wir unterhalten uns hier ja vorwiegend über technische Aspekte, aber ich glaube weniger, dass alleinig diese schlussendlich die Entwicklung ausmachen. Container hin oder her . . Auf der anderen Seite ist es typisch, dass solche Dinge technisch Tätige wie Devs' und Ops; eher interessiert.
Es ist ja grundsätzlich kein neues Phänomen, dass Betriebssysteme bis hin zum Quasimonopol bevorzugt werden und andere trotz mindestens qualitativ gleichstehender Technik, beinahe oder gar ganz verschwinden.
Angesichts der Menge die an Software inkl OS gebraucht wird - und zwar zunehemend - eigentlich doch paradox.
Frage nebenbei : wer von hier hat noch ein Blackberry (OS10) -oder Symbian-Smartphone und hatte irgendwer mal eines der letzten Generation?
Warum man keines hatte, kann möglicherweise prinzipiell die selbe Ursache haben, wie sich eine Firma gegen FreeBSD entscheidet.
Eine Ursache kann sehr subtil und muss keineswegs spektakulär sein.
Ich glaube nicht, dass das grosse Kopfschütteln ausbrechen würde, würde hier ein Haufen Entscheidungsträger von Firmen mitlesen.
Selbst da wo man im eigenen Leben "Entscheidungsträger" ist, entscheidet man doch allzuoft aus profanen Beweggründen.
Nicht nur OS, oder tolle Anwenderprogramme sind auf solche Weise verschwunden, sondern m.E. gar ganze Technologien. Ein Teil davon gehört zum üblichen Verlauf des technischen Fortschritts, ein Teil aber auch nicht. Und so einer liegt hier vor.
Schlussendlich ist das Ganze eine Mischung aus Details und Strukturen.
Wen die Technik da ist und auch gut ist, dann liegt einer der Ursachen vlt doch eher an den Strukturen.
Und ich halte es auch für möglich, dass solche Entwicklungen zyklisch sind und sich über-regional etwas unterscheiden.
Ob jemand in 50 Jahren noch von Windows oder Unix spricht?
Idefixx
Well-Known Member
Ein Beispiel: ich besuchte gestern einen Freund, mit einem Win10 PC. Da gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows
Das Werkzeug DU (Disk Usage) gibt es auch unter Windows, ja, aber, daß habe ich noch nicht erlebt/gesehen. Also, wenn das stimmt, dann ist da was oberfaul. Entweder taugt das Werkzeug nichts, oder da gibt es einen Haufen versteckter Dateien.
Aber so etwas gibt es vom System her nicht.
Snapshots, auf Endnutzer-Windowsen meist in Form von Sicherungspunkten. Dazu versteckte Systemdateien, unter anderem dieDa gibt eine eine Festplatte die ist fast voll (fast die kompletten 450GB) - wenn man aber z.B. ein tool wie du (gibt es auch in Windows
hiperfil.sys für den Ruhezustand.bofh_hannibal
THE BOFH
Moin,
also was FreeBSD schon seit Jahren fehlt sind ordentliche bootstrapping optionen.
Nehmen wir einfach mal das aufsetzten (Unattended) einer Virtuellen FreeBSD Machine in irgend einem Hypervisor:
1.) PXE Boot:
PXE mit TFTP ist einfach OUT.
Klar kann man iPXE mit http umsetzten. Es sollte aber mit FreeBSD Boardmitteln machbar sein.
2.) Init
Da fehlt es bei FreeBSD komplett an einer Lösung.
Und Cloud-init läuft einfach nicht Ordentlich mit FreeBSD.
Aber man hätte hier auch eine einfache Variante bauen können.
Scripte sind auf Dauer keine Lösung (auch bsdinstall ist nur ein Shell Script), weil die keiner Pflegt.
3.) Bhyve
Selbst mit Bhyve hab ich keine ordentlich Bootstrapping option für FreeBSD VM's out of the box.
(Thema: Metadata Store pro VM)
Gerne würde ich dazu mal updates hören und mich freuen wenn sich hier etwas getan hat in der letzten Zeit.
also was FreeBSD schon seit Jahren fehlt sind ordentliche bootstrapping optionen.
Nehmen wir einfach mal das aufsetzten (Unattended) einer Virtuellen FreeBSD Machine in irgend einem Hypervisor:
1.) PXE Boot:
PXE mit TFTP ist einfach OUT.
Klar kann man iPXE mit http umsetzten. Es sollte aber mit FreeBSD Boardmitteln machbar sein.
2.) Init
Da fehlt es bei FreeBSD komplett an einer Lösung.
Und Cloud-init läuft einfach nicht Ordentlich mit FreeBSD.
Aber man hätte hier auch eine einfache Variante bauen können.
Scripte sind auf Dauer keine Lösung (auch bsdinstall ist nur ein Shell Script), weil die keiner Pflegt.
3.) Bhyve
Selbst mit Bhyve hab ich keine ordentlich Bootstrapping option für FreeBSD VM's out of the box.
(Thema: Metadata Store pro VM)
Gerne würde ich dazu mal updates hören und mich freuen wenn sich hier etwas getan hat in der letzten Zeit.
Ganz allgemein (und gegen niemanden speziell hier gerichtet) finde ich aber dieses "FreeBSD müsste" doch immer etwas problematisch. FreeBSD ist ein Open Source Projekt, was sich bis auf 3 angestellte Entwickler der FreeBSD Foundation ausschließlich freiwillige Arbeit stützt. Freiwillig im Sinne von Unternehmen, die FreeBSD nutzen und Entwicklungszeit spenden, dazu eben Hobbyisten. Unternehmen entwickeln in Bereichen, die ihnen Vorteile bringen und Hobbyisten im Rahmen ihrer Interessen. Das funktioniert meist ganz gut, aber wenn man etwa Spezielles will, kommt man nicht darum herum es selbst zu machen oder eine Bounty auszuschreiben. Und das Selbstmachen ist oft gar nicht schwer, es muss nicht einmal zwingend Code sein. Nehmen wir mal Bhyve, da es oben genannt wurde meine letzte Runde FreeBSD-Beiträge vor allem dort war:
- Bhyve ist rein funktional inzwischen fast vollständig. Es fehlen vor allem Kleinigkeiten und Komfortfeatures, die sind aber meist schnell implementiert. Ich brauche Bhyve im Moment zum Beispiel für Windows-Gäste auf billigen Intel-Desktop-CPUs. Da war es im wahrsten Sinne des Wortes kacklahm. Das Problem zu analysieren (fehlendes TPR Shadowing, da für Xeons nicht relevant) hat mich ungefähr 4 Stunden Arbeit gekostet. Im Intel Architecture Manual nachzulesen und es in Bhyve zu implementieren noch mal zwei Stunden. Da Review war tatsächlich sogar mehr Aufwand, als die Implementierung.
Einen einfachen Identifier durch die SMBIOS-ID in die VM zu injizieren, wäre auch eine Sache von 20 Zeilen und vielleicht einer halben Stunde. Ab damit in den Bhyve-Umbrella auf https://reviews.freebsd.org/ und die Sache ist in ein paar Wochen durch. Oft kann es sich auf helfen in die auf Bhyve aufbauenden Projekte wie ACRN (https://projectacrn.org/) zu schauen, sie haben teilweise interessante Dinge bereits implementiert, die man mit wenig Aufwand zurückportieren kann. - Aber auch wenn man nicht programmieren will oder kann, kann man mit solchen Wünschen herantreten. Gerade bei eher kleinen Dingen ist die Wahrscheinlichkeit erhört zu werden doch sehr groß. Beispielsweise lagen zwischen dem Wunsch VMs beim Herunterfahren des Gasts automatisch zu zerstören und der Implementierung keine 48Stunden. Dafür gibt es die freebsd-virtualization@freebsd.org Liste, es gibt den sehr freundlichen und hilfsbereiten #bhyve Channel auf Freenode und es findet alle 14 Tage eine Telefonkonferenz zwischen Bhyve-Nutzern und Entwicklern statt. Für eine Einladung einfach Michael Dexter anschreiben. Die Konferenz rotiert in Sachen Uhrzeit immer etwas, um allen Zeitzonen die Chance zur Teilnahme zu geben.
bsd4me
Well-Known Member
bofh_hannibal
THE BOFH
Am FreeBSD init und auch sonst ist nix verkehrt.
Und natürlich kann man den init ändern. Ich hab auch schon Unattended installations mit FreeBSD über PXE boot und bsdinstaller gemacht. Leider ist das aber Aufwändig und schlecht zu Pflegen.
Mir geht es nicht ums Blamen, sondern es bezieht sich auf den Topic warum ein Interesse an FreeBSD rückläufig sein könnte.
Wenn ein OS nicht aktuelle Techniken (vergleichbar zum Mainstream) beherrscht, dann ist die Kosten/Nutzen Rechnung für Unternehmen sehr einfach.
Und FreeBSD spielt in den Clouds für viele Unternehmen (aus Nutzersicht) keine Rolle mehr (VM's, Container, K8, ...). Ich denke der Zug ist abgefahren. Eventuell kommt FreeBSD noch im Backend zum Einsatz.
Hast du Erfahrungen jüngeren Datums mit cloud-init und FreeBSD? Mein letzter Anlauf ist ein paar Jahre her, da musste man noch alle Images selber basteln und der Support in cloud-init war noch sehr rudimentär.
Andy_m4
Well-Known Member
Sehr witzig. :-)
Aber Du weißt sicher, was ich meine.
Ums mal salopp zu formulieren, wenn die Leute mit BSD nicht umgehen können, kriegen sie damit auch nichts zustande. Mit Containern kriegen sie trotzdem was ans laufen, das ist dann aber buggy und/oder mit Sicherheitslücken durchsetzt.
Das spricht nicht gegen Container ansich. Das bedeutet, das bessere Tools nicht automatisch zu besseren, sondern manchmal sogar zu schlechteren Ergebnissen führen. Hatten wir aber eigentlich alles schon mal.
Gibt sicherlich auch Vorzeigeprojekte oder Leute die es richtig machen.
Im allgemeinen ist die IT aber in Firmen in einem eher schlechten Zustand.
Und da wird dann sowas wie Docker und Co eingesetzt um die Probleme zu lösen. Und das ist das was ich sehe und was ich auch anprangere. Und nicht die handvoll Firmen die es richtig machen.
Wie gesagt. Ich kenne mich da nicht aus. Ich wundere mich nur, das einerseits angeblich so viel Geld dafür da sein soll für FreeBSD Lösungen zu entwickeln, andererseits Projekte wie Bastille und Co dann noch nicht weiter sind.
Jaja. Der allseits beliebte Fachkräftemangel.
Komisch ist nur, das man davon als Entwickler immer nix merkt, sobald es an Gehaltsverhandlungen geht. :-)
Man kann sich ja auch zusammentun.
Falls Du es noch nicht wusstest: Bei GIT kann man bei Netzwerkausfall auch nix zum Server commiten. Oder wie kriegst Du ohne Netz Dein Kram nach github und Co.?
Sorry, aber das sind doch herbeigedichtete Probleme.
Es gibt ganz sicher gute Gründe für GIT. Keine Frage. Aber ein pauschales "Subversion ist veraltet und GIT in allen Belangen überlegen" ist doch totaler Quatsch. Und das Du keine konkreten Punkte nennen konntest, sollte Dir da zu denken geben. :-)
Andy_m4
Well-Known Member
FreeBSD hat rc. Was fehlt Dir daran?
Cloud-init ist jetzt was und inwieweit steht das in Beziehung zu einem Init-System wie rc ?
Die Einstiegshürde in BSD - mal abgesehen von der Bekanntheit beim unbedarften Publikum - ist jetzt nicht nennenswert höher als bei bei z.B. Ubuntu Server. Installer mit Defaultwerten durchklicken und hinterher hast du eine nackte Shell.
Umgekehrt hatten wir hier schon altgediente BSD-Nutzer im Forum, die im Brustton des Stolzes berichtet haben, wie sie mit ihren komplett ungepatchten Solaris-Installationen im World Wide Web unterwegs sind und auch nach dem Hinweis auf den Faktor Security kein Problembewusstsein entwickelt haben.
Derselbe Anwender hätte alternativ eine Sammlung niemals aktualisierter FreeBSD-Packages auf seinem System - zumal er auf Linux-Seite zuerst bei z.B. den Ubuntu Packages landen würde. Derselbe Anwender würde ja schon daran scheitern, seine Container als Service zum Laufen zu kriegen.
Ich hätte eher auf eine Gauss'sche Verteilungskurve getippt, wobei man sich über die Mitte streiten kann.
Die Firmen, die ihre IT nicht im Griff haben, lassen meistens von vornherein die Finger von Docker & Co. - deren Admins und Entwickler haben nämlich null Bock auf neues Zeug. Die sind froh, wenn alles so bleibt wie es ist und nach Möglichkeit niemals irgendeine Form von Innovation gibt.
Aus meiner persönlichen Erfahrung ohne Anspruch auf Allgemeingültigkeit: Unternehmen mit FreeBSD als Server-Plattform sind jetzt nicht unbedingt - Ausnahmen bestätigen die Regel - an der Speerspitze der IT-Entwicklung unterwegs. Dort geht es eher gemächlich zu, frei nach dem Motto "never change a running system" und "keine Experimente".
Es hat schon einen Schock wie COVID-19 gebraucht, um aus der gewohnten Trägheit zu erwachen. Jetzt sieht man mit Erstaunen, wie die Konkurrenz mit neumodischen Methoden wie "DevOps" und neumodischer Technik wie "Containern" in (für die alte Garde) Rekordzeit auf geänderte Rahmenbedingungen reagieren kann (vgl. mein Erfahrungsbericht hier im Forum).
Zumindest im Süden der Republik kann man sich nicht beschweren. Man wird als Entwickler aktiv umworben und die Firmen wissen den Wechsel schon schmackhaft zu machen.
Dafür bräuchten die Unternehmen die Kontakte. Erfahrungsgemäß sind die FreeBSD-Verfechter nicht unbedingt die, die bei den einschlägigen IT-Community-Veranstaltungen überrepräsentiert sind, auf denen man einen Erstkontakt für die Zusammenarbeit herstellen könnte.
Bei Git sind commit und push zwei unterschiedliche Aktionen. Subversion macht immer beides unzertrennbar mittels commit.
Mit Git kann man problemlos offline eine Familienpackung Commits in ein lokales Repository machen und - sobald man wieder Netz hat - am Ende das Gesamtwerk zu einem anderen Repository (z.B. GitHub) übertragen. So hat man eine schön nachvollziehbare Commit-Historie mit kleinen Änderungen fürs Review und keinen Big-Bang-Mega-Commit, dessen Änderungen keine Sau mehr nachvollziehen kann.
Korrekt, die Aussage ist aber auch nirgendwo hier gefallen. Beides hat wie immer seine jeweiligen Vor- und Nachteile.
Meine Aussage war nebst meinem Exkurs über die Nachteile von Subversion im Vergleich zu einem DVCS (egal ob mercurial, git o.ä.) folgender Punkt für das Gedeihen von FreeBSD:
Hintergrund meiner Aussage? Der "FreeBSD Survey 2019" der FreeBSD Foundation, Frage 14.
Auf Platz 1 der Antworten auf den zu ergänzenden Satz "I would contribute to FreeBSD more if the FreeBSD Project" steht: "Transitioned to using git"!
Wenn die zentrale FreeBSD-Community den Wechsel von Subversion zu Git als wichtigste Änderung überhaupt für mehr Beiträge zu FreeBSD sieht, nehme ich das natürlich in die Liste der aus meiner Sicht sinnvollen Änderungen im FreeBSD-Umfeld auf.
Obige Umfrageergebnisse findet man auf Seite 30 sowie 49f.: https://wiki.freebsd.org/DevSummit/...o=get&target=core.10+BSDCan+Status+Update.pdf
Mehr Infos gibt es bei der Aufzeichnung der Präsentation der Ergebnisse.
Ich wollte eine ausufernde Diskussion über Versionsverwaltungssysteme vermeiden, zumal alle relevanten Kandidaten auf allen relevanten Betriebssystemen laufen und es für den Einsatz von FreeBSD keinen Unterschied macht, wenngleich für die Beiträge zu FreeBSD.
Für eine umfangreiche Diskussion über die Vor- und Nachteile von CVCS vs. DVCS, Subversion vs. Git, Files vs. Objects als Grundlage und vieles mehr bin ich natürlich immer zu haben. Dafür kannst du gerne einen neuen Thread aufmachen.
Ich darf die Homepage von cloud-init zitieren:
Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization. It is supported across all major public cloud providers, provisioning systems for private cloud infrastructure, and bare-metal installations.
Cloud instances are initialized from a disk image and instance data:
Cloud instances are initialized from a disk image and instance data:
- Cloud metadata
- User data (optional)
- Vendor data (optional)
Was hat das mit rc zu tun? In diesem dynamischen Umfeld ist es sehr vorteilhaft, ein Init-System mit einem guten Management für notwendige und optionale Abhängigkeiten sowie einer exzellenten Reaktionsmöglichkeit auf Events zu haben. Um es vorsichtig zu formulieren: FreeBSDs rc hat seine Stärken mehr in eher statischen Umgebungen.
Bei Interesse kann ich weiter ausholen - mehr will ich aber eigentlich gar nicht schreiben, sonst sind wir sofort bei der endlosen Diskussion rund um Init-Systeme...
Zuletzt bearbeitet:
bofh_hannibal
THE BOFH
Hi Azazyel,
ich hatte vor ca. 4-5 Jahren mal Cloud-init auf FreeBSD getestet, irgend wann war der Port dann auch Broken.
Bis jetzt hab ich es nicht wieder getestet.