Fehlerfreiheit OpenBSD & Updatezyklen, Schlankheit und allgemeine Diskusion zur Softwareentwicklung & Zyklen
- Ersteller Tatzahn
- Erstellt am
Packages kommen unter
pkg_add -u, ja. Aber bei syspatchhat sich lange nichts getan. Ich bin halt noch nicht so lange auf diesem OS unterwegs und kanns daher nicht einschätzen. Schaumermal.
midnight
OpenBSD & FreeBSD
Dieses Jahr gab es seit Mai schon 8 Patches. Letztes Release gab es 21 Patches und davor 25 Patches und davor 22 Patches usw. 8 Patches sind sogesehen unterhalb des Durchschnitts, was aber gut ist. OpenBSD hat prinzipiell eine sehr gut auditierte Codebase (sowohl durch die OpenBSD-Devs als auch durch externe User und Firmen) und es ist gut, wenn die Patches von Release zu release weniger werden, denn das spricht fuer die Codequalitaet.
Beruhigend.
Ich habe mir die einzelnen Jahre auch ein wenig angesehen, aber eben die Patches nicht als "Einschläge" interpretiert, bei denen dann weniger=besser ist.
Jupps, OpenBSD patcht vor allem echte Sicherheitslücken und nur in ganz dringenden fällen größere nicht Sicherheitsrelevante Bugs.
Das meiste was neu entwickelt wird fließt in ~current - wenn man also mal neue features oder kleinere Bugfixes braucht kann man ~current folgen.
Ich mache das sehr bewusst nicht, nur manchmal wenn ich ein Problem habe und gegenprüfen möchte ob es in ~current evtl. gefixt ist.
Das meiste was neu entwickelt wird fließt in ~current - wenn man also mal neue features oder kleinere Bugfixes braucht kann man ~current folgen.
Ich mache das sehr bewusst nicht, nur manchmal wenn ich ein Problem habe und gegenprüfen möchte ob es in ~current evtl. gefixt ist.
Das Basissystem ist auch nicht riesig und gerade die Dinge die OpenBSD-Bestandteile sind (sowas wie relayd, httpd) sind einfach auch von der Codebase kleiner, und Code der nicht existiert kann halt auch keine Sicherheitslücken haben. Bai LibreSSL hat man auch schön gesehen wie einfach mal massiv Code weggeschnitten wurde und dann allein deshalb schon viele OpenSSL-Bugs irrelevant waren, weil der Code einfach nicht mehr da ist.
Wird halt echt häufig unterschätzt dass jedes Feature natürlich auch eine Fehlerquelle ist.
Wird halt echt häufig unterschätzt dass jedes Feature natürlich auch eine Fehlerquelle ist.
Die Frage ist dann aber, warum es nicht generell Praxis ist, den Code klein zu halten.
Etwas off-topic, aber hoffentlich nahe genug am Thread-Thema; ansonsten gerne ins Geplauder-Forum verschieben.
OpenSSL hat(te) eine seit den 1990ern gewachsene Code-Basis mit 500.000 Zeilen Quellcode, die von 1-2 Leuten gewartet, getestet und weiterentwickelt wurde.
Vor Heartbleed 2014 waren da gar keine Ressourcen für nennenswerte Wartungsarbeiten vorhanden. Zumal OpenSSL stets vor dem Dilemma der Abwärtskompatibilität stand; welche Features konnten sie denn überhaupt rausschmeißen, unwissend, was von den Anwendern tatsächlich noch genutzt wurde?
LibreSSL konnte - mangels Bestandsnutzern - einfach alles wegschmeißen, was nicht mehr notwendig und (zwischenzeitlich) überflüssig erschien.
Viele Projekte und Produkte (sowohl Open als auch Closed Source) machen regelmäßig Refactorings und überarbeiten den Quellcode. In einer Welt von begrenzt Zeit und Ressourcen ist aber auch immer die Frage, wieviel Zeit und Energie man in dergleichen Aktivitäten reinsteckt.
In den allerwenigsten Fällen wird zum Beispiel formale Verifikation eingesetzt, die zwar unzweifelhaft zu weniger Fehlern führt, aber die Entwicklungsaufwände gerne mal um Zehnerpotenzen erhöht. Auf Faktor 10 bis 100 an Mehraufwand kommt man da locker.
Auch werden bei so manchem Projekt/Produkt Features abgekündigt - was aber sehr schwierig ist, weil es immer jemanden gibt, der sein Feature behalten möchte. Man schaue sich nur die Diskussion hier im Forum rund um das Ende von x.org bzw. X11 an.
Wir wollen mit Software auch immer mehr machen. Dementsprechend steigt die Komplexität und damit die realen oder vermeintlichen Bugs. Es gibt auch reichlich Projekte mit Zero-Bug-Policy, aber gerade bei Open-Source-Projekten kommen auch sehr viele fragwürdige Bug-Reports rein. Was macht man, wenn der Bug-Report gegen eine uralte Version geht und mit der aktuellen Version vom Maintainer nicht reproduzierbar ist und man auf Feedback vom Bug-Reporter wartet?
Es sind auch die Zeiten vorbei, in denen man tagelang händisch seine Software bei jeder Änderung testen musste und via CD ausgeliefert hat. Durch die kurzen Turnaround-Zeiten ist es natürlich einfacher, auftretende Bugs einfach zeitnah zu fixen.
Um die Kurve zurück zu OpenBSD zu kriegen: wo ist die Grenze zu sinnvollen Features?
OpenSSL hat(te) eine seit den 1990ern gewachsene Code-Basis mit 500.000 Zeilen Quellcode, die von 1-2 Leuten gewartet, getestet und weiterentwickelt wurde.
Vor Heartbleed 2014 waren da gar keine Ressourcen für nennenswerte Wartungsarbeiten vorhanden. Zumal OpenSSL stets vor dem Dilemma der Abwärtskompatibilität stand; welche Features konnten sie denn überhaupt rausschmeißen, unwissend, was von den Anwendern tatsächlich noch genutzt wurde?
LibreSSL konnte - mangels Bestandsnutzern - einfach alles wegschmeißen, was nicht mehr notwendig und (zwischenzeitlich) überflüssig erschien.
Viele Projekte und Produkte (sowohl Open als auch Closed Source) machen regelmäßig Refactorings und überarbeiten den Quellcode. In einer Welt von begrenzt Zeit und Ressourcen ist aber auch immer die Frage, wieviel Zeit und Energie man in dergleichen Aktivitäten reinsteckt.
In den allerwenigsten Fällen wird zum Beispiel formale Verifikation eingesetzt, die zwar unzweifelhaft zu weniger Fehlern führt, aber die Entwicklungsaufwände gerne mal um Zehnerpotenzen erhöht. Auf Faktor 10 bis 100 an Mehraufwand kommt man da locker.
Auch werden bei so manchem Projekt/Produkt Features abgekündigt - was aber sehr schwierig ist, weil es immer jemanden gibt, der sein Feature behalten möchte. Man schaue sich nur die Diskussion hier im Forum rund um das Ende von x.org bzw. X11 an.
Wir wollen mit Software auch immer mehr machen. Dementsprechend steigt die Komplexität und damit die realen oder vermeintlichen Bugs. Es gibt auch reichlich Projekte mit Zero-Bug-Policy, aber gerade bei Open-Source-Projekten kommen auch sehr viele fragwürdige Bug-Reports rein. Was macht man, wenn der Bug-Report gegen eine uralte Version geht und mit der aktuellen Version vom Maintainer nicht reproduzierbar ist und man auf Feedback vom Bug-Reporter wartet?
Es sind auch die Zeiten vorbei, in denen man tagelang händisch seine Software bei jeder Änderung testen musste und via CD ausgeliefert hat. Durch die kurzen Turnaround-Zeiten ist es natürlich einfacher, auftretende Bugs einfach zeitnah zu fixen.
Um die Kurve zurück zu OpenBSD zu kriegen: wo ist die Grenze zu sinnvollen Features?
- Brauchen wir wirklich Dateisysteme wie ZFS oder btrfs (die viele Unix-Philosophien verletzen) oder reicht nicht UFS völlig aus?
- Brauchen wir wirklich Bluetooth? Man kann doch auch kabelgebundene Geräte verwenden.
- Brauchen wir wirklich Power Management oder ist es zugunsten der geringeren Komplexität besser, auf den komplizierten Code zu verzichten und dafür mehr Energie zu verbrauchen?
Andy_m4
Well-Known Member
Vielleicht hätte man das trotzdem einfach mal machen sollen, so nach dem Motto:
Die ganze Welt benutzt es und wer die Features behalten will, soll sich gefälligst dran beteiligen.
Auf der anderen Seite hat man ja auch so viel Aufwand. Der wird bloß immer klein gerechnet.
Niemand geht ja hin und sagt: Ich schreibe jetzt Software und ich kalkuliere jetzt schon ein, das ich in Zukunft mit (nicht wenigen) Bugs zu kämpfen haben werde.
Denn deren Fix kostet auch, taucht aber auch erst später als Kostenfaktor auf.
Außerdem ist es gut, wenn der Code und Programmiersprache Verifikation quasi supportet. Das macht entweder "niemand", weil dann das gerade hippe Framework nicht supportet ist oder man Bestandscode hat auf dem man aufbaut.
Erfahrungsgemäß regen sich immer die am meisten auf, die nie etwas beitragen. :-)
Naja. :-)
Software leichter verteilen zu können hat aber auch dazu geführt, das man Releases nicht mehr so sorgfältig testet, weil man sich immer sagen kann: "Wenn was ist, fixen wir es später".
Ich will nicht sagen, das früher alles besser war, aber ich hab den Eindruck, heutzutage treffe ich häufiger auf Bugs als früher. Und ja. Das liegt sicher auch daran, das ich heute mehr Software einsetze als früher.
Aber ist ja auch nicht so, das Bugs dann unbedingt zeitnah gefixt werden.
Außerdem hat man durch das "release often" das Problem, das die Software zu einem "moving target" wird. Das sich Dinge ändern. Und das evtl. auch Bugs gefixt werden aber auch neue hinzu kommen.
Früher hatte man das Problem nicht so in dem Maße. Wie gesagt. Da gabs auch Bugs. Die kannte man aber irgendwann und konnte lernen, damit umzugehen. Heute ist muss man sich ständig an Änderungen gewöhnen.
Inzwischen hab ich eine regelrechte Aversion gegen Updates weil ich immer denke: "Was ist jetzt schon wieder geändert" und "Was sind da wieder für neue Fehler drin".
Und man kann Updates ja auch nicht vor sich herschieben (zumindest nicht lange), weil ja häufig auch sicherheitsrelevante Bugs gefixt werden. Man hat regelrecht ein ungutes Gefühl, wenn die Software nicht auf den neusten Stand ist.
Ich glaube, wir haben uns an die (kurzen) Updatezyklen auch gewöhnt. Wenn mal ein Jahr lange keine Updates kommen, fängt man sich schon an zu fragen, ob sich überhaupt noch wer um die Software kümmert und ob die überhaupt anständig gewartet wird.
Daher ist auch die Herstellerseite inzwischen so ein bisschen angehalten, öfter mal zu updaten auch dabei auch sichtbare Änderungen zu machen, damit der Kunde sieht "Ah. Da tut sich was". Insofern schaukelt sich das auch ein wenig selbst hoch.
Insofern finde ich es wohltuend, wenns da auch mal Software gibt, die so ein wenig auf die Bremse tritt und wo es wenig Updates mit langer "Haltbarkeit" gibt.
Dann teilt man das halt mit. :-)
Jetzt sind wir aber arg off-topic - das schreit nach einer Verschiebung ins Geplauder-Forum...
Ich bin deiner Meinung. Rückblickend wäre Lernen durch Schmerzen die bessere Alternative gewesen.
Rückblickend ist aber auch alles offensichtlich.
Häufig ein Fall von Lieber den Spatz in der Hand als die Taube auf dem Dach. Reichlich Software wäre niemals entstanden, hätte man von Anfang an ehrlich gerechnet.
Idealerweise verdient man dann mit der Software schon genug Geld, dass man hinterher aufräumen kann.
Ich bin ja schon froh über Programmiersprachen mit einem ausdrucksstarken, statischen und starken Typsystem, deren Community groß genug ist. Ohne Anspruch auf Vollständigkeit kommen mir da spontan nur Typescript, Kotlin und zunehmend Rust in den Sinn (wobei die auch wieder ihre eigenen Probleme haben).
Es gibt für die Fehlerfreiheit noch bessere Sprachen (wenn man ausschließlich die Programmiersprache an sich betrachtet), dann läuft man aber in der Praxis in andere Probleme (Idris, ADA, Haskell, F# und viele andere lassen grüßen), die man erst recht nicht haben möchte.
Gerne in Personalunion mit der Weigerung, sich auch nur ein Quentchen in die Position des anderen zu versetzen.
Wobei man auch Umstände kritisieren darf, zu deren Verbesserung man nichts beitragen kann - der Ton macht die Musik.
Die Qualität ist je nach Bereich schon deutlich gestiegen. Unit Tests, Continuous Integration, statische Codeanalyse und vieles mehr haben schon für eine deutliche Steigerung dessen geführt, was mit moderatem Wissen und moderatem Aufwand heutzutage möglich ist.
Müll gibt es aber natürlich nach wie vor reichlich, allein schon weil deutlich mehr Software produziert wird...
Wenn ich mir die Liste installierter Software auf meinem Rechner anschaue, sind Anzahl und Möglichkeiten förmlich explodiert.
Das war früher definitiv nicht besser.
Ich bin ein Freund von häufigen Releases. Es ist viel einfacher, ein Problem zu diagnostizieren, wenn sich 1 Paket geändert hat, als bei einem Big-Bang-Release, bei dem sich auf einen Schlag hunderte oder tausende Pakete geändert haben.
Die Bugs blieben einem dafür auch lange erhalten. Debian stable mit jahrelang ungefixten Bugs - das war und ist echt nicht paradisisch.
Jeder wie er mag. Viele Hersteller bieten nicht umsonst LTS-Versionen ihrer Software an, wenn man keine regelmäßigen Veränderungen haben möchte. Dafür hat man von Zeit zu Zeit dann riesige Änderungen auf einmal mit entsprechenden Schmerzen.
Es hat ja auch schon reichlich Software gegeben, die ihre Dependencies nicht gepflegt haben und dann eiskalt erwischt wurden, als sie in einer Hauruckaktion Dependency A aktualisieren mussten, die wiederum ein Update von Dependency B erfordert hat, womit man aber auch Dependency C aktualisieren musste...
Zur Vermeidung von bit rot muss man auch regelmäßige Updates fahren. Sonst kommt leicht es zu oben beschriebener Situation.
Als Hersteller will man kurze Feedback-Zyklen von den Anwendern haben. Die erreicht man nur mit häufigen Releases.
Meist ist das dann aber auch Software, die entweder wenig Weiterentwicklung erfährt oder bei der bei einem großen Update alle Probleme auf einmal einschlagen.
Das macht man - was aber auch wieder dazu führt, das in der Übersicht ein offener Bug steht.
Ich bin deiner Meinung. Rückblickend wäre Lernen durch Schmerzen die bessere Alternative gewesen.
Rückblickend ist aber auch alles offensichtlich.
Häufig ein Fall von Lieber den Spatz in der Hand als die Taube auf dem Dach. Reichlich Software wäre niemals entstanden, hätte man von Anfang an ehrlich gerechnet.
Idealerweise verdient man dann mit der Software schon genug Geld, dass man hinterher aufräumen kann.
Ich bin ja schon froh über Programmiersprachen mit einem ausdrucksstarken, statischen und starken Typsystem, deren Community groß genug ist. Ohne Anspruch auf Vollständigkeit kommen mir da spontan nur Typescript, Kotlin und zunehmend Rust in den Sinn (wobei die auch wieder ihre eigenen Probleme haben).
Es gibt für die Fehlerfreiheit noch bessere Sprachen (wenn man ausschließlich die Programmiersprache an sich betrachtet), dann läuft man aber in der Praxis in andere Probleme (Idris, ADA, Haskell, F# und viele andere lassen grüßen), die man erst recht nicht haben möchte.
Gerne in Personalunion mit der Weigerung, sich auch nur ein Quentchen in die Position des anderen zu versetzen.
Wobei man auch Umstände kritisieren darf, zu deren Verbesserung man nichts beitragen kann - der Ton macht die Musik.
Die Qualität ist je nach Bereich schon deutlich gestiegen. Unit Tests, Continuous Integration, statische Codeanalyse und vieles mehr haben schon für eine deutliche Steigerung dessen geführt, was mit moderatem Wissen und moderatem Aufwand heutzutage möglich ist.
Müll gibt es aber natürlich nach wie vor reichlich, allein schon weil deutlich mehr Software produziert wird...
Wenn ich mir die Liste installierter Software auf meinem Rechner anschaue, sind Anzahl und Möglichkeiten förmlich explodiert.
Das war früher definitiv nicht besser.
Ich bin ein Freund von häufigen Releases. Es ist viel einfacher, ein Problem zu diagnostizieren, wenn sich 1 Paket geändert hat, als bei einem Big-Bang-Release, bei dem sich auf einen Schlag hunderte oder tausende Pakete geändert haben.
Die Bugs blieben einem dafür auch lange erhalten. Debian stable mit jahrelang ungefixten Bugs - das war und ist echt nicht paradisisch.
Jeder wie er mag. Viele Hersteller bieten nicht umsonst LTS-Versionen ihrer Software an, wenn man keine regelmäßigen Veränderungen haben möchte. Dafür hat man von Zeit zu Zeit dann riesige Änderungen auf einmal mit entsprechenden Schmerzen.
Es hat ja auch schon reichlich Software gegeben, die ihre Dependencies nicht gepflegt haben und dann eiskalt erwischt wurden, als sie in einer Hauruckaktion Dependency A aktualisieren mussten, die wiederum ein Update von Dependency B erfordert hat, womit man aber auch Dependency C aktualisieren musste...
Zur Vermeidung von bit rot muss man auch regelmäßige Updates fahren. Sonst kommt leicht es zu oben beschriebener Situation.
Als Hersteller will man kurze Feedback-Zyklen von den Anwendern haben. Die erreicht man nur mit häufigen Releases.
Meist ist das dann aber auch Software, die entweder wenig Weiterentwicklung erfährt oder bei der bei einem großen Update alle Probleme auf einmal einschlagen.
Das macht man - was aber auch wieder dazu führt, das in der Übersicht ein offener Bug steht.
midnight
OpenBSD & FreeBSD
Das ist alles richtig. OpenBSD ist allerdings primaer ein Server-OS mit Fokus auf Sicherheit und vermeidet wo es geht die GPL und unpassende Lizenzen und auch Blobs. ZFS und btrfs haben leider die falsche Lizenz. Die einzige Auswahl waere HAMMER2, woran bereits extern gearbeitet wird.
Der Bluetooth-Stack ist ziemlich verbuggt und voller Blobs. Daher wurde er irgendwann entfernt. Die wenigsten OpenBSD-User, die OpenBSD auf dem Desktop verwenden, vermissen Bluetooth. Die meisten Bluetooth-Geraete liefern eh einen USB-Dongle mit, der dann auch unter OpenBSD funktioniert.
Powermanagement ist unter OpenBSD auch schlechter als unter Linux. Allerdings ist das inzwischen um Welten besser geworden und hat mich ehrlich gesagt noch nie gestoert, da mein Notebook nie den ganzen Tag ohne Steckdose durchhalten musste.
Ich verwende OpenBSD auf dem Desktop, da ich dort die gleichen Tools verwenden kann wie auch auf meinen OpenBSD-Servern und Routern. Das ist alles eine Frage der Gewohnheit. Mehr als Programmieren, Fachbuecher als Ebooks lesen, Emails lesen oder schreiben, gelegentlich LibreOffice verwenden oder im Internet surfen und chatten tue ich mit dem Rechner auch nur selten.
OpenBSD hat eher diese Philosophie:
Perfection is attained
not when there is nothing left to add
but when there is nothing left to take away.
(Antoine de Saint-Exupéry)
Andy_m4
Well-Known Member
Das wäre vielleicht gar nicht so schlecht. :-)
Weil es einfach viel Ärger erspart. Insbesondere als Kunde schaut man ja dann in die Röhre.
Ist ja auch irgendwie nicht einzusehen, warum Software anders behandelt werden sollte als Hardware.
Wenn ein Kühlschrank gekauft wird, würde das ja auch niemand akzeptieren, wenn einmal im Monat jemand zum Patchday vorbei kommt, um irgendwelche kritischen Teile zu wechseln die ja von Anfang an fehlerhaft waren.
Oder wenn die so konstruiert sind, das die gefährlich sind.
Warum sollte das bei Software anders sein?
Das man jetzt kostenlose Software oder Open-Source nicht auf diese Weise regulieren kann/sollte, ist schon klar. Aber bei Kommerz-ware ist das eigentlich nicht einzusehen.
Nur geschieht das halt kaum. Schön zu bestaunen bei Firmen, wo man denkt das da eigentlich das Geld dafür da wäre.
Stattdessen investiert man lieber in neue Features. Klar kann man sagen, das hier die Konsumenten schuld sind, die eben nach neuen Features gucken.
Damit macht man sich es aber zu einfach. Man braucht einfach bessere Möglichkeiten den Hersteller zur Verantwortung zu ziehen. Dann kann sich auch niemand mehr so einfach mit schlechter Software durchmogeln.
Vermutlich schon. Auf der anderen Seite trifft man halt auch viele leichte Fehler, wo man sich schon denkt: "Hat das denn keiner mal ausprobiert?"
Das ist dann noch gepaart damit, das kaum einer noch hinkriegt eine vernünftige (aussagekräftige) Fehlermeldung zu liefern.
Hab hier gerade ein Android-Handy, was nicht updaten will und nur lapidar sagt: "Updateprozess kann nicht durchgeführt werden". Aber was nun konkret das Problem ist, ist nicht (bzw. nur mit Aufwand) rauszukriegen.
Und solche Dinge sind nicht Einzelfälle, sondern man kann schon fast sagen die Regel.
Ja. Das geht aber an dem, was ich gesagt habe, vorbei.
Das Problem hast Du ja nur, weil die Situation ist, wie sie ist.
Und das vor allem weil es kostengünstiger ist.
Der Anwender ist heute einfach ausgelagerter Tester. Man hat sozusagen die Kosten für das, was man früher selbst machen und begleiten musste, externalisiert.
Ich find das auch ok, wenn beide Seiten damit einverstanden sind und man das vorher vereinbart hat. Nur geschieht das häufig ja nicht.
Oder weil eine Software ausentwickelt ist. Nur passiert das heute nicht mehr so häufig. Es gibt eine Tendenz dazu, immer mehr Features einzubauen und Software aufzublasen.
Zu OpenBSD auf Laptops:
- Die meisten Leute kennen es überhaupt nicht, so wie alle anderen BSD's. Denen ist Windows und Mac OS ein Begriff und von Linux haben sie schon gehört.
- Ausgefeiltes Powermanagement ist bei Laptops mittlerweile sekundär, weil die Teile meist als Desktop verwendet werden, den man im Falle des Falles auch mal mitnehmen kann. Kreativ-Leute stöpseln eben noch einen externen Monitor dran.
- Das große Hindernis in der Breite wird Hardwareunterstützung und die Handhabung an sich sein. Ich betreue 2 Laptops mit Debian in meinem Umfeld. Mit OpenBSD würde ich diese unbedarften Leute nicht nerven wollen. Zu dem Mehraufwand bei den BSD's muss man halt bereit sein.
Ich habe in der letzten Zeit mit OpenBSD tatsächlich viel Bildbearbeitung betrieben, Texte geschrieben und Broschüren layoutet, die dann an die Druckerei gingen. Da hieß es ja vor ewigen Zeiten, dass so was unbedingt einen Mac braucht. Die Zeiten ändern sich.
PS: Ansonsten lausche ich still und leise euren Ausführungen.
midnight
OpenBSD & FreeBSD
Fuerwahr habe ich Gimp, Inkscape, Scribus und Blender unter OpenBSD unterschlagen. Gerade Gimp und Blender verwende ich unter OpenBSD sehr haeufig. Ich hatte vor einiger Zeit das aktuelle Design fuer @dettus d11amp mit Gimp gepixelt und mit Blender erstelle ich z.B. 3D-Modelle fuer meinen 3D-Drucker oder auch fuer ein altes Browsergame, welches ich unter OpenBSD betreibe und weiterentwickle. :-)
Zuletzt bearbeitet:
Ich wollte nur am Bespiel von OpenBSD darauf hinaus, dass das Entwickeln ebenso wie das Nichtentwickeln von Features seinen Preis hat. Eine zu kleine Community - mangels Feature - verursacht auch Schmerzen (siehe NetBSD).
Nicht alles, was hinkt, ist ein Vergleich. Einen Kühlschrank zu patchen ist auch ungleich teurer und aufwändiger als ein Software-Update, dessen Grenzkosten gegen null gehen.
Die mögliche Ausgestaltung dessen rechtfertig fast schon einen eigenen Thread.
Bei kürzeren Feedback-Zyklen kommt halt am Schluss auch bessere Software raus, was die Nachfrage natürlich beeinflusst und tendenziell einen Trend hin zu kürzeren Release-Zyklen antreibt.
Ansonsten bist in der Wahl der von dir verwendeten Software frei. Bei Betriebssystemen hast du von Rolling Release bis 13 Jahre keinerlei Feature-Updates (Red Hat et al.) das komplette Programm im Angebot.
Ich kenne auch wirklich wenig Software, die ich als ausentwickelt bezeichnen und bei der ich mir nicht irgendeine Form der Verbesserung wünschen würde.
Zum Thema Weiterentwicklung, bei Blender haben wir jetzt eines der ersten Features, das zwingend Wayland voraussetzt und unter X11 schlicht unmöglich ist: HDR
Andy_m4
Well-Known Member
Naja. Das ist ja auch der Punkt, worum es geht. Dadurch das es billig ist kann sich ja der Hersteller erlauben zu "schlampen".
Ich weiß nicht, ob man das mit der besseren Software generell so sagen kann.
Ich würde dem auch nicht grundsätzlich widersprechen.
Ich sehr nur ein ganz klares Für und Wider und das es sich unterschiedlich auswirken kann und es nicht immer besser ist.
Und ich habe eben versucht klar zu machen, welche Probleme auch damit einhergehen. Und die lassen sich auch nicht so einfach wegwischen mit "ist doch alles halb so wild".
Es geht gar nicht so sehr um mich oder was ich anders machen könnte. Das weiß ich natürlich alles.
Es geht darum, den IST-Zustand zu beschreiben.
Irgendeine Form der Verbesserung lässt sich wahrscheinlich immer irgendwie finden.
Trotzdem ist feature-bloat ein Problem. Nicht umsonst gibts ja auch immer wieder neue Software, die als schlank daher kommt und (zumindest zu Anfang) bewusst Features weglässt. Das würde es ja nicht geben, wenn Feature-Reichtum kein Problem wären.
Schlamperei kostet den Hersteller trotzdem viel Geld (und sei es, dass das Folgegeschäft ausbleibt). Frag mal Myspace, Lotus, Knight Capital, Netscape, Microsoft und viele andere Firmen.
Ziemlich off-topic, aber vergleichen wir doch mal zwei Softwareprodukte. Beide können aufgrund ihrer Natur wöchentlich released werden.
- Software A wird wöchentlich released
- Software B wird jährlich released
- Im Schnitt kommt jeden Monat ein Bug in der Entwicklung dazu, der nicht von der hauseigenen Qualitätssicherung gefunden wird
Software A bringt eine neue Version raus, die einen Bug enthält. Der Fehler lässt sich vom Entwickler leicht eingrenzen, die Erinnerung an die Codestelle ist noch frisch, der Fix schnell geliefert. Falsche Grundannahmen in der Entwicklung lassen sich zeitnah korrigieren.
Software B bringt eine neue Version raus. Wir haben jetzt leider parallel mindestens 12 Bugs, für die Reports eintrudeln. Plus Bugs, weil Bugs mit Bugs interagieren. Plus Bugs, die von anderen Bugs verdeckt werden.
Software B braucht jetzt erstmal Wochen der Triage, um die Bug-Reports zu sortieren. Viele Bugs sind ja vor vielen Monaten entstanden und die Entwickler haben längst vergessen, woran sie überhaupt damals gearbeitet hatten. Die in 12 Monaten aufgelaufenen Änderungen im Quellcode sind natürlich auch gigantisch und müssen erstmal für jeden Bug neu analysiert werden.
Einige Bugs lassen sich auch gar nicht sofort beheben, weil falsche Grundannahmen sich 12 Monate durch die Codebasis fortpflanzen konnten, viel neuer Code auf diesen falschen Annahmen aufgebaut hat und jetzt erstmal ein aufwändiges Refactoring stattfinden muss, bevor man überhaupt mit der Fehlerbehebung anfangen kann.
Software B muss jetzt auch anfangen, ein internes Release-Management aufzubauen, um die Situation bei der "stabilen" Version in den Griff zu kriegen. So mancher Anwender wartet jetzt auch schon mal viele Monate auf seine Fehlerbehebung.
Mehr Testkapazität braucht man auch, weil man jetzt immer die "stabile" Version beim Anwender und die aktuelle Entwicklungsversion testen muss. Plus Nachtests, wenn ein Bug in der "stabilen" Version behoben wird und auf der Entwicklungsversion auch behoben werden muss (oder umgekehrt).
Viele Anwender von Software B warten jetzt natürlich aus der Erfahrung heraus lange mit den Upgrades (wodurch der Feedback-Zyklus noch länger und das Problem noch größer wird). Jetzt hat sich der Feedback-Zyklus für manche Änderungen auf gut und gerne 18-24 Monate verlängert.
Die ganzen Aufwände von Software B führen natürlich auch dazu, dass weniger Kapazität zur Weiterentwicklung der Software zur Verfügung steht.
Bei obigem Beispiel mit Software, die man wöchentlich releasen kann - welchen Vorteil hat Variante B?
Zuletzt bearbeitet:
Andy_m4
Well-Known Member
Naja. Das sehe ich nicht so. Sonst würde es ja etliche Hersteller nicht mehr geben.
Gerade Dein Microsoft-Beispiel zeigt das ja sehr schön. Die kommen seit Jahrzehnten mit Schlamperei durch.
https://de.wikipedia.org/wiki/Microsoft#Umsatz-_und_Gewinnentwicklung
Die machen also satte Gewinne. Oder meinst Du jetzt, das die noch mehr Gewinn gemacht hätten, wenn die nicht geschlampt hätten?
Und Netscape ist ja auch nicht pleite gegangen, weil die ein schlechtes Produkt abgeliefert haben. Sondern weil Marc Andreessen die tolle Idee hatte, einen Browser verkaufen zu wollen.
Das klappte eher nicht so gut. Erstens weil sich die Leute an kostenlose Browser gewöhnt hatten und zweitens weil es mit Microsoft Konkurrenz gab, die ihren Browser einfach quersubventionieren konnte ohne auf direkte Einnahmen angewiesen zu sein.
Mit vormals kostenlosen Diensten/Programmen Geld verdienen hat ja auch, gerade im Internet, vielen anderen Kopfzerbrechen bereitet und das teilweise bis heute.
Ich kenne all diese Gedankengänge. Und wie schon gesagt: Man kann sich immer eine idealisierte Welt zusammenbasteln in der dann alles super funktioniert. Nur haben wir die - wie bereits gesagt - eben nicht. Und ich greife nur das auf, was ich in der realen Welt beobachte.
Und an der Stelle möchte ich auch nochmal sagen, das ich weder das eine Modell noch das andere Modell klar bevorzuge. Es geht ja genau darum zu differenzieren. Und klar. Wenn man ein junges Produkt hat (oder sagen wir mal Produktklasse) dann ist da logischweise noch viel Bewegung drin, weil man noch nicht genau weiß, welche Vorgehensweise gut ist und welche nicht so gut und dann muss man halt auch schauen und dann machen kruze Updatezyklen auch Sinn.
Bei althergebrachten Softwarekonzepten eher nicht so. Sowas wie ein Editor. Ist im Prinzip ausentwickelt. Man weiß, was man davon erwarten kann und wie Dinge umgesetzt werden. Da benötigt man dann auch nicht viele Updates und es beschränkt sich im Wesentlichen auf Produktpflege und kleinere Änderungen. Und klar kann auch mal eine ganz neue Idee kommen, die Editoren überflüssig macht. Aber dann macht es eh kaum Sinn den bestehenden Editor umzubauen, sondern man startet auf der grünen Wiese.
Aber selbst bei jungen Produkten kann es sinnvoll sein, sich Zeit zu lassen und sich was zu überlegen. Nur nimmt die sich "keiner" mehr, weil time to market muss kurz sein damit man schnell Einnahmen hat und sich auch vor der Konkurrenz etablieren kann. Qualität bleibt da logischerweise auf der Strecke. Wie solls auch anders sein. Schnell sein und gründlich/softfältig sein sind Sachen, die sich widersprechen.
Und klar. Theoretisch kann man das Qualitätsproblem aufholen, wenn man erfolgreich ist.
Aber das geschieht oftmals nicht in dem Maße. Weil entweder hat man eine marktbeherrschende Stellung: Dann gibts kein Anreiz sich zu verbessern, weil Konkurrenz eh chancen los ist.
Und hat man noch vitale Konkurrenz hat man keine Zeit für Qualität, weil man durch nachlegen von Features dazu angehalten ist, sich vom Konkurrent abzusetzen.
Es gibt natürlich zu allem auch Gegenbeispiele. Das will ich gar nicht verleugnen. Es geht mir hier um einen allgemeinen Trend.
Und ja. Moderne Softwareentwicklung hilft definitiv dabei, Probleme zu vermeiden und Qualität zu verbessern. Allerdings steigt halt auch die Komplexität. Und es ist ja nicht so, das schön linear in doppelt zu viel Codezeilen potentiell doppelt zu viele Bugs stecken, sondern das Wachstum an Bugs ist exponentiell. Und "in the long run" gewinnt nun mal die Exponentialfunktion egal was Du tust.
(und jetzt kriegen wir mit "KI"/machine-learning auch noch Software, die wir noch sehr viel komplexer ist und - zumindest zur Zeit - nicht mal mehr vernünftig debuggen und gezielt bugfixen können)
Logischerweise bringt es wenig einfach nur die Release-Zeit zu verlängern wenn dafür trotzdem viele Bugs auftauchen.
Mein Forderung war ja, das man diese Zeit dann auch für sorgfältige Entwicklung nimmt.
Du konstruierst Dir das wunderbar so hin, das kurze Release-Zyklen besser aussehen und - oh Wunder - steht das "Rolling-Release" am Ende der Analyse besser da.
Du nimmst immer selektiv den Teil aus Deiner idealisierten Welt und den Teil der aus der realen Welt so, das es für Deine Argumentation gut aussieht.
Also entweder gucken wir vollständig auf die Realität oder vollständig aufs (erstrebenswerte) Ideal. Alles andere macht wenig Sinn.
Thema Updates und deren Häufigkeit.
Wir müssen da mal unterscheiden zwischen verschiedenen Programmtypen und Programmnutzern und ob Updates neue Eigenschaften einbauen oder relevante Fehler fixen. Es gibt da ja verschiedene Nutzertypen (Sicher oder schnell neue Funktion als Prämisse).
Für mich gilt:
Das Programmierpragma "Das fixen wir dann mit der nächsten Release" oder "ich habe über den Fehlerpfad nicht nachgedacht" ist bei vielen SW-Systemen nicht tragbar. Aber dann muß man auch Geld und Zeit in die Hand nehmen und Profis dran lassen.
Ich habe ja früher Automatisierungssoftware für Fertigungszellen / Fabriken gemacht. Da geht's um viel Geld pro Stunde Ausfall des Systems. Da werden auch viele SW Erweiterungen (neue Maschinen, neue Prozesse, ...) gemacht, aber das darf das System nicht lahm legen. Der bestehende Code wird möglichst nicht angelangt und Module dürfen sich nicht auf irgendwelche undokumentierten Verhaltensweisen verlassen. Am Hauptsystem gepatched wurde auch nur in festen Zyklen nach langen Tests. Beim Thema Code-Optimierung gilt m.E. oft: Schnellere HW ist billiger und zuverlässiger als eine SW-Änderung plus Fehlerrisiko.
An sicherheitsrelevanten Systemen patchen - da setzt man ganz schnell eine Kette mit Aufsichtsbehörden etc. in Gang. Also das muß auch auf Anhieb funktionieren.
Mal zum Vergleich: Elektronik und Mechanik Ingenieure können auch nicht so einfach patchen ("ach die Schaltung mit dem DC/DC Konverter war jetzt doch nicht so toll und brennt ab und zu durch"). 1 Mio Steuergeräte tauscht man nicht so einfach kostenneutral. Wenn ein paar 5 Euro Netzteile einfach nicht mehr gehen egal, wenn sie abfackeln: nicht egal.
Für mich gilt:
BSD als OS, weil da weniger an der Code Basis rumgespielt wird und nicht jedes Feature hopplahopp eingebaut wird.
SW, die tut, benutzen, auch wenn sie alt ist. Da sind dann viele Fehler schon rausgemacht.
SW, die sich auf eine begrenzte Zahl an Aufgaben konzentriert, benutzen.
KISS Prinzip beachten.
Den etabliertesten kleinstmöglichen Standard zum Datenaustausch benutzen.
Ich denke, daß ich dann zuverlässig arbeiten kann ohne dauernde Updates und Sicherheitsrisikos. SW ist für mich ein Werkzeug (wie ein Schraubenschlüssel) und das muß tun, wofür es bestimmt ist.
Falls jetzt jemand sagt, daß in alter SW Sicherheitslücken ungepatcht sind - auch alte SW wird gewartet, aber es sind bei bewährter SW halt wenig Fehler drin, sodaß Patches selten notwendig sind. Und die werden auch gemacht. Übel wird's , wenn die SW für einen Patch umgebaut werden muß. Das sollte man vermeiden.
Viel was ich erlebt habe, ist halt schlampige Programmierung. Das Verhalten von Sub Funktionen war außerhalb des normalen Eingabebereichs (oder was der Programmierer dafür hielt) undefiniert. Fehlerbehandlung fand nicht statt. Der Satz "Funktionen geben Fehlercodes zurück, damit man sie beachtet" wird oft ignoriert. Bei Funktionen war zum Teil gar nicht klar, was sie machen müssen. Und dann wurde halt gepatched. Funktionen wurden auf Zuruf vom Kunden eingebaut.
Leider ist es halt oft schwer, dem Mgmt. beizubringen, daß 70% vom Code verhältnismäßig schnell erledigt sind, aber Definition, umfassende Tests und Dokumentation (OK, SW-Systeme brauchen nicht dokumentiert werden, weil der Code dokumentiert ja was er macht) richtig Geld und Zeit brauchen.
Wir müssen da mal unterscheiden zwischen verschiedenen Programmtypen und Programmnutzern und ob Updates neue Eigenschaften einbauen oder relevante Fehler fixen. Es gibt da ja verschiedene Nutzertypen (Sicher oder schnell neue Funktion als Prämisse).
Für mich gilt:
Das Programmierpragma "Das fixen wir dann mit der nächsten Release" oder "ich habe über den Fehlerpfad nicht nachgedacht" ist bei vielen SW-Systemen nicht tragbar. Aber dann muß man auch Geld und Zeit in die Hand nehmen und Profis dran lassen.
Ich habe ja früher Automatisierungssoftware für Fertigungszellen / Fabriken gemacht. Da geht's um viel Geld pro Stunde Ausfall des Systems. Da werden auch viele SW Erweiterungen (neue Maschinen, neue Prozesse, ...) gemacht, aber das darf das System nicht lahm legen. Der bestehende Code wird möglichst nicht angelangt und Module dürfen sich nicht auf irgendwelche undokumentierten Verhaltensweisen verlassen. Am Hauptsystem gepatched wurde auch nur in festen Zyklen nach langen Tests. Beim Thema Code-Optimierung gilt m.E. oft: Schnellere HW ist billiger und zuverlässiger als eine SW-Änderung plus Fehlerrisiko.
An sicherheitsrelevanten Systemen patchen - da setzt man ganz schnell eine Kette mit Aufsichtsbehörden etc. in Gang. Also das muß auch auf Anhieb funktionieren.
Mal zum Vergleich: Elektronik und Mechanik Ingenieure können auch nicht so einfach patchen ("ach die Schaltung mit dem DC/DC Konverter war jetzt doch nicht so toll und brennt ab und zu durch"). 1 Mio Steuergeräte tauscht man nicht so einfach kostenneutral. Wenn ein paar 5 Euro Netzteile einfach nicht mehr gehen egal, wenn sie abfackeln: nicht egal.
Für mich gilt:
BSD als OS, weil da weniger an der Code Basis rumgespielt wird und nicht jedes Feature hopplahopp eingebaut wird.
SW, die tut, benutzen, auch wenn sie alt ist. Da sind dann viele Fehler schon rausgemacht.
SW, die sich auf eine begrenzte Zahl an Aufgaben konzentriert, benutzen.
KISS Prinzip beachten.
Den etabliertesten kleinstmöglichen Standard zum Datenaustausch benutzen.
Ich denke, daß ich dann zuverlässig arbeiten kann ohne dauernde Updates und Sicherheitsrisikos. SW ist für mich ein Werkzeug (wie ein Schraubenschlüssel) und das muß tun, wofür es bestimmt ist.
Falls jetzt jemand sagt, daß in alter SW Sicherheitslücken ungepatcht sind - auch alte SW wird gewartet, aber es sind bei bewährter SW halt wenig Fehler drin, sodaß Patches selten notwendig sind. Und die werden auch gemacht. Übel wird's , wenn die SW für einen Patch umgebaut werden muß. Das sollte man vermeiden.
Viel was ich erlebt habe, ist halt schlampige Programmierung. Das Verhalten von Sub Funktionen war außerhalb des normalen Eingabebereichs (oder was der Programmierer dafür hielt) undefiniert. Fehlerbehandlung fand nicht statt. Der Satz "Funktionen geben Fehlercodes zurück, damit man sie beachtet" wird oft ignoriert. Bei Funktionen war zum Teil gar nicht klar, was sie machen müssen. Und dann wurde halt gepatched. Funktionen wurden auf Zuruf vom Kunden eingebaut.
Leider ist es halt oft schwer, dem Mgmt. beizubringen, daß 70% vom Code verhältnismäßig schnell erledigt sind, aber Definition, umfassende Tests und Dokumentation (OK, SW-Systeme brauchen nicht dokumentiert werden, weil der Code dokumentiert ja was er macht) richtig Geld und Zeit brauchen.
Gerne:
- Spotify vs. iTunes: iTunes war der alles dominierende Platzhirsch von Apple. Leider waren die Updates immer an die jährlichen macOS-Releases gekoppelt, während Spotify kontinuerlich neue Releases und Verbesserungen rausgebracht hat - und so Apple das Wasser abgegraben hat.
- Figma vs. Sketch vs. AdobeXD: Sketch (2010) war marktbeherrschend mit Releases alle 2 Jahre. Figma (2016) hat durch kontinuerliches Feedback und schnelle Releases Sketch schnell das Wasser abgegraben. Selbst Adobes XD (2017) konnte trotz der Milliarden von Adobe im Hintergrund aufgrund der damals (vor Adobe Cloud) noch "klassischen" Adobe-Releasezyklen nicht mithalten.
- Slack vs. Hipchat: Hipchat konnte eigentlich nur gewinnen. Mit Atlassian (bekannt v.a. durch Jira und Confluence) hatte man praktisch schon überall den Fuß in der Tür. Es hat dann aber mit jährlichen Releases doch nicht gereicht, weil Slack wöchentlich besser wurde. Hipchat hat dann in großen Releases immer die Features von Slack kopiert und rausgebracht, die Slack schon Monate vorher durch noch bessere Lösungen ersetzt hatte. Umgekehrt konnte Slack gute Ideen von Hipchat binnen kürzester Zeit kopieren und ausrollen.
Die machen also satte Gewinne. Oder meinst Du jetzt, das die noch mehr Gewinn gemacht hätten, wenn die nicht geschlampt hätten?
Natürlich. Microsoft könnte heute zusätzlich den Markt für Browser (statt Google), Server (statt Linux), Tablets (statt Apple), Smartphones (statt Apple/Google) und vieles mehr beherrschen.
Zusätzlich hat Netscape von 1998-2002 kein neues Release rausgebracht. Der Internet Explorer hatte 4 Jahre ungestört Zeit, besser als Netscape zu werden. Die 4 Jahre im stillen Kämmerlein waren für Netscape katastrophal, weil Netscape Millionen von Seiten (die die interne Qualitätssicherung natürlich nicht allesamt testen konnte) fehlerhaft oder gar nicht dargestellt hat.
Das hätte man mal neovim oder Visual Studio Code sagen sollen.
Auch die will man doch möglichst zeitnah an den Endanwender bringen und nicht monate- oder gar jahrelang auf irgendwelchen Git-Branches verrotten lassen.
Als Endanwender möchte ich doch auch möglichst zeitnah Fehlerbehebungen und vieles mehr haben. Es ist doch Kacke, wenn ich einen Fehler in einem Open-Source-Projekt entdecke, fixe, mein Merge Request dafür akzeptiert wird und ich jahrelang auf ein offizielles Release warten muss, in dem mein Bugfix enthalten ist.
Auch auf der grünen Wiese gilt doch release early, release often. Du willst doch möglichst früh wissen, ob dein Konzept in der Praxis tatsächlich funktioniert.
Der Qualitätsanspruch ist aber unabhängig vom Release-Zyklus (abgesehen davon, dass Big-Bang-Releases natürgemäß mehr Probleme mit sich bringen).
Unnötig lange Release-Zyklen sorgen automatisch für mehr Verwaltungsaufwand. Der Aufwand dafür fehlt natürlich anderenorts - und sei es bei der Qualitätssicherung. Während man einerorts noch große Releases bürokratisch verwaltet, hat man anderenorts schon die Testautomatisierung optimiert.
Du konstruierst Dir das wunderbar so hin, das kurze Release-Zyklen besser aussehen und - oh Wunder - steht das "Rolling-Release" am Ende der Analyse besser da.
Ich warte gerne auf Beispiele, bei denen durch unnötig lange Releasezyklen die Qualität besser wird.
Solange die Anforderungen so erfreulich stabil sind.
Gerade im Bereich der Systemprogrammierung vermeidet man natürlich mit moderneren Programmiersprachen (z.B. Rust) viele potentielle Fehlerquellen, die mit C oder C++ auftreten können.
Je mehr Zeit zwischen Entwicklung und Einsatz in Produktion vergehen, desto größer ist natürlich das Risiko, dass das Delta sehr groß wird und größere Anpassungen fällig werden.
Zuletzt bearbeitet: