Künftige Chrome-Versionen setzen Linux-Kernel 3.17 voraus

[JochenF]

Zwei meiner Lieblingsbeispiele muss ich noch loswerden.

Ein schönes Beispiel für Komplexität die keiner mehr beherrscht ist dieser Bug im Ubuntu. Ab und zu verstellt sich das Keyboard-Layout mitten unterm tippen auf US-Layout. Der Bug ist seit Oktober 2013 bekannt und 86 Leute haben sich bisher als betroffen gemeldet (das ist auf Launchpad überdurchschnittlich viel!). Die haben keinen blassen Schimmer was die Ursache dafür sein könnte. Zwischendurch hatte der Bug mal hohe Priorität, mittlerweile haben sie ihn auf "Low" abgestuft, offenbar haben sie es aufgegeben die Ursache zu finden. Ich war damals auch von dem Bug betroffen, und ich finde einen Fehler der einem dauernd die Tastatur umstellt schon ziemlich gravierend. Aber die wissen nicht wo sie suchen sollen, ist ja auch schwer bei Fehlern die nur sporadisch auftreten und nicht reproduzierbar sind. Deswegen sollte ein System nie so komplex werden dass man den Überblick verliert. Das ganze Gnome- und Unity-Zeug ist mittlerweile viel zu komplex geworden. Oft werden auch einfach nur Workarounds empfohlen und die Fehler nicht abgestellt, weil man dazu nicht in der Lage ist oder keine Kapazitäten hat.

Ein weiteres schönes Beispiel ist dieser Linux Kernel Commit. Also, wenn ich einen Fehler lokalisiert habe, dann grübel ich doch so lange über dem Code bis ich ihn verstanden habe und korrigiere ihn richtig. Noch dazu wenn es nur eine Zeile ist. Ich ändere den doch nicht auf gut Glück ab, nach der Devise "schauen wir mal was passiert".

Bei OpenBSD gefällt mir übrigens dass die immer wieder mal einen Code-Review machen und den Code nach Fehlern abklopfen. Sowas sollte eigentlich selbstverständlich sein. Das Mindeste wäre für mich, dass man alle Compiler-Warnings beseitigt.

 

[CommanderZed]

Ich kann dir da, in beiden Punkten nur zu 100% Zustimmen ... das mit dem Audio ist ein Super beispiel, ich verwende unter Gentoo deswegen nur Alsa, das scheint rel. stabil zu sein, aber toll ist das alles nicht.

Das ist alles ein furchtbares Gefrickel - Pulseaudio, Gnome, verschiedene Automatismen die von US-Amerikanern mit nur einem Monitor Entwickelt werden, und in die man dann irgendwann Deutsche Layoutes und Multimonitorsupport "irgendwie reinfrickelt". Oder ein Networkmanager der in Version X nur neue WLAN-Treiber unterstützt aber in Version Y nur alte, und mit Statischen IPs schonmal garnichts anfangen kann ... oder ... die Liste im Linux und Gnome, KDE & Co lager ist lang, und ich finde es schade das man ständig versurcht irgendwelche bescheuerten Features zu integrieren anstelle den scheiss mal stabil zu bekommen.

Aber in meinen Augen ist das weniger ein Problem der aktualität des Betriebsystems (Vor 4 Jahren war der ganze mist schon genauso verbugt), sondern der Entwickler in dem jew. Umfeld, die tendenziell alle für sich und ihre eigenen Interessen entwickeln und dabei das große ganze aus den augen verlieren.

Ich mag deshalb die OpenBSD Philosophie an der Stelle. Jedes halbes Jahr kommt ein neues Release raus, in dem als Stabil eingestufte änderungen am OS eingepflegt wurden, und in den Ports und Packages aktuelle, stabile Versionen aufgenommen werden. Dieser Releasewird dann ein jahr supported, währendedessen die Entwicklungen für den nächsten Release 6 Monate später beginnen. Das gibt auch Planungssicherheit, da die beiden Releases jedes Jahr immer am gleichen Datum erfolgen.

Und auch generell werden weiterentwicklungen im Betriebsystem in ruhe und mit bedacht durchgeführt, mit dem Zeil einer nachhaltigen Langfristigen entwicklung.

 

[JochenF]

ich finde es schade das man ständig versurcht irgendwelche bescheuerten Features zu integrieren anstelle den scheiss mal stabil zu bekommen.

Zum Thema "bescheuerte Features" habe ich auch noch einen. Die Batterieanzeige im Unity-Panel zeigt jetzt die meiste Zeit nur den Zustand der Funkmausbatterie an.
https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1315434
https://bugs.launchpad.net/indicator-power/+bug/1100546

Kein Mensch will dieses tolle neue Feature, aber anstatt das wieder auszubauen überlegen sie krampfhaft wie sie das Problem so in den Griff bekommen dass alle zufrieden sind. So kann man natürlich auch die knappen Entwicklerresourcen vergeuden.

 

[-Nuke-]

Nun, ich bin selber Software-Entwickler, und zwar seit 30 über Jahren, großteils im Unix-Umfeld. Ich stelle fest dass die Entwicklung derzeit viel zu schnell voranschreitet, alle Systeme immer komplexer werden, und nie ein Zustand der Reife erreicht wird. Je komplexer, umso mehr Fehler, um die Tatsache kommt keiner drumrum. Mir ist eine einfache (KISS-Prinzip) und ausgereifte Software lieber, als immer "bleeding edge" und voller Fehler. Guckt euch nur mal an was derzeit Google im SSL-Umfeld alles an Bugs ausgräbt (Heartblead usw.).

Da hast du dir mit OpenSSL aber ein ganz schlechtes Beispiel rausgesucht. OpenSSL wurde seit Jahren nicht großartig angefasst und _SEHR_ konservativ entwickelt. Das dort Fehler drinnen sind, lag einzig und allein darin, dass genau das der Fall war. Es waren eine handvoll Leute die daran gearbeitet haben, dort passieren Fehler. Und wenn sich keiner alten Code anguckt ohne Bedarf ihn zu verbessern, dann bleiben Fehler gerne für Jahre im System. "Never touch a running System" mag bei Hardware gelten, ist bei Software aber ganz ganz ganz ganz böse. Und bei sicherheitskritischer Software fatal.

Das ist doch abartig! Ganz ganz übel ist die Dauerbaustelle Linux. Da kann man das alte Sprichwort "viele Köche verderben den Brei" sehr gut beobachten. Als Beispiel nenne ich einfach mal nur die Soundsysteme unter Linux: OSS v3, ALSA, Pulseaudio, Jack und was es da sonst noch gibt. Dauernd was Neues, und ständig irgendwo Probleme weil nix zusammenpasst. Das bescheuerte Pulseaudio stellt bei jedem dritten Resume meinen Soundausgang auf Kopfhörer um. Ich wette dass den Bug keiner niemals nicht beheben wird.

Unter Linux gibt es als Soundsystem an sich nur noch ALSA. Alles andere setzt oben drauf und ist austauschbar. Und Soundserver wie JACK und Pulseaudio ist kein Linux-Problem. Das hat FreeBSD auch.

Blickt doch keiner mehr durch. Und jetzt fangen sie gerade mit systemd an alle Räder neu zu erfinden, und dann Wayland. Ich hab wirklich keinen Bock mehr auf diese Baustellen die nie ein Stadium erreichen wo ein System rundum funktioniert und brauchbar ist. Das derzeitige Motto "immer schneller, immer höher, immer weiter" ist zum Scheitern veurteilt. Das Ganze hat heute einen Komplexitätsgrad erreicht, den kein menschliches Hirn mehr überblicken kann, geschweige denn annähernd fehlerfrei zu erstellen.

Nun, aber zum Beispiel Projekte wie Wayland sind genau dazu da, alle alten Probleme zu beheben. Es gibt genug Leute die mit X11 Probleme haben. Und diese Probleme sind keine "Bugs", sondern schlicht in der Architektur von X11 bedingt. Nur weil du sie nicht hast, heißt das nicht, dass alle anderen nun mit den Problemen leben sollen "damit sich für dich nichts ändert". Wayland wird nicht gebaut weil man es kann, sondern weil es einfach nötig ist. Xorg ist ein großer unwartbarer Moloch geworden der gigantische Sicherheitslücken rumschleppt. Multimonitor, Farbkorrektur, V-Sync etc... alles Sachen die in Xorg nachträglich reingebaut wurden, was die Architektur an sich gar nicht hergab. OS X war bisher das einzige System, wo die Anwendung informiert werden kann, wann der zu zeichnende Inhalt auf dem Bildschirm dargestellt wurde. Jetzt gibt es schon 2.

Und mit dem Vorsatz "das funktioniert doch, warum sollte ich es verbessert" kannst du gleich sämtliche Forschungen auf dieser Welt einstellen. Das läuft natürlich darauf hinaus, dass es auch Projekte gibt, die hier und da Probleme haben. Aber es ist ja nun auch nicht so, als wenn alte Projekte gar keine Probleme haben.

Und auch wenn Linux hier und da etwas zu schnell voranschreiten mag... seit Kernel 2.6 (das ist schon verdammt lange her!) hat sich die Userland-API vom Kernel nicht geändert. Das heißt du kannst einfach in einem aktuellen System den 2.6er Kernel unterschieben und das System startet und funktioniert. Wenn es dir zu schnell geht, nimm einen der 6 (!) verfügbaren Long-Term Versionen der Kernel. Das sind Support-Zeiträume von denen träumen Systeme wie FreeBSD nur Und gerade FreeBSD ist ja eines der Systeme, wo du Anleitungen relativ schnell wieder wegwerfen kannst.

 

[goblin]

Ich war bisher der Meinung für die Programmiersprache C gäbe es Normen.

Chrome ist in C++ geschrieben, und der aktuelle Standard ist C++14. Den wollen sie auch verwenden, was meiner Meinung nach eine vollkommen legitime Haltung ist.

Eine mögliche Lösung wäre, mit dem alten Systemcompiler eine aktuellere Compilerversion zu kompilieren, und den dann zu nutzen, um Chrome zu kompilieren. Aber das ist das Problem der Debian-Maintainer und nicht das des Chrome-Projektes.

Was sie allerdings mit Windows machen, wo Visual Studio noch nichteinmal C++11 wirklich komplett unterstützt, ist mir schleierhaft.

 

[JochenF]

Chrome ist in C++ geschrieben, und der aktuelle Standard ist C++14. Den wollen sie auch verwenden, was meiner Meinung nach eine vollkommen legitime Haltung ist.

Das kann man auch anders sehen. Produktiv eingesetzte Systeme werden nie einen so neuen Stand besitzen. Man kann sowas gerne für das nächste Major Release vorsehen, muss dann aber parallel das vorige Release mit Sicherheitsupdates beliefern. Wenn man diese Zweigleisigkeit nicht will, darf man auch nicht brandaktuelle Tools einsetzen. Kann man zwar machen, disqualifiziert sich dann aber produktiv eingesetzt werden zu können.

Was sie allerdings mit Windows machen, wo Visual Studio noch nichteinmal C++11 wirklich komplett unterstützt, ist mir schleierhaft.

Offenbar schaffen sie es da auch mit älterem Compiler-Standard klar zu kommen. Warum sie das bei Linux nicht wollen bleibt wohl ihr Geheimnis.

 

[goblin]

Das kann man auch anders sehen. Produktiv eingesetzte Systeme werden nie einen so neuen Stand besitzen. Man kann sowas gerne für das nächste Major Release vorsehen, muss dann aber parallel das vorige Release mit Sicherheitsupdates beliefern. Wenn man diese Zweigleisigkeit nicht will, darf man auch nicht brandaktuelle Tools einsetzen. Kann man zwar machen, disqualifiziert sich dann aber produktiv eingesetzt werden zu können.

Ich setze FreeBSD produktiv ein und das hat aktuelle Compiler an Bord. Wenn das nicht reicht, installiere ich eben den aktuellsten aus den Ports. Das ist genau das, was ich für Debian vorgeschlagen habe, nur dass die ihre Pakete halt auch nie aktualisieren. Aber daran habe ich beim Schreiben des ersten Postings nicht gedacht.

Im Endeffekt finde ich es trotzdem ganz gut, so bekommen die mal ihre eigene Medizin zu schmecken. Denn so wie die Chrome-Entwickler jetzt gerade Debian behandeln, so behandeln die meisten Linux-Entwickler andere POSIX-Systeme: "Du musst unsere Software nicht benutzen, wenn dir nicht gefällt, wie sie entwickelt wird."
Immerhin handelt es sich hier mit C++14 um einen richtigen, nicht nur um einen Pseudo-De-Fakto-Standard wie cgroups und dem ganzen freedesktop.org-Zeug.
Vielleicht hilft das denen beim Umdenken, aber das bezweifle ich dann doch.

Offenbar schaffen sie es da auch mit älterem Compiler-Standard klar zu kommen. Warum sie das bei Linux nicht wollen bleibt wohl ihr Geheimnis.

Ich denke die unterscheiden zwischen C++-Compilern und MSVC. Von ersteren wird Standardkonformität erwartet, und wenn die Plattform keinen mit dem verwendeten Standard konformen Compiler bietet, wird sie nicht unterstützt. Und das andere, das ist eben der MSVC, der muss eh gesondert behandelt werden.

Im Grunde verstehe ich deine Probleme ja auch, ich finde das Entwicklungsmodell der meisten Google-Software nicht sonderlich schön, auch Android braucht eine genau richtige Version von gcc und gmake, jede Version jeweils andere. In meinen Augen ist da das Tooling massiv kaputt.
Aber eine Lösung, außer eben Chrome nicht zu verwenden, habe ich auch nicht.
Dennoch finde ich, dass upstream machen kann, was es will. Wir haben keinen Anspruch darauf, dass sie keine Scheiße bauen und die haben keinen Anspruch darauf, dass wir ihre Software einsetzen. Abgestimmt wird dann halt mit den Füßen.

 

[JochenF]

Dennoch finde ich, dass upstream machen kann, was es will. Wir haben keinen Anspruch darauf, dass sie keine Scheiße bauen und die haben keinen Anspruch darauf, dass wir ihre Software einsetzen. Abgestimmt wird dann halt mit den Füßen.

Das ist zwar richtig, aber die meisten machen das ja nicht aus Spaß an der Freud, sondern aus einem bestimmten Ziel heraus. Im Falle Google ist das Ziel ganz klar: die haben einen eigenen Browser entwickelt um ihre Cloud-Dienste anbieten zu können. Die ganzen Cloud-Apps sind ja alle in Javascript programmiert, und zur damaligen Zeit waren die Javascript Engines der etablierten Browser einfach zu langsam dafür. Also musste Google was neues entwickeln. Heute sind für Google hauptsächlich 2 Nutzer-Gruppen interessant: die Windows-User und Googles Spielzeug, das Chromebook. Die restlichen Linux- oder gar BSD-User sind für Google uninterressant, deswegen braucht man da auch keine Rücksicht nehmen. Ich könnte mir vorstellen dass Google das Chromebook als eine Art "Technologie-Studie" ansieht, und deswegen da immer neueste Technik einsetzt. Mit dem Chromebook können sie ja experimentieren wie sie wollen, ebenso bei Android. Bei Windows müssen sie auf die vorhandene Infrastruktur Rücksicht, und der Rest ist ihnen, wie gesagt, vollkommen egal.

BTW: wie sieht das eigentlich mit Chrome unter MacOS aus? Dort werden sie auch das nehmen müssen was Apple anbietet.

 

[chaos]

Da hast du dir mit OpenSSL aber ein ganz schlechtes Beispiel rausgesucht. OpenSSL wurde seit Jahren nicht großartig angefasst und _SEHR_ konservativ entwickelt.

NACK. Gefühlt jeder RFC wird in OpenSSL implementiert und per default aktiviert:
Nur so war Heartbleed möglich: Per Default ein neues Feature aktiviert, anstatt auf KISS und least surprise zu bauen.

Und auch wenn Linux hier und da etwas zu schnell voranschreiten mag... seit Kernel 2.6 (das ist schon verdammt lange her!) hat sich die Userland-API vom Kernel nicht geändert.
Das heißt du kannst einfach in einem aktuellen System den 2.6er Kernel unterschieben und das System startet und funktioniert.

Das stimmt wohl nur teilwese: Nach https://www.archlinux.org/news/udev-minimum-kernel-version/ braucht man mindestens 2.6.24.5, wenn die Distribution udev 145-1 einsetzt.

 

[-Nuke-]

NACK. Gefühlt jeder RFC wird in OpenSSL implementiert und per default aktiviert:
Nur so war Heartbleed möglich: Per Default ein neues Feature aktiviert, anstatt auf KISS und least surprise zu bauen.

Bei der Mannstärke wäre dieser Teil dann nie aktiviert worden. Und selbst wenn man noch 1 Jahr gewartet hätte mit der Aktivierung... gleiches Problem. Heartbleed hatte als Ursache nichts Neues. Der Input wurde nicht korrekt geprüft. Weiterhin war/ist die Architektur von OpenSSL über die Jahre einfach eklig und unüberschaubar geworden.

Hier wird jetzt aber gefordert "bloß nichts neu machen", "never touch a running system"... genau hier ist das Problem von OpenSSL. Es hätte einfach schon vor verdammt vielen Jahren mal einen Rewrite nötig gehabt. Mal ein Großputz. So ziemlich genau das was LibreSSL jetzt getan hat. Nur zu spät und als Reaktion. Und trotzdem wird gemeckert, wenn andere Projekte es früher machen, bevor alles baden geht.

Das stimmt wohl nur teilwese: Nach https://www.archlinux.org/news/udev-minimum-kernel-version/ braucht man mindestens 2.6.24.5, wenn die Distribution udev 145-1 einsetzt.

Mit "Kernel 2.6" meine ich schon den 2.6-Release auf Kernel.org (2.6.32.65). Es wäre dumm etwas älteres zu installieren (Sicherheitslücken, etc.). Der Kernel kriegt durchaus neue Featuers. Aber du musst deine Libraries nicht wegen einer neuen Kernel-Version neu kompilieren/umschreiben.

Die Userland API ist eben seit Jahren stabil und es ist auch die oberste Devise der Kernel-Entwickler, dass das so bleibt.

 

[chaos]

Bei der Mannstärke wäre dieser Teil dann nie aktiviert worden.

Wo ist dabei das Problem, dass ein Feature, dass kaum einer braucht (TCP und OSI-Schichtenmodell sei Dank!), nur bei denen aktiviert wird, die es wirklich brauchen?

 

[-Nuke-]

Wo ist dabei das Problem, dass ein Feature, dass kaum einer braucht (TCP und OSI-Schichtenmodell sei Dank!), nur bei denen aktiviert wird, die es wirklich brauchen?

Es wäre auch Jahrzehnte eine schlummernde Lücke gewesen und es hätte sich nichts getan. So ist jetzt was passiert, sowohl negatives als auch verdammt viel positives!

Dass es den Heartbeat bei TLS gibt, dass kann man aber nun auch den Leuten in die Schuhe schieben die den Standard gemacht haben. OpenSSL hält sich hier einfach nur an den Standard. "Hinterher ist man immer schlauer", ja.

Aber wenn wir jetzt auch noch anfangen Standards nicht zu implementieren / nicht zu nutzen, dann haben wir ja wieder Stillstand. Nachher überlegen die Browser noch kommende HTML Versionen nicht zu unterstützen "weil es ja neu ist"....

Das Problem hier war eben grottiger Code in einer grottigen Bibliothek. Und natürlich, dass sich auch alten Code niemand anguckt. Das würde bei "wir machen das mal ab und an neu" nicht so schnell passieren.

 

[Yamagi]

Mit der Aussage, dass man auf einer aktuellen Linux-Distribution einfach ohne Folgen einen älteren Kernel booten kann, wäre ich vorsichtig. Zwar hat die Interface-Flut unter Linux etwas nachgelassen nachdem die Erkenntnis wuchs, dass man jedes dieser Interfaces für praktisch immer unterstützen muss, aber dennoch sind seit Linux 3.0 allein bei den Syscalls eine ganze Reihe hinzugekommen. Da sind auch gar nicht mal so obskure wie sched_setattr(2) drunter. Klar, die Basiskomponenten nutzen sie nicht. Aber auf den höheren Ebenen kann es schon Ärger geben...

 

[-Nuke-]

Mit der Aussage, dass man auf einer aktuellen Linux-Distribution einfach ohne Folgen einen älteren Kernel booten kann, wäre ich vorsichtig.

Ohne Folgen sicherlich nicht. Die Hardware wird eingeschränkter, Features gehen verloren, etc. Jedoch ist der Umstieg auf die 3.x Linie bei einigen Distributionen noch gar nicht so lange her. CentOS 6.6 -> Kernel 2.6.32. CentOS 7 kam vor einem halben Jahr raus.

Wäre mir also neu, dass irgend eine Software auf dem 2.6er Kernel streiken würde.

Unabhängig davon ob man nun eine Software findet oder nicht, war die Grundaussage dahinter ja mehr: "Wenn dir der Fortschritt bei Linux zu schnell ist, nimm ein LTS-Kernel, von mir aus auch den ältesten".

Da ist man bei FreeBSD viel öfter bei "kompiliere/reinstalliere mal bitte all deine Software noch mal neu". Gut, das ist nicht nur der Kernel, sondern auch das Basissystem, aber das ist das was man "beim großen Ganzen" eben mitbekommt. Das ist jetzt auch nicht als negative Kritik gemeint, bin ja mit FreeBSD sehr zufrieden. Jedoch ist das rumgehacke auf Bleeding Edge Linux auf dauer auch etwas nervig xD

 

[Yamagi]

Damit hast du aber vollkommen recht. Wir FreeBSDler sind auf der einen Seite immer sehr stolz auf unsere angeblich ewige Rückkompatibilität und vergessen dabei, dass auf der anderen Seite weite Teile des Kernelinterfaces per Design gar nicht kompatibel sein können. Das beginnt schon bei einer ganzen Reihe ioctl(), die Structs durch die Gegend schießen. Jede Änderung der Structs führt zwangsläufig zu Brüchen, denen man auch nur begrenzt mit Spare-Felder bei kommt. Das führt dann dazu, dass einige Tools bei gefühlt jedem Hauptversionssprung explodieren. Ein gutes Beispiel ist sockstat. Auch hat das FreeBSD-Userland noch immer kein durchgehendes Symbol-Version, was ein weiterer Grund für "bitte alles neu übersetzen ist".

Und Bleeding Edge Linux... Ich sehe es sogar noch radikaler als du: Neue Software ist in fast allen Fällen immer besser als alte Software und "update early, update often" ist eine gute funktionierende Strategie. Nach Jahren mit Arch Linux und co. ist mein Fazit, dass diese angeblich so instabilen Distributionen genauso gut oder schlecht wie z.B. Debian sind. Es sind andere Probleme und sie sind anders über die Zeit verteilt, aber in der Masse nicht mehr oder weniger. Das Hauptargument für über lange Zeit stabile Distributionen würde ich auch nicht in "stabil", sondern in "das Admintier ist ein Faultier und die Kiste wird mir 5 Jahre keinen Ärger machen" sehen. Was ein durchaus valider Grund ist.