News 0,8 Prozent Marktanteil für Qualcomm: Nur 720.000 Notebooks mit Snapdragon-Chip verkauft

Aus meiner Sicht sind die Dinger einfach zu teuer für einen Kauf ins Ungewisse. Mit der (aktuellen) Nischenarchitektur hängt man dann an einem dünnen Faden des Softwaresupports (primär das Betriebssystem mitsamt Treibern). Evtl. kann man sich dann in 4-5 Jahren günstig so eine Softwareleiche erstehen und mit Linux sinnvoll weiterbetreiben. Aktuell würde ich bei dem UseCase Tatsache eher ein MacBook mit M4 bevorzugen, denn wenn man schonmal viel Geld für so ein Teil ausgibt, dann will ich da auch langfristig zugesagte Unterstützung.
 
Zuletzt bearbeitet:
lynx007 schrieb:
Softwareangebot vermute ich mal.
Ich tippe halt eher auf den Startpreis, die ersten Systeme waren schlicht zu teuer und die aktuelle Senkung erfolgte doch auch nur weil sie wie Blei in den Regalen liegen, den Rest wird M$ mit CoPilot und Recall verschreckt haben. Kenne keinen der gesagt hat, Wow, das muss ich haben".
DaZpoon schrieb:
Aus meiner Sicht sind die Dinger einfach zu teuer für einen Kauf ins Ungewisse. Mit der (aktuellen) Nischenarchitektur hängt man dann an einem dünnen Faden des Softwaresupports (primär das Betriebssystem mitsamt Treibern).
Das ist es ja, auf der einen Seite kann ich verstehen das man es höher angesetzt hat um nicht gleich alle zu verschrecken wenn am Ende die Software nicht läuft bzw. langsamer.
Hätten sie es günstiger angeboten hätten es dann wohl zu viele gekauft und ein riesen Aufschrei wäre gekommen.
Weil sind wir doch mal ehrlich, wer außer in der CB Bubble weiß den schon was mit einer CPU Architektur und Softwarekompatibiliät anzufangen. Die Geräte werden als schnell, leicht und ausdauernd beworben, da geht der Vati und die Mutti in den Mediamarkt und holen sich das weil der Preis stimmt und zu hause ist dann das böse erwachen.

Dann also teuer wo die Käuferschaft das abwiegen bzw beurteilen kann. Und die wurden dann von CoPilot und Recall verschreckt. Windows 11 macht auch immer mit Updateproblemen von sich reden was sogar die Migration bei uns mittlerweile abwarten lässt.
 
sikarr schrieb:
Wer sagt das die Liste vollständig ist?
Wer sagt das sie nicht wächst?
Die Liste sagt nur das es weniger gibt aber auch das viele bekannte Sachen bereits verfügbar sind

Deswegen gibts eine Emulationsschicht.
Du hast alle Gründe aufgezählt warum QC mit Windows on Arm floppt.

1. Vermutungen das in Zukunft mehr als eine Handvoll Apps gibt.

2. Du sagst selber das Treiber fehlen.

3. Emulation ist langsam.

4. Produkt zu teuer


Mit diesen Giftpillen wird es nix mit Windows on Arm.
 
pacifico schrieb:
Du hast alle Gründe aufgezählt warum QC mit Windows on Arm floppt.

1. Vermutungen das in Zukunft mehr als eine Handvoll Apps gibt.
Es gibt jetzt bereits schon mehr als eine Handvoll nativer APPs und es werden auch mehr.
pacifico schrieb:
2. Du sagst selber das Treiber fehlen.
Das ist ein Thema von Qualcomm selbst da sie die einzigen sind die Treiber für ihre Produkte bereitstellen. In dem Fall halt nur über Windows Update durch M$
pacifico schrieb:
3. Emulation ist langsam.
Emulation ist immer langsamer als nativ. Und hierin liegt wohl auch der größte Irrtum. Die Emulationsschicht ist ein temporäres Mittel bis eben Anwendungen portiert sind, ohne diese würde ja gar keine Anwendung laufen.
Apple hat dieses Spiel schon 2 mal erfolgreich gespielt, auch da waren es die gleichen Probleme wie jetzt hier, mittlerweile kräht aber kein Hahn mehr danach.
pacifico schrieb:
4. Produkt zu teuer
Definitv
pacifico schrieb:
Mit diesen Giftpillen wird es nix mit Windows on Arm.
Microsoft sollte Windows on ARM für alle Hersteller öffnen und nicht nur für Qualcomm exklusiv. Dann würde die Verbreitung und Entwicklung auch schneller vorangehen und wohl auch günstigere Endgeräte.

Ampere würde dann bestimmt nicht nur Server CPUs produzieren, die machen das ja schon länger.
 
@sikarr

Das ist ein Argument. Exotische Archetektur plus Preis machts nicht einfacher das an den Mann zu bringen. Surface RT ging damals auch nur, weil es offzice gab und nochmal 30% weniger kostete als das Intel Pendant. Und selbst das war kein Selbstläufer.
 
@sikarr
Wie gut funktioniert den diese "Emulation shicht"? klann ich da als Anwender jede apk, oder iphone anwendung reinwerfen und Sie läuft? Und bliebe da auch so, selbst wen Qualcom und MS sein Abenteuer, ähnlich wie WinRT, WinPhone nicht mehr vortsetzt?
Denn das große Problem ist ja die Kompatibilität. Wozu gibt es cloud, wozu webapps? Es ist halt einfach sehr komfortabel gerätunabhäng ein Account zu haben, und die Anwendung läuft. Das ist aber oft nciht der Fall.

Sollte das mit der Emulationsschicht wirklich der vergangenheit angehören, dann sehe ich keinen Grund am scheitern. Aber oft wird ja vieles versprochen, anfangs ist es oft noch so, und dann wen der Hyper vorbei ist, hat man ein Grerät ohne wert und nutzen. Ich habe mich damit ehrlich gesagt aber auch noch wenig damit auseinandergesezt, vermultich weil ich durch WinRT und WinPhone schon ein gebrantes Kind bin.

Dabei hätte ich überhaupt kein Problem wen Arm sich überall durchsetzt, also auch im Desktop, sollte es grundsätzlcih die besser Archetektur sein. Aber in der Praxis wird immer erst viel versprochen, und dann nur leider sehr wenig eingehalten. Insbesondere wen es um tatsächliche kompatibilität und langlebigkeit geht.

Und tatsächliche kompatibilität scheint abseits des Prospekts durch aus ein Thema zu sein laut GPT:

  • Performance-Verlust: Langsame 3D-Renderings (AutoCAD), Verzögerungen bei Videoschnitt (Premiere Pro), ineffiziente Excel-Makros.
  • Hardware-Kompatibilität: RSA-Token unbrauchbar, USB-Messgeräte inkompatibel, keine eGPU-Unterstützung.
  • Software-Kompatibilität: Keine AVX-Unterstützung (MATLAB), Maschinensteuerungen nicht lauffähig (TIA Portal), Virtualisierung eingeschränkt (VMware).
  • Zielgruppe: Gut für Office (Word, Excel), ungeeignet für Power-User und spezialisierte Anwendungen.

Hört für mich wie WinRT2.0 an.... wen das unsinn ist, bitte korregiert das? Aber ihr dürft die Probleme gerne auch bestätigen? Gerade eine "Emulationschicht" die aber Treiber und Apis nicht unterstützt.... ist das nciht auch für Devs dann ein gau? Also damit kann man eben nicht alles in nen "Container" werfen und es läuft out of the Box. Aber das ist ja ohne x86 geschweige x64 kompatibilitä nicht der fall? Und so habe ich doch wieder ein Henne/Ei problem oder nicht?

Technische Herausforderungen von Windows on ARM: API- und Kompatibilitätsprobleme


Windows on ARM versucht, durch Emulation x86- und x64-Anwendungen lauffähig zu machen. Dennoch gibt es klare Einschränkungen bei der Unterstützung von Befehlssätzen, APIs und hardware-nahen Funktionen. Im Folgenden eine strukturierte Übersicht:




1. Performance-Verlust durch fehlende CPU-Befehlssatz-Unterstützung


Einige wichtige Befehlssätze können nicht emuliert werden, was zu Leistungseinbußen oder Funktionsausfällen führt.


  • Nicht unterstützte Befehlssätze:
    • AVX/AVX2: Wichtige Erweiterungen für wissenschaftliche Berechnungen und Machine Learning (z. B. MATLAB, TensorFlow).
    • SSE4.2: Eingeschränkte Unterstützung, was Performanceprobleme bei Programmen wie Adobe Photoshop verursacht.
    • MMX/3DNow!: Veraltete, aber in älteren Programmen genutzte Befehlssätze fehlen.
  • Beispiele für betroffene Anwendungen:
    • Simulationstools: MATLAB, ANSYS (wegen AVX-Abhängigkeit unbrauchbar).
    • Videobearbeitung: Adobe Premiere Pro (langsames Rendering).
    • 3D-Rendering: Blender, SolidWorks (fehlerhafte Berechnungen, Verzögerungen).



2. API-Kompatibilität: Eingeschränkte Unterstützung und Performance


Während viele Standard-Win32-APIs emuliert werden, gibt es Einschränkungen bei Grafik- und hardware-nahen APIs.


  • Grafik-APIs:
    • DirectX:
      • DirectX 11/12: Besser unterstützt, aber Performance stark abhängig von nativen ARM-Treibern.
      • DirectX 9 und älter: Häufige Inkompatibilitäten oder massive Performanceeinbrüche.
    • OpenGL: Oft schlecht performend oder gar nicht unterstützt, je nach Anwendungsversion.
  • Hardware-nahe APIs:
    • Anwendungen, die direkte Hardwarezugriffe benötigen (z. B. Maschinensteuerungen, CAD), funktionieren nicht oder nur eingeschränkt.
  • Beispiele für betroffene Anwendungen:
    • Maschinensteuerungen: Siemens TIA Portal (Hardwarezugriff über spezielle APIs).
    • Virtualisierung: VMware, VirtualBox (eingeschränkte Funktionalität).
    • Sicherheitssoftware: Einige VPN-Clients und Firewalls funktionieren nicht wegen fehlender Treiberintegration.



3. Treiber-Inkompatibilität: Nur native ARM64-Treiber


Treiber für x86/AMD64 werden nicht emuliert, was viele hardware-nahe Anwendungen unbrauchbar macht.


  • Betroffene Geräte:
    • Sicherheitsgeräte: RSA-Token, Smartcards (z. B. YubiKey) funktionieren nur mit ARM64-Treibern.
    • USB-Messgeräte: Industrielle Geräte von Fluke oder Keysight sind inkompatibel.
    • eGPUs: Externe Grafikkarten (z. B. NVIDIA, AMD) werden nicht unterstützt.
  • Beispiele für No-Go-Szenarien:
    • Produktionsumgebungen: Spezialmessgeräte in der Fertigung können nicht genutzt werden.
    • Bankensektor: Hardware-Sicherheitskeys für 2FA ohne ARM64-Treiber.
    • Grafik-Rendering: Keine Nutzung von High-Performance-Grafikkarten über Thunderbolt.



4. Zielgruppe: Eingeschränkt auf Standardanwendungen


Windows on ARM ist gut für Office-Anwendungen und Cloud-basierte Tools geeignet, aber ungeeignet für spezialisierte Software und Power-User.


  • Empfohlene Anwendungen:
    • Office: Word, Excel, PowerPoint laufen nativ und performant.
    • Web-Applikationen: Microsoft Teams, Google Workspace funktionieren ohne Einschränkungen.
    • E-Mail und Browser: Outlook, Edge, Chrome bieten native ARM-Unterstützung.
  • Ungeeignete Anwendungen:
    • Entwicklung: Komplexe IDEs wie Visual Studio laufen eingeschränkt.
    • Datenanalyse: SPSS, R mit großen Datensätzen nur langsam ausführbar.
    • Grafik/3D: Blender, Maya nur eingeschränkt nutzbar.



Fazit:


Windows on ARM bietet akzeptable Performance für Office- und Web-basierte Anwendungen, ist jedoch für rechenintensive Programme, hardware-nahe Anwendungen und spezialisierte Software ungeeignet. Die fehlende Emulation von Treibern und bestimmten Befehlssätzen (AVX, SSE) sowie eingeschränkte API-Unterstützung führen zu gravierenden Kompatibilitätsproblemen in professionellen Umgebungen.

@Volker

Habt ihr dazu schon mal einen Artikel geschrieben was (in-)kompatibiltät angeht? Würde mich sehr interessieren, was Arm-x86/amd64-emulator alles NICHT-kann. Sehe ich es richtig, das das ding nichtmal mit nem USB-Sicherheithadwartoken umgehen könnte, und damit für viele Firmen umgebung ungeeigent wäre?

Also für mich wirkt es leider wieder wie ein WinRT2.0, nur mit schlechteren Abverkauf. Man darf ja nicht vergessen, hostorisch war x86 ja so unglaublich erfolgreihc, aufgrund der kompatibilität. Gerade bei Firmenumgebungen, insbesondere heute durch Homeoffice, ist das für viele essenziell.

Und wen es wirklich nur um Surfen, Filme und Office geht, das macht halt jedes Tablet schon seit 15 Jahren auch. Sprich der Kuchen ist schon sehr verteilt. Was auch das geringe Wachstum erklärt. Denn 0,8 ist schon sehr mager. Zum vergleich, als ich für MS zur Surface Veröffentlichung im Einsatz war, da ging praktisch jedes 5 Surface als WinRT raus! Und selbst das wurde dann eingedampft, vermutlich auch weil es ohne direkt Vertrieb gar nicht ging.
 
Zuletzt bearbeitet:
sikarr schrieb:
Hauptsache sie haben ihr Office (liegt nativ für ARM vor) und einen Browser (liegt auch für ARM vor) und die können arbeiten wie gewohnt.
Meinten Sie: Hauptsache sie haben "Microsoft Office"

sikarr schrieb:
Und Windows ist kein Android (Gott sei Dank).
Wieso Gott sei Dank? Android ist besser als Windows. Sehen alle meine Anwender so.

sikarr schrieb:
Laggy ist die aktuelle Lösung auch nicht, klar Emulation kostet Leistung aber besser so als bei Windows RT wo man dan wirklich keine Software nutzen kann.
Niemand kauft ein Itanium-System, auf dem er nur emulierte x86-Software ausführen.
Niemand kauft ein ARM-System, auf dem er nur emulierte x86-Software ausführen kann.

sikarr schrieb:
Qualcomm ist nicht das Problem sondern M$, dieses sture denken das alles bis ins Unendliche abwärtskompatibel sein muss. Klar ist es schön wenn man Software länger nutzten kann aber was hats uns gebracht, Performanceprobleme, zig APIs, massig Sicherheitslücken weil alter Ballast mit geschleppt wird.
Das ist der einzige Grund, warum sich Anwender überhaupt noch mit Microsoft beschäftigen.

Wenn nichts kompatibel sein muss, sind sie weg von Wintel. Es gibt ansonsten keine Gründe mehr für Windows, tut mir leid, wenn du das nicht siehst.
 
lynx007 schrieb:
Wie gut funktioniert den diese "Emulation shicht"? klann ich da als Anwender jede apk, oder iphone anwendung reinwerfen und Sie läuft? Und bliebe da auch so, selbst wen Qualcom und MS sein Abenteuer, ähnlich wie WinRT, WinPhone nicht mehr vortsetzt?
Natürlich deckt sie nicht 100% ab, wie genau das in Windows implementiert ist musst du M$ fragen. Aber selbst Apple konnte mit Rossetta und Rossetta 2 nicht jede Software ab decken.
lynx007 schrieb:
Sollte das mit der Emulationsschicht wirklich der vergangenheit angehören, dann sehe ich keinen Grund am scheitern.
Die Emulationsschicht ist nicht die Lösung, sie ist ein Mittel für ein temporäres Problem (so die Idee). Sie soll einen Übergang/Wandel ermöglichen damit man eben nicht wie bei WinRT komplett ohne dasteht und gar keine Software hat bzw. man warten muss bis sie portiert wurde.
lynx007 schrieb:
Dabei hätte ich überhaupt kein Problem wen Arm sich überall durchsetzt, also auch im Desktop, sollte es grundsätzlcih die besser Archetektur sein.
Besser schlechter sind 2 Paar Schuhe, beide Architekturen haben vor und Nachteile. x86 gibt es schon ewig und die 2 letzten Hersteller haben ihren Markt. ARM kommt aus einem anderen Markt und es fehlt an Software (bei Windows), Intel und M$ arbeiteten stark zusammen was die Anpassung an deren Architektur anging und das über Jahrzehnte. Das holst du nicht so eben auf, größtes Problem ist das sich AMD und INTEL die letzten Jahre halt zu sehr auf ihren Lorbeeren ausgeruht haben, Konmkurenz belebt ja das Geschäft.
lynx007 schrieb:
Hört für mich wie WinRT2.0 an.... wen das unsinn ist, bitte korregiert das? Aber ihr dürft die Probleme gerne auch bestätigen?
Windows on ARM ist sogesehen ein alter Hut. Windows NT gabs auch für Alpha und PPC Prozessoren und Windows Embedded / CE auch für ARM nur waren das immer Nischen, Ob man es nun WinRT 2 oder Windows on ARM nennt ist dabei eigentlich nebensächlich, es ist halt ein Windows was für ARM Cpus kompiliert wurde und darauf läuft, die Entwickler der Software müssen halt jetzt nachziehen und da muss M$ eigentlich jeden Unterstützen damit das breite Anwendung finden kann.
lynx007 schrieb:
Gerade eine "Emulationschicht" die aber Treiber und Apis nicht unterstützt.... ist das nciht auch für Devs dann ein gau?
Die Entwickler sollen ja nicht für die Emulation entwickeln sondern native APPs. Die Emulation ist für uns als Endkunden da damit ein großteil unserer Software am Anfang überhaupt drauf laufen kann.
Längerfristig wird die Emulation aus Hard und Software wieder rausfliegen.
lynx007 schrieb:
Also damit kann man eben nicht alles in nen "Container" werfen und es läuft out of the Box. Aber das ist ja ohne x86 geschweige x64 kompatibilitä nicht der fall? Und so habe ich doch wieder ein Henne/Ei problem oder nicht?
Ein Container ist keine Emulation
Ergänzung ()

wechseler schrieb:
Meinten Sie: Hauptsache sie haben "Microsoft Office"
Libre Office und OnlyOffice gibt es mittlerweile genauso für ARM, aber ansonsten ja.
Mag dir nicht gefallen aber M$ Office ist Standard in deutschen Unternehmen, ob gut oder schlecht ist ne andere Frage.
wechseler schrieb:
Wieso Gott sei Dank? Android ist besser als Windows. Sehen alle meine Anwender so.
Magst du so sehen und auch andere, ich aber z.B. nicht und auf meinem PC brauch ich kein Android das reicht mir schon auf dem Handy.
wechseler schrieb:
Niemand kauft ein Itanium-System, auf dem er nur emulierte x86-Software ausführen.
Um Itanium gehts doch hier gar nicht, die Architektur ist tot und das hatte halt Gründe.
wechseler schrieb:
Niemand kauft ein ARM-System, auf dem er nur emulierte x86-Software ausführen kann.
Keine Ahnung ob deine Brille schmutzig ist aber es gibt genug native Software für ARM und es wird auch stetig mehr. Aber du tust so als ob es gar keine Software dafür gebe und alles emuliert werden müsste und das ist schlicht falsch.

Wie ich oben schon schrieb soll die Emulation nicht die Lösung sein sondern ein Mittel zum Wandel um ungläubigen wie dir einen Problemfreieren Wechsel zu ermöglichen.
wechseler schrieb:
Das ist der einzige Grund, warum sich Anwender überhaupt noch mit Microsoft beschäftigen.

Wenn nichts kompatibel sein muss, sind sie weg von Wintel.
Die wenigsten beschäftigen sich wirklich mit Windows oder Betriebssystemen. Es gibt einen Anwendungsfall und danach wird das Produkt ausgewählt. Ob das am Ende ein Linux, Windows oder MacOS wird weiß der Geier und ist am Ende egal wenn dem Anwender seinen Anwendungsfall damit abdecken kann.
wechseler schrieb:
Es gibt ansonsten keine Gründe mehr für Windows, tut mir leid, wenn du das nicht siehst.
Mir tut es leid das du nicht über den Tellerrand, aus deiner Blase herausschauen und dein Geist mal für neue und andere Dinge öffnen kannst.
 
Zuletzt bearbeitet:
Tomsenq schrieb:
Welcher Großabnehmer von Laptops setzt denn Linux ein? Die paar hundert Privatleute welche auf Linuxsupport wert legen gehen den Herstellern am Alerwersten vorbei.
Das mag sein, aber trotzdem sind es meine Gründe dagegen! Mir müsste man schon Geld dafür zahlen, dass ich Windows 11 nutze. Ohne Linux kaufen die paar hundert Linux Nutzer halt keinen Snapdragon Laptop!

Wer braucht die auch ? Die neuen AMD/Intel Prozessoren sind nicht schlechter!
 
Zurück
Oben