Ubuntu-maker Canonical start samenwerking met Qualcomm

Qualcomm wordt onderdeel van het siliconpartnerprogramma van Canonical. Als onderdeel van de nieuwe samenwerking gaan de twee bedrijven samenwerken aan geoptimaliseerde versies van Ubuntu en Ubuntu Core voor processors van Qualcomm.

Canonical werkt in zijn siliconpartnerprogramma samen met diverse hardwarefabrikanten, waaronder MediaTek, Nvidia, AMD, Arm en Intel. Als onderdeel daarvan krijgen de partners toegang tot onder meer geoptimaliseerde versies van Ubuntu voor hun hardware, langdurige ondersteuning en referentiearchitectuur. Nu Qualcomm daar ook onderdeel van uitmaakt, komen er dus ook geoptimaliseerde versies van Ubuntu voor Qualcomm. De bedrijven spreken in een aankondiging bijvoorbeeld al over een geoptimaliseerde versie van Ubuntu voor Qualcomm IoT-chipsets.

De twee bedrijven zeggen zelf dat de samenwerking ervoor zorgt dat producten en apparaten sneller op de markt komen. Daarnaast zou er meer aandacht voor beveiliging komen met een 'security-first'-aanpak. Welke producten of apparaten de twee bedrijven precies gaan maken, is niet aangekondigd.

Reacties (26)

[vlaaing peerd]

Ehm, moet CPU support niet plaatsvinden op kernel niveau?

Afgezien daarvan interessant nieuws, ik zou graag meer hardware zien draaien op niet commerciele besturingssystemen die niet vanalles voor me willen bepalen en me het gevoel geven dat ik niet eigenaar van mijn hardware en OS ben.

[estej]

Canonical doet ook aardig wat kernel ontwikkeling (die weer upstream komt). Omdat ze er baat bij hebben dat het zo goed mogelijk werkt op zo veel mogelijk apparaten.

[2green]

Canonical heeft wel de neiging erg veel werk downstream te doen i.t.t. bijvoorbeeld Redhat die juist veel upstream werkt.

Zal proberen een recente discussie hierover opzoeken en hier plaatsen.

Edit: eerste hit op google, 3mnd oud.

[Reactie gewijzigd door 2green op 23 juli 2024 07:41]

[rob12424]

Qualcomm draagt volgens mij aardig wat bij op kernel niveau?

[2green]

Mijn kennis is mogelijk gedateerd, maar weet alleen dat zo snel je met Qualcomm te maken kreeg als Linux developer dat de kans dat je stack opensource bleef vrijwel nihil was. Maakt niet uit wat je deed. Bluetooth, sensors, complete socs, altijd ellende.

Je vraag triggerde mij en wat opgezocht. Lees dat er wel stappen worden gemaakt op met name desktop georiënteerde toepassingen. Maar eigenlijk nog helemaal zelfde.

Bron.

[rdk1980]

Zover downstream is het ook niet debian sid als devel base...heeft debian ook profijt van...anders dan manjaro downstream arch... Ubuntu kan je ook niet met rh vergelijken maar ze hebben ubuntu core met snaps in reguliere releases te ver doorgedrukt

[CAPSLOCK2000]

Als onderdeel daarvan krijgen de partners toegang tot onder meer geoptimaliseerde versies van Ubuntu voor hun hardware, langdurige ondersteuning en referentiearchitectuur.

Ik snap het niet, moet dat niet omgekeerd zijn?
Hoe komt Ubuntu aan geoptimaliseerde versies voor de hardware van de partner?
Wat voor langdurige hardwarespecifieke ondersteuning moet Ubuntu geven?

Is het niet zo dat de hardwarefabrikant ondersteuning aan Ubuntu gaat geven?
Zoals het leveren van drivers en documentatie?
Zoals het helpen optimaliseren van Ubuntu/Linux voor hun hardware?
Een referentiearchitectuur klinkt al helemaal als iets dat een hardwarefabrikant maakt, niet OS-leverancier.

Ik kan me wel voorstellen dat Ubuntu deze hardwarefabrikanten helpt met kennis van de Linux-kernel of het testen van hun onderdelen/drivers/integraties.


Zie dit aub niet als kritiek op het project zelf want dat is verder prima. Hardwareondersteuning wil je zo dicht mogelijk bij de bron doen, liefst direct door het bedrijf dat de basis-chips maakt zoals hier. Het model waarbij iedere eindfabrikant z'n eigen drivers maakt voor vrijwel identieke hardware past niet goed bij Linux (en werkt in het algeheel niet goed omdat het veel werk dupliceert).

Nu wordt het vaak opgelost doordat de eindfabrikant één keer een setje drivers voor Linux maakt op grond van referentiedrivers van de chipfabrikant en die dan nooit meer update en verwacht dat iedereen maar op een oude versie van LInux/Ubuntu blijft draaien zonder ooit te updaten. Sommigen houden dat jaren vol waardoor het OS al verouderd is op het moment dat je hardware nieuwe koopt. Erg zonde omdat die chips vaak door veel apparaten gedeeld worden die beter af zouden zijn als ze samen aan één goede driver werken.

Ubuntu lijkt hier te helpen om te zorgen dat die basis er is zodat al die eindfabrikanten niet zelf Ubuntu gaan zitten patchen met hun brakke drivers, maar dat je gewoon de normale versie van Ubuntu zelf kan gebruiken omdat de drivers er al in zitten (zoals gebruikelijk onder Linux).

[laurxp]

Programma's worden gecompileerd voor de grootste gemene deler. Als een programma moet draaien op een PC van 15 jaar oud, kan het op CPU-niveau geen gebruik maken van instructies die pas 2 jaar geleden uit zijn gekomen - de 15 jaar oude CPU zou dan namelijk crashen omdat hij niet weet wat hij er mee moet.

Ubuntu kan een gespecialiseerde versie maken door het hele OS te compileren voor een nieuwere CPU-generatie. Ook kan het programma's zo schrijven dat ze tijdens het draaien kijken welke CPU je gebruikt, en dan dynamisch CPU-specifieke versies van functie gebruiken.

Daarnaast is het buiten de x86-wereld van Intel en AMD erg lastig om een generieke "installatie-CD" te maken. Voor installatie heb je een apparaat-specifiek image nodig, dat de juiste hulpprogramma's en definities bevat om de hardware tijdens booten te configureren. Ook dit kan Ubuntu grotendeels op zich nemen: Qualcomm helpt eenmalig met het uitvogelen wat nodig is, en Ubuntu zorgt er voor dat er regelmatig een up-to-date installatie-image beschikbaar komt.

Tenslotte heeft Qualcomm wel veel hardware-kennis, maar relatief weinig Linux-kennis. Voor het schrijven van drivers is het daarom ideaal om samen te werken met een partij als Ubuntu. De drivers worden dan van veel hogere kwaliteit, en het is een stuk makkelijk om ze te upstreamen naar de Linux-kernel. Dit is iets waar Qualcomm traditioneel bijzonder slecht in is, dus hopelijk kan Ubuntu hierbij helpen.

[Bytebandit]

Qualcomm is niet bepaald het bedrijf dat ik associeer met fatsoenlijke drivers i.c.m. Linux. Momenteel best wel wat problemen op kantoor met een specifieke wifi chipset die in diverse moderne Thinkpads gebruikt wordt (bron: https://forums.lenovo.com...sassociations/m-p/5252399) Ik hoop dat het iets positiefs oplevert voor Linux maar eerst zien dan geloven.

[rubenbe]

Ik was recent ontgoocheld in de Xilinx variant. Uiteraard hadden we net een bord dat niet ondersteund was.
Maar blijkbaar kon je die met wat geknutsel toch laten starten. Maar IIRC bleef het root filesystem read only zonder verklaarbare reden.

Het grootste probleem is dat Ubuntu veel te complex is voor dit soort targets. Alles is custom dus je komt voortdurend incompatibiliteiten tegen met de hardware die je hebt. En Ubuntu maakt het gewoon heel erg complex om te debuggen. Een Yocto of Buildroot Linux is veel eenvoudiger te begrijpen, te debuggen en te patchen waar nodig.

FYI: https://xilinx-wiki.atlas...04+LTS+for+Xilinx+Devices

[bbstreams]

nu nog een samenwerking met apple, zodat je een volledige linux versie op apple silicon en iphones/ipads kan zetten.

[Bux666]

Verplaatst...

[Reactie gewijzigd door Bux666 op 23 juli 2024 07:41]

[devilkin]

-

[Reactie gewijzigd door devilkin op 23 juli 2024 07:41]

[OCU-Macs]

Canonical gaat op deze manier een beetje Apple achterna. Straks heb je een speciaal geoptimaliseerde Linux voor machines voorzien van Qualcomm hardware.

[Bux666]

Straks heb je een speciaal geoptimaliseerde Linux voor machines voorzien van Qualcomm hardware.

En dat is precies waarvoor die samenwerking bedoelt is.
Uit het artikel:

Canonical werkt in zijn siliconpartnerprogramma samen met diverse hardwarefabrikanten, [...]. Als onderdeel daarvan krijgen de partners toegang tot onder meer geoptimaliseerde versies van Ubuntu voor hun hardware, langdurige ondersteuning en referentiearchitectuur.

[youridv1]

Straks heb je een speciaal geoptimaliseerde Linux voor machines voorzien van Qualcomm hardware.

En dat is slecht omdat? Jij wil liever één generieke kernel zonder optimalisaties voor specifieke hardware? Zodat iedereen een slechte ervaring heeft?

Er zitten ook ontelbare optimalisaties voor AMD hardware in de kernel. Sterker nog, AMD hardware wordt in de regel native door de kernel ondersteund. Zelfs voor de videokaarten is geen losse driver nodig. Hoe is dit anders?

Of is dit nou gewoon een "boee qualcomm slecht" reactie?

[Reactie gewijzigd door youridv1 op 23 juli 2024 07:41]

[CAPSLOCK2000]

En dat is slecht omdat? Jij wil liever één generieke kernel zonder optimalisaties voor specifieke hardware? Zodat iedereen een slechte ervaring heeft?

Volgens mij is dat niet waar het om gaat. De huidige praktijk is dat sommige hardware fabrikanten zelf Linux optimaliseren maar die optimalisaties niet delen met de rest van de wereld als open source drivers.
Dat betekent dat je die hardware alleen kan gebruiken met de Linux-distro van de hardwarefabrikant en dat je voor upgrades (van alles, niet alleen die drivers) afhankelijk bent van die fabrikant.
Bij de wat kleinere fabrikanten is het niet ongebruikelijk dat je wordt afgescheept met link naar een iso op Google drive die nooit wordt bijgewerkt.

AMD doet het wel goed. AMD werkt direct met de Linux-kernel samen en zorgt dat "officiele" Linux-kernel alle drivers en optimalisaties bevat. Iedereen die (software voor) apparaten bouwt met een AMD-processor kan daar gebruik van maken.

[youridv1]

Ik neem aan dat het werk wat canonical met qualcomm gaat doen wel in de upstream belandt. Canonical draagt in ieder geval tot nog toe een hoop bij.

[rbr320]

Ik neem aan dat het werk wat canonical met qualcomm gaat doen wel in de upstream belandt.

Assumptions are the mother of all fuck-ups.

In dit geval ga ik er ook wel vanuit dat het werk wat Canonical en Qualcomm hiermee gaan verzetten uiteindelijk upstream beland, maar Canonical heeft niet echt een vlekkeloze reputatie als het gaat om hun werk netjes open source houden en samen werken met de community.

[Xander2]

En dat is slecht omdat? Jij wil liever één generieke kernel zonder optimalisaties voor specifieke hardware? Zodat iedereen een slechte ervaring heeft?

Dat is slecht omdat het uitstekend werkt drivers te mainlinen in plaats van een kernel tree te customizen met geheugen en subsystem hacks om te optimaliseren, een bron van ellende voor security en problematisch om security patches door te voeren.

AMD hardware wordt gemainlined, ergo, als de code zich niet aan de spelregels houdt wordt daar iets mee gedaan.

Als consument wil ik langdurige ondersteuning voor meerdere versies met snelle security fixes, niet een door Qualcomm/Ubuntu gemaintainde kernelbranch. Er werken veel meer kerneldevelopers op mainline dan Ubuntu zich ooit kan veroorloven en die kosten gaan ze niet langdurig opbrengen. Het succes van Linux is omdat optimalisatie nooit een probleem is geweest.

Dit gedrag speelt bij meerdere chipfabrikanten, custom trees, versiehernummering etc. wat eigenlijk neerkomt op een blob omdat de aanpassingen vaak ingrijpend zijn en amper te volgen.

[OCU-Macs]

[...]

En dat is slecht omdat?

Of is dit nou gewoon een "boee qualcomm slecht" reactie?

Ho! Even de rem erop.

Vertel mij eens waar ik zeg dat dit een slechte ontwikkeling is?

Het was gewoon een constatering. Ik begrijp werkelijk niet waar je deze emotie uit haalt.

Edit: Overigens ben ik zelf Apple gebruiker. Zowel privé als zakelijk.

[Reactie gewijzigd door OCU-Macs op 23 juli 2024 07:41]

[youridv1]

ach zo, mijn fout

[disjfa]

Zeg maar hetzelfde als dat microsoft net gedaan heeft waar de Snapdragon X Elite uit is komen rollen.

Dus het lijkt me geen slechte keuze om linux ook erbij op in te laten spelen.

[downtime]

Dat is toch goed? Zolang die "optimalisaties" maar open source zijn kan iedere andere distro die ook gebruiken. Maar die lopen dan misschien net een release achter op Ubuntu. Daar is mee te leven.

[PrimusIP]

Niet verkeerd toch, een geoptimaliseerde versie? Heb je volgens mij nu ook al, geoptimiseerde versies voor bepaald gebruik (privacy, servers, pentesting), bepaalde filosofie (alleen open source spul willen), verschillende interfaces en verschillende hardware (X86 en ARM versies, of voor oude hardware/lage performance).