Asahi Linux krijgt DP Alt Mode en DirectX 12 in 2025, oprichter vertrekt

Het ontwikkelaarsteam achter Asahi Linux breidt uit met zeven nieuwe personen. Wel vertrekt oprichter marcan. De ontwikkelaars willen in 2025 onder andere DisplayPort Alt Mode en ondersteuning voor DirectX12 en interne microfoons implementeren in de Linux-distro.

De ontwikkelaars van Asahi Linux, een distro specifiek gebouwd voor Apple-apparaten met M-socs, verwachten in 2025 ondersteuning voor DP Alt Mode voor de distro uit te kunnen brengen. Dat gebeurt in ieder geval voor apparaten die op een M1- of M2-soc draaien. Met DP Alt Mode is het mogelijk externe monitors via USB-C aan te sluiten op oudere MacBooks die op het OS draaien.

De makers willen verder in 2025 ook DirectX 12-ondersteuning mogelijk maken. Op het moment ondersteunt de Vulkan-driver die de ontwikkelaars gebruiken alleen DirectX 11, maar de ontwikkelaars willen dat verbeteren.

Tot slot willen de ontwikkelaars ondersteuning bieden voor de interne microfoon van MacBooks. Nu ondersteunt Asahi alleen externe microfoons via de 3,5mm-poort, maar nog geen interne. Volgens de ontwikkelaars is dat lastig, omdat de microfoon op kernelniveau toegang nodig heeft tot meerdere hardwaresystemen in de pc, waaronder de Secure Enclave en de always-onprocessor.

De ontwikkelaars zeggen zich verder te willen richten op kernelupstreaming. In de downstream van Asahi zitten inmiddels meer dan duizend patches, zeggen de ontwikkelaars, die allemaal nog in de Linux-upstream moeten worden geïntegreerd. De makers willen daarom eerst werken aan het wegwerken van die patches.

Ook wil het Asahi-team het testproces verbeteren door een proces van continuous integration te implementeren. Daarmee hopen de makers een duurzamere oplossing te vinden om het project op de lange termijn te kunnen ondersteunen.

Het opzetten van een upstreaming- en een CI-proces krijgt prioriteit in het komende jaar, zeggen de makers, naast de eerdergenoemde nieuwe features. Dat betekent echter wel dat er voorlopig geen werk wordt verricht aan compatibiliteit voor de M3- en M4-processors. "Wel zijn sommige communityleden al bezig met het reverse-engineeren ter voorbereiding voor als de basis straks staat", zeggen de ontwikkelaars.

Oprichter vertrekt

De oprichter van Asahi Linux, Hector Martin, vertrekt bij het project. In een persoonlijke blogpost laat hij weten dat hij graag meer tijd over wil houden. Het ontwikkelen van Asahi en het leiden van het team kosten nu veel tijd, zegt Martin. Wel breidt de rest van het ontwikkelteam uit. Er komen zeven personen bij, waaronder drie kernelontwikkelaars. Ook gaan twee ontwikkelaars zich bezig houden met de Fedora Asahi-variant van het OS en komt er een audio- en een grafisch ontwikkelaar bij het team.

Reacties (40)

[HollowGamer]

Hij vertrekt omdat Rust schijnbaar een heel erg issue is voor hem.

Ben geen C developer, maar ik snap echt niet wat het probleem is bij Rust. Alles lijkt juist gemaakt te zijn voor jouw als programmeur.

Maar goed, ook genoeg die niet houden van verandering.

Edit: dank voor de correcties. Ik dacht namelijk dat hij juist tegen Rust in de kernel was. Heb er filmpjes over gezien (in het algemeen), en ik zag vooral mensen die niets constructief wilde, maar vooral echt geen verandering of iets anders wilde.

[Reactie gewijzigd door HollowGamer op 14 februari 2025 17:08]

[MaestroMaus]

Als je zijn post leest dan zie je dan burnout de hoofdoorzaak is. En die is mede veroorzaakt doordat hij:

• Hij het moeilijk vindt om zijn privétijd en zijn werktijd af te grenzen. Dit komt doordat het ook zijn hobby is. Dit werd erger doordat hij onverwacht aan het begin van het jaar veel tijd aan privézaken heeft moeten wijden. Daardoor heeft hij een schuldgevoel; mensen doneren immers geld zodat hij software kan ontwikkelen.
• Hij zich niet gerespecteerd voelt door de gebruikers (veel negatieve reacties over kleine dingen die niet werken en veel gebruikers die onrealistische eisen stellen).
• Hij vindt dat hij niet goed behandeld is door verschillende mensen die de Linux kernel onderhouden

Van wat ik inmiddels gelezen heb, is er ook een goede reden waarom de maintainers van de Linux kernel rust niet verder willen integreren in het project. Het wordt dan een multi-language project waardoor het lastiger wordt om te onderhouden. Zij kennen immers Rust niet maar moeten wel bij ernstige situaties ingrijpen. Iets wat, denk ik, fair is.

[Reactie gewijzigd door MaestroMaus op 14 februari 2025 16:50]

[GertMenkel]

Hoewel de technische reden gegrond zou kunnen zijn, is de manier waarop dit gebeurt nou niet echt op technische basis gestoeld. Bij de druppel die deze emmer deed overlopen is het aanbod om anderen de Rust-wrappers te laten onderhouden is afgeschoten, en de voorgestelde "oplossing" was om alle Rust-drivers dezelfde code te laten copy/pasten voor hun eigen gebruik. Iedere programmeur zal zich hopelijk realiseren dat dat geen goede aanpak is.

Daarnaast zit Rust al in de kernel op dit moment (al is het uit te schakelen als je dat wilt). Zelfs als de C-maintainers Rust uit hun "gebied" houden, introduceren ze met wijzigingen compiler errors. De insteek die deze mensen willen houden is "ik vind het geen probleem als de Rust-code stopt met werken, die zet ik namelijk altijd uit" maar dat is natuurlijk geen manier van werken: op diezelfde manier zou je ook kunnen zeggen "het maakt me niet uit als de SATA-driver niet compileert, die zet ik altijd uit". Zelfs als je niet weet hoe de SATA-code werkt, zou je bij je codewijzigingen de compiler error moeten fixen, of hulp inroepen van mensen die de fix kunnen maken.

Sterker nog, in de mailuitwisseling werd door gregkh (een hoge pief voor zover Linux die heeft) gesuggereerd om de NACK van de C-maintainer te negeren en "volgens de policies van het rust voor Linux project" de code alsnog te mergen, met de implicatie dat een hoge maintainer het merge request voor zijn neus krijgt en de keuzes van de maintainer die er een probleem mee had overrulet.

De crux van het probleem zit hem in het feit dat sommige mensen Rust in de kernel willen en sommige niet. In de ruzie die daarover ontstaat worden een hele hoop persoonlijke opvattingen verhuld met technische argumenten, maar ik vind die technische argumenten maar altijd matig relevant. Uiteindelijk komt het neer op "ik wil" versus "ik wil niet", en wat mij betreft faalt de top van Linux momenteel in het afhandelen van deze ruzie. Zolang de top geen duidelijk "rust gaat erin" of "rust gaat eruit" aankondigt, blijft het hele project ruzie en drama aantrekken.

Ik denk dat alle andere redenen om te stoppen ook bij veel andere projecten zullen spelen, maar het "rust vs Linux" verhaal voegt extra stresspunten toe vanuit de hoek waar je eigenlijk steun en begrip zou moeten verwachten.

[Neophyte808]

Zolang de top geen duidelijk "Rust gaat erin" of "Rust gaat eruit" aankondigt, blijft het hele project ruzie en drama aantrekken.

Zo lang de ruzie aan houdt, zou je kunnen stellen dat er geen rust in komt.

[GertMenkel]

Nou ja, dat is het dus. Het zit al in de mainlinekernel. Het feit dat de "top" van Linux deze code wel geaccepteerd heeft terwijl er nog zo'n ruzie is, is waar dit echt fout lijkt te gaan.

[Neophyte808]

Ik bedoelde rust zonder de hoofdletter

[GertMenkel]

Gelukkig is het weekend, ik heb duidelijk m'n eigen rust nodig.

[bzuidgeest]

Het wordt dan een multi-language project waardoor het lastiger wordt om te onderhouden.

Als je ooit vooruit wil komen dan moet dat juist. Je kan in C blijven hangen, maar Rust heeft veel voordelen. De kernel volledig opnieuw schrijven is geen optie. Dus moest het erbij komen.
Er is ook geen reden dat ze in moeten grijpen als er iets mis is. Dat kunnen ze aan de kernel Rust community vragen. Er word ook tooling ingezet om de nodig bindings automatisch te genereren.

Voor wat ik lees had die Hector behoorlijke issues. Hij nam aanstoot aan opmerkingen waar ik en anderen na een uur googlen nog niet achter zijn wat het probleem er mee is. Blijkbaar mag je geen "thin blue line" zeggen of zo. Maar volgens het internet is het gewoon een verwijzing naar politiemachten in het algemeen en niet aanstootgevend. En elk groot project heeft mensen met verantwoordelijkheden en die zijn automatisch een soort agent door hun positie.

[jbhc]

Persoonlijk vind ik linux (Mint) een top programma.

Ik gebruik het al jaren naar volle tevredenheid, ik vind het namelijk heerlijk om de volledige controle te hebben over mijn computer en na een jaartje Debian ben ik toch weer terug bij Mint.

[goarilla]

Ja het is een dramafest daar in kerneland. Raar wel want toen rust in de kernel kwam waren we allebei denk ik wel blij dat dat kon. Dat er een 2de programmeertaal kon gebruikt worden. Ik weet niet wat ik er nu
van moet denken. Soms ketsen ze dingen af die je toch doen afvragen waarom ze een 2de taal hebben toegelaten dan in de eerste plaats. Voor de prestige, voor het vinkje ?

[HollowGamer]

Ik ben geen C developer, maar wat ik heb begrepen is dat Rust veel voordelen heeft t.o.v. 'klassiek' C/C++.

Het is niet zozeer dat het memory lekken voorkomt, maar het helpt je bij het tegengaan van fouten maken ervan.
Ik vergelijk het als webdeveloper met TypeScript. Ja, het is een extra laag die erboven op komt (interfaces, types, etc.). Sommige vinden die laag overbodig en veel gedoe, maar hoe meer je ermee werkt, hoe meer je begrijpt dat het voorkomt dat je bijvoorbeeld iets doet dat niet mag of later fout kan gaan. Je kan die overrulen (any, unknown, etc.), maar dan heb je weinig(er) aan TS.

Wat ik heb gelezen over Rust vs C in de kernel, is dat veel developers Rust te veel gedoe vinden. Je moet een interface bouwen, je moet X doen, je moet het via Y doen, etc. Dat terwijl het dus, zeker op kernel niveau, veel toevoegt als je samenwerkt met andere/onbekenden. Je weet zeker dat module args X enkel een number kan zijn, en niet een string. Het heeft dus in security context ook veel voordelen, en voor mensen die je code niet kennen, ook voordelen in wat ze kunnen verwachten (ongeveer).

De filmpjes die ik heb gezien op YT over mannen die als een Trump/Wilders gingen roepen dat het enkel werkt oplevert en dat 'ze' extra werk moeten doen, was echt heel wazig om te zien. Het brengt allemaal voordelen, het werkt samen met C (je hoeft bestaande code niet perse te vervangen), en het enige dat de Rust developers (soms) vragen zijn bindings (een API) tussen die twee.

Developers zijn rare mensen (me to), maar wat ik zo lees en zie, is dat er voor hun 5% max. veranderd aan hun workflow. Of als zij het niet willen doen, de Rust-developers vragen hebben, maar die nog niet eens worden beantwoord of ze op social media worden lastiggevallen. Er zitten ook andere stuff in de kernel, zoals Python bijvoorbeeld. Daar is dan minder moeite mee?

Mijn verwachting is dat er een split gaat komen met de huidige kernel. Mensen die het zo willen houden, en andere die meer richting Rust willen. Het is eigenlijk wachten op een groot bedrijf (Google, Mozilla (tja wat er nog van over is), Red Hat/IBM, etc.) die de kernel gaat forken.

[Reactie gewijzigd door HollowGamer op 15 februari 2025 10:43]

[Ablaze]

Rust is inderdaad veiliger, maar ook wat omslachtiger, zeker als je low level aan het programmeren bent. En er zitten veel ontwerpprincipes in die C/C++ programmeurs standaard niet kennen.

De vraag is of het wel zo'n goed idee is om een tweede taal te gaan ondersteunen en de mentale overhead voor programmeurs te vergroten, terwijl je aan de andere kant de komst van de AI hebt, waarmee bugs in "onveilige" talen zelfs al voor een compilatie automatisch gevonden kunnen worden.

[goarilla]

De vraag is of het wel zo'n goed idee is om een tweede taal te gaan ondersteunen en de mentale overhead voor programmeurs te vergroten, terwijl je aan de andere kant de komst van de AI hebt, waarmee bugs in "onveilige" talen zelfs al voor een compilatie automatisch gevonden kunnen worden.

Mja ... ze zitten daar toch ook al met de C Preprocessor die ze (te) uitgebreid gebruiken - serieus het is praktisch een eigen minitaal hoe ze het gebruiken daar - en daarnaast heb je misschien ook maar dat weet ik zo niet zeker m4 macro's. En AI wel ... dat zal zeker en vast beter en belangrijker grondiger de (simpele/gekende) fouten eruit kunnen filteren op korte termijn, waarschijnlijk nu al, maar ik zou daar toch de bank niet op willen gokken, zeker voor subtiele runtime bugs. En wanneer dat niet gebruiken om ook de rust interfaces niet te controleren als ze dat dan zo belangrijk vinden.

[bzuidgeest]

Omdat sommige mensen beseffen dat je soms een moeilijke stap moet zetten om bij te kunnen blijven. Rust heeft grote voordelen. De kernel opnieuw schrijven als een los project is niet echt een optie. Dus dit is de beste tussen optie. Langzaam meer in rust geschreven subsystemen toevoegen. De memory safety van Rus is vele malen beter dan die van C. En dat is belangrijk in een wereld van exploits die allemaal voorkomen uit memory leaks en andere C foutjes.

[goarilla]

Ja en dat besef ik en was niet het punt wat ik wou maken. Ik wil eigenlijk gewoon zeggen dat Rust in de kernel nooit de aandacht heeft gekregen van de echte stakeholders en het lijkt of het wel op de vine moest sterven. Als ik zie hoe het behandelt werd en wordt. En dat ik vind ik spijtig want we waren allemaal enorm blij dat er een 2de taal bijkwam alhoewel ik helemaal niet wist toen wat "memory safeness" ook maar was (niet dat er zoveel verandert is op dat front ). Maar het was iets nieuw - een major bulletpoint op de kernel ChangeLog. Zoals de introductie van een compleet nieuw filesystem, task scheduler, IO elevator, etc ...

[bzuidgeest]

Ik denk dat er veel mensen best zullen begrijpen waar de verandering vandaan komt en waarom het gebeurd. Maar veel mensen zijn ook terecht wat terughoudend en voorzichtig. Het is natuurlijk nog al wat zo een aanpassing.
En er zijn mensen die bang zijn dat ze obsolete worden of ineens hun C code ongewenst is, of ouderwets of wat dan ook. Terecht of onterecht. Dit ging altijd een moeilijke transitie worden. Dat zijn dit soort dingen overal. Als de rust ontwikkelaars daar niet op voorbereid waren of van schrikken, dan hebben ze zich niet goed voorbereid. Zover ik kan zien is Linus een voorstander, dus met geduld en goede technische discussie en ondersteuning van de oude garde komt het er uiteindelijk wel denk ik.

Met roepen op social media dat de "oude.,... allemaal tegen je zijn" is niet de oplossing. En als ik het goed lees is dat waar linus, hector over terecht wees. Geen "politiek" in de kernel. (voor zover iets zonder politiek kan zijn)

[Reactie gewijzigd door bzuidgeest op 17 februari 2025 11:46]

[goarilla]

Denk jij dat dit de nieuwe garde vs de oude is met verzieking aan beide kanten of is er iets fundamenteel mis met de nieuwe garde (waaronder ik mijzelf in mijn 40ste levensjaar ook wel onder schaar) want ook BcacheFS was een dramafest dat na 10 jaar eigenlijk niets heeft opgebracht en BTRFS is nog altijd geen ZFS (zelfs geen raid5/raidz alternatief) maar zit er wel nog in.

[bzuidgeest]

Denk jij dat dit de nieuwe garde vs de oude is met verzieking aan beide kanten of is er iets fundamenteel mis met de nieuwe garde

Jeetje wat een moeilijke vraag. Ik verdiep me niet in alles rond de kernel. Ik ben geen kernel dev. Maar ik lees wel eens wat verder dan het nieuwsbericht met soaps als deze om een betere mening te kunnen vormen. De kernel is uiteindelijk heel belangrijk voor onze samenleving vind ik. "Alles" draait linux, van je koelkast tot auto tot in kleiner percentage desktop, groter percentage super computer.
Ik heb deze gelezen en zie eigenlijk het probleem van hector niet echt. Dus stel ik hier vragen en deel mijn observaties.

Ik denk dat het niets zo simpels is als oud tegen nieuw. Ik denk dat het grote probleem gebrekkige communicatie is. En dat is niet ongewoon bij developers. En misschien wat gebrek aan begrip aan beide kanten (en dat begrip gebrek verschilt van persoon tot persoon).
Het is ook nog eens een internationale omgeving, dus iets wat iemand in zeg maar Turkije heel normaal vind om te zeggen kan in vertaling heel rot overkomen. Dus dat is ook al een hindernis. Dat zie je ook in Youtube comments bijvoorbeeld. Aanstoot nemen aan van alles, zonder na te denken over of de ander wel in dezelfde context zit....

Dan heb je dus een enthousiaste club die vol energie Rust in de kernel wil hebben en daarnaast een stel mensen die nieuwe code en mogelijkheden ook wel leuk vind, maar tegelijk ook alle andere belangen van stabiliteit en ondersteunbaarheid etc etc in de gaten moet houden. En ja daar zitten terecht ook bedrijfsbelangen bij in. De hele wereld draait linux. Het is geen hobby project meer. Ik zeg hiermee niet dat de Rust code, hobby code is (hopelijk lees je zo ver ). Ik onderstreep het belang van de kernel hiermee. Maar het is het nieuw is en dat is "eng". Dan komen er vragen als "kan ik als C dev meekomen", "kan ik dit onderhouden". Of "ik zit hier al 20 jaar en ik ga er nog eens 20 jaar zijn.... gaat die "nieuwe dat ook doen of zit ik morgen met zijn werk". En ga zo maar door.

Zelfs al zijn de zorgen van de oude garde niet legitiem, dat is nog niet bewezen en dat de zorg niet legitiem is, betekend ook niet dat de zorg niet gevoeld word. Dus je zal er iets mee moeten. Meestal praten tot je er bij neervalt en geduld. Het is niet anders.

Dit is overigens niet allemaal uniek aan de linux kernel ontwikkeling. Je kan dit vinden in elk ontwikkelteam van een ouder product. Daarom is het ook voor mij als iemand die niet aan zoiets als de kernel werkt goed te begrijpen en herkennen. Ladingen intelligente mensen, verschillende visies, conflicterende belangen, hoge prestatie druk en enorm complexe code.

Als er niet af en toe wat ontplofte zou ik verbaasd zijn. Dat is niet erg. Verandering, heroriëntatie, herevaluatie. Dat maakt een gezond project.

edit: Het enige wat echt slecht is, is mensen dwingen geforceerd in een soort communicatie keurslijf te gaan. Beter een ontploffing en weten waar het zeerdoet dan een zweer onder de oppervlakte.

[Reactie gewijzigd door bzuidgeest op 17 februari 2025 14:27]

[GertMenkel]

Ik denk dat je dat verkeerd om hebt. Hij vertrekt omdat diverse Linux-maintainers zo hard mogelijk hun best doen om Rust uit Linux te houden, terwijl Rust een van de speerpunten is geweest van het Asahi-project. Dat heeft in het verleden al vaker tot opstootjes geleid (bij diverse leden van het Asahi-team en diverse Linux-maintainers) maar het laatste opstootje ging gepaard met wat drama op sociale media.

Er speelt natuurlijk ook meer mee, hij heeft een uitgebreide blogpost geschreven over de redenen voor zijn vertrek. Maar als er iemand juist voor Rust in de kernel is, is het Hector Martin wel.

[bzuidgeest]

Elke vernieuwing van deze vorm levert altijd issues. Dat is niet te vermijden. Dat had hij gewoon moeten beseffen. De verwachting dat niemand zou klagen, of dat er geen verzet zou zijn is volledig onrealistisch van die man. Zo werken mensen niet. Hij nam voor wat ik lees ook aanstoot aan het minste en geringste. Opmerkingen waar je met de beste wil van de wereld geen problemen in kan zien vond hij problematisch.
Hij had ook verkeerde verwachtingen van Linus (alhoewel dat stuk verwarrend is voor mij).

Van zijn blogpost kreeg ik niet de indruk dat ik veel sympathie zou hebben voor deze persoon. Mogelijk is het omdat hij een burn-out heeft.

[roelboel]

Als ik het goed lees is het precies andersom: hij voor Rust, sommige anderen tegen.

[ManIkWeet]

Het probleem is onderhoud van Rust in de kernel, zo schijnt. Korte termijn kan je wel beloftes maken dat je alle Rust dingen netjes onderhoud geeft. Maar lange termijn? Dan vallen mensen weg, en moeten de andere onderhouders opeens alsnog Rust leren.

[bzuidgeest]

Er komen ook weer Rust mensen bij. Lange termijn is nooit zeker. Wel zeker is dat de markt richting Rust gaat en weg van C. Rust heeft voordelen en is gewoon doorgaans veiliger dan C. Minder kans op foutjes.

[ZinloosGeweldig]

Hij heeft problemen met de gang van zaken in het Rust for Linux project, niet met het doel van dat project of met de programmeertaal Rust.

[Hawkysoft]

Rust doet veel voor je, maar als je goed kan ontwikkelen (wat wel meer tijd vergt trouwens ook) is c, c++ vele malen beter. En als je gaat focussen op de echte performance, kan je meer doen met een c++ dan met Rust. Kortom, ja het is een mooie taal maar ik zie het persoonlijk meer als een c# variant, leuk om iets snel te bouwen maar als het echt om performance gaat toch liever naar de oudere talen.

[Mijzelf]

DirectX 12? Dat is toch een Windows API? Heeft Linux daar tegenwoordig ook ondersteuning voor?

[Soldaatje]

Jazeker! Met de Vkd3d api, deze lijkt op de Direct3D 12 api en vertaalt naar Vulkan. Ik denk dat al het twee a drie jaar goed bruikbaar is maar dit kan per spel verschillen.
DP Alt mode werkt trouwens ook al een aantal jaar op de x86 Linux.

[MaestroMaus]

Via Proton kun je DirectX 12 calls omzetten naar Vulcan API calls.

[GertMenkel]

Microsoft heeft een driver die een kleine set DirectX-API's aanbied binnen WSL, maar dat was het dan wel.

De manier waarop je op Linux (of op Windows, bij Intel Alchemist) meestal DirectX-software draait is door middel van DXVK of soortgelijke wrappers. Deze vertalen de method calls voor DirectX naar Vulkan of misschien OpenCL.

Wil je DirectX 12 ondersteunen op Linux, dan moet je GPU-driver ook de nodige API's dekken zodat die vertaalslag mogelijk is. Aangezien ze bij Asahi met veel succes de GPU-driver hebben geschreven (hun driver is OpenGL-compliant, in tegenstelling tot die van Apple op macOS!) vermoed ik dat het hier gaat om het toevoegen van de nodige Vulkan-API's die het mogelijk maakt om met DXVK spellen op basis van DirectX 12 te spelen.

[goarilla]

Wine heeft onlangs een driver in de kernel gekregen (ntsync) die NT -> Linux syscall translatie sneller moet maken door het in de kernel te steken ipv de job over te laten aan een single threaded user-space RPC server (wineserver). Want dat begon een serieuze bottleneck te worden.

[NESFreak]

Hector Martin was recent nog bij wat rust for linux drama betrokken. Veel van het werk wat asahi doet word in rust geschreven, en een paar kernel maintainers lijken actief ervoor te zorgen dat er geen rust code in de kernel komt. Het drama wat daaruit volgde zorgde ervoor dat Martin zich al eerder terugtrok als kernel maintainer.

YouTube: Rust Is Splitting The Linux Kernel In Half

[goarilla]

Ja en ik begrijp het niet. Iedere rust driver moet zijn eigen C API wrappers hebben en niet een universele C API rust wrapper ? Je mag geen code hergebruiken of een subsystem bouwen waar de C API wordt gewrapped voor rust en in dit geval maar 1 deeltje van rust dacht ik (dma) ? Is dat nu net niet wat je wilt ? Modulaire en maintainbare code ipv dat iedere kernel Rust dev zich moet bezig houden met het copy pasten van de meest capabele wrapper met de juiste license waar hij weet van heeft of het zelf doen. Ik ben geen programmeur, maar ik snap het echt niet. Is dat geen "Clean Code" principe of 2-3.

[bzuidgeest]

De rust developers voor de kernel moeten zich (en zullen dat meest wel) realiseren dat het een uphill battle is. Ze zullen in de komende jaren voorzichtig moeten laten zien dat het iets is waar op gebouwd kan worden en dat ze er zijn om te helpen onderhouden.

Jij er zijn developers met sociale issues. Maar als developer kan ik wel stellen dat dit niet bepaald ongewoon is in het vak. Er zit gewoon veel behoudende mensen en sterke opinie en dat botst. En als je dan als die hector ineens overal een belediging in gaat zien hou je het niet lang vol.

Rust in de kernel is gewoon ook politiek bedrijven, niet iedereen is daar goed in. Dat is niet uniek aan de kernel. En vergeet niet kernel developers zitten in alle landen en spreken alle talen, dus in een vertaling gaat wel eens wat verloren. Je moet voorzichtig zijn met belediging zien, waar eigenlijk gewoon ongelukkige vertaling staat.

Hector nam bijvoorbeeld aanstoot aan een opmerking met "thin blue line" erin. Ik kan echter de reden niet vinden. En de post waar het instond was niets bijzonders mee. Het verwees gewoon naar dat er een groep is die beslist wat wel en niet in de kernel komt, en dat er ergens een eindbeslissing moet worden gemaakt is niet meer dan logisch.

[Ebbez]

Hector nam bijvoorbeeld aanstoot aan een opmerking met "thin blue line" erin. Ik kan echter de reden niet vinden. En de post waar het instond was niets bijzonders mee. Het verwees gewoon naar dat er een groep is die beslist wat wel en niet in de kernel komt, en dat er ergens een eindbeslissing moet worden gemaakt is niet meer dan logisch.

Geloof dat dat niet Hector Martin was maar Karol Herbst, een maintainer van Nouveau (open-source Nvidia driver voor Mesa) en Rusticl (Rust OpenCL driver).

https://lists.freedesktop...2025-February/046677.html

De rust developers voor de kernel moeten zich (en zullen dat meest wel) realiseren dat het een uphill battle is. Ze zullen in de komende jaren voorzichtig moeten laten zien dat het iets is waar op gebouwd kan worden en dat ze er zijn om te helpen onderhouden.

Eens. Het is alleen wel vervelend dat er al vrij veel downstream is, maar dat er verder weinig animo is om het upstream op te nemen ookal is het al wel in de downstream 'bewezen'. Verder is het ook erg demotiverend als de head maintainer al zegt alles te willen gaan doen om Rust in de kernel te voorkomen, en lijkt er van geen ene kant een toezegging op gedaan te willen worden. Het is begrijpelijk, maar dan hadden ze misschien toch eigenlijk niet Rust for Linux moeten accepteren. Lijkt me erg frustrerend als er al enorm veel werk in heeft gezeten terwijl de head maintainer pas op het laatste moment NACKed.

[bzuidgeest]

Geloof dat dat niet Hector Martin was maar Karol Herbst, ee

Je hebt gelijk. Het is soms een hoop gedoe om het allemaal goed te onthouden.

e head maintainer al zegt alles te willen gaan doen om Rust in de kernel te voorkomen,

Die is niet in zijn eentje de baas. Voor zover ik begrijp is torvald een voorstander van Rust, dus uiteindelijk komt er wat door en van daaruit verder.

Torvald op een vraag over de "head maintainer"
Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve.

Die head maintainer is niet de baas in zijn eentje en gaat er niet eeuwig zijn. Dit is politiek en frusterend voor die Rust programmeurs. Maar het is ook onvermijdelijk dat dit proces er bij hoort.

[Ariejan]

Jammer dat het sceenshot prominent Arch laat zien. Vorig jaar is Asahi overgestapt op Fedora als basis.

Hier overigens mijn persoonlijke ervaringen met Asahi op 'n M1 Max MacBook Pro: https://www.devroom.io/tags/asahi/

[Reactie gewijzigd door Ariejan op 14 februari 2025 17:17]

[RGort10]

Het is jammer om te zien dat zo’n prominente developer weg gaat. Het is wel belangrijk om te melden dat de 7 mensen die het project nu gaan leiden niet nieuw zijn maar al zeer lang met het project betrokken zijn.

[bzuidgeest]

Prominente of luide? Er is een verschil

[RGort10]

Prominente. Een paar zijn bijvoorbeeld voor een groot deel verantwoordelijk voor de implementatie van de mesa driver en audio driver. (En nog wel meer)