ComputerJunge schrieb:
Auch ich bin aus eigener Erfahrung zu der Einsicht gekommen, dass "Komplexe Software immer Bugs" haben wird.
Der Witz an der Sache ist ja: Bugs hatten wir schon früher. Ich will also das gar nicht unbedingt als "früher war alles besser" missverstanden wissen. Und ich muss sagen, wir hatten und haben große Fortschritte in der Softwareentwicklung. Viele Software die es heute gibt hätten wir früher gar nicht haben können. Und das nicht nur wegen der begrenzten Hardware-Ressourcen, sondern weil der Entwicklungsprozess so primitiv war, das es einfach nicht gegangen wäre. Man denke da nur mal an Sachen wie Unit-Tests und dergleichen. Heute total etabliert. Hats früher schlicht nicht gegeben.
All solche Sachen führen dazu das wir überhaupt komplexe Programme haben können ohne das es uns sofort alles auseinander fällt.
Mein Problem was ich habe ist das diese Fortschritte in der Softwareentwicklung viel zu schnell dadurch aufgefressen werden das wir noch mehr Komplexität einführen.
Wünschenswert wäre es ja, wenn wir jetzt irgendwie in der Softwareentwicklung auf einem Stand wären das wir unsere Programme beherrschen und wenn wir dann in der Softwareentwicklung Fortschritte machen uns erst dann auch erlauben unsere Programme komplexer zu machen.
Stattdessen ist es umgekehrt. Die Komplexität wächst und mit Fortschritten in der Softwareentwicklung versuchen wir das im nachhinein wieder einzufangen.
ComputerJunge schrieb:
Ich fand die Begründung für die harte Umstellung auf das AddOn-Konzept nachvollziehbar. Und die Idee eines "Boutique"-Browses mit einem "guten" Kern ist auch immer noch eine gute. Ich denke allerdings, das kommunizierte Ziel der Komplexitätsreduktion war nur vorgeschoben. Aus Nutzersicht wurde die Komplexität nur verlagert. Es ging primär um Kostenreduktion - eine vollkommen legitime Motivation.
Ob vorgeschoben oder nicht ist ja egal. Wichtig ist, was hinten raus kommt.
Und ja. Du hast durchaus in gewisser Weise Recht. Alles in AddOns auszulagern delegiert bestimmte Dinge an dem Nutzer. Der muss dann entscheiden was er nimmt und im Zweifel kannst Du dem immer vorwerfen: Was nimmst Du auch AddOn xyz. Selbst schuld.
Und ja. Auch die Motive die Du nennst will ich gar nicht in Abrede stellen.
Das spricht aber nicht gegen das Konzept ansich. Man kann ja durchaus beide Ansätze miteinander vereinen und das beste aus beiden rausholen.
Man kann ja einen schlanken Browser haben und dann z.B. davon eine Distribution mit bestimmten AddOns rausbringen (von mir aus auch vom Core-Team gepflegt oder was auch immer).
So hat man auf der einen Seite dem Rechnung getragen das jemand, der nur spezifische AddOns (oder gar keine) haben will das so tun kann. Auf der anderen Seite wird auch dem Normal-Nutzer entsprochen, der sich dann sein batteries-included-Browser holt. So analog zu "Standard-Install" und "Expert-Install" :-)
ComputerJunge schrieb:
Der Kern war/ist zu abgespeckt. In der Konsequenz hat man sich produktstrategisch durch diese strikte Philosophie die (funktionale) Attraktivität des Produkts zu stark von externen "Lieferanten" abhängig gemacht hatte. Und leider betraf das auch Funktionen, die nach meinem Dafürhalten zwingend zum Kernbrowser gehören, darunter Tab- und Sessionmanagement. Und Keyboard-Shortcuts sind immer noch unveränderlich.
Man kann natürlich immer darüber streiten was zum Kern gehören sollte und was nicht. Oder wie kleinteilig man bestimmte Dinge aufsplitten will. Wie eine AddOn-API aussehen und was die alles enthalten soll.
Man kann auch sicher kritisieren wie gut das im Firefox (oder anderen Browsern) umgesetzt ist. Aber das Konzept als Solches würde ich erst mal nicht in Frage stellen.
MountWalker schrieb:
Ich gestehe zu das Compiler ne gewisse Abhängigkeit von der CPU haben. :-)
Die Frage ist aber dann immer noch, wie weit reize ich das aus. Ich kann natürlich ne CPU-Detection machen und den Compiler anweisen da Spezialkniffe etc. auszunutzen. Ich kann aber natürlich auch sagen: Erzeuge mir mehr oder weniger generic x86-Code der quasi "überall" läuft aber halt nicht das rausholt was möglich wäre. Ich würde aber mal dreist behaupten der Code ist dann immer noch gut genug.
Insofern gibts da ja nicht nur Schwarz-Weiß a-la Compiler-Interpreter, sondern durchaus auch Grauschattierungen.