Rückwärtskompatibilität x86 vs. ARM

M

McMoneysack91

Gast
Liebe Freunde,

in einem Diskussionsthread über Sicherheit ARM vs. x86 schrieb @Marco01_809 folgendes:

x86 hat das Problem dass es aus Kompatibilitätsgründen sehr viel Altlasten mitschleppt und es dadurch in der Firmware/BIOS/UEFI sehr viel Angriffsoberfläche gibt, die auf ARM nicht vorhanden ist. Hier bauen die Hersteller ja sowieso immer eigene, inkompatible Lösungen wie der Bootvorgang vonstatten geht.

und gab mir dadurch zu denken.

Ich finde die angesprochene Rückwärtskompatibilität im Grunde eine großartige Sache - vielleicht spricht aber auch nur der absolute Laie aus mir. Ich finde es z.B. toll, uralte PCs noch völlig problemlos mit aller modernster Software verwenden zu können. Alte PCs von 2002 und älter lassen sich mich ultraleichten Linux OS wie etwa Arch32, Debian, oder ganz Hardcore TinyCore, SliTaz etc. zum Leben erwecken und quicklebendig und munter benutzen.

Bemerkung: Vermutlich wurde das obige Zitat mit Hinblick auf Windows formuliert. Ich als Linuxbenutzer mache mir um Schadsoftware nicht viele Gedanken. Soll keine Überheblichkeit sein, sondern der Ausdruck dessen, dass ich meine PCs für sehr simple Aufgaben nutze.

Das obige Zitat lässt mich im Umkehrschluss folgern, dass eine solche als Problem dargestellte Rückwärtskompatibilität bei ARM nicht existiert. Was genau bedeutet dies? Heißt das, dass ein ARM Gerät, z.B. ein Raspberry Pi 4 in seiner Zeit gefangen ist und in wenigen Jahren auf den Müll gehört, weil die Software zu weiteren, neueren ARM Architekturen weiterziehen wird und der Support für die heute aktuellen Sachen wegfällt, um eine "Leichtigkeit ohne Altlasten" zu gewährleisten?
 
McMoneysack91 schrieb:
Heißt das, dass ein ARM Gerät, z.B. ein Raspberry Pi 4 in seiner Zeit gefangen ist und in wenigen Jahren auf den Müll gehört
Kurz: Ja. Siehe Smartphones. Die meisten Hersteller bringen nur 2 Jahre unregelmäßige Updates und die Custom ROM-Community schafft es auch nicht ewig, alte SoC noch zu unterstützen, da hier viel Arbeitsleistung vonnöten ist.

Das liegt primär daran, dass jeder ARM-basierte SoC vollkommen anders aufgebaut sein kann, und es keine einheitlichen Hardware/Firmware-Schnittstellen für Betriebssysteme gibt. Das Betriebssystem muss gezielt für jeden SoC einzeln gebaut werden. Fast alle ARM-Geräte, auch der R-Pi (zumindest für die längste Zeit afaik) können nicht den offiziellen Linux-Kernel von kernel.org booten, sondern brauchen händisch angepasste Kernel.

Die Hersteller der SoCs wie z.B. Qualcomm bemühen sich auch nicht darum ihre Treiber in den Linux-Kernel zu upstreamen. Stattdessen geben sie modifizierte Kernel raus in denen die Treiber für den SoC fest einprogrammiert sind. Egal was du auf dem Gerät ausführen willst, du MUSST die Kernel-Version vom Hersteller verwenden.

Da im Kernel die kritischsten Sicherheitslücken und Bugs auftreten ist das Gerät eigentlich sofort unbrauchbar nachdem der Hersteller den Support einstellt. Der R-Pi ist aber ein so populäres Gerät unter Entwicklern, der wird seitens der Software/Linux/Treiber noch lange überleben und ich weiß dass zumindest daran gearbeitet wurde, Treiber in den offiziellen Kernel aufzunehmen.

McMoneysack91 schrieb:
weil die Software zu weiteren, neueren ARM Architekturen weiterziehen wird und der Support für die heute aktuellen Sachen wegfällt, um eine "Leichtigkeit ohne Altlasten" zu gewährleisten?
Ich glaube nicht dass Simplizität bzw. Befreiung von Altlasten das Ziel der Chip-Hersteller ist ... sondern vielmehr die geplante Obsoleszenz indem man die Software-Unterstützung für alte SoCs einstellt und die Treiber für neue SoCs für die alten nichts nützen.

Wenn es nur um Userspace-Software geht ist das Kompatibilitätsproblem bei ARM aber nicht soo viel schlimmer als auf x86. Auch auf letzterem gibt es ja diverse Erweiterungen wie SSE, AVX, VT-x u.s.w. die älteren CPUs fehlen und zunehmend von Programmen genutzt werden.
 
Wo ist denn der Support für meinen Rasberry Pi der ersten Generation? Die Frage hast Du dir, was den Support angeht ja selbst beantwortet.

Die These so hinzustellen "neuer ist besser" stimmt halt auch nicht. Nur weil das Konzept anders ist, ist es nicht fehlerfrei.

In der x86/x64 Architektur hat sich in den letzten 50 Jahren so einiges an Befehlen angesammelt und mit jeder Generation kommen weitere dazu. Nicht jeder Befehlt ist mit jedem anderen Befehl kompatibel und kann zu Fehlern führen. Daher wird durch die Compiler der Hersteller auch verhindert, das Befehle, die problematisch sind neben einander gesetzt werden. Je Komplexer die Systeme werden, umso schwieriger werden diese für den Menschen zu verstehen sein.

Es gab vor ein paar Jahren mal einen Versuch alle Befehle einer Intel 64 Bit CPU zu erkennen, also auch die Illegalen, welche der Hersteller nicht dokumentiert hat oder die als "Fehler" noch enthalten sein können.

https://www.cattius.com/images/undocumented-cpu-behavior.pdf
 
Der Bootloader, der das System lädt ist ähnlich wie das BIOS/UEFI Firmware oft closed source.
Das stört aber das Betriebssystem meist nicht.
Aber jedes Linux muss für jede Hardware dann unterschiedlich booten - "gemeinsame" Bootarten/"Bootdisketten"/USB-Sticks funktionieren damit nicht immer - weil die Features, die der Bootloader unterstützt nicht standardisiert sind
McMoneysack91 schrieb:
Heißt das, dass ein ARM Gerät, z.B. ein Raspberry Pi 4 in seiner Zeit gefangen ist und in wenigen Jahren auf den Müll gehört, weil die Software zu weiteren, neueren ARM Architekturen weiterziehen wird und der Support für die heute aktuellen Sachen wegfällt, um eine "Leichtigkeit ohne Altlasten" zu gewährleisten?

Viele ARM Boards haben nur einen Hersteller mit eigenem Softwarepack ("BSP" mit eigenen Treibern, Software...).
Das bedeutet dass es nach einiger Zeit eben keinen Herstellersupport für dieses Softwarepack gibt (oder kein Fixen bei Problemen wie Sicherheitslücken).
Damit erhält das System keine Updates mehr. Da es ein "eingebettetes System" ist, ist die Lebensdauer oder Funktionsweise meist festgelegt und Updates sind "egal" - bei Verwendung als "PC" oder ähnliches sind Updates manchmal gewünscht.

Beispiele:
  • Raspberry Pi ist zB wohl keine "guter" ARM-Prozessor - denn diese CPU kann kein anderer Hersteller außer der Raspberry Pi Foundation verwenden.
  • Aktuell wird bei Raspi immernoch ein "eigener" Linux-Kernel verwendet (auf 5.4.x mit eigenen Patches,src) und nicht der Mainline-Kernel. (aktuell 5.10.x)

- Der Bootloader (Firmware) zB. oft u-boot - unterstützt unterschiedliche Arten wie der Kernel geladen wird - aber je nacht Platzbedarf oder "Anpassungen" der Hersteller sind zB andere Komprimierungsarten und Partitionierungen und Dateisysteme vorgesehen.

- Der 3D Support ist bei ARM oft nur durch Herstellertreiber realisiert - erst seit kurzem gibt es Treiber im Kernel, die mit "ganz alten" ARM Chips auch eine beschleunigte Grafikausgabe via OpenGL ermöglichen - oder auch mit "default" Linux Hardwaredecoding bieten ohne "Herstellertools"/BSP zu nutzen.
Mali GPUs mit Bifrost,Panfrost Treibern (siehe zB div. Blogposts hier oder Kernel/Freedesktop Git)

- Die Geräte auf ARM Architekturen benutzen keine "Plug-And-Play" Busse - die Konfiguration muss bekannt sein ("DTS" - device tree) - die "Einstellungen" / Treiber für diese Geräte sind eventuell nicht öffentlich / ohne Datenblätter / nur mit NDA verfügbar.
Es gibt zwar ein "ARM Programming Guide" genauso wie es ein X86_64 Programming Guide bzw. Intel Programming Guide gibt, aber es fehlen dann "spezielle" Datenblätter - die übrigens zB auch AMD oder Intel nicht herausgeben.

- Den günstigen ARM Geräten fehlen teilweise die "Debug" Schnittstellen - weil 0.5ct an Materialkosten bei 10.000 Stk Auflage gespart wurden - Serielle Konsole und die Schaltung dafür (Widerstände...) sind nicht belegt.
 
  • Gefällt mir
Reaktionen: Marco01_809
Wow, das sind sehr ausführliche Antworten und dafür zuerst einmal großen Dank! Jetzt muss ich Laie all die Info erstmal für mich parolenartig komprimieren. Habe ich es also richtig verstanden, wenn ich für mich folgende Thesen hieraus mitnehme:

1. Aktuell ist x86 langlebiger, weil a) uralte Hardware immer noch unterstützt und somit brauchbar ist und b) aktuelle Hardware in diesem Sinne noch lange lange unterstützt werden wird. ARM ist aktuell noch eher ein Produkt seiner Zeit bzw. Periode, essei denn es ist ein sehr beliebtes ARM, welches eine entsprechende Community hinter sich hat, wie etwa Raspberry.

2. x86 ist eher ein offenes System, weil es eben ALLE diese Codes aus vergangenen Zeiten mitnimmt und damit empfänglich ist für alle mögliche Software, während ARM oft als SoC kommt und eher eine geschlossene Welt mit klaren Grenzen darstellt, welche auch noch sehr speziell von Hersteller zu Hersteller geschlossen entwickelt und supportet wird.

3. ARM zielt jedoch ebenfalls darauf ab, wie x86 einen publiken Kernel zu verwenden, um sich von der Abhängigkeit zum Hersteller zu lösen.

Auch wenn die derart lange Rückwärtskompatibilität von x86 als "Altlast" betitelt wird (das habe ich schon des Öfteren gelesen, das ist jetzt keine Anprangerung gegen @Marco01_809 ) so finde ich als Laie die Vorstellung eigentlich echt schön.

Ein uralter PC oder Laptop wird definitiv kein Windows 10 ziehen. Aber ich habe schon aus Jux etliche URALTE PCs (teilweise 700Mhz Prozessor, 128MB RAM) mittels bestimmter minimalistischer Linux Distros zu kleinen blitzschnellen Office Computern ummoduliert. Durch das Entfernen von lauten nicht runterregelbaren Lüftern (lediglich Rippen für passive Kühlung dran gelassen) erhielt ich ein 100% stilles, kühles (40°C), stromsparsames, flinkes System welches seine Dienste absolut einwandfrei erledigte.

Ich bin kein großer Fan von schmeiß weg, hol neu. Klar, wenn ein ales Gerät bei 1Ghz Prozessorleistung 400W Strom fressen und mein Büro auf Karibiktemperaturen aufheizen würde, keine Frage. Aber ich finde, dass Hardware ab sagen wir 2000 (immerhin schon 20 Jahre alt) mit minimalistischer Software ziemlich passabel in Sachen Re-use ist.

Aber das wäre wahrscheinlich schon eine eine eigene eher philosophische Diskussion in einem neuen Thread.
 
McMoneysack91 schrieb:
Aber ich habe schon aus Jux etliche URALTE PCs (teilweise 700Mhz Prozessor, 128MB RAM) mittels bestimmter minimalistischer Linux Distros zu kleinen blitzschnellen Office Computern ummoduliert

Natürlich hat Linux da Vorteile, aber du haust mit "blitzschnell" da ganz schön auf die Ka**e
;)
 
@coasterblog Ich bleibe mal bei meiner Formulierung.^^ Es ist ja alles relativ und im Auge des Betrachters. Ein Kumpel von mir hat sich (lass mich nich lügen, 2015?) einen nagelneuen PC mit Intel i3 Prozessor und 8GB Ram geholt. Win10 vorinstalliert. Wenn er da auf einen Ordner klickt, öffnet der PC diesen Ordner langsamer, als das Antike Pharonenteil mit SliTaz einen Ordner öffnet. Gleiches gilt für Office-Dateien oder Browser.

KLAR, diese minimalistischen Distros benutzen ältere, abgeschwächte oder anderswie erleichterte Software. Doch ich rede ja von ganz basic Aufgaben. Buchführung in einer Tabellendatei (etwa Libre Office Calc) oder das Ablagern und Sortieren von PDF-Dateien.

Ich bin kein Miesmacher von Windows und kein Vergötterer alter Technik (ich hätte weder von dem einen noch von dem anderen keinen persönlichen Vorteil) doch meine Beobachtung war ebendiese. Gleichzeitig schockiert und fasziniert.
 
McMoneysack91 schrieb:
KLAR, diese minimalistischen Distros benutzen ältere, abgeschwächte oder anderswie erleichterte Software. Doch ich rede ja von ganz basic Aufgaben
Diese "Abschwächung" hätte in deine erste Formulierung rein gemusst ;)
Und dass mit dem Vergleich i3 8 GB zu deinem 700MHz 128 MB nehm ich dir so nicht ab. Tut mir leid. Soll aber kein Streit sein. Meine eigene Erfahrung widerspricht dem nunmal.
 
  • Gefällt mir
Reaktionen: McMoneysack91
McMoneysack91 schrieb:
Ein Kumpel von mir hat sich (lass mich nich lügen, 2015?) einen nagelneuen PC mit Intel i3 Prozessor und 8GB Ram geholt. Win10 vorinstalliert. Wenn er da auf einen Ordner klickt, öffnet der PC diesen Ordner langsamer, als das Antike Pharonenteil mit SliTaz einen Ordner öffnet. Gleiches gilt für Office-Dateien oder Browser.
2015 kam die Skylake-Architektur auf den Markt, die im Kern heute noch von Intel verwendet wird. 8GB RAM sind für einfache office-Sachen auch genug. Wenn die Kiste eine SSD bekommt, ist sie auch mit Windows 10 für derart einfache Aufgaben eine absolut brauchbare Lösung, die auch noch stromsparend ist.
Habe erst kürzlich meinen Homeserver geupgradet auf einen gebrauchten Skylake-i3 - mit 18W IDLE-Verbrauch (ohne Platten).
LibreOffice benötigt meiner Erfahrung nach mittlerweile auch einiges an CPU-Leistung und einen modernen Webbrowser kann man auch auf alten Rechnern nur mit deaktivierem JavaScript (und auch dann nur leidlich) benutzen. Ich hatte bis vor einiger Zeit noch ein Notebook mit 2009er Celeron (Single-Core, 2.2 GHz) und 4GB RAM (und SSD). Das Teil war zum Schluss wirklich unbenutzbar, trotz Linux.

Ja, es ist cool, dass man auch uralte Kisten mit einem Minimallinux zum laufen bekommt, aber anständig benutzen erfordert mittlerweile schon ein bisschen Leistung.
Und der Stromverbrauch im IDLE ist bei modernen Rechnern sowieso um ein vielfaches niedriger.
 
Es wurde schon viel dazu geschrieben. Worauf ich jetzt nur eingehen möchte:

McMoneysack91 schrieb:
Ich finde die angesprochene Rückwärtskompatibilität im Grunde eine großartige Sache - vielleicht spricht aber auch nur der absolute Laie aus mir. Ich finde es z.B. toll, uralte PCs noch völlig problemlos mit aller modernster Software verwenden zu können. Alte PCs von 2002 und älter lassen sich mich ultraleichten Linux OS wie etwa Arch32, Debian, oder ganz Hardcore TinyCore, SliTaz etc. zum Leben erwecken und quicklebendig und munter benutzen.

McMoneysack91 schrieb:
1. Aktuell ist x86 langlebiger, weil a) uralte Hardware immer noch unterstützt und somit brauchbar ist und b) aktuelle Hardware in diesem Sinne noch lange lange unterstützt werden wird.

Die Rückwärtskompatibilität ist meiner Meinung nach eher umgekehrt gemeint: Man kann mit heutigen x86-CPUs auch noch uralte Software benutzen. Dein beschriebener Fall wird sehr schnell an modernen Befehlserweiterungen scheitern, wenn sie eine Mindestvoraussetzung sind (hatte @Marco01_809 auch schon erwähnt).

Nimm als Beispiel einen Pentium 4 von Ende 2000. Damit kannst du vielleicht noch ein 32-Bit-Betriebssystem installieren (deine erwähnten Linux-Installationen) und Office betreiben, aber keine Software nutzen, die SSE3 oder höher verlangt. Oder Software, welche nur als 64-Bit-Version existiert.
Umgekehrt kann eine heutige x86-CPU aber jede Software aus dem Jahre 2000 und älter ausführen, so lange das aktuelle Betriebssystem mitspielt (ein 64-Bit-Windows kann z.B. keinen 16-Bit-Code ausführen).
 
  • Gefällt mir
Reaktionen: McMoneysack91
Bislang hatte ich in meiner Überlegung lediglich die zwei Systeme x86 "klassischer" PC und ARM Single Board Computer verglichen.

Um nun Äpfel mit Äpfeln vergleichen zu können, möchte ich herausfinden, wie es denn um x86 SBC steht. Ich muss einfach sagen, mir gefällt prinzipiell die Idee eines SoC SBC. Ich bin kein klassischer Aufrüster, der hier und da mal RAM nachsetzt oder eine Grafikkarte erneuert etc.

Haben x86 SBC ebenfalls eine ziemlich eigene Firmware wie etwa ARM Boards wie Raspberry Pi und co? Oder ist es eher wie bei klassischen PCs ein BIOS/UEFI? Sollte dem so sein, so sagt mir mein Laienverstand, dass ein x86 SBC wesentlich zukunftsfähiger in Sachen Kompatibilität ist als ein ARM SBC.

Geht dieser Gedanke in die richtige Richtung?
 
McMoneysack91 schrieb:
Ich finde die angesprochene Rückwärtskompatibilität im Grunde eine großartige Sache - vielleicht spricht aber auch nur der absolute Laie aus mir.
Mir gefällt an den x86/x64-Systemen mehr die Vorwärtskompatibilität: Neue Linux- oder Windows-Versionen laufen ohne Probleme, natürlich müssen die mit passenden Treibern versorgt werden.

Immer wenn ich mir wieder denke "Hey, läuft Android mittlerweile auf Raspberry Pi?" merkt man, dass die Vorwärtskompatibilität da ein extrem großes Problem ist. Ähnliches wurde schon im Zusammenhang mit Smarpthones genannt: Auch Custom Roms werden irgendwann eingestellt, weil der Aufwand Sicherheitslücken der uralten Android-Versionen einfach zu groß ist, bzw von Google keine Updates mehr am Sourcecode gemacht werden und die neuere Android-Version mangels Treiber nicht läuft.
 
Kann man denn überhaupt eine ungefähre Schätzung abgeben, wie langlebig z.B. der explizite Falle eines Raspberry Pi 4B sein wird? Reden wir von 1-5 Jahren, 5-10? Jahrzehnte?

Vermutlich wird es auch damit zusammenhängen, wie es um die Raspberry Foundation steht, oder? Denn die arbeiten ja auch an dem Kernel, soweit ich richtig verstehe.
 

Ähnliche Themen

M
Antworten
11
Aufrufe
2.263
McMoneysack91
M
Zurück
Oben