News Snapdragon X2: Qualcomm unterstützt Linux erstmals offiziell

Grundsätzlich begrüße ich die Idee, aber bei Qualcomm bin ich immer skeptisch.
Hoffe mal, die geben wirklich alles als Open Source raus ohne Blobs. Bei AMD mit Vulkan hat man ja gesehen, was die Community da an Leistung rausholen kann. Die Mesa-Treiber waren am Ende schneller als die Lösung von AMD. Und die Qualität von Qualcomm Treibern war oft eher so Meh.
Eigentlich wäre OpenSource für mich als CPU Hersteller ein Nobrainer.
 
  • Gefällt mir
Reaktionen: eastcoast_pete, Gohma, Termy und eine weitere Person
Uh, jetzt wirds spannend. Mein Traum wären "MacBooks (Air)" mit 100%iger Linux-Unterstützung, gerne Arch... Tuxedo, ich habe ein Auge auf euch!
 
  • Gefällt mir
Reaktionen: Cookie4u
cruscz schrieb:
Vermutlich will Qualcomm bestimmte Daten nicht Open Source stellen, was die Voraussetzung für eine Kerneleinbindung ist. Im Prinzip der gleiche Grund, weshalb eine NVIDIA GPU extra Treiber braucht unter Linux, eine AMD oder Intel GPU aber nicht. Letztere haben genug offen gelegt, erstere nicht.
Und genau deswegen ist es Schmutz. Qualcomm wird auch hier wie schon wie bei Windows 11 im typischen Consumer markt direkt scheitern und nur mit erheblichen Rabatten die Geräte loswerden.
Weitere Gründe:
Touchpadstandby Bug, generell Energiesparfunktionen durchweg fehlerhaft. x86 Emu weiterhin fehlerhaft, insbesondere an USB Schnittstellen (Scannertreiber 404, Druckertreiber 404). Gaming 404, Grafikkarte ist selbst im Vgl. mit Intel einfach ein Witz, fast nichts läuft wirklich richtig rund. NPU nutzlos.
Davon ab sind die Geräte oft mit beschissenen Minitastaturen versehen sowie schlechten Lautsprechern, im Premiummarkt werden die damit niemals ankommen. Achja, kein Support für alte Geräte, siehe hier, Kernel nur für X2.

Ganz ehrlich, die sollen lieber wieder gute Tablets mit Android bauen, anstatt Papiertigerhardware zu verhökern.
 
  • Gefällt mir
Reaktionen: derohneWolftanzt, peru3232, MGFirewater und 2 andere
Mich wundert die Wahl der Distro.
Es ist zwar verständlich dass Qualcomm erst einmal auf das weit verbreitete ubuntu abzielt, aber jeder patch und jede Änderung dauert im Debian Repository gefühlt Ewigkeiten.

Da wäre wohl ein Arch-Derivat agiler bzw. dynamischer gewesen - ausserdem sind da vermutlich mehr Power-User und die experimentierfreundigeren User unterwegs.

...aber qualcomm wird sicher seine Gründe haben, ich traue denen zu, dass sie das besser erörtert haben als ich :freaky:


ich selbt hätte ja mit einem Chimera oder void Linux angefangen... :mussweg:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tsu
Chriz schrieb:
Mich wundert die Wahl der Distro.
Es ist zwar verständlich dass Qualcomm erst einmal auf das weit verbreitete ubuntu abzielt, aber jeder patch und jede Änderung dauert im Debian Repository gefühlt Ewigkeiten.

Da wäre wohl ein Arch-Derivat agiler bzw. dynamischer gewesen - ausserdem sind da vermutlich mehr Power-User und die experimentierfreundigeren User unterwegs.
Wen interessiert schon "dynamische Agilität", hier gehts um erste Implementierungen, da geht Reproduzierbarkeit und Stabilität über alles.

Ich bin selbst ja auch auf Arch unterwegs, aber kann trotzdem nicht die Begeisterung für viele Updates in kurzer Zeit nachvollziehen. Ich stoss so alle 1-2 Monate mal ein Systemupdate an. Reicht mir mich dann damit auseinanderzusetzen und nicht jeden oder jeden zweiten Tag^^.
 
  • Gefällt mir
Reaktionen: Deinorius
Bin genau deswegen noch auf x86 beim Neukauf geblieben.
Aber schön, dass offizieller Support kommt
 
  • Gefällt mir
Reaktionen: x37
Schinken42 schrieb:
Wen interessiert schon "dynamische Agilität", hier gehts um erste Implementierungen, da geht Reproduzierbarkeit und Stabilität über alles.

Das ist mir schon bewusst. Ich dachte eben dass es in einem Updatezyklus (z.b. im AUR) schneller gehen würde Fehlerbehebungen einzuspielen. Wenn Qualcomm ein patch veröffentlichen möchte, wird es im stabel-zweig noch wochen dauern, bis der patch wirklich ausgespielt wird. unstable ode rtesting kommt für ein produktivsystem ja nciht unbedingt in Frage.


Wenn es dann fehlerfrei funktioniert, dann ist debain stable sicher die beste Wahl. Ich bin selbst von Arch über Manjaro bei debian gelandet, weil ich ein funktionierendes OS wollte und keine Lust darauf hatte, mich ständig und maßgeblich um die administration des OS zu kümmern - das Ding soll halt laufen...
 
  • Gefällt mir
Reaktionen: Tenferenzu und Schinken42
ebird schrieb:
Das Relativiert sich mit KI Unterstützung.
Also mal abgesehen davon, dass es vergtraglich verboten ist die Doku und den Code von Qualcomm in eine AI zu kippen, macht selbst Opus noch subtile Fehler bei der Analyse, die man dann im Review definitiv gegenprüfen muss… hab ich gehört. Und dann stehst du wieder da und musst die Doku wälzen und mit dem Support sprechen.
Außerdem hilft dir die beste ki nichts, wenn das delivery von Qualcomm verbuggt ist und nur ein binary blob.
Shit in shit out. Auch mit AI.
 
  • Gefällt mir
Reaktionen: Schinken42
Fein. Schade das Qualcomm sich selbst und allen Anwendern durch den Exklusivdeal mit Microsoft erheblich Schaden zugefügt haben. Seit IBM hat sich kein Unternehmen mehr so von Microsoft schädigen lassen?

Linux unterstützt ARM schon länger und besser als Windows. Keine Emulationen, keine Layer, offener Quellcode und hohe Portabilität. Vielleicht besteht noch eine Chance für die ThinkPads mit Qualcomm oder umgekehrt - endlich AMD ohne Lüfter :)

Qualcomm sollte die Unterstützung in Mainline GNU und Linux einziehen. Wenn ich von einzelnen Distributionen lese, bedeutet dass, das noch Arbeit getan werden muss. Als Anwender bedeutet „Wir unterstützen Suse, Red Hat oder Canonical“, da sind noch Patches im Umlauf. Als Anwender will ich lesen „Läuft mit Linux“.
 
  • Gefällt mir
Reaktionen: HolySkillet
Chriz schrieb:
Das ist mir schon bewusst. Ich dachte eben dass es in einem Updatezyklus (z.b. im AUR) schneller gehen würde Fehlerbehebungen einzuspielen. Wenn Qualcomm ein patch veröffentlichen möchte, wird es im stabel-zweig noch wochen dauern, bis der patch wirklich ausgespielt wird. unstable ode rtesting kommt für ein produktivsystem ja nciht unbedingt in Frage.
AUR und rolling release ja auch nicht wirklich. Ebenso wenig bleeding edge Hardwaresupport.

Ob die patches dann ein par wochen länger brauchen bis sie global verfügbar sind ist da egal. Mir wäre es das jedenfalls^^. Und Qualcomm scheint ja auch ähnlich zu denken, wenn man sich ansieht wie langatmig, um nicht lahmarschig zu sagen, deren Updates kommen :D.
 
flaphoschi schrieb:
Qualcomm sollte die Unterstützung in Mainline GNU und Linux einziehen.

ich bin von dieser Thematik wirklich weit weg, deshalb vlt. die "doofe" Frage:

Würde ja bedeuten, dass Qualcomm alles opensource machen müsste, sämtliche Treiber und microcodes müssten offen gelegt werden, oder?

Wie machen das Intel und AMD?
 
Dies könnte tatsächlich ein Game changer werden für mich.
Es braucht dann halt auch die passenden lüfterlosen Notebooks in guter Austattung und ab geht's. (Framework?)
Damit könnte es dann das Macbook Air für mich ersetzen.
Ich benutze bereits seit einigen Jahren unterschiedliche Linux Distris und habe zum Jahreswechsel den harten Schnitt vollzogen:
  • Erstes Macbook Air für alles was ich neben Gaming am Desktop gemacht hatte
  • Gaming Desktop auf Bazzite migriert und steht jetzt als "Steam OS Konsole" hinter dem Fernseher
  • Das alte Windows 10 ist noch auf einer zweiten SSD, falls ich irgendwelche Firmware Upgrades für Flight Sticks oder Lenkräder brauche (und wurde seit einem halben Jahr nicht mehr gebootet).
 
flaphoschi schrieb:
Vielleicht besteht noch eine Chance für die ThinkPads mit Qualcomm
gibts doch, gerader erst erschien das Thinkpad T14s Gen7 mit X2E.
Chriz schrieb:
Würde ja bedeuten, dass Qualcomm alles opensource machen müsste, sämtliche Treiber und microcodes müssten offen gelegt werden, oder?
Nein müssen sie nicht, da gibts mehrere Methoden wie man das machen könnte
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tsu
„Gemeint is die Unterstützung von Linux.“
Da ist jemanden kurzfristig der Berliner Dialekt rausgekommen :D
 
spamarama schrieb:
Also mal abgesehen davon, dass es vergtraglich verboten ist die Doku und den Code von Qualcomm in eine AI zu kippen, macht selbst Opus noch subtile Fehler bei der Analyse, die man dann im Review definitiv gegenprüfen muss… hab ich gehört. Und dann stehst du wieder da und musst die Doku wälzen und mit dem Support sprechen.
Außerdem hilft dir die beste ki nichts, wenn das delivery von Qualcomm verbuggt ist und nur ein binary blob.
Shit in shit out. Auch mit AI.
Opus ist auch Bullshit und ich verstehe den Hype dahinter nicht. Ich bekomme mit meinem eigenen Agent bessere Ergebnisse und vor allem stabilere Ergebnisse hin. Da habe ich in einigen Teilprojekten 130 fast autonome Schritte mit zwei Minifehlern (ein Regex und ein Template Formatierung) bekommen und das in konstanter Qualität und das mit einem OpenWeight Modell für 1/20 der Kosten von Opus. Bei Opus muss ich mich glücklich Schätzen, wenn ich nur 20% der Schritte korrigieren muss und das bei lediglich 50 Teilschritten.

Das waren konkrete Projekte und das 130Schritt Projekt hatte zwei geplante massive Refaktorierung (Erweiterungen) mitgemacht.

Und noch zur Klarstellung. Mein Agent arbeitet aber auch anders und ich würde mit Opus auch bessere Ergebnisse bekommen, als mit den Tools von Anthropic.
 
Wär mal schön wenn die Smartphone SoCs die gleiche Liebe bekommen und Android auch quelloffene GPU-Treiber als Standard hat.
 
Bei Smartphones und Tablets ergibt Linux endlich mal Sinn.
Hier könnte ich mir ein solches Produkt mit Linux durchaus vorstellen.
Das Problem mit den vorherigen Alternativen war eigentlich immer die Geschwindigkeit.
 
Bin sehr auf die Umsetzung gespannt :)
Könnte die Snapdragon Geräte tatsächlich deutlich interessanter für Arbeit machen, als es Windoof aktuell ist.
 
Zurück
Oben