Notiz Linus Torvalds: Linux-Chefentwickler wechselt von Intel auf AMD-System

[Jesterfox]

Selbst Microsoft hat ja mittlerweile verstanden das Linux wichtig ist und es in Windows integriert (WSL)...

 

[Herdware]

...Da hat Microsoft von Anfang an große Fehler in der Entwicklung gemacht und WIndows zu stark auf x86 ausgelegt. ...

Eigentlich nicht. Windows NT, das seit XP bis heute die Grundlage für alle aktuellen Windows-Versionen bildet, war von Anfang an plattformunabhängig. Die ursprüngliche Entwicklung war glaube ich sogar auf DEC Alpha-CPUs.*

Dass die diversen Versuche von Microsoft, Windows auf alternativen CPU-Architekturen zu etablieren, halbherzig wirkten und letztlich gescheitert sind, lag meines Erachtens nicht an Microsoft.
Es fehlte eigentlich hauptsächlich am Support von Seiten der anderen Entwickler, sprich an nativen Anwendungen für das nicht-x86-Windows. Anders als z.B. Apple, hat Microsoft das ja nicht unter Kontrolle. Die können nur das OS und Entwicklungsumgebungen anbieten und hoffen, dass die Entwickler das annehmen.

* Edit:
Ich lag etwas daneben. Windows NT wurde ursprünglich für den i860 (ein RISC-Prozessor von Intel) entwickelt und lief mangels verfügbarer Hardware anfangs in einem N10 oder N-Ten genannten Emulator. Daher das Kürzel "NT".
Der Chef-Entwickler von Windows NT, David Cutler, stammte aber aus der DEC-Ecke.

 

[storkstork]

Dass die diversen Versuche von Microsoft, Windows auf alternativen CPU-Architekturen zu etablieren, halbherzig wirkten und letztlich gescheitert sind, lag meines Erachtens nicht an Microsoft.
Es fehlte eigentlich hauptsächlich am Support von Seiten der anderen Entwickler, sprich an nativen Anwendungen für das nicht-x86-Windows. Anders als z.B. Apple, hat Microsoft das ja nicht unter Kontrolle. Die können nur das OS und Entwicklungsumgebungen anbieten und hoffen, dass die Entwickler das annehmen.

Ich kenne mich nicht so gut aus in der Thematik und möchte dir nicht direkt widersprechen. Aber wäre es nicht auch andersrum möglich, dass Windows seinen "Kern" für Windows 10 damals so programmiert hätte, dass es auch nativ auf anderen Architekturen läuft? So hätten die Software-Entwickler weiterhin für ein Betriebssystem entwickeln können, was aber am Ende auch auf anderen Architekturen läuft.

Soetwas ist wahrscheinlich nicht einfach und dauert ein paar Jahre, aber wenn man dahin kommen möchte, dass mehrere Architekturen nativ von einem Betriebssystem unterstützt werden, dann führt wahrscheinlich kein Weg daran vorbei.

Ich könnte mir vorstellen, dass man im Betriebssystem bestimmte Bedingungen vorgeben kann, was die Mindestvorraussetzungen an Programme betrifft. So dass Photoshop in Zukunft vielleicht mindestens 2 Kerne und 4 GB Ram vorraussetzt. Wenn das Smartphone diese Bedingungen erfüllt, kann man Photoshop installieren. Es macht dann vielleicht keinen Sinn damit zu arbeiten, weil alle Icons und der Bildschirm extrem klein wären und weil es bei 2 Kernen und 4 GB Ram vielleicht 5 Sekunden statt 1 Sekunde dauert, bis man einen Effekt ausgeführt hat, aber das spielt ja dann keine Rolle. Der Entwickler hat ja immer noch die Option sein Programm so anzupassen, dass es auch eine Version gibt, die auf dem Smartphone nutzbar ist, mit weniger Optionen. So wie es heute auch schon ist. Nur dass es eine Version gibt, die selbst erkennt, auf welcher Hardware sie läuft und sich dann entsprechend abgespeckt installiert. Am besten natürlich mit einer manuellen Option, dass man es auch selbst auswählen kann, wenn man unbedingt die "Vollversion" auf dem Smartphone nutzen möchte.

Wäre soetwas machbar, bzw. Sinnvoll?

 

[Herdware]

Aber wäre es nicht auch andersrum möglich, dass Windows seinen "Kern" für Windows 10 damals so programmiert hätte, dass es auch nativ auf anderen Architekturen läuft? So hätten die Software-Entwickler weiterhin für ein Betriebssystem entwickeln können, was aber am Ende auch auf anderen Architekturen läuft.

Ich bin auch kein Programmierer, aber das wenigste, was man machen müsste, ist wohl den Source-Code der Anwendung für jede CPU-Architektur neu zu kompilieren, sonst kann sie nicht nativ darauf laufen. Selbst diese Mühe haben sich die wenigsten Anwendungsentwickler bisher gemacht. (Damit die Software vernünftig läuft, dürfte obendrein immer noch einiges an Optimierungsarbeit und sonstige Anpassungen nötig sein.)

Die andere Option ist, dass die Software in einem Emulator läuft. Also eine Übersetzungsschicht, die der Anwendung eine andere Umgebung vorgaukelt. Sowas hatten die alternativen Windows NT auch immer mit an Bord, das Win10 für ARM eingeschlossen. Man kann also (mit ein paar Einschränkungen) auch x86-Windows-Anwendungen darauf nutzen, nur verliert man dadurch einen guten Teil der Leistung. Da greifen die meisten Anwender doch lieber direkt zu einem x86-PC.

Ich kann mir gut vorstellen, dass es irgendwann in der Zukunft ein Windows gibt, das alle Anwendungen und vielleicht sogar zum großen Teil sich selbst immer in VMs und/oder Emulatoren ausführt. Damit wäre es nahezu komplett hardwareunabhängig und könnte jeder Anwendung immer eine optimale Umgebung bieten.
Wenn CPU-Leistung und sonstige Systemressourcen im Überfluss zur Verfügung stehen, kann man sowas eventuell machen. Aber das war in den letzten 30 Jahren noch nicht der Fall.

 

[new Account()]

Naja, auch nur so halbherzig, Windows on ARM ist bisher nicht so wirklich mit x86 zu vergleichen, während es bei Linux schon heute kein großes Ding ist, einen PC mit ARM-Architektur zu verwenden, da läuft die meiste Software drauf die man auch sonst so verwendet.

Zum Glück laufen die Linuxprogramme quasi alle unter Windows.

Da hat Microsoft von Anfang an große Fehler in der Entwicklung gemacht und WIndows zu stark auf x86 ausgelegt.

?
Das aktuelle Problem ist Anwendungskompatibilität.
Windows gibts schon in ARM - wie kommst du da darauf, dass Windows zu stark auf x86 ausgelegt ist?

 

[screwdriver0815]

In der Tat aber das ist halt auch eine Budget Frage. Wenn man den Markt seit 10 Jahren melkt kann man auch mal etwas zurück geben

Wo ein Wille ist, ist auch ein Weg. Hat mit Geld eher weniger zu tun, wenn man seine Treiber in den Kernel packt. Das kostet nämlich fast nichts. Im Gegenteil. Also hier ist AMD derjenige, der gewaltigst Kritik zu ertragen hat und Relativieren ist absolut fehl am Platz

Wobei Intel sicher nicht aus reiner Menschenfreundlichkeit handelt, wenn sie Linux unterstützen. Da ist eine Menge Eigennutz dabei.

Sicherlich. Bei jeder Firma die ihre Sachen in Linux einbringt, ist 100% Eigennutz dabei. Deshalb: AMD könnte ebenfalls eigennützig sein... sind sie aber wohl nicht, sondern betreiben lieber Engagement auf Sparflamme für ihre Kunden. Schade. Und ziemlich dumm. Da könnte man fast zum Intel-Fanboy werden.

 

[chithanh]

Wo ein Wille ist, ist auch ein Weg. Hat mit Geld eher weniger zu tun, wenn man seine Treiber in den Kernel packt. Das kostet nämlich fast nichts. Im Gegenteil. Also hier ist AMD derjenige, der gewaltigst Kritik zu ertragen hat und Relativieren ist absolut fehl am Platz

Ich finde Intel hat sich was die Linux-Treiber angeht weitaus mehr fragwürdige Aktionen geleistet als AMD.

AMD unterstützt immerhin jede jemals auf den Markt gekommene Radeon-Karte und jede APU seit der Ur-Radeon aus dem Jahr 2000 mit brauchbaren Linux-Kerneltreibern und in Mesa.

Bei Intel sieht es anders aus, besonders mit den Atoms. Die kamen oft mit PowerVR-Grafik (z.B. Poulsbo mit GMA500), für die Intel nur proprietäre Treiber geliefert hat. Irgendwann sind sie dann von PowerVR weg, und... beim Atom x3 SoFIA zu ARM Mali hin?! Wtf. Immerhin haben sie den Low-Power-Atom Geschäftszweig inzwischen an Spreadtrum ausgelagert, so dass wenigstens nicht mehr Intel draufsteht (aber wieder PowerVR drin ist). Brauchbare Linux-Unterstützung gibt es für diese Chips bis heute nicht, und die proprietären Treiber sind so veraltet, dass sie nicht mehr auf modernen Distributionen laufen.

Wer einen Bay Trail-Atom hatte, kannte vielleicht auch das jahrelange Problem unter Linux, dass entweder Strom sparen oder Stabilität möglich war, nicht beides.

Die Nachfolgegeneration Cherry Trail (Whiskey Cove Plattform) war seit dem Launch nur halbherzig unterstützt, erst ein Community-Entwickler hat in seiner Freizeit wichtige Funktionen unter Linux implementiert.

 

[UrlaubMitStalin]

Wenn Torvalds sich 2005 unbedingt einen neuen PC anschaffen wollte/musste, wäre für seinen Anwendungsfall so ein Dualcore-Pentium4 wahrscheinlich sogar die objektiv beste Lösung gewesen. AMDs Athon64-Dualcores kamen ja erst wesentlich später (und wurden schon von den C2D überschattet).

Ähm.... Nein?
Der Athlon 64 X2 kam 2005 raus. Zu diesem Zeitpunkt war AMD immer noch führend.
Der C2D kam erst 2006 und war auch nicht wesentlich flotter als die AMDs... erst in den späteren Generationen (45nm) konnte AMD dann nicht mehr mithalten, das war so 2008 rum.
Und als dann die iCore's kamen sah es ganz finster aus, seit Sandy Bridge war AMD de facto nicht mehr in der selben Liga wie Intel.

Man kann also sagen, die Staffelstabübergabe von AMD an Intel war so 2008 rum. Und 2019 gehts dann wieder an AMD.

 

[Herdware]

Der Athlon 64 X2 kam 2005 raus. Zu diesem Zeitpunkt war AMD immer noch führend.

Du hast Recht. Ich hatte nur kurz auf CB gecheckt und da war der erste Athlon 64 X2-Test erst 2006.

Aber die Frage, warum sich Linus Torvalds nach eigener Aussage 2005 etwas anderes als eine AMD-CPU zugelegt hatte, obwohl die damals unbestreitbar besser waren als Intels Pentiums, hat sich ja inzwischen dank MountWalker geklärt. (Geschenkter Dual-G5-PowerMac.)

 

[screwdriver0815]

AMD unterstützt immerhin jede jemals auf den Markt gekommene Radeon-Karte und jede APU seit der Ur-Radeon aus dem Jahr 2000 mit brauchbaren Linux-Kerneltreibern und in Mesa.

"Brauchbar" ist irgendwie eine Definitionsfrage würde ich sagen. Wenn "brauchbar" = "ich sehe ein Bild auf dem Monitor", dann ja. Dann sind die ach so schlechten Intel-Teile allerdings ebenfalls brauchbar. Das Navi-Desaster spricht Bände und ist symptomatisch für das Vorgehen von AMD. Der amdgpu Treiber ist auch weit davon entfernt, das gelbe vom Ei zu sein. Brauchbar? Naja...

Außerdem geht es auch nicht nur um Grafiktreiber. Intel leistet noch sehr viele andere Beiträge zu Linux, wo AMD überhaupt nicht vertreten ist - sie aber vertreten sein könnten und es ihnen auch nützen würde. Intel ist auch federführend in der Wayland-Entwicklung.

Nicht falsch verstehen: ich finde es gut, dass sich AMD überhaupt an Linux beteiligt und die Kritik an Intel ist auf jeden Fall berechtigt. Ich kann nur nicht dieses ewige "AMD = GUT; Intel = BÖSE" stehen lassen, weil es nicht so ist und AMD sehr viele Baustellen offen hat, bzgl. open source etc., die ihnen nicht zur Ehre gereichen.

 

[chithanh]

"Brauchbar" ist irgendwie eine Definitionsfrage würde ich sagen. Wenn "brauchbar" = "ich sehe ein Bild auf dem Monitor", dann ja.

"Brauchbar" = "es ist im Desktop-Betrieb nutzbar (auch 3D-Desktops), und Video-Playback funktioniert". Bei batteriebetriebenen Geräten zusätzlich noch "es saugt den Akku nicht ratzfatz leer". Bei Gaming-Grafikkarten "Spiele für die Leistungsklasse laufen größtenteils".

Bei den PowerVR-Atoms ist das bis heute nicht der Fall, und Intel macht auch keine Anstalten, daran etwas zu ändern.

Dann sind die ach so schlechten Intel-Teile allerdings ebenfalls brauchbar. Das Navi-Desaster spricht Bände und ist symptomatisch für das Vorgehen von AMD. Der amdgpu Treiber ist auch weit davon entfernt, das gelbe vom Ei zu sein. Brauchbar? Naja...

Das "brauchbar" bekommt AMD hin. Manchmal dauert es einige Monate wenn man unbedingt die neuste Hardware beim Launch kaufen will, bis das auch unter Linux läuft. Und ja, es gibt auch Bereiche wie OpenCL/ROCm die AMD seit Jahren vermurkst, aber die sind für Nischenanwender. Und AMD arbeitet stets aktiv daran, das zu verbessern.

Außerdem geht es auch nicht nur um Grafiktreiber. Intel leistet noch sehr viele andere Beiträge zu Linux, wo AMD überhaupt nicht vertreten ist - sie aber vertreten sein könnten und es ihnen auch nützen würde. Intel ist auch federführend in der Wayland-Entwicklung.

Zur Erinnerung: AMD hat die x86_64-Architektur in Linux erst eingeführt.
Wayland ist ein gemeinsames Projekt von vielen Akteuren, Intel ist da stark beteiligt (und beschäftigt oder beschäftigte einige Wayland-Entwickler) aber nicht federführend.

Natürlich gereichen die Beiträge von Intel auch AMD zum Vorteil und umgekehrt, das ist das Wesen von Open Source. FreeSync im Windows-Treiber von AMD ist nutzlos für Intel. Variable-Refresh-Code in den Linux-Treibern kann hingegen auch von Intel für genutzt werden.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Eyeing-VRR-Linux-Bits
https://www.phoronix.com/scan.php?page=news_item&px=AdaptiveSync-xf86-video-modeset

Nicht falsch verstehen: ich finde es gut, dass sich AMD überhaupt an Linux beteiligt und die Kritik an Intel ist auf jeden Fall berechtigt. Ich kann nur nicht dieses ewige "AMD = GUT; Intel = BÖSE" stehen lassen, weil es nicht so ist und AMD sehr viele Baustellen offen hat, bzgl. open source etc., die ihnen nicht zur Ehre gereichen.

Ich finde, wenn man die Größe der jeweiligen Firma würdigt, dann kommt AMD mit ihren Beiträgen ziemlich gut weg. Die Baustellen sind in der Tat zahlreich und die Ressourcen begrenzt, aber AMD geht sie eine nach der anderen an (in der Reihenfolge wie wichtig sie den Anwendern mutmaßlich sind). Intel hingegen hat an vielen Stellen aufgegeben und lässt die Anwender mit unbrauchbarem Linux-Hardwaresupport im Regen stehen. Bei der Größe und den Ressourcen der Firma unverzeihlich.

AMD ist auch nicht überall gut sondern in manchen Bereichen böse. Das PS4-Linux-Projekt etwa sah sich Anfeindungen durch AMD-Entwicker ausgesetzt.

 

[PPPP]

Bei den PowerVR-Atoms

Sind das nicht alles 7 Jahre alte 1-2 Kern CPUs ohne Leistung (1,x Ghz)? Die benutzt doch kaum jemand, erst recht nicht für Linux. Weshalb stellt das so ein großes Problem für dich persönlich dar?

 

[MountWalker]

@ PPPP

Also wenn jemand sowas benutzt, dann unter Linux. Ich könnte mir sowas beispielsweise als Vortrags-Slideshow-Bootloader vorstellen; für Honorarkräfte im Schulbetrieb beispielsweise.

 

[chithanh]

@PPPP
PowerVR-Atoms die max. 7 Jahre alt sind:
2013: Atom Z25xx-Serie (Clover Trail) mit 2C/4T und bis zu 2,0 GHz.
2014: Atom Z35xx (Moorefield) mit 4C/4T und bis zu 2,3 GHz
Mali-Atoms:
2015: Atom x3-C32xxx/C34xx (SoFIA 3G) mit 4C/4T und bis zu 1,4 GHz
2016: gleiche CPUs aber mit LTE-Modem statt 3G

ab 2017 hat Spreadtrum dann die Sparte weitergeführt (SC98xx mit bis zu 8 Airmont-Kernen und PowerVR-Grafik)

Bei Intel ist sogar die Windows-Treiberunterstützung mies. Für Clover Trail ist bei Windows 10 Anniversary Update (Version 1607) Schluss, gerade mal 3 Jahre nach Launch. Mit dem Creators Update laufen die nicht mehr richtig und das Update wird durch Microsoft verhindert.

Bei AMD kamen 2013 die Jaguar-APUs raus. Die laufen auch heute noch prima mit den Open Source Treibern, z.B. als HTPC, und können einwandfrei 1080p H.264 hardwarebeschleunigt abspielen.

 

[kasperL.]

Wundert mich das er so lange gewartet hat mit dem wechsel auf Threadripper. Alle die ich so privat kenne und öfter Kernel kompilieren, haben das direkt zur ersten Generation gemacht weil die gespaarte Zeit so hoch war.