Interesse an FreeBSD rückläufig? Schwächen und Stärken von FreeBSD.
- Ersteller satriani
- Erstellt am
Andy_m4
Well-Known Member
Vielleicht ist es ja gar nicht provokant gemeint, sondern Du empfindest es nur als provokant. Diese Möglichkeit sollte man auch in Betracht ziehen. Nicht nur immer beim Anderen gucken, was der falsch macht. Sondern auch bei sich selber.
Es kommt auch sehr viel drauf an, welche Erwartungshaltung man gegenüber einem Diskussionsforum hat.
Also ich sehe es eher als eine Plattform des Austausches und durchaus (und gerne) auch mit kontrovers diskutierten Meinungen. In dem Wissen, das ich selbst nur ein eingeschränkten Blickwinkel hab hilf mir jemand mit einer anderen Meinung ja evtl. dabei bestimmte Dinge mal aus einem anderen Blickwinkel zu betrachten. Und das kann ja nur gewinnbringend sein. Dafür nehme ich dann auch gern in Kauf, das mein Gegenüber vielleicht auch mal eine saloppe Wortwahl an den Tag legt.
Mag ja sein, das Du eine bestimmte Diskussion nicht führen willst. Weil sie Dich nicht interessiert oder weil Dich die Argumente nicht überzeugen. Das ist auch alles ok.
Aber dann sollte man das auch klar so sagen.
Unglücklich empfinde ich es immer, wenn man sich aus einer Diskussion rauszieht und versucht das über sachfremde Themen mit Schuldzuweisung zu anderen zu rechtfertigen. "Du bist mir zu provokant. Mit Dir rede nicht nicht mehr".
Das wirkt nicht nur kindisch, sondern macht auch den Eindruck als hätte man keine Argumente her und zieht deshalb so was an den Haaren herbei, um sich dann aus der Affäre zu ziehen.
Ich sag nicht, das es so ist. Aber so wirkt das halt (auf mich).
Möglicherweise macht man das auch unbewusst. Der Mensch neigt ja dazu, Kritik an Sachen die er selbst benutzt zu negieren. Denn das Eingeständnis das die Kritik berechtigt ist würde ja auch irgendwo implizieren, das man auf falsche System gesetzt hat. Also selber ein Fehler gemacht hat und das gesteht man sich ja nicht gerne ein. :-)
Davon sollte man versuchen sich zu lösen. Denn nur so kann man sich weiter entwickeln und offen für neue Perspektiven bleiben. Das ist nicht einfach. Ich ertappe mich ja auch oft selbst dabei, wie ich in diese Falle laufe. Versuchen ein Auge darauf zu haben kann aber sicherlich nicht schaden.
Ich weiß nicht, ob und was davon was ich hier schreibe zutreffend ist oder nicht und ich erwarte auch keine Antwort. Aber wenn sich jemand angesprochen fühlen sollte, kann er ja vielleicht mal in sich gehen und darüber nachdenken.
Aber genug der Predigten. Lasst uns weiter flamen. :-)
Ne, ich will hier weder "flamen" noch mich auf einen Diskussionsstil einlassen, den ich sinnlos finde. Kurz gesagt, ich habe kein Interesse an eristischer Dialektik. Und ja, ich habe keine Argumente, die nicht schon genannt wurden. Diese zu wiederholen wäre also sinnlos und langweilig. Eine Verteidigung gegen rhethorische "Kunstgriffe" würde andererseits zwangsläufig zum "flame" führen. Ich halte mich daher hier am besten an mr44ers guten Rat 
Pardon, wenn ich mich missverständlich ausgedrückt habe. Es war nicht provokant gemeint - ich möchte wissen, wie andere die Standard-Linux-Container-Workflows unter FreeBSD abbilden. Ich kann mir nicht vorstellen, dass ich der einzige bin, der vor dieser Frage steht.
Ich hätte mir anhand deines Satzes
erhofft, du verrätst mir anhand meines 08/15-Docker-Workflows, wie ich das unter FreeBSD abbilden kann - so à la "unter FreeBSD geht das konzeptionell etwas anders; wir haben das in der Firma mittels BastilleBSD, ZFS send/recv plus X so und so gelöst - das Problem Y haben wir dabei durch Z umgangen".
Zwecks Perspektiven bin ich auf das Thema Container eingegangen. Ich habe einige kleine bis mittlere FreeBSD-Kunden, die seit vielen Jahren mit FreeBSD zufrieden sind - oder eher waren.
Nachdem man dort in der IT wie an den meisten Stellen jahrelang so sein Ding gemacht hat, kommen jetzt dort nach Überwindung des initialen COVID-19-Schocks viele Dinge auf den Prüfstand. So wird auch die Frage gestellt, ob man in Sachen Unternehmens-IT richtig aufgestellt ist.
Bei einem Mittelständler kocht es gerade richtig hoch. Unter dem COVID-19-Ansturm ist die auf FreeBSD selbstgehostete Anwendung zusammengebrochen (was nicht an FreeBSD lag). Ein paar engagierte Entwickler haben die Anwendung in Rekordzeit in einen Linux-Container gepackt und quasi über Nacht mittels AWS ECS wieder live gesetzt, wo sie anstandslos den Ansturm bewältigt hat. Nach der initialen Aufregung und Empörung über diese U-Boot-Aktion war das Management in Anbetracht von einigen Millionen Euro Mehrumsatz bei überschaubaren Kosten recht angetan.
Nach vielen Erklärungen fürs Management kam im Nachgang natürlich die Frage auf, wie sich das mit dem existierenden Selbsthosting und FreeBSD in der Art und Weise umsetzen lässt. Verständlicherweise ist durch die Antworten "gar nicht" und "gar nicht" jetzt beides auf dem Prüfstand.
Bei anderen (vor allem kleineren) Kunden sind es vor allem die engagierten Entwickler, die jetzt die Chance nutzen, träge Entwicklungs- und Betriebsprozesse öffentlich zu hinterfragen. Dort werden oftmals durch eine Container-Live-Demo nicht nur überholte Verfahren, sondern gleichzeitig auch FreeBSD als Kollateralschaden in Frage gestellt - unabhängig vom tatsächlichen Mehrwert von Containern für den Kunden.
Als alter Hasen werde ich jetzt natürlich auch um Rat gefragt. Viele Kunden kenne ich schon seit Jahren und habe teilweise bei ihnen FreeBSD eingeführt. Momentan tue ich mich mit einer Antwort schwer.
Die neuen Zöpfe sind meistens - nicht immer - weniger fettig und strähnig sowie deutlich pflegeleichter und schöner anzufassen.
Das würde ich in der Allgemeinheit nicht unterschreiben; klingt aber nach einem Thema für einen eigenen Thread.
Andy_m4
Well-Known Member
Ja. Ich sag ja auch nicht generell, das diese Dinge schlecht sind. Aber sie sind mittlerweile halt recht komplex. Das heißt, solange es in Ordnung ist läuft es auch ganz anständig. Aber wehe Du hast mal ein Problem. Dann hast Du kaum noch eine Chance den Fehler zu finden.
Man muss sich ja einfach nur angucken, wie sich so die Qualität der Software verändert hat.
Früher (also jetzt wirklich früher und nicht irgendwie vor 10 oder 20 Jahren) da hat Software funktioniert. Und wenn sie nicht funktioniert hat, dann hat man bei sich selber geguckt ob man einen Fehler gemacht hat. Man wäre nicht so schnell auf die Idee gekommen, das ein Fehler in der Software liegen könnte. Und warum war das so?
Weil es halt auch in 99% der Fälle so war das man selbst Unsinn gebaut hat und das Programm ansich korrekt gearbeitet hat.
Das ist total gekippt. Heute gibt man als Anwender der Software die Schuld. Warum? Weils halt in 99% der Fälle so ist, das es irgendein Bug ist oder so.
Inzwischen sind die Leute aber so schmerzfrei geworden, das sie das gar nicht mehr wahrnehmen. Und es wird dem Fehler auch nicht mehr auf dem Grund gegangen, sondern er wird akzeptiert.
Das äußert sich in Äußerungen wie "Musst Du mal neu booten." oder "Installier mal frisch neu" oder "Trenn mal das Gerät für 1 Minute vom Stromnetz". usw. usw. usw.
Du hast also tägölich mti einem Haufen Bugs zu tun die gar nicht mehr hinterfragt werden, sondern mit irgendwelchen Holzhammermthoden erschlagen werden.
Das ist inzwischen auch schon längst in Software gegossen. Da hast Du dann halt irgendein watchdog der guckt nach Prozessen und wenn die abschmieren startet der die einfach wieder neu. Man macht sich oft deshalb also nicht mal mehr die Mühe Bugs auf den Grund zu gehen oder gar zu fixen, weil "läuft doch auch so".
Hier schlägt übrigens auch schön das Komplexitätsproblem zu. Weil jetzt hast Du halt nicht mehr nur Dein Service-Prozess, sondern einen weiteren Prozess der darauf aufpasst. Nur auch der kann ja kaputt gehen. Und was machste dann? Ein watchdog für den watchdog?
Containerlösungen gehen ja in eine ähnliche Richtung. Man macht sich gar nicht mehr die Mühe Software so zu schreiben, das sie sauber getrennt ist. Man schludert irgendwas hin und packt das halt in einen Container (wo das Programm dann wüten kann als hätte es den Rechner für sich alleine). Jetzt hast Du aber nicht nur das Programm, was kaputt gehen kann, sondern auch noch den Container.
Und wenn Du viele Container hast ist sowieso umständlich also packen wir noch Kubernetes drauf (also noch mehr Komplexität).
Zum Schluss hast Du halt ein riesigen Berg an irgendwelchem Kram. Und der Anteil an diesem Berg der die eigentliche Aufgabe erledigt, die Du erledigt haben willst wird immer kleiner.
Aber Du brauchst eigentlich dafür gar nicht bei Containern gucken. Schon allein auf Programmlevel hast Du ja in Form von Frameworks und anderen Abstraktionslayern so viel Kram drin, das ist echt nicht mehr schön.
Ich will das nicht alles schlecht reden. Klar gibt es für solche Sachen auch vernünftige Gründe die einzusetzen.
Das Problem ist eher, das sie heute so inflationär eingesetzt werden. Und dann so, das Du auch gern und schnell den Überblick verlierst. Wie oft hatte man schon mit Sicherheitsproblemen in Programmen zu tun, weil die gegen irgendeine Uralt-Bibliothek gelinkt war und ähnliche Geschichten.
Im kommerziellen Sektor wird dies alles noch dadurch begünstigt, das kurzfristige Profite mehr zählen als Langfristigkeit. Der Manager will halt gute Quartalszahlen haben. Also werden Schnussschusslösungen bevorzugt. Bugfixing wird auf später (in Klartext: nie) verschoben. Und wenn einem die Sachen irgendwann um die Ohren fliegen, wen juckts? Der zuständige Manager ist dann schon längst in der nächsten Firma. Und wenn nicht, tritt er halt zurück und nimmt noch ne Abfindung mit.
Du hast halt auch oft Bedingungen, die Pfuschlösungen bevorzugen. Und den Kunden hat man ja jahrelang erfolgreich eingeredet, das Fehler in Software unvermeidbar sind und dazu gehören.
derOliver
Systemheld
Nur CUPS, mdnsresponder, Objective C, Swift und ordentlich Arbeit an LLVM und KHTML (als Fork WebKit). Es hab sogar mal OpenDarwin mit dem man versucht hat ein Ökosystem neben macOS aus dem xnu (auch Open Source) zu schaffen. Klar da ginge mehr, aber es ist ja nicht so dass die gar nix zurück geben.
Schau dich mal auf opensource.apple.com um, du wirst überrascht sein.
Den Link den ich da gepostet habe... das war einer von vielen. Davor schon gefühlt 7 mal ähnliche Überschriften gesehen, ohne Covid 19. Nie durchgelesen weil es mich in der Tiefe nicht interessiert. Solaris wird vielleicht noch seinen Platz haben, aber eben nie wieder als Desktop/Workstation.
Dachte halt aufgrund solcher Überschrift dass diese Technologien durchaus gefragt sind. Ich war aber etwas überrascht wenn Jails oder auch bhyve genannt wurden.
Dachte halt aufgrund solcher Überschrift dass diese Technologien durchaus gefragt sind. Ich war aber etwas überrascht wenn Jails oder auch bhyve genannt wurden.
Apple hat früher viel an FreeBSD zurückgegeben, hauptsächlich Bugfixes im Userland, aber nach und nach ist es weniger geworden und vor so 10 bis 12 Jahren mehr oder weniger eingeschlafen. Das mag auch daran gelegen haben, dass Darwin und FreeBSD damals schon sehr weit divergiert waren und inzwischen 20 Jahre auseinander liegen. Ich glaube nach dem initialen Import zu FreeBSD 3.x / 4.x, als Apple aus NextStep sein OS X gemacht hat, hat Apple nie wieder größere Mengen Code aus FreeBSD übernommen. FreeBSD entwickelte sich in die eine, Darwin in die andere Richtung...
Andy_m4
Well-Known Member
CUPS: Ja. Stimmt. Besonders den Schritt Sachen zu entfernen, die Apple nicht brauchte (aber u.a.halt die Linux-Leute), da waren einige echt angepisst von. :-)
So eine ähnliche Geschichte gabs auch bei KHTML/Webkit. Auch da hat sich Apple viele "Sympathiepunkte" in der Open-Source-Community erworben. :-)
Objective-C und Swift haben außerhalb des Apple-Ökosystems nie wirklich Fuß gefasst.
mdnsresponder: Genau. Wird auch weithin eingesetzt. Niemand tut sich Avahi an :-)
LLVM: Lasse ich gelten. Ein tolles Projekt.
Du meinst die gute alte Unix-Zeit von "he who does not check input before - dumps core", als Kommandozeilen-Utilities bei unbekannten Parametern gerne mal Coredumps geworfen haben? Oder bei gültigen Parameter-Konstellationen, die ihnen in Kombination nicht gefallen haben und zum Coredump geführt haben?
Ich kann mich auch noch an SunOS & Co. und viele Kernel Panics erinnern.
Oder meinst du die gute alte Zeit noch früher, als man noch keine Probleme mit Netzwerken hatte, weil man keine Netzwerke hatte?
Was war früher besser? Das ein Admin eingreifen und den Prozess manuell neu starten musste?
Kommt auf das Umfeld, die Budgets und die Prioritäten an.
Der Watchdog ist so simpel, dass dort nicht viel schiefgehen kann. Falls du mehr Aufwand treiben möchtest, kannst du dich noch um die formale Verifikation deiner Software bemühen. Dann musst du aber sehr viel Geld und sehr viel Zeit mitbringen.
Falls wir so in den klassischen Unix-Einsatzbereich schauen, baut man inzwischen Software normalerweise so, dass idealerweise jeder Teil ausfallen kann (Software wie Hardware) und trotzdem noch der Betrieb gewährleistet ist.
Für deine Software macht es in erster Näherung keinen Unterschied, ob sie auf Blech, in einer VM oder in einem Container läuft. Deine Software wird erstmal nicht besser oder schlechter, wenn du sie von heute auf morgen in einen Container packst.
Container sind keine Raketenwissenschaft. Erstmal ist der Container nur ein Prozess mit etwas mehr Isolation als ein normaler Prozess durch Funktionen wie cgroups, namespaces und dergleichen: https://jvns.ca/blog/2016/10/10/what-even-is-a-container/
Auf dem Weg zum nächsten Punkt gibt es jetzt noch einige Zwischenschritte und Betrachtungen, die ich in Anbetracht der späten Stunde mal überspringe.
Kubernetes ist momentan ein ziemlicher Hype - der Hype kommt aber nicht von ungefähr. Für den Betrieb einer Hallo-Welt-Anwendung ohne jegliche Ansprüche an Verfügbarkeit ist es natürlich Overkill, vor allem wenn man es selber hochverfügbar betreiben möchte (was (noch) nicht trivial ist).
Auf der anderen Seite muss ich sagen: was Kubernetes ermöglicht - brilliant.
Im Gegenteil: Container und das damit verbundene Ökosystem ermöglichen es uns heute in vielen Fällen, mit weniger Aufwand qualitativ höherwertige Software zu entwickeln, besser zu testen und zuverlässiger zu betreiben.
Es ist immer eine Gratwanderung, das richtige Maß zwischen zuviel und zuwenig Abstraktion zu finden. Die ganzen Bibliotheken, Frameworks und Abstraktionslayer ermöglichen natürlich aber auch eine enorme Produktivität.
Es hat schon einen Grund, warum Container gerade eben einer der Gründe schlechthin sind, warum Linux in vielen Firmen FreeBSD verdrängt - unabhängig von den großen Firmen hinter Linux, proprietärer Software die nur auf Linux läuft, dem besseren Marketing rund um Linux, der Bekanntheit von Linux durch Android und all den anderen Gründen, die hier regelmäßig genannt werden.
Falls Interesse besteht, kann ich mit der BSD-Brille aus dem IT-Alltag in Firmen erläutern, wie FreeBSD mit einer konkurrenzfähigen Container-Lösung wieder viel Boden gut machen und Abwanderung zu Linux verhindern könnte.
Man kann seine Software warten, man muss aber nicht.
In börsennotierten Aktiengesellschaften, ja.
Je nach Unternehmen, ja.
Darüber kann man einen eigenen Thread starten.
pit234a
Well-Known Member
Also, fachlich nur auf die Features bezogen, kann man diese Diskussion wohl nicht führen.
Ich denke, man muss die unterschiedlichen Entwicklungsumgebungen im Blick haben. Linux, also der Kernel, denn an GNU wird ja so gut wie nichts mehr gebastelt, wenn ich das richtig sehe, wird von einigen, wenigen Leuten entwickelt. Diese geben die Richtung vor. Das ist mehr oder weniger Liebhaberei, was die Entwickler in ihrer Freizeit tun. Dann aber kommt GNU/Linux zu einigen Unternehmen, die Man-Power und Geld in die Entwicklung stecken. Ich nenne nur zwei: RedHat und Ubuntu. Da ist professionelles Engagement im Spiel und die, sowie einige andere Unternehmen, haben ein Interesse daran, "im Markt präsent" zu sein. Das bedeutet, sie fördern Entwicklungen, die nachgefragt werden und zwar nicht aus altruistischen Motiven heraus. Und aus ihrer Präsenz am Markt fließen auch wieder Gelder und damit Entwicklungsmöglichkeiten zurück. Das beschleunigt sich quasi selbst.
Dieser Beschleunigungsmechanismus ist FreeBSD nicht zu eigen, denn es ist nach wie vor ein akademisches Projekt, das aus einem Selbstzweck heraus betrieben wird. Man hat überhaupt gar kein Interesse daran, am Markt präsent zu sein. Es wird oft so ausgedrückt, dass es sich nicht anbiedert. Ich sage mal so: was der Anwender wünscht, ist den Entwicklern egal, die haben eigene Interessen und Ziele.
Nun reden wir über Drittparty-SW, ohne die ja kaum eines der Systeme auskommt.
Grundsätzlich ist alles, was Open-Source ist, allen Systemen zugänglich.
Es wird aber deutlich Linux-Zentrisch entwickelt und ich kann mir vorstellen, dass die Beliebtheit von Linux da nicht unbedingt an der GPL liegt, bin mir aber auch nicht sicher. Wir erinnern uns ja des Rosenkrieges um cdrecord und an die Entstehung von LibreOffice aus OpenOffice. Vielleicht ist gerade letzteres ein gutes Beispiel, denn die Entwickler hätten ja zB auch die FreeBSD-Lizenz wählen können, oder die EU-PL oder so etwas, nahmen aber die L-GPL. Also ist es ganz offenbar so, dass sich viele Entwickler unter einer GPL wohl fühlen und das Ergebnis gibt ihnen Recht: durch die GPL fließen Entwicklungen immer in die Comunity, unter der FreeBSD-Lizenz bleiben sie womöglich in einem einzigen Unternehmen hängen. Wenn alle wissen dürfen, wie etwas geht, können auch alle daran mitarbeiten und es weiter entwickeln. Obwohl mir persönlich auch die Idee hinter der GPL tatsächlich gut gefällt, meine ich das hier nicht ideologisch, sondern sehe einfach nur einen Grund, weshalb sich einfach unter der GPL viel mehr öffentlich tut.
Wenn nun eine SW Rücksicht auf Spezialitäten nimmt, die es nur in Linux gibt, wie etwa udevd oder systemd, dann fällt es anderen Systemen zunehmend schwer, das noch mit zu machen. Und die Linux-Entwickler, also, die in Firmen arbeiten und abgesichert sind, die sagen immer häufiger: "interessiert uns nicht. Wir machen unser Ding, wenn ihr nicht mitmachen wollt, dann müsst ihr halt sehen, wo ihr bleibt".
Das ist nichts anderes, als das, was FreeBSD schon immer sagt.
Meine Befürchtung ist deshalb auch eher, dass es immer schwieriger für die FreeBSD Ports-Maintainer wird, von denen es außerdem auch immer weniger gibt.
FreeBSD wird sicher noch lange weiter bestehen, es wird womöglich immer mehr an Bedeutung verlieren und das ist diesen, nunja, ich sage es trotzdem es natürlich provokativ gemeint ist, diesen "weltfremden Akademikern in ihrem Elfenbeinturm" auch ganz egal. Die reiben sich nicht an Bedürfnissen irgendwelcher Leute von außen, weder an den Ansprüchen eines Endverbrauchers, noch an denen von Unternehmen, weder Unternehmen der IT, noch der Industrie.
Nimm es, oder lass es.
Achso. ZFS, als großartiger Vorteil von FreeBSD hier mehrmals genannt, passt genau in die gleiche Schiene, wie oben kurz angesprochen cdrecord. ZFS ist eine super Sache, aber sie floss nur deshalb so problemlos in FreeBSD ein, weil die unterschiedlichen Lizenz-Modelle dies zuließen. Es war mitnichten eine Entwicklung aus dem FreeBSD-Elfenbeinturm. Das sollte man nicht vergessen.
Überhaupt scheinen mir Entwicklungen bei FreeBSD immer nur von wenigen Einzelpersonen auszugehen. Und wenn diese besonders enthusiastisch sind, halten auch die es im Elfenbeiturm nicht aus und wir bekommen OpenBSD und DragonFly-BSD.
So lange ich das sehen kann, ist FreeBSD kein innovatives System. Es ist träge reaktiv, aber nicht innovativ, nie gewesen und es scheint sich so auch selbst zu gefallen und selbst zu genügen.
Mir selbst tut das gut, denn ich liebe langsame Entwicklungen. Ich bin kein IT-Freak und möchte mich nicht jeden Monat für irgendeine Neuheit interessieren.
Deshalb passt FreeBSD gut zu mir und ich werde es nutzen, so lange das geht.
Ich erwarte aber gar nicht, dass es sich für irgendwelche Bedürfnisse seiner Anwender interessiert. Im Gegenteil. Ich hoffe, dass es noch lange so bleibt, wie es ist und dass einige Maintainer mir möglichst lange die wichtigsten Ports erhalten.
Ich denke, man muss die unterschiedlichen Entwicklungsumgebungen im Blick haben. Linux, also der Kernel, denn an GNU wird ja so gut wie nichts mehr gebastelt, wenn ich das richtig sehe, wird von einigen, wenigen Leuten entwickelt. Diese geben die Richtung vor. Das ist mehr oder weniger Liebhaberei, was die Entwickler in ihrer Freizeit tun. Dann aber kommt GNU/Linux zu einigen Unternehmen, die Man-Power und Geld in die Entwicklung stecken. Ich nenne nur zwei: RedHat und Ubuntu. Da ist professionelles Engagement im Spiel und die, sowie einige andere Unternehmen, haben ein Interesse daran, "im Markt präsent" zu sein. Das bedeutet, sie fördern Entwicklungen, die nachgefragt werden und zwar nicht aus altruistischen Motiven heraus. Und aus ihrer Präsenz am Markt fließen auch wieder Gelder und damit Entwicklungsmöglichkeiten zurück. Das beschleunigt sich quasi selbst.
Dieser Beschleunigungsmechanismus ist FreeBSD nicht zu eigen, denn es ist nach wie vor ein akademisches Projekt, das aus einem Selbstzweck heraus betrieben wird. Man hat überhaupt gar kein Interesse daran, am Markt präsent zu sein. Es wird oft so ausgedrückt, dass es sich nicht anbiedert. Ich sage mal so: was der Anwender wünscht, ist den Entwicklern egal, die haben eigene Interessen und Ziele.
Nun reden wir über Drittparty-SW, ohne die ja kaum eines der Systeme auskommt.
Grundsätzlich ist alles, was Open-Source ist, allen Systemen zugänglich.
Es wird aber deutlich Linux-Zentrisch entwickelt und ich kann mir vorstellen, dass die Beliebtheit von Linux da nicht unbedingt an der GPL liegt, bin mir aber auch nicht sicher. Wir erinnern uns ja des Rosenkrieges um cdrecord und an die Entstehung von LibreOffice aus OpenOffice. Vielleicht ist gerade letzteres ein gutes Beispiel, denn die Entwickler hätten ja zB auch die FreeBSD-Lizenz wählen können, oder die EU-PL oder so etwas, nahmen aber die L-GPL. Also ist es ganz offenbar so, dass sich viele Entwickler unter einer GPL wohl fühlen und das Ergebnis gibt ihnen Recht: durch die GPL fließen Entwicklungen immer in die Comunity, unter der FreeBSD-Lizenz bleiben sie womöglich in einem einzigen Unternehmen hängen. Wenn alle wissen dürfen, wie etwas geht, können auch alle daran mitarbeiten und es weiter entwickeln. Obwohl mir persönlich auch die Idee hinter der GPL tatsächlich gut gefällt, meine ich das hier nicht ideologisch, sondern sehe einfach nur einen Grund, weshalb sich einfach unter der GPL viel mehr öffentlich tut.
Wenn nun eine SW Rücksicht auf Spezialitäten nimmt, die es nur in Linux gibt, wie etwa udevd oder systemd, dann fällt es anderen Systemen zunehmend schwer, das noch mit zu machen. Und die Linux-Entwickler, also, die in Firmen arbeiten und abgesichert sind, die sagen immer häufiger: "interessiert uns nicht. Wir machen unser Ding, wenn ihr nicht mitmachen wollt, dann müsst ihr halt sehen, wo ihr bleibt".
Das ist nichts anderes, als das, was FreeBSD schon immer sagt.
Meine Befürchtung ist deshalb auch eher, dass es immer schwieriger für die FreeBSD Ports-Maintainer wird, von denen es außerdem auch immer weniger gibt.
FreeBSD wird sicher noch lange weiter bestehen, es wird womöglich immer mehr an Bedeutung verlieren und das ist diesen, nunja, ich sage es trotzdem es natürlich provokativ gemeint ist, diesen "weltfremden Akademikern in ihrem Elfenbeinturm" auch ganz egal. Die reiben sich nicht an Bedürfnissen irgendwelcher Leute von außen, weder an den Ansprüchen eines Endverbrauchers, noch an denen von Unternehmen, weder Unternehmen der IT, noch der Industrie.
Nimm es, oder lass es.
Achso. ZFS, als großartiger Vorteil von FreeBSD hier mehrmals genannt, passt genau in die gleiche Schiene, wie oben kurz angesprochen cdrecord. ZFS ist eine super Sache, aber sie floss nur deshalb so problemlos in FreeBSD ein, weil die unterschiedlichen Lizenz-Modelle dies zuließen. Es war mitnichten eine Entwicklung aus dem FreeBSD-Elfenbeinturm. Das sollte man nicht vergessen.
Überhaupt scheinen mir Entwicklungen bei FreeBSD immer nur von wenigen Einzelpersonen auszugehen. Und wenn diese besonders enthusiastisch sind, halten auch die es im Elfenbeiturm nicht aus und wir bekommen OpenBSD und DragonFly-BSD.
So lange ich das sehen kann, ist FreeBSD kein innovatives System. Es ist träge reaktiv, aber nicht innovativ, nie gewesen und es scheint sich so auch selbst zu gefallen und selbst zu genügen.
Mir selbst tut das gut, denn ich liebe langsame Entwicklungen. Ich bin kein IT-Freak und möchte mich nicht jeden Monat für irgendeine Neuheit interessieren.
Deshalb passt FreeBSD gut zu mir und ich werde es nutzen, so lange das geht.
Ich erwarte aber gar nicht, dass es sich für irgendwelche Bedürfnisse seiner Anwender interessiert. Im Gegenteil. Ich hoffe, dass es noch lange so bleibt, wie es ist und dass einige Maintainer mir möglichst lange die wichtigsten Ports erhalten.
Dazu müssten sie teilweise die gleiche Einstellung haben wie du!
Ich hoffe dass FreeBSD sich noch steigern kann, dass es dabei im grossen und ganzen seiner Philosophie treu bleibt und treu bleiben KANN und seinen festen Platz beibehält und stets interessant genug ist damit wir weiterhin unser GhostBSD oder halt Desktopumgebung und unsere Anwendungen weiterhin benutzen können und Freude dran haben.
Aber in grossen und ganzen würde ich denken dass das Interesse insgesamt etwas zunimmt und die Zukunft durchaus interessant sein kann.
Weiterhin frohes Schaffen :-)
(anbei heute über 30 Stellen mit FreeBSD, bei indeed.. oder war das Stepstone? Jedenfalls nicht soo schlecht!)
Andy_m4
Well-Known Member
Ich sag ja nicht, das es früher keine Probleme oder Fehler gab. Aber in der Tendenz war es besser. Darum hab ich ja auch die Verhaltensweisen von heute vs. früher beschrieben. Die kommen ja nicht von ungefähr.
Ist übrigens auch logisch, warum früher die Programme "besser" waren. Zum einen waren sie natürlich kleiner. Aber es gab noch nen anderen Grund. Es gab nämlich kein Internet. Das heißt, wenn Du irgendwie ein Programm ausgeliefert hast, dann war das durchaus eine Weile unterwegs und auch relativ lange unverändert in Gebrauch.
Heute ist es eher so, das man eine Software leichtfertiger raushaut. Weil "wenn was ist", kann man ja updaten. Das setzt halt den Anreiz eben nachlässiger bei Tests zu sein und erst dann zu reagieren, wenn sich jemand beschwert. Man wälzt damit quasi den Testaufwand an den Kunden ab.
Windows 10 ist ein schönes Beispiel dafür. :-)
Zwangsupdates für die Home-User. Das sind unsere Betatester. Die Business-Kunden kriegen dann den Kram, der sich beim einfachen Pöbel bewährt hat. Und die Betatester müssen die Bugs nicht mal aktiv melden (machen die eh nicht; jedenfalls nicht in der Masse). Dafür haben wir Spionage ähm ... meinte Telemetrie eingebaut.
Früher war der Leidensdruck da, das Problem zu fixen. Heute ist der nicht mehr da.
Das führt dazu, das Bugs länger bestehen bleiben.
Danke. Aber mir ist sehr bewusst was Container sind.
Nichtsdestotrotz führen sie mehr Komplexität ein.
Du darfst das auch nicht verwechseln mit Komplexität in der Bedienung. Die Bedienung wird zweifelsohne einfacher. Auch die Automatisierung von vormals maneullen Prozessen führt zur Verringerung an Fehlern, weil Du halt nicht mehr einfach mal ein Handgriff vergessen kannst.
Die Komplexität des Systems steigt aber.
Jaja. Genau. Du redest wie ein Vertreter. :-)
Gucken wir mal in die Realität. Da treten immer noch Sachen wie BufferOverflows, fehlende Längenprüfung etc. auf. Also eine Klasse von Bugs, wo Du eigentlich schon seit 20 Jahren nicht mehr wirklich rechtfertigen kannst, die drin zu haben.
Und die Leute, die halt beim Programmieren sonst immer geschlampt haben, denen unterstellst Du jetzt, das sie bei Ihrem Container alles richtig machen, richtig konfigurieren, richtig abdichten?
Merkst selbst, oder? :-)
Bei Open-Source-Projekten ist die Situation auch immer noch relativ gut, weil die Macher immer damit rechnen müssen, das doch mal jemand anderes in den Quelltext rein guckt. :-) Und dann will man sich natürlich nicht die Blöße geben da offensichtlich Pfusch gemacht zu haben.
Sobald Du Programme hast, wo keiner rein gucken kann schnellt der Pfuschlevel extrem in die Höhe.
Ironischerweise ist Microsoft da noch eine der Vorzeigefirmen die die Prozesse (inzwischen) relativ gut im Griff haben. Aber auch bitter daraus gelernt, das sie es einfach machen müssen, wenn sie überleben wollen. Und dann hatten sie noch das Glück genug Geld in der Kaffeekasse zu haben, um das auch wirklich zu stemmen und das Ruder herum zu reißen. Sonst wäre Windows & Co längst Geschichte.
Genau. Marketing ist ja quasi ein Garant dafür, das sich die bessere Lösung durchsetzt. *LOL*
Ohne Frage ...
... und genau da beginnt das Problem. Im Zweifel wird man aber nicht abwägen, sondern sich immer für die bequemere Lösung entscheiden.
Selbst wenn man weiß, das man das was man grad macht eigentlich nicht wirklich gut ist, tröstet man sich immer mit der Ausrede: "Das fixen wir später. Wenn wir mal Zeit haben"
Das Problem ist, die Zeit hast Du nie. Weil dann schon längst wieder ein neues Feature oder neues Projekt ansteht. Nach ein paar Wochen ist Dir das Problem nicht mal mehr bewusst. Du hast es vergessen. Und Du hast es natürlich auch nirgends dokumentiert, weil wozu auch der Aufwand der Dokumentation. Iss ja nur ein Provisorium, das Du ja eigentlich bei nächster Gelegenheit fixen wolltest.
Komm. Hör bloß auf. Ich guck mir jetzt die Sache schon seit Jahrzehnten an. Immer mal wieder wird was Neues auf den Tisch gepackt, was dann plötzlich alle Probleme lösen sollte.
Komm wir machen OOP. Da haste weniger Probleme, weil Du Code Resusen kannst.
Komm wir machen Java. Keine manuelle Speicherverwaltung mehr. Sandboxed Security. Da kann nichts mehr schief gehen.
Zur Zeit sind es eben Container.
Nicht vergessen. Ich stelle diese Technologien nicht grundsätzlich in Frage oder das sie einen Anteil an Verbesserungen haben und haben können.
In der Praxis läuft es aber immer so, das überzogene Erwartungen (vor allem durchs Marketing!!) geweckt werden und das Zeug überall eingesetzt wird. Egal obs passt oder nicht oder obs das Eigentliche Problem wirklich löst.
Mit nem Hammer in der Hand sieht jedes Problem wie ein Nagel aus. Und der Hammer ist im Augenblick eben Docker.
Und DAS ist der Punkt. Nicht das die Technologien nicht auch sinnvoll sein können.
Das passiert, wenn das vorher ausgedachte Theoriegebäude am rauhen Fels der Praxis zerschellt.
Theoretisch ist alles einfach. Wir haben Deployment, Continous-Delivery etc.
Das baut für uns alles automatisch. Zieht die gebrauchten Module von selbst von github usw.
Plötzlich stellt sich aber heraus, der github-Account ist schon lange verwaist und es gab ewig keine Updates mehr. Das Projekt ist inzwischen längst geforkt und wird dort weiter entwickelt etc.
Und Du merkst nicht mal was, weil alle Deine tollen Tools (die zwar einfach sind, die Du aber nicht verstehst) fehlerfrei arbeiten.
Klar kann man hier einwenden: Du musst es halt RICHTIG machen.
Und dann sind wir aber wieder bei dem Punkt: Die Leute, die vorher schon ihr einfaches Programm schlampig entwickelt haben, die machen dann plötzlich die ganzen neuen Prozesse sorgfältig? Wie kommt man zu so einer naiven Erwartung?
Was die ganzen Technology-Apologeten nicht verstehen (verstehen wollen), das Technik keine Lösung ist, sondern ein Werkzeug. Das kann zur Lösung beitragen. Nur muss der jenige mit dem Werkzeug halt auch umgehen können.
Man wird nicht automatisch dadurch zu nem guten Maler, in dem man sich den besten Pinsel und die teuersten Farben besorgt, die man kriegen kann.
Das sagt Dir aber kein Marketing. Logischweise. Der will Dir nur sein Produkt verkaufen. Der ist an Deinem Problem nicht im Geringsten interessiert.
Ich will das auch gar nicht werten. Aus seiner Position handelt er total logisch und rational. Nur muss man das eben im Hinterkopf haben, wenn man mit Marketing konfrontiert wird.
Ja. Da ist es natürlich besonders deutlich. Zugegeben.
Und es gibt natürlich auch noch Unternehmen die langfristiger denken. Die Tendenz ist aber eine Andere.
In der Tat.
Lustig ist ja, das diese ganzen Hype-Begriffe (DevOps, Container, Blockchain) ja immer suggerieren man sei furchtbar modern und quasi am Puls der Zeit und verwendet das Neuste vom Neusten.
Und wenn Du dann genau hinguckst, werden nicht mal einfache Kompilerschalter gesetzt die schon seit >10 Jahren verfügbar sind und Dir ne ganze Fehlerkategorie eliminieren. :-)
Andy_m4
Well-Known Member
Jetzt mal abseits von Lizen usw. Der große Vorteil bei ZFS und FreeBSD ist, das ZFS ins System integriert ist. Es ist also nicht nur einfach ein weiteres Dateisystem, was Du mounten kannst. Es ist mit anderen Funktionen in FreeBSD verzahnt und hat damit eine echte Integration ins System.
Im Linux-Umfeld gibts halt schon mehrere dutzend Dateisysteme und da ist ZFS einfach nur ein Yet-another-filesystem.
Klar. Es mag hier und da auch dort ein paar Vorteile haben. Aber die sind halt nicht so weitgehend, wie bei FreeBSD. Dementsprechend nüchtern sind auch manche Stimmen im Linux-Lager zu ZFS-on-Linux.
Eher weniger. Die Tendenz ist auch eher fallend, was den Anteil von GPL-Software an Open-Source angeht. Es ist auch längst nicht mehr die häufigste Open-Source-Lizenz.
siehe dazu auch:
https://resources.whitesourcesoftwa...p-open-source-licenses-trends-and-predictions
Ein Verhalten, was im akademischen Umfeld keineswegs ungewöhnlich, sondern sogar gewollt ist.
Es soll ja genau darum gehen auch über Sachen nachdenken zu dürfen die nicht dem Mainstream entsprechend. Was auch völlig richtig ist. Denn was im Mainstream finanziert wird, finanziert sich von alleine weil sich genug Geldgeber/Interessenten finden.
Im akademischen Umfeld soll es eher darum gehen frei von fremden Interessen zu entwickeln.
Die Frage ist dann eher, ist es für FreeBSD der richtige Ort. Ist FreeBSD nicht eigentlich zu sehr Mainstream als Akademie? Ich mein, es hat immer noch einen monolithischen Kernel und völlig veraltete UNIX-Konzepte die es schon seit Jahrzehnten gibt. Gut. Sie wurden evolutionär weiter entwickelt. Trotzdem ist es nicht gerade das, was man jetzt als typisches Forschungsprojekt sehen würde.
Das sehe ich bei Projekten wie DragonflyBSD viel eher, die dann auch mal Sachen ausprobieren wo man nicht weiß, ob sie sich in der Praxis dann tatsächlich auch bewähren oder eher nicht.
FreeBSD ist da eher konservativ. Vielleicht sollte man das eher so bei den Theologen mit unterbringen. :-)
marmorkuchen
Well-Known Member
Oder um es "etwas" kürzer zu fassen: "A fool with a tool is still a fool"
Richtig ätzend wir es immer dann, wenn man Dir nicht die Zeit gibt etwas richtig zu machen. Von wegen mach erst einmal die Version 0.8 die 1.0 machen wir später...
Wenn du den Faktor Betrieb der Software - mit der Entwicklung allein ist es ja nicht getan - reinrechnest, sinkt die Gesamtkomplexität mit Containern in meiner Erfahrung deutlich.
In Jahrzehnten der professionellen Softwareentwicklung und vielen Projekten mit und ohne Container habe ich meine Erfahrungen gesammelt. Ich möchte keinesfalls zurück zur alten Welt mit händisch gewarteten Servern, Deployment-Tickets für Betriebsabteilungen und vielen manuellen Eingriffen.
Die aktuell 3 großen Programmiersprachen (JavaScript, Python, Java) ist es fast unmöglich, noch einen Buffer Overflow zu programmieren - schon gar nicht unabsichtlich. Du kriegst schlimmstensfalls eine
ArrayIndexOutOfBoundsException o.ä. um die Ohren geschmissen, wenn du nicht sowieso foreach() o.ä. Konstrukte verwendest. Deinen Stack oder Heap zerschießen wie früher wird schwierig.Bestehende Anwendungen in C und vielen anderen Sprachen werden das Problem immer haben.
Keineswegs. Solange Menschen Software schreiben, werden uns diverse Bugs unterschiedlichster Couleur noch lange begleiten. :-)
Allein durch die konsistente Laufzeitumgebung, egal wo man den Container betreibt, werden jede Menge Fehlerquellen beseitigt. Ich kann ein und denselben Container auf Fedora entwickeln, unter Ubuntu bauen und auf CentOS betreiben. Ich nicht davon abhängig, das auf meinem Zielsystem Package X in Version Y vorhanden ist und muss nicht beten, dass ein Admin auf Produktionskiste Z die richtigen Pakete in der richtigen Version installiert hat.
Es gibt auch massig schlechte Projekte dort draußen. In der Praxis schaut man sich natürlich die interessanten Projekte an, in die viel Liebe, Know-How, Manpower und Energie geflossen sind und die viel Zeit zum Reifen hatten.
Ich habe auch schon abartig guten Quellcode in proprietärer Software gesehen, der so ziemlich alle mir bekannten Open-Source-Projekte in den Schatten gestellt hat. Das war aber ausnahmslos Software fürs Produktgeschäft, d.h. die Qualität der Software hat über Gedeih und Verderb der Firma bestimmt.
Das Problem ist: viel Closed-Source-Software ist Individualsoftware für einen begrenzten Nutzerkreis mit überschaubaren (manchmal trotzdem obszön hohen) Budget ohne die Skalierungseffekte des Produktgeschäfts. Dort sind nichtfunktionale Anforderungen meist zweitranging.
Das war nicht meine Aussage. Völlig unabhängig von der Qualität oder Funktionalität ist es im Normalfall leichter, Linux als FreeBSD in einem Unternehmen einzuführen, weil mehr Leute schon mal was von Linux als von FreeBSD gehört, gelesen, gesehen oder erfahren haben. Sowohl auf Management-Ebene (ältere Semester erinnern sich an die IBM-Linux-Werbespots) als auch bei den Technikern.
Es sind viele Faktoren im Spiel, von denen Bequemlichkeit eine ist. Verbreitung, Bekanntheit, Integration in ein Ökosystem und vieles mehr spielt auch eine große Rolle.
Es gibt leider für Software noch keine quantifizierbare Metrik, wann die eigene Arbeit gut genug ist. Von externen Faktoren ganz zu schweigen.
Ich hab auch schon genug Hype-Zyklen mitgemacht, um zu wissen, dass es keinen Silver Bullet gibt.
Es geht aber darum, Software und deren Betrieb besser zu machen. Wir verzichten als Softwareentwickler ja auch nicht auf statische Codeanalyse, nur weil die nicht all unsere Probleme löst.
Container sind momentan eine dieser Technologien, die signifikante Verbesserungen bringen. Es hat einen Grund jenseits aller Hypes, warum ich das Fehlen einer konkurrenzfähiger Container-Technologie in FreeBSD so bedauere.
Korrekt. Container sind jetzt im Hype-Zyklus aber schon auf dem Plateau der Produktivität angekommen.
Bei Kubernetes würde ich dir vielleicht noch rechtgeben. Container sind aber in weiten Teilen schon 08/15 und nicht mal mehr erwähnenswert - es sei denn, sie werden irgendwo nicht unterstützt.
Das ist ja heute kein Hexenwerk mehr. Die Twelve Factor-App ist so die Untergrenze für moderne Softwareentwicklung. Wenn man die nicht vorfindet, gilt "love it, change it or leave it".
Versionierte Artefakte, auch bei den Abhängigkeiten, lassen sich einfach umsetzen. Dabei kann man auch gleich vollautomatisch bekannte Sicherheitsklücken in den Abhängigkeiten und mögliche Updates überprüfen. Das erfordert weder viel Elan noch sonderlich viel Know-How.
Business as usual. Eine verwendete Bibliothek wird nicht mehr gepflegt, also nimmt man eine andere, baut die Funktionalität selber oder oder oder.
Völlig nimmt uns die Software das Denken noch nicht ab.
Es gibt ein paar Mindeststandards, die man einhalten sollte. Wie Anschnallen im Auto. Die von mir skizzierten Lösungen sind keine Raketenwissenschaft.
Ich gehe - ausgehend von mir - von maximaler Faulheit und Dummheit aus. Deswegen setzt man einmal einen CI-Server auf, erzwingt Code Reviews in seiner Versionsverwaltung und noch ein paar andere Mindeststandards. Die statische Codeanalyse lässt den Build fehlschlagen, wenn kritische Findings oder unzureichende Testabdeckung gefunden wird. Die Einrichtung solcher Tools ist bei meinen Kunden eine Übungsaufgabe für Fachinformatiker im ersten Lehrjahr.
Ja, Software schreibt sich (leider oder zum Glück) noch nicht von alleine. Es gibt aber viele Tools wie z.B. statische Codeanalyse, die viele allzu menschliche Fehler im Quellcode findet, ohne das man viel Know-How für den Umgang damit haben müsste.
Korrekt - aber ein und derselbe Maler wird mit gutem Handwerkszeug ein besseres Bild hervorbringen als mit unzulänglichem Schrott.
Richtig. Um zurück zum Thema zu kommen, wir reden aber hier im Thread ausschließlich von Software, die man - selbst im großen Maßstab - völlig kostenlos einsetzen kann.
Viele aktuelle Trends sind schon lang bekannt. Funktionale Programmierung stammt aus den 60ern, virtuelle Maschinen aus den 70ern - die Liste ist lang. Manchmal dauert es aber, bis es im Mainstream ankommt oder es so einfach anwendbar wird, dass die Nutzungshürde weit genug sinkt.
Inzwischen sind zumindest zwei deiner Punkte Mainstream. DevOps und Container sind in der Softwareentwicklung nichts Exotisches mehr. Man kann auf IT-Konferenzen oder IT-Meetups (aktuell dank COVID-19 offline etwas schwierig) einfach Leute nach ihren Erfahrungen damit fragen - sie werden dir freudig erzählen, wie das bei ihnen funktioniert. Die erzählen einem dann, dass sie sich nicht mehr vorstellen können, wie sie früher ohne gearbeitet haben.
Ob es irgendwann mal für Blockchain eine Anwendung in der Breite gibt - ich lasse mich überraschen...
Blinde Flecken - wer keine hat, werfe den ersten Stein.
Umso schöner ist es, wenn man dann mit wenig Aufwand für Erleuchtung sorgen kann.
derOliver
Systemheld
Nur weil manchen die Entscheidungen nicht gefallen, ist das nicht weniger wert. Ich wollte nur darlegen, was Apple so herausgibt.
vielleicht kannst du mir auch ausführen, wo die Probleme bei CUPS und WebKit liegen? und was sind die Alternativen?
bsd4me
Well-Known Member
tja, ein bisschen Senf möchte ich auch dazugeben ;-) Ich nutze FreeBSD schon seit dem 1.* Release, damals - jaja... Das war vor 20 Jahren, als ich mit Tapes und Linux angefangen und dann bei *BSD hängengeblieben bin. Nun, es stimmt, manchmal geht was nicht. Desktop ist auch nicht "out of the box". Aber ich habe auch mit anderen Systemen Probleme gehabt und erlebt, von Ubuntu, Windows, OsX etc. Es gab sogar einen Lenovo R51Laptop, der unter FreeBSD jahrelang ohne Probleme lief und unter Ubuntu dann jeden Tag abstürtzte... Trotz aller kleiner Schwächen mag ich *BSD und werde es solange es geht nutzen. Es ist halt nur schade, dass manche Anwendungen keine Portierung nach *BSD haben. Was ich besonders lobenswert finde, sind die Leute hier in BSDFOREN Nett und informativ... VG Norbert
Nett und informativ... VG Norbert
Andy_m4
Well-Known Member
Wie soll das gehen? Vorher hattest Du nur das Programm. Jetzt hast Du Programm plus Container. Das ist eindeutig mehr Komplexität.
A+B > A | wenn B>0
[/QUOTE]
Davon war ja auch nie die Rede.
Ich sprach mich sogar explizit für Automation statt manuelle Vorgänge aus.
Wie Du da das Gegenteil rauslesen kannst, ist mir ein Rätsel.
Ich glaube auch manchmal, Du wirfst mehrere Sachen durcheinander. Nämlich Automation und Container. Automation kriegst Du auch ohne Container hin. Also bitte: getrennt betrachten
Ist korrekt. Nur kommt das immer wieder in der Praxis vor. Warum? Weil halt nicht überall Javascript, Python und Java eingesetzt wird.
Mal wieder eine Schönwetterannahme von Dir, die in der Praxis zerschellt.
Außerdem fängst Du Dir gerade mit Javascript und Python andere Probleme ein. Ich sag nur dynamische Typisierung. Das Problem, das viele Fehler erst zur Laufzeit erkannt werden und nicht zur Kompilierzeit. Das heißt, um solche Fehler zu finden musst Du jeden möglichen Codepfad während der Laufzeit einmal durchlaufen.
Klar kann man auch hier wieder gegensteuern. Man kann Unit-.Tests machen und ähnliches. Aber mal ehrlich: Leute die zu Python greifen, weil sie faul sind und da keine Datentypen zu deklarieren brauchen, schreiben andererseits plötzlich wasserdichte Unit-Tests? lol
Mal abgesehen davon. Ich komme eher aus der Lisp-Ecke. Und die Lisp-Leute die hatten ja schon die ganzen Sachen die später als modern galten schon vor 30 Jahren. Die Macher der modernen Sprachen hatten also eine 1A Vorlage.
Wurde aber nicht genutzt. Stattdessen mussten diese Sprachen im Verlaufe ihrer Evolution all die Probleme lösen, die die Lisp-Leute eigentlich schon für sie gelöst hatten und im Endeffekt ist das Ergebnis schlechter als das was wir vor 30 Jahren hatten.
Auch wieder ein sehr sehr schönes Beispiel dafür, das Technologie alleine keine Probleme löst, wenn man mit ihr nicht umzugehen weiß.
Und was haben wir jetzt? 3 Programmiersprachen mehr, dessen Implementationen gepflegt werden müssen. Wo Du Leute haben, die die beherrschen müssen usw. Das ist ja dann auch immer ein Rattenschwanz ohne Ende den solche Sachen nach sich ziehen.
Ich verstehe ja due Ursachen und die Dynamik dahinter, warum solche Sachen so laufen, wie sie laufen. Ich verstehe nur nicht, warum da keiner mal ehrlich anerkennt, das das Mist ist und versucht die Situation zu bessern, statt den Weg stumpf weiter zu gehen. Oder wenn man den Weg schon stumpf weiter geht (weiter gehen muss, weil man sonst seinen Job verliert) wenigstens so aufrichtig ist und zugibt, das da Mist gebaut wird.
Ich meine, wir sind hier im Forum. Anonym. Gibt doch gar kein Grund, Sachen schönzureden. Es sei denn, man glaubt tatsächlich an den ganzen Schwachsinn der da draußen so abläuft und das das der einzig wahre und richtige Weg ist.
Und vielleicht ist er das ja auch. Immerhin hat er ja auch Erfolge vorzuweisen. Ist ja nicht alles schlecht. Nichtsdestotrotz kann man dazu lernen und sich weiter entwickeln nur, wenn man auch mal Dinge hinterfragt und nicht immer nur so tut, als sei alles gut.
Oder sehe ich das alles sooo falsch? Kann auch sein, das meine Wahrnehmung gestört ist. Nur andererseits, wenn ich sagen: Wenn ihr das so und so macht geht die Sache hoch und rundrum sehe ich auch überall Explosionen, rede ich mir ja immerein, das so falsch das was ich sage ja nicht sein kann.
Ja. Aber selbst hier ließe sich viel machen. Ohne Aufwand. In der Praxis werden die Sachen aber nicht benutzt. Auch auf die Gefahr hin das ich mich wiederhole: Versteh doch. Das Problem ist nicht die Technik. Das Problem sind die Leute, die sie benutzen!
Das Problem ist nicht, das Bugs vorkommen können. Das Problem ist, das man gewisse Probleme versucht auf Teufel komm raus mit Technik zu erschlagen. Im Endergebnis hast Du einfach nur mehr Baustellen und mehr Bugs. Nicht weniger!
Das beschreibt schön, was ich meine. Du hast ne Kack-Umgebung. Anstatt das man aber diese Kack-Umgebung mal gerade zieht, baut man irgendwas mit Containern, damit einem die Kack-Umgebung nicht mehr so leicht auf die Füße fällt.
Dafür habt ihr dann mehr Komplexität die dann wiederum neue Probleme bringt. Aber keine Sorge. Irgendwer wird sich auf dafür ne Lösung einfallen lassen. Die wiederum mehr Komplexität einbringt.
Das ihr das aber auch nicht merkt! Angeblich Jahrzehnte in der Branche unterwegs und Dir ist das nie aufgefallen.
Man! Es ging um ne Gesamtbetrachtung! Klar gibt es immer Ausnahmen.
Solche Argumentationen erinnern mich immer an diese Raucher-Nichtraucher-Diskussionen, wo dann irgendwer sein 90-jährigen sein Leben lang stark qualmenden Opa aus dem Arsch zieht, um damit zu Belegen, das Rauchen ja wohl doch nicht so schädlich sei.
Ja. Sorry.
Ist mir vollkommen bewusst. Aber genau das verhindert halt auch häufig, das eine bessere Lösung eingesetzt wird.
Manchmal sogar mehr oder weniger bewusst: So nach dem Motto: Wir wissen zwar, das die Sch??ße sind aber da wissen wir halt, was wir kriegen. Bei jemand anderen könnte es ja noch schlechter sein.
Apropos IBM. Waren die das nicht auch die, die damit geworben haben: Es wurde noch nie jemand gefeuert der sich für ein IBM-Produkt entschieden hat?
Exemplarisch dafür, wie Marketing funktioniert. Es wird gar nicht auf die Lösung und deren Stärken und Schwächen eingegangen, sondern quasi nur noch mit Emotionen gespielt. Das ist Werbung (kannst Du in jedem beliebigen SPot bewundern). Das ist Marketing. Das sollte aber nicht die Maxime unseres Handelns sein.
Das was Du ja (auch vollkommen korrekt) beschreibst ist genau das, was ich kritisiere. Oder besser gesagt: Worauf ich hinweise. Um damit zu erklären, warum im Allgemein der Zustand so schlecht ist, wie er ist.
Noch mal: Es geht nicht darum, das Technologie sinnvoll sein kann und dann natürlich auch eingesetzt werden sollte.
Ich stehe ja nicht auf dem Standpunkt: Früher war alles besser und den ganzen neumodischen Krempel braucht kein Mensch.
Ich dachte eigentlich, das hätte ich deutlich gemacht.
Dann dürfte ja in der Praxis nirgendwo mehr was hochgehen. Das tut es aber. Offenbar wird es dann doch nicht überall richtig eingesetzt.
Da sind wir wieder bei dem was ich sagte: Die Leute, die vorher schon ihre Prozesse nicht auf die Reihe gekriegt haben, kriegen sie auch nicht mit neuer Technologie auf die Reihe.
Wie ich schon sagte. Bestimmt kommt der Einwand, dass .
naja. Den Rest schrieb ich bereits. Darfst Du gerne noch mal nachlesen.
Auch hier wiederhole ich das, was ich im letzten Posting schon sagte. Nämlich, das es darum nicht geht, ob eine Lösung schwierig einzusetzen ist.
Lies nach.
Daher macht es keinen Sinn, wenn Du Dich wiederholst. Dann muss ich mich nur wiederholen und damit ist keinem gedient.
Ist mir alles bekannt. Nützt nur nicht viel, wenn diese nicht benutzt werden. Nimm ein beliebiges und seit einiger Zeit schon frei verfügbares Tool und lasse es mal über ein paar Softwareprojekte laufen.
Normalerweise würde man davon ausgehen, das das nix findet. Denn die Entwickler haben das doch bestimmt gemacht, wenn die Hürde des Einsatzes soooo verdammt niedrig ist.
Sorry, wenn ich hier dazwischen grätschen muss. Aber DevOps. Ist nicht dafür da, um die Softwarequalität zu erhöhen, sondern um Kosten zu senken.
Früher hattest Du halt ein Entwickler, der die Software entwickelt hat und ein Operator, der die Software baut und ausrollt. Das soll jetzt einer machen. Als DevOps. Der muss also jetzt plötzlich nicht nur Know-How im programmieren haben, sondern auf für den Betrieb von Programmen (Administration, wenn Du so willst). Der muss also quasi doppelt so viel wissen, hat aber dafür nur halb so viel Zeit.
Prrrrreisfrage: Wie wird sich das auf die Qualität auswirken? Ist die Chance größer das die steigt oder eher, das sie sinkt? Na? Kommst du da alleine drauf, oder willst Du vorher lieber mit dem Marketing telefonieren um Dir versichern zu lassen, das Du noch auf der richtigen Seite stehst? ;-)
Klar. Auch jetzt wirst Du wieder Einwände bringen, das es ja all die tollen Tools gibt die das total einfach zugänglich machen. Und während Du noch am reden bist, laufen im Security-Ticker weiter Horrormeldungen ein, weil diese Schönwetter-Theorien in der Praxis alle auseinanderfallen.
Es geht nicht darum, das man versehentlich etwas übersieht. Es geht darum, das Leute die schon immer schlampig gearbeitet haben nicht dadurch besser werden, in dem man ihren Werkzeugen einen neuen Anstrich verpasst.Blinde Flecken - wer keine hat, werfe den ersten Stein.
Ich dachte, das hatte ich deutlich gemacht.
Weiß nicht. Der Vorteil von Open-Source ist ja, das möglichst viele davon profitieren. Wenn Du irgendwas als Open-Source rausbringst, was aber keiner außer Dir gebrauchen kann, dann ist es ähm ... nicht so der Bringer. :-)
Hab ich doch genannt. Bei CUPS hatten sie irgendwelche Sachen rausgeworfen, die unteranderem die Linuxer noch brauchten.
Was das alles im Detail war, weiß ich auch nicht mehr. Ich weiß nur, das es einen gewissen Wirbel darum gab, so das sogar ich das mitbekommen hab.
Wenn man im Internet sucht, findet man auch rasch die Details dazu.
Ja. Ich wollte auch nur Ergänzen, das das alles nicht gänzlich unumstritten ist oder war.
Die Betrachtung greift für meinen Geschmack zu kurz - sonst würden wir alles in Maschinencode schreiben, denn die Verwendung eines Assemblers oder Compilers erhöht die Komplexität.
Es sei denn, es gilt A+B und A+C+D mit (C+D) < B.
So ist es mit Containern und betrieblichen Aspekten, wenn wir mehr als triviale Fälle betrachten, speziell in breiten Einsatzgebieten von Unix-Systemen.
Das war eine allgemein bezogene Aussage und nicht auf dich bezogen.
Container machen Automation deutlich leichter (siehe unten). Das macht einen beträchtlichen Teils ihres Erfolgs aus.
Die Aussage habe ich nicht getätigt. Meine Aussage ist, dass die heutigen Brot-und-Butter-Sprachen keine Buffer Overflows mehr haben. Andere existierende Programmiersprachen wie C habe ich extra erwähnt.
Das würde ich aber in einem Programmiersprachen-Thread behandeln, genauso wie die komplette Programmiersprachen-Diskussion (gerne auch mit Lisp-Macros
), sonst hat das hier nichts mehr mit FreeBSD zu tun.Willkommen in der Welt der menschlichen Natur. Abseits der Software läuft es ganz ähnlich, wenn ich meinen Freunden abseits der IT glauben schenken darf. In vielen Fällen hilft nur Lernen durch Schmerzen, bei Menschen wie bei Organisationen.
Das Phänomen ist mir bestens vertraut - leider. Die Menschen wirst du nicht ändern, du kannst sie höchstens behutsam mit der Geschwindigkeit eines Gletschers in eine Richtung bewegen.
Themen wie Testabdeckung oder statische Code-Analyse waren vor 10-15 Jahren Randerscheinungen; heute sind sie auf breiter(er) Front im Einsatz.
Korrekt. Es gibt Probleme, die sich nicht mit Technik lösen lassen. Das Kunststück ist, das eine vom anderen unterscheiden zu können.
Manchmal kommt auch neue Technik vorbei, die es schwerer macht, es falsch zu machen.
Aus meiner Erfahrung in diversen Unternehmen: es ist in der Praxis leichter und weniger komplex, mit Containern funktionierende und reproduzierbare Umgebungen (es ist in der Regel mehr als eine) aufzubauen als ohne. Allein der Hardware-Bedarf und die Turnaround-Zeiten sind mit VMs deutlich größer als mit Containern, von den Faktoren wie Netzwerk, Firewall-Regeln uvm. ganz abgesehen. Eine 08/15-Anwendung mit Frontend, Backend und Datenbank kann ich mir für die lokale Entwicklung als Container schnell hochziehen. Mit 3 VMs wird das auf dem Laptop unlustig.
Ohne Container komme ich in der Praxis als Unternehmen schnell in einen Bereich, in dem ich entweder einen eigenen OpenStack-Cluster betreiben (irrwitziger Aufwand) oder mit einen Public-Cloud-Provider ins Bett muss. Oder ich mache halt doch wieder viel Handarbeit oder halbgare Lösungen.
Ein argumentum ad hominem bringt uns in der Diskussion nicht weiter. Natürlich ist mir das aufgefallen, aber spätestens in klassischer IT mit getrennten Entwicklungs- und Betriebsabteilungen ist das nicht so einfach wie in einer 3-Mann-Klitsche. Ich muss erstmal nennenswert Kontrolle über die Zielumgebung haben, um dort etwas ändern zu können.
Korrekt, da bin ich deiner Meinung. Deswegen habe ich mich ganz auf die Technik konzentriert und Marketing ausgeklammert, um dem sonst hier üblichen Argument vorzubeugen, die größere Verbreitung von Linux denn FreeBSD in Unternehmen würde ausschließlich an Faktoren wie Marketing liegen.
Es erhöht die Produktivität. Die Fürsprecher für DevOps kommen viel aus der Entwickler-Ecke, weil die keinen Bock mehr haben, von einer Betriebsabteilung abhängig zu sein, die keine API hat.
Es sind immer noch zwei Leute. Die sitzen jetzt halt im selben Team und es werden keine Softwareartefakte mehr über den Zaun zwischen zwei Silo-Abteilungen geschmissen.
Die Firmen, die du beschreibst, hatten nie einen Betrieb - das hat der Entwickler schon immer nebenher in Produktion mitadministriert.
Ich glaube nicht, dass es überall so ist - aber es wird für meinen Eindruck anteilig besser. Wir bauen heute natürlich wesentlich mehr Software als früher, die wesentlich häufiger am Netzwerk bzw. Internet hängt und es so überhaupt erstmal in den Security-Ticker schaffen kann. Wenn statt 50% der Software nur noch 1% Sicherheitslücken hat, wir aber 100 mal so viel Software haben, besteht keine Gefahr für Langeweile beim Security-Ticker.
So habe ich dich auch verstanden.
Worauf ich hinauswill: es ist technisch (Container, Infrastructure as Code etc.) und organisatorisch (DevOps) einfacher, dass schlampige Arbeit beim Verursacher frühzeitig auffällt bzw. aufschlägt und man nicht es "auf den Betrieb" schieben kann. Man ist auch mehr als früher davor gefeit, dass ein schlampiger Admin Produktion verkonfiguriert und deswegen an sich einwandfreie Software trotzdem schlecht in Produktion läuft.
Das weiß man manchmal erst hinterher. Reichlich Standard-Open-Source-Software hat als kleines Hobby-Projekt mit fragwürdiger Qualität angefangen und ist erst über viele Jahre gereift. Rückblickend ist alles offensichtlich.
Zuletzt bearbeitet:
pit234a
Well-Known Member
Das ist eine sehr interessante Diskussion zwischen @Andy_m4 @Azazyel
Ich finde aber schon, dass sie auch ein wenig aus dem Ruder läuft. Denn die Komplexität und Fehlermöglichkeiten von Programmiersprachen und die Abläufe diverser Entwicklungen beziehen sich nicht unbedingt auf FreeBSD.
Lasst es mich mal versuchen, auf den einfachsten Punkt zusammenzufassen und aber als Frage zu stellen, ob ich das so richtig sehen kann:
Am Beispiel Docker wird erklärt, dass FreeBSD eine Entwicklung verschläft und genau an diesem Beispiel wird auch hinterfragt, ob das nicht sinnvoll sein kann und Docker (wie gesagt, als hervorstechendes Beispiel) eigentlich auch nicht wirklich gebraucht wird.
Wenn ich das so richtig erstehe muss ich von meinem bescheidenen Standpunkt aus sagen, dass ich beide Seiten für gültig ansehe.
Ich glaube nämlich nicht, dass sich Bedürfnisse verallgemeinern lassen, dass also wirklich alle Anwender von FreeBSD in etwa das gleiche wollen. Wer Docker will (und erfolgreich auf anderen Systemen damit arbeitet), wird es auf FreeBSD vermissen. Wer Docker nicht will und auch ohne dieses erfolgreich seine Aufgaben erledigt, wird es auch in FreeBSD nicht vermissen.
Es ist unstrittig, dass es Docker für FreeBSD nicht gibt. Es ist gut möglich, dass dies ein entscheidendes Argument für den Einsatz eines Systems sein kann. Für alle, die Docker wollen oder brauchen, kommt deshalb FreeBSD nicht Frage.
Für alle anderen bleibt es interessant.
Kann man das so zusammen fassen?
Ich finde aber schon, dass sie auch ein wenig aus dem Ruder läuft. Denn die Komplexität und Fehlermöglichkeiten von Programmiersprachen und die Abläufe diverser Entwicklungen beziehen sich nicht unbedingt auf FreeBSD.
Lasst es mich mal versuchen, auf den einfachsten Punkt zusammenzufassen und aber als Frage zu stellen, ob ich das so richtig sehen kann:
Am Beispiel Docker wird erklärt, dass FreeBSD eine Entwicklung verschläft und genau an diesem Beispiel wird auch hinterfragt, ob das nicht sinnvoll sein kann und Docker (wie gesagt, als hervorstechendes Beispiel) eigentlich auch nicht wirklich gebraucht wird.
Wenn ich das so richtig erstehe muss ich von meinem bescheidenen Standpunkt aus sagen, dass ich beide Seiten für gültig ansehe.
Ich glaube nämlich nicht, dass sich Bedürfnisse verallgemeinern lassen, dass also wirklich alle Anwender von FreeBSD in etwa das gleiche wollen. Wer Docker will (und erfolgreich auf anderen Systemen damit arbeitet), wird es auf FreeBSD vermissen. Wer Docker nicht will und auch ohne dieses erfolgreich seine Aufgaben erledigt, wird es auch in FreeBSD nicht vermissen.
Es ist unstrittig, dass es Docker für FreeBSD nicht gibt. Es ist gut möglich, dass dies ein entscheidendes Argument für den Einsatz eines Systems sein kann. Für alle, die Docker wollen oder brauchen, kommt deshalb FreeBSD nicht Frage.
Für alle anderen bleibt es interessant.
Kann man das so zusammen fassen?
Ich habe erwartet, dass diese Diskussion aus dem Ruder läuft, und sehe schon einige Zeit keinen Sinn mehr darin. Wenn mit "Cloud" argumentiert wird (wofür es ohne Zweifel gute Gründe gibt), wieso interessiert mich dann überhaupt das System, auf dem gehostet wird? Damit habe ich doch nichts mehr zu tun! Wenn ich aber selbst betreiben will, und "Container" brauche, dann kann ich die auf FreeBSD auch haben. Alles, was Docker technisch ausmacht, kann FreeBSD auch, manches davon schon länger und besser als andere Systeme. Wenn ich natürlich "speziell Docker" haben will (und auch dafür mag es gute Gründe geben), dann nehme ich vielleicht lieber ein anderes OS. Ich sehe nicht, wie FreeBSD als OS hier etwas "verschlafen" haben sollte. Das OS stellt die Technik bereit, die Anwendungen bauen andere darauf.
Ich bin da inhaltlich komplett ausgestiegen, offenbar gehts jetzt nur noch um den bereich "Web und Entwicklung" und auch sonst um einen recht engen Bereich, hat schon mit den Bullshitbegriff "Enterprise" vor 1,2 Seiten angefangen
Da aber alle beteiligten sich "zivil" verhalten und offenbar Spaß an der Diskusion haben, warum nicht.
Da aber alle beteiligten sich "zivil" verhalten und offenbar Spaß an der Diskusion haben, warum nicht.
derOliver
Systemheld
Das kann eine Motivation sein, es gibt aber auch andere. Und davon gleich darauf zu schließen, niemand könnte das gebrauchen ist auch weit her geholt.
Keiner hat CUPS geforked oder ne Alternative gebaut. Kann also nicht so schlimm gewesen sein, oder? Im Umkehrschluss wars dann vielleicht doch ganz okay das auszubauen?
Natürlich nicht die sind halt nun mal Apple und nicht die Wohlfahrt