News Qualcomm × Asus: Klares Jein zum Snapdragon X2 Elite unter Linux

[mae]

BTRFS ist im Vergleich zu ZFS ein Trauerspiel

Ich habe seit mind. 2013 BTRFS auf einem Laptop und seit 2015 auf dem Desktop im Einsatz. Auf der Arbeit verwendet der NFS-Server BTRFS (mit RAID1). Alles funktioniert voellig unauffaellig. Wir haben ZFS auf anderen Maschinen im Einsatz. Funktioniert auch unauffaellig.

Was die Sache mit BSD und AT&T auf der technischen Seite betrifft, hat AT&T Unix mit System V in eine ganz andere Richtung weiterentwickelt als BSD, die aber offenbar fuer professionelle Anbieter interessanter war. So hatte z.B. Sun als Berkeley-Spinoff[*] am Anfang das BSD-basierte SunOS, und hat dann ca. 1990 auf das auf System Vr4 basierende Solaris gewechselt, unter lautstarkem Protest der SunOS-Traditionalisten. Wer also behauptet, nur Unix von AT&T waere das Wahre, der sollte von BSD die Finger lassen.

Meine eigene Erfahrung ist, dass sie die Unix-Varianten (inkl. Linux) auf der System-Call-Ebene nicht so sehr unterscheiden (bzw. man ueber die Unterschiede leicht herumarbeiten kann; ich vermute, auch BSD unterstuetzt inzwischen das von System Vr4 kommenden sigaction(), Linux tut es jedenfalls). Viel mehr Probleme habe ich im Userland: Wenn es nicht GNU ist, ist es fuer mich ein Problem. Aber das GNU Userland laeuft auf allen moeglichen Unices; es wird halt auf BSD oder Solaris oft nicht installiert, weil da die Sysadmins oft meinen, dass man das nicht braeuchte.

P.S.: Nicht ganz: Der Name Sun kam von "Stanford University Network", drei der vier Gruender kamen von Stanford. Das entscheidende in diesem Zusammenhang ist aber, dass der Software-Mensch bei Sun von Berkeley kam, und derselbe Bill Joy war, der in Berkeley die BSD-Entwicklung anfuehrte, bis er Berkeley verliess und Sun mitbegruendete.

 

[andy_m4]

Meine eigene Erfahrung ist, dass sie die Unix-Varianten (inkl. Linux) auf der System-Call-Ebene nicht so sehr unterscheiden

Kommt drauf an.
Es gibt halt inzwischen viel Linux-spezifischen Kram der auf anderen UNIX-Systemen häufig nicht (oder nur eingeschränkt) funktioniert. So typisch sind Dinge cgroups und namespaces.

Wenn es nicht GNU ist, ist es fuer mich ein Problem
...
weil da die Sysadmins oft meinen, dass man das nicht braeuchte.

Sehe ich nicht so eng.
Wenns wirklich um scrpting geht, dann ist es eh angenehmer / komfortabler eine entsprechende Programmiersprache zu nutzen als irgendwie mit Shell-Skripten herum zu hantieren.
Und interaktiv: Gibt halt inzwischen moderne Alternativen die besser funktionieren als der GNU-Krempel.
Und will man maximal kompatibel sein über UNIX-Grenzen hinweg, muss man eh auf POSIX-Shell zurückgreifen.

Insofern ist/wird zunehmend der einzige Grund für die GNU-Tools Gewohnheit und/oder vorhandene Bash-Skripte.

Wenn das also jemand nicht installiert, dann hab ich da durchaus Verständnis für.

 

[Piktogramm]

@mae
Btrfs funktioniert gut, wenn die Funktionen genutzt werden, die gut funktionieren.
Raid 5/6 ist mäßig, Scrub mit Raid5/6 nah dran an unbenutzbar, Performance mit Snapshots und Quotas ist mies, Verschlüsselung auf Dateisystemebene ist seit Ewigkeiten in Entwicklung, ..

Ich rolle ja selber gerne BTRFS aus, aber seit einer Dekade wird da Kram nicht fertig, der unter ZFS einfach geht.

 

[mae]

Kommt drauf an.
Es gibt halt inzwischen viel Linux-spezifischen Kram der auf anderen UNIX-Systemen häufig nicht (oder nur eingeschränkt) funktioniert. So typisch sind Dinge cgroups und namespaces.

Ja, dass ich bei den system calls den Eindruck selten habe, dass da viel Unterschied besteht, liegt wohl daran, dass ich mich tendentiell auf POSIX-system calls beschraenke (meine Programme fangen mit z.B. cgroups auch nichts an). Nur bei mmap() ist mir in letzter Zeit eine Divergenz zwischen Systemen aufgefallen: Es gibt inzwischen Systeme, bei denen mmap() fuer einen Speicherbereich mit RWX-Erlaubnis fehlschlaegt, und da sind neben MacOS fuer Apple Silicon (fuer Intel geht's) auch mindestens ein BSD dabei.

Wenns wirklich um scrpting geht, dann ist es eh angenehmer / komfortabler eine entsprechende Programmiersprache zu nutzen als irgendwie mit Shell-Skripten herum zu hantieren.

Ich weiss nicht, welche "entsprechende Programmiersprache" das sein soll, bisher habe ich keine gesehen, die Aufgaben, die ich mit shell scripts loese, aehnlich kompakt hinbekommt.

Und interaktiv: Gibt halt inzwischen moderne Alternativen die besser funktionieren als der GNU-Krempel.

Andere Leute moegen das vielleicht so empfinden (und das sind dann z.B. die Sysadmins, die ich genannt habe), aber wenn etwas, was ich verwende, auf der "modernen Alternative" nicht funktioniert, ist es fuer mich schlechter.

Und will man maximal kompatibel sein über UNIX-Grenzen hinweg, muss man eh auf POSIX-Shell zurückgreifen.

Das ist wohl der entscheidende Unterschied zu den system calls. Bei system calls will ich portablen Code schreiben, bei shell scripts nicht.

Insofern ist/wird zunehmend der einzige Grund für die GNU-Tools Gewohnheit und/oder vorhandene Bash-Skripte.

Kann man so sehen, aber die Gelaeufigkeit, die man als "Gewohnheit" kleinreden kann, hat einen betraechtlichen Wert, natuerlich nur fuer den, der sie hat. Der naechste baut ein inkompatibles "besseres" Werkzeug, das fuer andere eine Verschlechterung darstellt.

Ergänzung (Sonntag um 23:51)

Btrfs funktioniert gut, wenn die Funktionen genutzt werden, die gut funktionieren.
Raid 5/6 ist mäßig, Scrub mit Raid5/6 nah dran an unbenutzbar, Performance mit Snapshots und Quotas ist mies, Verschlüsselung auf Dateisystemebene ist seit Ewigkeiten in Entwicklung, ..

Das erklaert's: Wir verwenden kein RAID5/6, keine quotas, und fuer die Verschluesselung verwende ich LUKS.

Ich rolle ja selber gerne BTRFS aus, aber seit einer Dekade wird da Kram nicht fertig, der unter ZFS einfach geht.

Mein Eindruck ist, dass die zu sehr den Features hinterherlaufen, die andere haben, und sich dadurch verzetteln. Aber naja, solange das, was wir verwenden, funktioniert, ist das nicht so tragisch.

 

[andy_m4]

Ja, dass ich bei den system calls den Eindruck selten habe, dass da viel Unterschied besteht, liegt wohl daran, dass ich mich tendentiell auf POSIX-system calls beschraenke

Sowas wie namespaces etc. braucht man ja auch in normalen Anwendungsprogrammen eher nicht.

Ich weiss nicht, welche "entsprechende Programmiersprache" das sein soll, bisher habe ich keine gesehen, die Aufgaben, die ich mit shell scripts loese, aehnlich kompakt hinbekommt.

Man könnte beispielsweise Python oder Ruby nehmen. Oder wenn Du es extrem kompakt magst gerne auch Perl. :-)

Andere Leute moegen das vielleicht so empfinden (und das sind dann z.B. die Sysadmins, die ich genannt habe), aber wenn etwas, was ich verwende, auf der "modernen Alternative" nicht funktioniert, ist es fuer mich schlechter.

Ich will Dir Deine GNU-Tools nicht wegnehmen.
Ich hab nur versucht darzustellen, warum das eben nicht für jeden so überwichtig ist und das es Alternativen gibt.

Mein Eindruck ist, dass die zu sehr den Features hinterherlaufen,

Ähm ja. Das ist doch der Grund, warum es Btrfs überhaupt gibt. Die haben ZFS gesehen und sich gesagt: Sowas wollen wir auch haben. :-)

 

[mae]

Man könnte beispielsweise Python oder Ruby nehmen. Oder wenn Du es extrem kompakt magst gerne auch Perl. :-)

Vor 30 Jahren hat ein Kollege was in Perl geschrieben, das ich dann warten sollte. Ich hab's dann lieber mit bash und awk neu geschrieben, und das Ergebnis war halb so lang.

Ergänzung (Montag um 20:15)

Die haben ZFS gesehen und sich gesagt: Sowas wollen wir auch haben. :-)

Koennte so gewesen sein. Und wenn das naechste coole Feature daherkam, haben sie das auch noch auf ihre ToDo-Liste gesetzt. Man sollte halt nicht versuchen, die ganze Liste gleichzeitig abzuarbeiten.

 

[BxBender]

Wieso sollte Snapdragon unter Linux schneller verbreitung finden als unter Windows? Letzteres hat einen viel höheren Marktanteil. Was wirklich fehlt, neben Linuxsupport, sind mehr Anbieter, attraktivere Preise und verbesserte x86 kompatibilität durch Windows.
Linux allein garantiert gar nix, die ganzen Firmen und auch Privatleute schauen auf Windows und nicht auf Linux außer eine kleine Minderheit, und das meine ich nicht abwertend, lass dich von der CB Bubble nicht verunsichern.

Und dennoch wird es Jahre dauern bis es spürbare Auswirkung hat, dann aber einfach zu einem anderen US Hersteller zu wechseln mindert die Abhängigkeit daran nicht.
Die EU braucht eigene Chiphersteller die auf dem Markt bestehen können.

Ergänzung (30. April 2026)

Sry, das ist Quatsch. ARM und X86 sind verschiedene ISAs. Wenn man so will kann man noch RISC und CISC in den Raum werfen aber intern ist x86 auch schon RISC und ARM wird auch ständig erweitert was ihn dann schon wieder zum CISC macht.

Auch das ist Quatsch, auch ARM ist vollgestopft mit Erweiterungen um Berechnungen zu beschleunigen, nennt sich dort NEON und ist eine Befehlssatzerweiterung.

Klar hätte man schon direkt mit Snapdragon X1 volle Windows Kompatibilität anbieten müssen, will man eine Chance auf dem Markt haben.
So eine Windows (ARM) Lösung ist echt lächerlich und weitaus schlechter als Linux.
Auch solche Dinge wie ein N100 mit 4GB Ram als Notebook aktuell im Angebot für 222 Euro verhökern zu wollen, das ist eine Zumutung und Verarsche des Kunden, der sein Geld quasi wegwirft.

Ich stimme zu, dass die EU dringend eigene Alternativen braucht, bei Hardware und Software.
Amerika hat sich als unzuverlässiger Handelspartner herausgestellt und droht und sogar mit (Handels)Krieg, da kann man ja auch gleich mit China verbrüdern und denen unsere sensiblen Daten geben.

Mit meinem einfachen Vergleich der Prozessoren wollte ich niemals suggerieren, dass es sich um gleiche Chiptypen handelt, wo man einfach einen bestehenden Prozessor genommen hat und dort Funktionseinheiten herausgenommen hat.
Es ist aber so, dass ARM eindeutig an gewissen Stellen gespart hat, um am Ende auf die Effizienz kommen zu können.
Es wäre physikalisch sonst gar nicht möglich.
Das ein ARM Chip natürlich auch Verdrahtungen für bestimmte Codecs hat und so haben muss, ist doch klar, und das habe ich nie in Frage gestellt.
Es sind aber nur die Sachen drin, die man auch wirklich beschleunigen will.
Und weil dem ganzen so ist, ist es nun mal kein x86 kompatibler Chip, weil ihm halt einige der Dinge fehlen, sonst würde ja viel mehr oder gar alles drauf laufen, wenn die das nur anders gelöst hätten, von der Schaltung her.
So wie älteren Garfikkarten Rytracing Kern fehlen, oder aber bestimmte Dinge, um die ganz neuen DLSS und FSR KI Funktionen nutzen oder schnell genug berechnen zu können.
Klar drücke ich mich nicht präzise genug und sehr oberflächlich aus, ich bin halt kein Techniker, der sich da gut (mit den Begrifflichkeiten) auskennt.

 

[sikarr]

Klar hätte man schon direkt mit Snapdragon X1 volle Windows Kompatibilität anbieten müssen, will man eine Chance auf dem Markt haben.

Die X1 sind schon tolle CPUs kann man echt nicht meckern, habe einen SD X1P und das ist ein tolles Gerät, vom Feeling merkst kein Unterschied. Wo ich es gemerkt habe, also spielen tue ich mit dem Gerät nicht, ist beim Bambu Studio. Das gibts nicht für ARM64 und da merkt man die Emulation brutal, das gleiche beim Treiber, da muss noch viel gemacht werden.
Andere Software läuftdagegen auch unter der Emulation super, wenn sie die beim X2 noch verbessert haben wäre das schon was. Für die Arbeit bin ich echt am Überlegen, unsere SoC Lösung läuft auch unter ARM, unsere Endpoint Lösung soll emuliert auch keine Probleme haben das wäre ein Blick wert.

Und weil dem ganzen so ist, ist es nun mal kein x86 kompatibler Chip, weil ihm halt einige der Dinge fehlen, sonst würde ja viel mehr oder gar alles drauf laufen, wenn die das nur anders gelöst hätten, von der Schaltung her.

Achtung, gefährliches Halbwissen: Jemand hier im Forum meinte das es sogar einfacher ist x86 Befehle in ARM kompatible umzuwandeln, das hat wohl was mit der Registergröße der ARMs zu tun. Anders herum ist wohl schwerer weil die Anweisungen wohl zerstückelt werden müssen was aufwendiger ist.

 

[mae]

Jemand hier im Forum meinte das es sogar einfacher ist x86 Befehle in ARM kompatible umzuwandeln, das hat wohl was mit der Registergröße der ARMs zu tun.

Mit der Anzahl der Register vielleicht. Bei den GPRs hat AMD64 (was Du "x86" nennst) 16 register, und ARM A64 hat 31. Da kann man einfach fuer jedes AMD64-Register ein bestimmtes ARM-Register festlegen.

Wenn man umgekehrt ARM A64 mit AMD64 emulieren will, ist eine einfache Implementierung, eine fixe Menge von z.B. 15 A64-Registern auf AMD64-Register abzubilden und die restlichen 16 Register im Speicher zu halten (ein Register ist dazu da, um so Dinge wie die Einschränkung der Operanden von AMD64 bei shifts oder bei mul zu handhaben, vielleicht braucht man auch mehr als 1, dann bleiben noch weniger für die direkte Abbildung übrig.

Die Performance ist aber vermutlich besser, wenn man immer die ARM-Register in AMD64-Registern hält, die gerade aktiv sind. Das ist aber komplizierter. Und in dieser Hinsicht ist es einfacher AMD64 auf ARM A64 zu emulieren.

Andererseits, bei AVX-256 und v.a. AVX-512 kannst Du die Register nicht so einfach auf Neon-Register abbilden, die sind nur 128 bit lang. Und auf SVE geht's auch nicht, da ist die Breite ja nicht festgelegt, und kann auch 128b schmal sein.