Erfahrungen mit MacOS?

[Lance]

Wie dem auch sei, alles hat seine Grenzen und solange man mit seinem OS rundum zufrieden ist - ich mit macOS, @pit234a mit FreeBSD und voller Kontrolle (über das mounten ) und Hans Maier mit seinem Windows 10 ist ja alles gut. Mögen uns die Systeme nicht unnötig belasten und Zeit für schöne und wichtigere Dinge lassen.
Und über Datenschutz kann man ja sonst mal in einem anderen Thread reden, wem noch danach ist. Ich hab erstmal genug (gelesen)

 

[Azazyel]

Anfangs ist es etwas off-topic, am Schluss kriege ich aber wieder die Kurve zu macOS.

Das würde ich so erst mal bestreiten. :-)
Als Beweisstück lege ich die ganzen FreeBSD-Entwickler vor. :-)

Du meinst die 0,1% der Entwickler? Wobei die Umfrage natürlich auch wieder ein selbstselektiertes Publikum an Interessierten ist und Entwickler jenseits von Windows und macOS dort normalerweise überrepräsentiert sind.

Korrigiere mich, wenn ich irgendwo falsch liege. Aber OCI-Container das ist ja jetzt nicht sowas wie bei der Java-VM so ne "write-once-run-everywhere"-Geschichte. Das ist jetzt ja nicht so gedacht, das Du Deinen OCI-Container über nem beliebigen Betriebssystem abwerfen kannst und der dann da läuft (wenn gleich man das via VM-Verrenkungen auch irgendwie hinkriegt).

Das OCI-Format ist prinzipiell OS-agnostisch (es gibt neben Linux Implementierungen für Solaris und Windows). Es ist aber tatsächlich nicht vorgesehen, dass du für Solaris erstellte Container unter Windows laufen lassen kannst.

Nichts und niemand hält die BSDs auf, ebenfalls eine OCI-Runtime zu implementieren. Die OCI-Maintainer haben sogar bei FreeBSD explizit nachgefragt, ob sich FreeBSD nicht beteiligen möchte.

Solche Container wie Docker und Co sind in erster Linie eine Deployment-Geschichte. Ich sags jetzt mal so salopp: Ich will ne Linux-Anwendung ausliefern aber ich will halt nicht davon abhängig sein was auf der Kiste für ne Datenbank, Lib-Versionen etc. installiert ist also packe ich meine Abhängigkeiten einfach dazu und gut ist.

Korrekt - wobei es nicht nur das Deployment ist, sondern auch der Entwicklungs-Workflow plus Betrieb samt Tooling, der Container so attraktiv macht.

Wenn ich also vorhabe containisierte Linux-Software zu schreiben, dann mach ich das halt am besten unter Linux. Aber nicht weil es auf anderen Plattformen möglicherweise keine OCI-Container gibt, sondern weil sich Linux-Software nun mal am besten unter Linux schreiben lässt, so wie sich Windows-Software am besten unter Windows oder MacOS-Software am besten unter MacOS entwickeln lässt.

Umgekehrt wird ein Schuh daraus: aufgrund der Vorteile von Containern für Entwicklung, Deployment, Betrieb und vieles mehr wird zunehmend immer mehr Software containerisiert. Laut jüngster Stackoverflow-Umfrage nutzen aktuell 35-40% der Entwickler Container, Tendenz steigend.

Linux kann diesen Container-Workflow nativ abbilden. Unter BSD geht das nur mit Krücken, d.h. du musst immer ein anderes Betriebssystem (i.d.R. Linux) in einer VM starten, um Container nutzen zu können.

Und wenn ich Multiplattform-Software schreibe, dann kümmert sich um das bauen halt der Build-Server. Da werf' ich meinen Quelltext usw. rein der spuckt mir dann hinten halt die setup.exe für Windows, das Docker-Image für Linux, die .dmg für MacOS usw. raus.

Mit einem Build allein ist es ja in vielen Fällen nicht getan. Du willst in vielen Fällen noch Integrationstests z.B. gegen eine Datenbank fahren und das für beliebig viele Umgebungen dynamisch ohne nennenswerten Aufwand in unterschiedlichsten Varianten provisionieren können. Gerne auch in mehreren Varianten parallel. Gerne auch automatisch für jeden Branch, Pull Request und so weiter.

Mit Containern ist das trivial. Ohne kotzt du ab, weil du abartig viel Zeit, Energie und Geld in Dinge investieren musst, die Container samt Ökosystem dir frei Haus liefern. Es hat schon einen Grund, warum z.B. Netflix als die FreeBSD-Bastion schlechthin nur die CDN-Appliances unter FreeBSD gelassen hat und abseits dessen so ziemlich deren gesamte Software in Linux-Containern läuft.

Insofern verstehe ich den Einwurf nicht so ganz.

Windows ist eine eigene Welt; MacOS ist eine eigene Welt. Wenn du dich für eine der beiden Welten auf dem Desktop entscheidest, dann im Normalfall aufgrund der individuellen Vorzüge der beiden Betriebssysteme. Die Schnittmenge zwischen BSD und Linux auf dem Desktop ist dagegen sehr groß.

Solange du auf BSD/Linux unterwegs bist, merkst du zwischen den beiden wenig Unterschied (administrativ sieht das wieder anders aus). Shells, Window Manager und Konsorten fühlen sich auf beiden Plattformen sehr ähnlich an. Dementsprechend fällt die Wahl des Betriebssystems für Entwickler meist anhand anderer Kriterien.

Wenn du dich als Entwickler zwischen BSD und Linux entscheidest, möchtest du im Normalfall nicht hinter den Möglichkeiten des aktuellen Stands der Technik zurückbleiben. Für eine große Menge der engagierten Entwickler ist deswegen die Abwesenheit von Containern auf BSD aktuell ein ziemlicher Showstopper.

Dieselben Leute tragen natürlich dann auch Linux auf die Server und Plattformen dieser Welt hinaus. In meinen lokalen Unix-User-Groups mit einem entsprechend hohen Anteil an Open-Source-Contributern ist deswegen auch der Anteil der BSD-User über die Jahre von ~15% auf 0% auf dem Desktop zurückgegangen. Wenn man auf einer Unix-User-Group mehr macOS- als BSD-Nutzer hat, muss Apple irgendwas richtig gemacht haben.

 

[Alexco]

Nichts und niemand hält die BSDs auf, ebenfalls eine OCI-Runtime zu implementieren. Die OCI-Maintainer haben sogar bei FreeBSD explizit nachgefragt, ob sich FreeBSD nicht beteiligen möchte.

Das wird dir aber nicht helfen, da 99,999% der Container eben einfach nur verkappte Linux-Container sind, selbst Docker für macOS nutzt ein virtualisiertes Linux. Die angebliche Plattformunabhängigkeit gibt es da nicht.
Wenn es nur um Container gehen würde, wären solche Sachen wie Bastille sicherlich verbreiteter.

 

[bsd4me]

Wenn du dich als Entwickler zwischen BSD und Linux entscheidest, möchtest du im Normalfall nicht hinter den Möglichkeiten des aktuellen Stands der Technik zurückbleiben. Für eine große Menge der engagierten Entwickler ist deswegen die Abwesenheit von Containern auf BSD aktuell ein ziemlicher Showstopper.

mhmm... Es wird proklamiert, diese Technologien würden alles so einfach machen, was meiner Meinung nach so nicht stimmt. Man vergisst, dass saubere Schnittstellen und Implementierungen viel wichtiger sind als das ganze Docker-Tum. Schön, etwas zu verpacken, aber wenn man es woanders nicht nutzen kann, weil die Daten-Schnitstellen dahin nicht passen, hilft auch keine Virtualisierung... Und jedes Programm in eine eigene VM zu stecken, das ist, als würde man jedem Bürger einen Polizisten zu Seite stellen ;-) VG Norbert

 

[Azazyel]

Das wird dir aber nicht helfen, da 99,999% der Container eben einfach nur verkappte Linux-Container sind, selbst Docker für macOS nutzt ein virtualisiertes Linux. Die angebliche Plattformunabhängigkeit gibt es da nicht.

Für macOS ist der Umsetzungsdruck sehr gering, nachdem es auf dem Server bedeutungslos ist und für den Desktop mit DMGs eine etablierte Lösung gibt, die meines Wissens gut genug funktioniert.

Wenn es nur um Container gehen würde, wären solche Sachen wie Bastillesicherlich verbreiteter.

Ich hab bastille und Konsorten ausprobiert. Ich hätte mich gefreut, wenn die konkurrenzfähig wären; sie lassen aber (noch) viel zu viel missen und ich verstehe, warum die auf BSD (noch) so ein Nischendasein fristen. Viele inzwischen 08/15-Anwendungsfälle sind mit OCI-Containern ein gelöstes Problem, mit bastille & Co. Stand heute aber meist gar nicht oder nur mit enormen Aufwand machbar.

mhmm... Es wird proklamiert, diese Technologien würden alles so einfach machen, was meiner Meinung nach so nicht stimmt.

Hast du mal produktiv damit gearbeitet? Es hat schon einen Grund, warum die Entwickler-Community mit den Füßen abgestimmt hat.

Man vergisst, dass saubere Schnittstellen und Implementierungen viel wichtiger sind als das ganze Docker-Tum.

Der Erfolg von Docker liegt doch darin begründet, dass sie so eine saubere und einfache Schnittstelle samt Implementierung geschaffen haben. Praktisch alle Docker-Kommandozeilen-Tools sind nur schön verpackte Aufrufe der Docker-API.

Schön, etwas zu verpacken, aber wenn man es woanders nicht nutzen kann, weil die Daten-Schnittstellen dahin nicht passen, hilft auch keine Virtualisierung...

Das sind zwei paar Stiefel. Container samt Ökosystem lösen Probleme, die selbst mit hypothetisch perfekten (die es in der Praxis niemals gibt) Anwendungsschnittstellen und -implementierungen auftreten.

Und jedes Programm in eine eigene VM zu stecken, das ist, als würde man jedem Bürger einen Polizisten zu Seite stellen ;-)

Container sind keine VMs. Es ist aber schon praktisch, eine effektive Polizei zu haben, die Zustände wie in Sierra Leone effektiv verhindert.

 

[Ktaadn]

Und jedes Programm in eine eigene VM zu stecken, das ist, als würde man jedem Bürger einen Polizisten zu Seite stellen ;-)

Qubes OS macht genau das und geht sogar noch weiter: So werden z. B. beim Webbrowser Instanzen für Online-Shopping von Online-Banking voneinander isoliert. Ein sehr spannendes Konzept, das sicher auch mit BSD geht.

In der Praxis lief es doch jahrelang so: Auf der jeweiligen Keynote beglückten Microsoft und Apple ihre Kunden mit neuen Features. In der Linux- und der BSD-Welt rieb man sich verwundert die Augen, weil man das tolle neue Feature schon seit Jahren hatte. Gerade BSD versteht sich ja auch als Forschungsprojekt. BSD und Linux sind demnach quasi die Speerspitze der Avantgarde. Ob sie das noch sind, darüber ließe sich trefflich streiten.

Auf das Sicherheitskonzept von Qubes OS bezogen bedeutet das, dass Apple und/oder Microsoft das so in Ihre Betriebssysteme einbauen würden, ohne dass Otto-Normal-Nutzer noch lange frickeln müsste. Apple bzw. Microsoft entscheiden aber darüber, ob sie ihren Kunden das anbieten oder nicht.

 

[Lance]

Auf der jeweiligen Keynote beglückten Microsoft und Apple ihre Kunden mit neuen Features. In der Linux- und der BSD-Welt rieb man sich verwundert die Augen, weil man das tolle neue Feature schon seit Jahren hatte.

Sorry, muss mich doch noch mal melden.
Diese Aussage pauschal ist totaler Blödsinn!

 

[bsd4me]

Hi @Azazyel, es simmt schon, was Du geschrieben hast. Klar ein Container ist keine VM Aber als ich mal Docker laufen lassen wollte (aus einem lxc Container unter Ubuntu) - ging das mal wieder nicht "out-of-the-box". Und da der Server stark in Benutzung ist, habe ich den lxc container nicht neu gestartet. Aber was ich eigentlich sagen wollte ist, gerade im Umfeld der Bioinformatik, dass Anwedungen gerne in Docker gesteckt werden, weil die Abhängigkeiten sonst Probleme machen, oder Pakete schon uralt sind. Aber das schreit doch in sich schon danach, dass man Hand an die Anwedung legen sollte, oder? VG Norbert

 

[drm]

Kleines Update von mir: Habe mir das Macbook Air M1 in der kleinsten Ausführung bestellt (8GB RAM, 256GB SSD) - nutze den Laptop ja nur privat und da reicht das erstmal. Wenn es doch mal knapp werden sollte, gibt es bestimmt schon wieder neue Modelle Und falls mir MacOS doch gar nicht gefällt, kann ich das Ding bestimmt besser weiterverkaufen als ein teureres, besser ausgebautes, da eben die meisten Privatanwender mit dem angebotenen Platz gut zurechtkommen und der Preis auch akzeptabel ist.

Lieferzeit liegt bei 3-5 Wochen, sobald ich es habe, werde ich hier nochmal einen Erfahrungsbericht schreiben.

Bis dahin!

 

[Azazyel]

Gerade BSD versteht sich ja auch als Forschungsprojekt.

Jetzt muss ich sicherheitshalber nachfragen: welches oder welche BSDs? Ich würde bestenfalls Plan 9 als Forschungsprojekt sehen. Gerade die 3 großen BSDs sind eher für ihre sehr (teilweise extrem) konservative Einstellung bekannt. Ich kann mich jetzt auch in den letzten paar Jahren an kein Projekt aus diesem Dunstkreis erinnern, dass in meinem eher Linux-dominierten Berufsalltag Begehrlichkeiten geweckt hätte. Natives ZFS vermisse ich gelegentlich, dank des Siegeszugs von S3 wird das aber auch immer seltener.

BSD und Linux sind demnach quasi die Speerspitze der Avantgarde. Ob sie das noch sind, darüber ließe sich trefflich streiten.

Klingt nach einem guten Thema fürs Geplauder-Forum mit akuter Flamewar-Gefahr.

Hi @Azazyel, es simmt schon, was Du geschrieben hast. Klar ein Container ist keine VM Aber als ich mal Docker laufen lassen wollte (aus einem lxc Container unter Ubuntu) - ging das mal wieder nicht "out-of-the-box". Und da der Server stark in Benutzung ist, habe ich den lxc container nicht neu gestartet.

Container im Container. Mit --exec-driver=lxc wäre es gegangen.

Aber was ich eigentlich sagen wollte ist, gerade im Umfeld der Bioinformatik, dass Anwedungen gerne in Docker gesteckt werden, weil die Abhängigkeiten sonst Probleme machen, oder Pakete schon uralt sind. Aber das schreit doch in sich schon danach, dass man Hand an die Anwendung legen sollte, oder?

So sieht es in der Theorie aus. In der Praxis sind Budget und Personal an Forschungsprojekte mit begrenzter Laufzeit gekoppelt. Für Wartung und Pflege ist das Budget (mit ganz wenigen Ausnahmen) exakt 0€.

Dementsprechend steckst du dein Projekt entweder in einen OCI-Container - mit der hohen Wahrscheinlichkeit, dass es auch in Jahrzehnten noch nutzbar ist - oder du denkst dir "nach mir die Sintflut".

 

[Ktaadn]

Jetzt muss ich sicherheitshalber nachfragen: welches oder welche BSDs?

Explizit: FreeBSD. OpenBSD bezeichnete Theo de Raadt als "research operating system". NetBSD stellt sich bewusst in die Reihe der Berkeley Computer Systems Research Group.

Ich würde bestenfalls Plan 9 als Forschungsprojekt sehen.

Ja, angewandte Forschung.

Gerade die 3 großen BSDs sind eher für ihre sehr (teilweise extrem) konservative Einstellung bekannt.

Konservative Einstellungen (und Strukturen) hindern Unis nicht am Forschen. Die BSDs entstehen halt zum Glück ohne Scrum.
(Fürs Phrasenschwein: Was früher modern war, ist heute konservativ.)

Ich kann mich jetzt auch in den letzten paar Jahren an kein Projekt aus diesem Dunstkreis erinnern, dass in meinem eher Linux-dominierten Berufsalltag Begehrlichkeiten geweckt hätte.

In die Richtung und darüber hinaus dachte ich mit meinem Gedanken, den ich mit "trefflich streiten" abschloss.

Klingt nach einem guten Thema fürs Geplauder-Forum mit akuter Flamewar-Gefahr.

Diesen Gedanken schloss ich ohne Flame-Bait-Absicht ab.

 

[Lance]

Genau, die lassen sich etwas bezahlen, das Freiwillige unentgeltlich besser hinkriegen.

mach mal folgendes:

Du hast vielleicht einen Ordner mit Namen "Hase" und der enthält Videos mit Namen "Hase 01" "Hase 02" usw. Du suchst nach "Hase" und dein Dateimanager (ich nehme mal den modernen Gnome3 3.38) filtert dir Den Ordner und die Dateien, die "Hase" beinhalten aus. Markiere mal alles und kopiere sie wohin. Was passiert? Er kopiert den Ordner und die einzelnen Dateien oder er sagt, die Datei gibt es schon.

macOS weiss aber dass die gesuchten Dateien sich in dem Ordner befinden und kopiert alles ohne Fehler bzw ohne die Dateien nochmal separat zu kopieren so dass ich sie 1x im Ordner und 1x separat habe.

Klingt aufwändig aber ist simpel und mal wieder ein Beweis für die kleinen Feinheiten von macOS.

 

[Andy_m4]

Du meinst die 0,1% der Entwickler?

Das war ja nur Gruppe die ich jetzt mal exemplarisch herausgepickt habe. Da Deine Behauptung war, das man unter FreeBSD gar keine Softwareentwicklung machen kann. Das ist so offenbar nicht korrekt und schon durch einen einzigen Entwickler widerlegt. Wenns mehr sind, worauf die von Dir verlinkte Quelle schließen lässt, dann wird die Beweislast eher erdrückender. :-)

Es war sicher auch nicht so von Dir gemeint das ausnahmslos JEDER Entwickler OCI-Container braucht. Ich denke auch, da sind wir uns einig das es nicht JEDER braucht aber es halt häufig vonnöten ist.

Das OCI-Format ist prinzipiell OS-agnostisch (es gibt neben Linux Implementierungen für Solaris und Windows).

Ja. Die machen dann halt genau das, was ich gesagt hab. Die nehmen den Linux-Docker-Container und lassen ihn dann in einer virtualisierten Linux-Umgebung laufen.
Auch hier sind wir uns offenbar einig, das ein (zumindest Stand jetzt) kein Write-Once-Run-Everywhere gibt.

Nichts und niemand hält die BSDs auf, ebenfalls eine OCI-Runtime zu implementieren.

Die sagen sich vielleicht das gleiche was ich mir auch sage. Was nützt mir der OCI-Support in der Praxis? Das Deployment fällt weg. Bleibt halt nur ein bisschen Erleichterung in der Entwicklung was ich aber auch so hinkriege.

Korrekt - wobei es nicht nur das Deployment ist, sondern auch der Entwicklungs-Workflow plus Betrieb samt Tooling, der Container so attraktiv macht.

Ja. Es macht auch den Entwicklungs-Workflow angenehmer. Aber genau das kann ich auch mit FreeBSD haben. Mit BastilleBSD hab ich sogar ein Framework was sich sehr stark Docker und Co orientiert.
Ich bin dann halt nur nicht OCI-komatibel. Auch das hat sicherlich seine Nachteile. Wie auch schon von Dir angesprochen viele Tools sind halt für Docker und Co gedacht und die kann ich dann natürlich nicht benutzen.
Das ist ein Nachteil. Aber bei dieser näheren Betrachtung ist er halt nicht mehr ganz so groß wie anfänglich suggeriert.

Viele inzwischen 08/15-Anwendungsfälle sind mit OCI-Containern ein gelöstes Problem, mit bastille & Co. Stand heute aber meist gar nicht oder nur mit enormen Aufwand machbar.

Hast Du da mal ein konkretes Beispiel bei der Hand, damit man sich mal ein Bild machen kann?

Aber kommt mir jetzt nicht mit Dockerhub oder so n Sch**ß :-)

Umgekehrt wird ein Schuh daraus: aufgrund der Vorteile von Containern für Entwicklung, Deployment, Betrieb und vieles mehr wird zunehmend immer mehr Software containerisiert. Laut jüngster Stackoverflow-Umfrage nutzen aktuell 3540% der Entwickler Container, Tendenz steigend.

Ich finde ja eine Sache ganz lustig. Anfänglich kamst Du noch so rüber, das man als Softwarentwickler heute unbedingt Container braucht etc. und jetzt wirfst Du hier ne Statistik raus, das es nur 40% sind. :-)

Mit Containern ist das trivial. Ohne kotzt du ab, weil du abartig viel Zeit, Energie und Geld in Dinge investieren musst, die Container samt Ökosystem dir frei Haus liefern.

Das funktioniert aber halt nur, wenn Du auf einer Plattform bist. Bei Multiplattform funktioniert es ja gerade nicht.

Wenn du dich als Entwickler zwischen BSD und Linux entscheidest, möchtest du im Normalfall nicht hinter den Möglichkeiten des aktuellen Stands der Technik zurückbleiben. Für eine große Menge der engagierten Entwickler ist deswegen die Abwesenheit von Containern auf BSD aktuell ein ziemlicher Showstopper.

Ich bezweifel ich gar nicht. Ich denk nur nicht, das die Verfügbarkeit von OCI-Containern da großartig etwas ändern würde. Und Du hast das bisher auch noch nicht wirklüch überzeugend darlegen können.

Und klar würde es Vorteile bringen wenns ein OCI-Containerframework für FreeBSD bringen., Aber ich glaube nicht, das der Vorteil so groß ist, wie Du hier darstellst.

Dementsprechend fällt die Wahl des Betriebssystems für Entwickler meist anhand anderer Kriterien.

Richtig. Aber gerade bei Containern ist das ja kein FreeBSD-exklusives Problem. Das Problem hast Du exakt genauso bei anderen Nicht-Linux-Betriebssystemen. Somit kommen wir wieder zu meiner Ursprungsaussage, das wenn Du irgendwie in diesem Umfeld was machst Du eh nicht um Linux drum herum kommst.

In meinen lokalen Unix-User-Groups mit einem entsprechend hohen Anteil an Open-Source-Contributern ist deswegen auch der Anteil der BSD-User über die Jahre von ~15% auf 0% auf dem Desktop zurückgegangen.

Interessant. Weil ich es genau anders herum erlebe. So von für FreeBSD ist ja für Server ganz ok aber auf dem Desktop ists nicht so der Bringer zu Ich hab die Wahl zwischen Golden-Käfig-MacOS, Telemetrie-und-Trojaner-Windows und Frickel-Linux, da ist FreeBSD inzwischen ne interessante Option.
Wenn dann sehe ich eher, das aufgrund von Docker und Co bei Servern die Bewegung weg von FreeBSD hin zu Linux geht. Aber wie gesagt. Auch da hilft mir OCI-Support nicht weiter, weil die verfügbare Software die ich auf den Servern fahren will halt auf Linux ausgelegt ist.

Linux nimmt (zumindest im Serverbereich) da so ein bisschen die Stellung ein die Windows früher hatte. Früher gabs wenig Software für Linux weil alles nur auf Windows lief.

Gerade BSD versteht sich ja auch als Forschungsprojekt. BSD und Linux sind demnach quasi die Speerspitze der Avantgarde.

Sehe ich komplett anders.
Gerade Linux ist doch eher sehr pragmatisch. Klar werden da auch mal neue Sachen ausprobiert, aber das hält sich doch alles eher im Rahmen.
Und bei den BSDs kommts halt drauf an. FreeBSD würde ich eher nicht als Forschungsprojekt sehen. Die sind eher konservativ.
OpenBSD schon eher aber auch vor allem unter der Maßgabe, wie bauen wir sichere Software (was ein wichtiger Bereich ist; ich will das gar nicht kleinreden). Aber weniger in die ganzheitliche Richtung: Wie könnten künftige Betriebssysteme aussehen.
Da finde ich dann Projekte wie DragonflyBSD schon spannender. Oder auch das hier schon genannte Plan-9, was viel zu wenig Beachtung findet (auch wenn Features es manchmal in den Mainstream schaffen) und auch zu wenig Zuwendung erhält.
NetBSD würde ich auch in der Richtung "Research" verorten. Da stimme ich @Ktaadn zu

Dementsprechend steckst du dein Projekt entweder in einen OCI-Container - mit der hohen Wahrscheinlichkeit, dass es auch in Jahrzehnten noch nutzbar ist

lol Uraltprogramme und uralt Code sind in der IT auch eine einzige Erfolgsgeschichte. :-)

Wenn ich so den ganzen legacy-Kram sehe, dann weiß ich nicht, ob ich mich da wirklich freuen sollte.
Bisher ist ja ganz ranziger Code dadurch weggefallen, das die Probleme damit soweit eskaliert sind, das selbst wildeste "Wieso neu machen? Läuft doch!"-Rhetorik nicht mehr darüber hinwegtäuschen konnte. Wenn das auch noch wegfällt, weil der Gammel-Code dann in irgendeinem Docker-Brutkasten am Leben gehalten wird, sinken natürlich die Chancen solche Metastasen dann doch noch irgendwie los zu werden. :-)

 

[Andy_m4]

macOS weiss aber dass die gesuchten Dateien sich in dem Ordner befinden und kopiert alles ohne Fehler bzw ohne die Dateien nochmal separat zu kopieren so dass ich sie 1x im Ordner und 1x separat habe.

Aber genau solche smarten Funktionen wo das System versucht zu erraten führt auch gern mal zu Problemen. Und zwei gleich in zwei Richtungen.

Einmal ins Mindset. So a-la "Ich brauche gar nicht mehr sorgfältig nachzudenken, das System weiß schon was ich meine". Was dazu führt was man auch (immer noch) z.B. beim Einsatz eines Taschenrechners beobachtet (ich nehm' mal das Beispiel, weil es "jedem" bekannt vorkommen dürfte). Da werden auch völlig unplausible Ergebnisse unkritisch übernommen weil hat ja die Maschine gesagt und dann muss das ja stimmen.

Das zweite Konfliktfeld ist, wenn das System eben Absicht errät aber falsch errät. Schlimmer noch. Wenn gar keine (Fehler-)Meldung kommt, kriege ich auch gar nicht mit das was "schiefgelaufen" ist.

Deswegen ist es mir immer ganz lieb, wenn völlig klar ist was das System bei einer Operation macht. Keep-it-simple-and-stupid. Oder wenns halt verschiedene Interpretationen einer Anweisungen gibt, das der dann wenigstens nachfragt. Der kann ja dann von mir aus auch per default die Variante auswählen, die Deine 99,9% der User nehmen würden, damit die die Meldung ungelesen wegklicken können. :-)

 

[Ktaadn]

Sehe ich komplett anders.

Das musst du FreeBSD und OpenBSD erzählen, nicht mir. Ich habe nur das Selbstverständnis wiedergegeben und mit Links bzw. einem bekannten Zitat belegt.

Gerade Linux ist doch eher sehr pragmatisch. Klar werden da auch mal neue Sachen ausprobiert, aber das hält sich doch alles eher im Rahmen.

Gerade eben habt ihr euch noch über Container unterhalten. Unter Linux wurden sie zum Massenprodukt. Da ist Linux tatsächlich eher pragmatisch. Entscheidende Impulse kamen aber von FreeBSD.

Und bei den BSDs kommts halt drauf an. FreeBSD würde ich eher nicht als Forschungsprojekt sehen. Die sind eher konservativ.

Jails sind doch eine FreeBSD-Erfindung, oder? Zum Rest siehe meinen Beitrag oben.

Da finde ich dann Projekte wie DragonflyBSD schon spannender.

Absolut. Volle Zustimmung.

 

[Andy_m4]

Das musst du FreeBSD und OpenBSD erzählen, nicht mir. Ich habe nur das Selbstverständnis wiedergegeben und mit Links bzw. einem bekannten Zitat belegt.

Ja. Dann widerspreche ich eben der Selbstdarstellung :-)

Entscheidende Impulse kamen aber von FreeBSD.

Ja. Wobei selbst Jails ja jetzt kein wirklich revolutionäres Konzept. Und selbst, das es angefangen wurde zu implementieren hat man da ja auch keine Revolution vom Zaun gebrochen, sondern hat sich sozusagen "nur" (ohne das Kleinzureden das schon vorhandene chroot genommen und das sicherer gemacht.
Und auch unter Linux gabs schon relativ früh solche Konzepte. Lediglich LXC ist ja relativ neu und die Ganze Thematik hat halt mit Docker so richtig Fahrt aufgenommen.

Jails sind doch eine FreeBSD-Erfindung, oder?

Ja. Sind sie.
Nicht falsch verstehen. Ich will auch gar nicht verneinen, das es Innovationen unter FreeBSD und von mir aus auch unter Linux gibt. Aber halt eher im begrenzten Stile. Also so richtig abgefahrenes Zeug wird eher nicht probiert. Und schon gar nicht, wenn es irgendwas Bestehendes kaputt machen könnte.
Da ist OpenBSD schon stringenter. Man denke nur an W^X was auch erst mal viel Software kaputt macht, aber die haben halt Sicherheit priorisiert und die ziehen das halt trotzdem durch. Und wenn irgendwelche Anwendungen dabei kaputt gehen, fixen sie halt die Anwendung anstatt Kompromisse bei der Grundausrichtung des Systems zu machen.

 

[midnight]

Die Softwareentwicklung hat sich die letzten Jahre gewandelt. Monolithische Architekturen wurden immer komplexer und fehleranfaelliger. Dadurch resultierend sind Build- und Releasezyklen immer laenger geworden. Neue Funktionen waren oft nur noch schwer implementierbar, bis die Software irgendwann legacy war. Daher haben sich Microservices in vielen Bereichen durchgesetzt.

Durch Docker, Kubernetes usw. koennen diese Microservices sozusagen on-the-fly verteilt und dadurch nahezu unbegrenzt skaliert werden. Wer im business auf Microservices setzt, kommt daher an Containern oft nicht vorbei. </off topic>

 

[Azazyel]

Da Deine Behauptung war, das man unter FreeBSD gar keine Softwareentwicklung machen kann.

Das habe ich niemals behauptet.

Ich zitiere mich mal selbst:

mangels OCI-Container-Support ist FreeBSD für Softwarenentwickler aktuell kaum eine Option

Das ist ein großer Unterschied.

Die nehmen den Linux-Docker-Container und lassen ihn dann in einer virtualisierten Linux-Umgebung laufen.

Es gibt zwar auch Projekte für Linux-Container unter Windows in einer Linux-VM, ich meinte aber schon explizit u.a. Windows Server Core in einem OCI-Container, der dann unter Windows läuft.

Auch hier sind wir uns offenbar einig, das ein (zumindest Stand jetzt) kein Write-Once-Run-Everywhere gibt.

Nicht betriebssystemübergreifend.

Die sagen sich vielleicht das gleiche was ich mir auch sage. Was nützt mir der OCI-Support in der Praxis? Das Deployment fällt weg. Bleibt halt nur ein bisschen Erleichterung in der Entwicklung was ich aber auch so hinkriege.

Kann du mir einen Blog-Beitrag nennen, bei dem jemand seinen Produktiveinsatz von BastilleBSD o.ä. für Entwicklung, Test und Produktivbetrieb hochverfügbarer und skalierbarer Software beschreibt? Gerne auch mit Anwendungsfällen wie Rolling Releases, A/B-Testing und vergleichbaren Szenarien, die im OCI-Umfeld Standard sind.

Für automatisierte Security-Scans existierender Jails - sowohl als Image in der Registry als auch laufende Jails - auf CVEs in 3rd-Party-Bibliotheken jenseits von Ports und Packages hätte ich auch gerne eine Lösung, damit ich als Entwickler immer weiß, ob ich bekannte Sicherheitslücken in meiner Software haben könnte.

Wie nutzt du für die Service Discovery bei der Skalierung von Services in Jails?

Falls du selber sowas beruflich produktiv mit Jails betreibst und gelöst hast, würde ich mich extrem über einen Erfahrungsbericht freuen!

Ja. Es macht auch den Entwicklungs-Workflow angenehmer. Aber genau das kann ich auch mit FreeBSD haben. Mit BastilleBSD hab ich sogar ein Framework was sich sehr stark Docker und Co orientiert.

Gerade im Bereich Networking ist es noch weit entfernt, aber immerhin ein Schritt in die richtige Richtung. Stand heute ist es halt noch lange kein Ersatz.

Ich bin dann halt nur nicht OCI-kompatibel. Auch das hat sicherlich seine Nachteile. Wie auch schon von Dir angesprochen viele Tools sind halt für Docker und Co gedacht und die kann ich dann natürlich nicht benutzen.

Korrekt. Warum sollte ein Entwickler also auf diese Vorteile verzichten und freiwillig mit schlechteren Tools als notwendig arbeiten?

Das ist ein Nachteil. Aber bei dieser näheren Betrachtung ist er halt nicht mehr ganz so groß wie anfänglich suggeriert.

Er ist aktuell für viele Entwickler (nicht nur mich) ein Showstopper für den Einsatz von BSD - nicht nur auf dem Desktop. Ich kann ja auch schlecht als Entwickler zum Kunden sagen: "Dein Anwendungsfall schreit nach Containern, aber wir setzen die jetzt nicht ein, denn BSD unterstützt die nicht. Komm, lass uns einfach schlechter Software machen und den Fortschritt der letzten 10 Jahre ignorieren."

Hast Du da mal ein konkretes Beispiel bei der Hand, damit man sich mal ein Bild machen kann?

Klar. Mit Tools wie Testcontainers (gibt es in ähnlicher Form für viele Programmiersprachen) kannst du Unit Tests für deine Anwendung ohne Mocks schreiben, sondern einfach für den jeweiligen Test automatisch einen Container mit deiner echten Datenbank oder was auch immer on the fly starten, dagegen testen und wieder entsorgen lassen. Du erreichst also eine bessere Softwarequalität, weil du keine Mocks, In-Memory-Datenbanken o.ä. verwenden musst, geschweige denn lokal auf deiner Kiste irgendwas in (einer) bestimmten Version(en) installieren musst.

Ich finde ja eine Sache ganz lustig. Anfänglich kamst Du noch so rüber, das man als Softwarentwickler heute unbedingt Container braucht etc. und jetzt wirfst Du hier ne Statistik raus, das es nur 40% sind. :-)

Umgekehrt wird ein Schuh daraus: mit FreeBSD bin ich vom einem großen Teil der Neuentwicklungen ausgeschlossen, die schon von 40% der Entwickler eingesetzt werden - Tendenz steigend.

Du fällst also immer weiter hinter den aktuellen Stand der Technik zurück; keine prickelnden Aussichten für einen Entwickler.

Das funktioniert aber halt nur, wenn Du auf einer Plattform bist. Bei Multiplattform funktioniert es ja gerade nicht.

Du kannst problemlos OCI-Container mit Windows, die auf Windows laufen und Linux nicht mal vom Hörensagen kennen, unter Windows mit verfügbaren Tools (ein willkürliches Beispiel hier) auf Sicherheitslücken scannen - eben weil es OCI-Container sind. Hier ist weit und breit kein Linux involviert.

Ich bezweifel ich gar nicht. Ich denk nur nicht, das die Verfügbarkeit von OCI-Containern da großartig etwas ändern würde. Und Du hast das bisher auch noch nicht wirklich überzeugend darlegen können.

Ich kann als Softwareentwickler nur von meinen Erfahrungen aus der Praxis bei Kunden, meinem Umfeld und meinen Beweggründen für den Einsatz von Linux auf dem Desktop berichten. Man soll nicht von sich auf andere schließen, aber nachdem ich inzwischen viele Softwareentwickler kenne, die als Grund für ihren Weggang von BSD die mangelnde Container-Unterstützung anführen und u.a. die alljährliche Stackoverflow-Umfrage meine Ansicht untermauert, scheine ich doch kein Einzelfall zu sein.

Und klar würde es Vorteile bringen wenns ein OCI-Containerframework für FreeBSD bringen. Aber ich glaube nicht, das der Vorteil so groß ist, wie Du hier darstellst.

Ich habe mehr als einen Kunden, für den die Abwesenheit von Containern ein Grund für die Migration weg von FreeBSD war. Ich hab hier im Forum vor knapp einem Jahr einen Fall aus meiner beruflichen Praxis beschrieben. Besagter Kunde hat zwischenzeitlich auch beschlossen, dass FreeBSD 12 nach rund zwei Jahrzehnten die letzte FreeBSD-Version in diesem Unternehmen gewesen sein wird.

Richtig. Aber gerade bei Containern ist das ja kein FreeBSD-exklusives Problem. Das Problem hast Du exakt genauso bei anderen Nicht-Linux-Betriebssystemen. Somit kommen wir wieder zu meiner Ursprungsaussage, das wenn Du irgendwie in diesem Umfeld was machst Du eh nicht um Linux drum herum kommst.

Unter Windows laufen OCI-Container produktiv, ganz ohne Linux. Wenn du willst, kannst du Windows-OCI-Container auf Windows-Hosts unter der Hoheit von diversen Orchestrierungsplattformen laufen lassen, ohne dass du irgendwo Linux in der Hand hättest.

Auf dem Desktop gibt es für Windows und macOS Docker Desktop (womit du unter Windows auch reinrassige Windows-Container bauen kannst). Der Mac kann hier in Verbindung mit seiner stimmigen UX samt Unix-Unterbau auch wieder gut punkten.

Interessant. Weil ich es genau anders herum erlebe. So von für FreeBSD ist ja für Server ganz ok aber auf dem Desktop ists nicht so der Bringer zu Ich hab die Wahl zwischen Golden-Käfig-MacOS, Telemetrie-und-Trojaner-Windows und Frickel-Linux, da ist FreeBSD inzwischen ne interessante Option.

Zumindest im Bereich der Softwareentwicklung sehe ich keinerlei Indikatoren, die für ein Revival von FreeBSD sprechen. Sofern du belastbare Belege für die Renaissance von FreeBSD in der Softwareentwicklung hast, immer her damit.

Mich würde auch die Antwort auf die Frage interessieren: "Welche Vorteile bietet mir FreeBSD gegenüber z.B. Arch Linux als Entwicklerplattform, was die Nachteile (u.a. kein Container-Support) mehr als kompensieren könnte?"

Wenn dann sehe ich eher, das aufgrund von Docker und Co bei Servern die Bewegung weg von FreeBSD hin zu Linux geht. Aber wie gesagt. Auch da hilft mir OCI-Support nicht weiter, weil die verfügbare Software die ich auf den Servern fahren will halt auf Linux ausgelegt ist.

Ist es nicht eher umgekehrt? FreeBSD stellt keine OCI-Runtime zur Verfügung. Will ich das rund um Docker entstandene Ökosystem und die damit verbundenen Vorteile nutzen, lande ich (bei den freien Betriebssystemen) automatisch bei Linux, weil sich die BSDs selber aus der Auswahl rauskegeln.

lol Uraltprogramme und uralt Code sind in der IT auch eine einzige Erfolgsgeschichte. :-)

Wie hat Bjarne Stroustrup, der Vater von C++, so schön gesagt:

"Legacy code" often differs from its suggested alternative by actually working and scaling.

Wenn ich mir anschaue, wie sehr unsere Zivilisation von Code aus den 1960/70ern abhängt...

Bisher ist ja ganz ranziger Code dadurch weggefallen, das die Probleme damit soweit eskaliert sind, das selbst wildeste "Wieso neu machen? Läuft doch!"-Rhetoik nicht mehr darüber hinwegtäuschen konnte. Wenn das auch noch wegfällt, weil der Gammel-Code dann in irgendeinem Docker-Brutkasten am Leben gehalten wird, sinken natürlich die Chancen solche Metastasen dann doch noch irgendwie los zu werden. :-)

Was ist denn dein praktikabler Lösungsvorschlag für das angesprochene Problem von Projektcode aus dem akademischen Umfeld, für den es keine Wartung gibt? Ich bin gespannt auf deine Lösungsvorschläge, das würde mich noch brennend interessieren.

Die restliche Diskussion rund um Legacy-Code können wir gerne in einen eigenen Thread auslagern, wir sind eh schon ordentlich off-topic.

 

[Columbo0815]

mach mal folgendes:

Du hast vielleicht einen Ordner mit Namen "Hase" und der enthält Videos mit Namen "Hase 01" "Hase 02" usw. Du suchst nach "Hase" und dein Dateimanager (ich nehme mal den modernen Gnome3 3.38) filtert dir Den Ordner und die Dateien, die "Hase" beinhalten aus. Markiere mal alles und kopiere sie wohin. Was passiert? Er kopiert den Ordner und die einzelnen Dateien oder er sagt, die Datei gibt es schon.

macOS weiss aber dass die gesuchten Dateien sich in dem Ordner befinden und kopiert alles ohne Fehler bzw ohne die Dateien nochmal separat zu kopieren so dass ich sie 1x im Ordner und 1x separat habe.

Klingt aufwändig aber ist simpel und mal wieder ein Beweis für die kleinen Feinheiten von macOS.

Das Beispiel zeigt mir, dass macOS scheinbar nicht macht, was ich von ihm verlange. Ich markiere 3 Elemente. Also möchte ich, dass 3 Elemente kopiert werden. Als User bin ich fähig, Ordner von Dateien zu Unterscheiden. Wenn ich also alles markiere, hat das einen guten Grund. Sonst würde ich nur die Videos markieren.

Ich habe dennoch dein Beispiel nachgestellt, weil mich interessiert, ob mein Dateimanager (midnight commander) tatsächlich so reagiert, wie ich es möchte:Ich suche nach "hase*", bekomme also den Ordner und die Videos in einer Vorschau des Suchergebnisses angezeigt. Zufrieden mit dem Suchergebnis, gehe ich auf "Anordnen". Was zeigt er mir? Einmal den Ordner und einmal "grün hinterlegt" die 2 Dateien. Markiere ich alle 3, macht das Programm erneut, das was ich von ihm erwarte: Es kopiert den Ordner (schließlich habe ich den Ordner markiert) samt darin liegender Dokumente und es kopiert die Videos in das Zielverzeichnis.

Ja, ich habe damit die Videos 2x kopiert. Aber genau das wollte ich doch.

 

[Lance]

Mit Verlaub, so ein wenig kommt es mir vor als wolle man hier „sein System“ verteidigen - was an sich völlig menschlich und nachvollziehbar ist.

Denn ich hatte gestern ca 70 Ordner und 140 Dateien und ganz sicher will ich mir da keine Mühe machen, nur die Ordner zu markieren. In jedem war eine Datei. Kurzerhand alles markiert und kopiert. Minimaler Aufwand.
Das ganze mal aus Jux bei Windows und Ubuntu nachgestellt und ja, ich müsste bei Ubuntu nur die Ordner markieren... Aber weiß ich zB bei 100 oder mehr Ergebnissen auf Anhieb dass immer eine Datei in dem Ordner ist und nicht evtl im übergeordneten? Was wenn es 500 Datein und Ordner sind? Willst du dann alles manuell markieren, damit du keine Doppelten hast? Na dann viel Spaß.

Anbei bei Windows 10 ging trotz Index der Filter nicht, warum auch immer.

Ich kann dieses „ich will explizit“ an sich nachvollziehen aber ich empfinde es v.a. ab einer gewissen Datenmenge anstrengend, es so machen zu müssen.

Eins was mir gestern beim vielen Hantieren mit Ubuntu noch negativ auffiel:

mal kann ich ein USB Laufwerk „sicher entfernen“ , mal nicht. Den CardReader tut er immer nur unmounten. Mal kommt eine Meldung von Gnome dass es sicher ausgesteckt werden kann, mal nicht.
Nachdem das Laufwerk aus dem Dateimanager verschwunden ist, gehe ich davon aus, es ist unmounted. Ich warte jedes Mal ein bis zwei Sekunden.
Fazit: insgesamt 7 x wurden Dateien nicht zu Ende geschrieben, somit kaputt oder 0 Byte.
Wenn beim Mac das Symbol vom Desktop verschwindet kann ich es seit Jahrhundeten sicher entfernen.
Bei einem 20.04 läuft das ganze aber zuverlässiger. Ich würde mir aber auch hier wünschen, dass ein Laufwerk immer sicher ausgeworfen wird und entweder immer eine Meldung kommt oder gar nicht (wie beim Mac). Klarheit und kein grübeln ob ich den Stick nun rausnehmen kann.

Das und viel mehr sind einfach Sachen im Alltag, die 100% funktionieren und bei BSD oder sogar Linux eben nicht ganz. Das macht das Arbeiten damit einfach total entspannt und angenehm.
Sich mit Kleinigkeiten rumärgern war für mich immer BSD typisch. Anfangs gelächelt und es irgendwie „süß“ gefunden wurde es einfach anstrengend.

P.S. Nein, ich will hier nicht gegen BSD Wettern, ich mag die Struktur und Logik dahinter usw. aber für mich gilt, dass es läuft. Ich wette dieses HelloSystem wird wiederum den meisten hier nicht zusagen, sofern es nicht wieder in der Versenkung verschwindet, was echt schade wäre.

 

[Andy_m4]

Das habe ich niemals behauptet.

Dann kam das hier falsch an.

Korrekt. Warum sollte ein Entwickler also auf diese Vorteile verzichten und freiwillig mit schlechteren Tools als notwendig arbeiten?

Nicht falsch verstehen.
Ich bin da komplett bei Dir, das ein fehlen von OCI-Containern für viele Entwickler FreeBSD unattraktiv macht. Ich glaube halt nur nicht, das die Verfügbarkeit von OCI-Containern das ändert. Weil damit eh letztlich Linux-stuff gemacht wird und dann macht man das halt auch gleich unter Linux.

Sollte es unter FreeBSD trotzdem OCI-Container geben?
Ja klar. Lieber gestern als heute. Container sind ansich schon ne praktische Sache und wenn man auf vorhandene Tools aufbauen kann um dann Container zu bauen die dann unter FreeBSD direkt laufen ist das ne gute Sache.

Meine Einschätzung ist dabei aber (und womöglich liege ich damit auch falsch):
Es wird aber nicht im großen Stil Leute rüber ziehen. Denn der Kram läuft unter Linux gut. Warum sollen sie jetzt auf FreeBSD wechseln wo es allenfalls genauso gut läuft. Das ist nämlich genau die Situation mit der sich Linux auf dem Desktop seit Jahrzehnten rumquält. Das die Alternativsysteme gut genug sind und wenn ich jetzt von meinem Windows nach Linux wechsle dann hab ich da eben erst mal keinen großen Vorteil. Im Gegenteil. Ich muss noch damit rechnen, das meine bisherigen Anwendung nicht oder anders funktionieren als unter Windows.

Ich hoffe, ich konnte das jetzt endlich mal klar machen. :-)
Weil ich hab bei vielen Anmerkungen das Gefühl das Du mich in die OCI-Container braucht kein Mensch-Ecke stellen willst.

Umgekehrt wird ein Schuh daraus: mit FreeBSD bin ich vom einem großen Teil der Neuentwicklungen ausgeschlossen, die schon von 40% der Entwickler eingesetzt werden - Tendenz steigend.

Du fällst also immer weiter hinter den aktuellen Stand der Technik zurück; keine prickelnden Aussichten für einen Entwickler.

Ja schon klar. Ich hatte es ja auch mit einem Augenzwinkern geschrieben weil vorher es ja eher so rüber kam das 99,9% der Entwickler Container einsetzen und dann kommst Du plötzlich mit 40% um die Ecke, was ja dann doch ein deutlicher Abstand ist. :-)

Du kannst problemlos OCI-Container mit Windows, die auf Windows laufen und Linux nicht mal vom Hörensagen kennen, unter Windows mit verfügbaren Tools (ein willkürliches Beispiel hier) auf Sicherheitslücken scannen - eben weil es OCI-Container sind. Hier ist weit und breit kein Linux involviert.

Klar wird es immer mal einzelne Sachen geben die auch ohne Linux funktionieren. Aber Du bindest Dir nicht extra ein FreeBSD ans Bein wenn Du damit dann nur die Hälfte der Sachen machen kannst. Da bleibste doch lieber bei Linux wo Du 100% der Sachen machen kannst und keine Reibungsverluste durch zusätzliche Plattformen hast.

Unter Windows laufen OCI-Container produktiv, ganz ohne Linux. Wenn du willst, kannst du Windows-OCI-Container auf Windows-Hosts unter der Hoheit von diversen Orchestrierungsplattformen laufen lassen, ohne dass du irgendwo Linux in der Hand hättest.

Die Frage ist halt, wer macht das. Also klar wird das sicherlich vereinzelt vorkommen. Aber da sind wir wieder bei dem Punkt, den ich schon mehrfach ansprach. Nur allein eine Verfügbarkeit von OCI-Frameworks führt noch nicht automatisch dazu, das das dann im großen Stil benutzt wird.

Oder ist das jetzt z.B. unter Windows ne richtig große Sache die auch ganz viel benutzt wird?
(ich weiß es selbst nicht; deshalb frage ich)

Zumindest im Bereich der Softwareentwicklung sehe ich keinerlei Indikatoren, die für ein Revival von FreeBSD sprechen. Sofern du belastbare Belege für die Renaissance von FreeBSD in der Softwareentwicklung hast, immer her damit.

Also ich meinte jetzt allgemein. Nicht auf Softwareentwicklung begrenzt. Weil Du ja die User-Group erwähnt hattest und ich war so frei davon auszugehen, das da nicht nur Softwareentwickler drin sind.

Mich würde auch die Antwort auf die Frage interessieren: Welche Vorteile bietet mir FreeBSD gegenüber z.B. Arch Linux als Entwicklerplattform, was die Nachteile (u.a. kein Container-Support) mehr als kompensieren könnte?

Gar keine. Das war auch gar nicht der Punkt. Der Punkt war, würde der Arch-User zu FreeBSD wechseln, wenn da plötzlich der OCI-Container-Kram verfügbar wäre.

Wenn ich mir anschaue, wie sehr unsere Zivilisation von Code aus den 1960/70ern abhängt

Ja. Wobei alter Code nicht notwendigerweise schlechter Code sein muss. Das Problem ist aber, er ist es halt in der Praxis häufig.

Was ist denn dein praktikabler Lösungsvorschlag für das angesprochene Problem von Projektcode aus dem akademischen Umfeld, für den es keine Wartung gibt? Ich bin gespannt auf deine Lösungsvorschläge, das würde mich noch brennend interessieren.

An der Stelle möchte ich noch mal festhalten, das es mir nicht darum geht Container schlechtzureden. Im Gegenteil. Ich finde das Konzept gut. Man sollte es auch einsetzen.

Worums mir geht (und ich glaub das klang ja auch in meiner Anmerkung an) ist darauf hinzuweisen, das der Einsatz von Containern auch bestimmte Probleme überdecken kann. Das ist halt kein Ersatz dafür ordentliche Software zu schreiben. Teilweise wird das Problem noch verstärkt. Denn wenn Du so ne tolle moderne Microservice-Architektur hast und es halt kein Problem ist, wenn Dir ein Container wegstirbt weil der hat ja irgendwie nen Fallback oder ist ruckzuck neu gestarten etc. dann sinkt auch die Motivation die Ursachen von Problemen zu fixen. Der Leidensdruck ist dann halt nicht mehr da. Dementsprechend bleibt es liegen und man arbeitet lieber an dem nächsten Feature.

Wo wir aber hinkommen sollten ist die Softwarequalität zu verbessern. Das ist jetzt auch völlig unabhängig davon ob ich Container einsetze oder nicht. Die Technik kann ja ohnehin nix dafür, wenn sie falsch eingesetzt wird. Deshalb ist so ne Frage in die Richtung: Was soll man statt Container machen? auch völlig sinnfrei.

Und wenn die irgendwelchen Legacy-Code hast denn Du auch nicht mehr (aus was für Gründen auch immer) nicht fixen kannst, dann sind natürlich von mir aus auch containerbasierte Übergangslösungen denkbar. Aber halt als Übergangslösung bis man das ordentlich gemacht hat. Und nicht in Nichts-hält-länger-als-ein-Provisorium-Manier.

Die restliche Diskussion rund um Legacy-Code können wir gerne in einen eigenen Thread auslagern, wir sind eh schon ordentlich off-topic.

In der Tat. Einfach den MacOS-Thread weggekappert. Vielleicht sollte man für die Mac-User sicherheitshalber ein paar "Dont try this at home"-Warnschilder aufhängen. :-)

Mit Verlaub, so ein wenig kommt es mir vor als wolle man hier „sein System“ verteidigen - was an sich völlig menschlich und nachvollziehbar ist.

Wie ich ja im Verlaufe des Threads schon sagte: Jeder hat halt so seine individuellen Vorlieben. Der eine wird diese Arbeitsweise bevorzugen, der andere diese. Es gibt da bei vielen Dingen kein pauschales "das ist schlechter" oder "das ist besser".

Denn ich hatte gestern ca 70 Ordner und 140 Dateien und ganz sicher will ich mir da keine Mühe machen, nur die Ordner zu markieren. In jedem war eine Datei. Kurzerhand alles markiert und kopiert. Minimaler Aufwand.

Der Nerd wird dafür einfach seine Kommandozeile zücken und seinen Befehl eintippen den er braucht. Klar. Wenn die Alternative ist da irgendwie mit der Maus wild im Dateimanager rumzuklicken, dann ist auch vollkommen klar das der "Mac-Weg" hier einfacher ist. Das ist aber halt nicht die einzige Alternative.

Abgesehen davon gibts natürlich auch tatsächlich echte Ärgernisse.
Gerade das von Dir angesprochene unmounten-Problem wo der unmount nicht klappt weil irgendwie ein Prozess noch ne Datei offen hat und ähnlicher Kram
Wobei ich explizit für das Process belegt Mountpoint-Problem schon aufploppende Dialogboxen a-la "Kill all processes" gesehen hab. Weiß aber nicht mehr, wo das war. Jedenfalls gibts ganz sicher noch ne Menge Optimierungspotential.

Man sollte aber halt bloß aufpassen das wenn man etwas bemängelt das nicht zwangsläufig daran liegen muss, das jemand das nicht eingebaut hat weil "keine Lust" so und ob nicht bestimmte Dinge so sind wie sie, weil sie auch so sein sollen. Auch wenn das im Einzelfall bedeutet das es der individuell eigenen Arbeitsweise ein bisschen im Weg steht.

Weil sonst kommen wir ganz schnell dahin was Du anderen vorwirfst. Das jeder lediglich sein System verteidigen will.

 

[Columbo0815]

Mein Eindruck ist, dass du,@Lance, versuchst ein BSD, Ubuntu oder ein Windows so zu benutzen, wie du es von deinem macOS gewohnt bist. Das funktioniert so aber nicht. Umgekehrt auch nicht. Ich versuche hierbei nicht BSD zu verteidigen (mir ist es im Grunde völlig egal, welches System du nutzt), ich versuche dir zu zeigen, dass ich eine andere Erwartungshaltung von meinem System habe als du von deinem.

Jeder User, der sich mit seinem System offen auseinandersetzt, hat für das von dir geschilderte "Problem" eine Lösung. Häufig stellt sich das "Problem" erst gar nicht, da die Herangehensweise von Anfang an eine völlig andere ist. Wenn ich aber ohne Kompromissbereitschaft so vorgehen möchte, wie ich es von meinem System gewohnt bin, finde ich mindestens genauso viele Beispiele, bei denen macOS sich selbst im Weg steht. In deinem Beispiel verlangt niemand, dass du 70 Ordner einzeln markierst. Das ist vielleicht (!) nur deshalb erforderlich, weil du so vorgehst, wie du vorgehst.

Auch möchte ich kurz auf das USB-Stick-Problem eingehen. Mir ist es lieber, dass ich mal einen USB nicht direkt sauber entfernen kann, als dass mir mein Betriebssystem auf jedes Gerät ungefragt irgendwelche Dateien (zB .DS_Store) anlegt, bei denen ich nicht weiß, welche Daten enthalten sind. Es gibt (sicher auch unter Windows) Gründe, weshalb der Stick noch nicht bereit ist. Der "sync" ist noch nicht fertig oder ein Prozess hängt. Hierfür gibt es regelmäßig Lösungen (zB sync anstoßen oder Prozess beenden).

Ich denke wir sollten - auch unter Berücksichtigung, dass ich mich ebenfalls in Details verlaufen habe - langsam wieder zum eigentlichen Thema zurückkommen, wenn es nicht sogar schon abschließend geklärt ist.

 

[Lance]

versuchst ein BSD, Ubuntu oder ein Windows so zu benutzen, wie du es von deinem macOS gewohnt bist

Bis auf "...Windows..." - ja, stimmt absolut! Windows ist und bleibt Windows, da versuche ich nichts.

(zB .DS_Store) anlegt, bei denen ich nicht weiß, welche Daten enthalten sind

mit BlueHarvest sind das zwei Klicks und meist wenige Sekunden dann ist alles weg bzw sauber. Ein BSDler würde wohl das Terminal nehmen

Hierfür gibt es regelmäßig Lösungen (zB sync anstoßen oder Prozess beenden).

Dann soll Ubuntu mir das sagen dass es hängt und nicht schweigen, so dass ich raten kann ob da jetzt was hängt oder nicht. Oft sagt Ubuntu auch dass es noch nicht ausgeworfen werden kann. Aber eben wohl nicht immer. NoGo! Ich fand das mit 18.04 schon heftig, und auch mein einziger dicker krititpunkt seitens Ubuntu bzw deren Gnome3 Ableger. Sowas geht in meinen Augen gar nicht! (Da hat mir MATE unter GhostBSD besser gefallen und mit einem Terminalbefehl lässt sich JEDES mal auch das Laufwerk sicher entfernen, aufwändiger aber funktioniert). Wie gesagt bei 20.04 ist es deutlich besser. Aber ich habe das Gefühl, dass das "Stock Gnome3" also z.B. bei Fedora das ganze "sauberer" erledigt. Dort hatte ich diese Probleme bislang nicht! (Wieder der Fall der zig Desktop-Ableger und somit Frickeleien die nicht sauber funktionieren... würde jede Distribution einen Stock Gnome nehmen... aber nein, muss jeder seinen Kram reinpacken..., das ist dann wieder schön bei FreeBSD, dort sollte man ja auch ein Stock-Gnome bekommen und nicht irgendwelche Philosophien die dann zu Problemen führen.)

 

[Alexco]

Mir ist es lieber, dass ich mal einen USB nicht direkt sauber entfernen kann, als dass mir mein Betriebssystem auf jedes Gerät ungefragt irgendwelche Dateien (zB .DS_Store) anlegt, bei denen ich nicht weiß, welche Daten enthalten sind.

Immer diese versteckten Seitenhiebe. Das Verhalten kann man auch abschalten. Und was da drin ist, bzw. wofür die gut sind, ist auch bekannt.
Wie ich schon irgendwann vorher geschrieben habe, jedes OS ist anders. Ich beschwere mich auch nicht, wenn Amiganoide ihre .info Dateien brauchen, oder Windows Dateitypen nur anhand der Endung erkennen kann. Leider ein Punkt, der ohne Rücksicht von fast allen Open Source Desktops kopiert wurde.

 

[Azazyel]

Weil ich hab bei vielen Anmerkungen das Gefühl das Du mich in die OCI-Container braucht kein Mensch-Ecke stellen willst.

Keineswegs. Ich war nur irritiert von "bleibt halt nur ein bisschen Erleichterung in der Entwicklung was ich aber auch so hinkriege", was ich mit meinen Erfahrungen nicht in Einklang bringen konnte.

Oder ist das jetzt z.B. unter Windows ne richtig große Sache die auch ganz viel benutzt wird?
(ich weiß es selbst nicht; deshalb frage ich)

Ich kenne zumindest einige Softwareprojekte auf Azure, die gleich in Windows-Containern gestartet sind. Es ist aber (noch) weit entfernt von der Bedeutung von Containern in der Linux-Welt.

Der Punkt war, würde der Arch-User zu FreeBSD wechseln, wenn da plötzlich der OCI-Container-Kram verfügbar wäre.

OCI-Container unter FreeBSD würden die Nutzerzahlen von FreeBSD nicht explodieren lassen, aber zu mehreren Effekten führen:

• Mehr Power-User würden FreeBSD als "daily driver" mal eine Chance geben
• Weniger Power-User würden einen Migrationsdruck von FreeBSD Richtung Linux spüren
• Firmen mit existierender FreeBSD-Landschaft hätten einen großen Grund mehr, weiterhin auf FreeBSD zu setzen

Inwieweit das valide Gründe für OCI-Container auf FreeBSD sind, möge jeder selbst beurteilen. Für mein Dafürhalten würden aber alle Gründe FreeBSD stärken.

Wieder der Fall der zig Desktop-Ableger und somit Frickeleien die nicht sauber funktionieren... würde jede Distribution einen Stock Gnome nehmen... aber nein, muss jeder seinen Kram reinpacken..., das ist dann wieder schön bei FreeBSD, dort sollte man ja auch ein Stock-Gnome bekommen und nicht irgendwelche Philosophien die dann zu Problemen führen.

Alles eine Frage der Wahl der richtigen Distribution. Unter anderem Arch Linux liefert (nicht nur) GNOME ohne Anpassungen aus.