Hoofdontwikkelaar bevestigt dat Rust-ondersteuning in Linux-kernel definitief is

De Rust-code in de Linux-kernel is een blijvertje, laat de hoofdontwikkelaar van het project weten. In 2022 werd Rust al toegevoegd aan de kernel, maar tot dusver was de ondersteuning van deze veiligere programmeertaal nog experimenteel.

De hoofdontwikkelaar van het Rust for Linux-project, Miguel Ojeda, laat weten dat het experiment is voltooid en dat de programmeertaal blijvend wordt toegevoegd aan de Linux-kernel. Hij vraagt andere kernelontwikkelaars om in de documentatie te verwijderen dat de toevoeging van de programmeertaal experimenteel is.

Hij hoopt naar eigen zeggen dat bedrijven en andere partijen nu meer gaan investeren in Rust-ontwikkeling. Hoewel het experiment is voltooid, betekent dat niet dat de werkzaamheden erop zitten. Rust werkt volgens Ojeda bijvoorbeeld nog niet voor iedere kernelconfiguratie en -architectuur.

Ojeda werkt sinds 2021 fulltime aan het Rust for Linux-project. Het ontwikkelteam wilde zorgen voor betere geheugenbeveiliging in de Linux-kernel door het mogelijk te maken om Linux-kernelmodules in Rust te ontwikkelen. De oorspronkelijke programmeertaal, C, heeft namelijk te maken met geheugenkwetsbaarheden.

In versie 6.1 van de Linux-kernel, die in december 2022 werd uitgebracht, werd er voor het eerst ondersteuning geboden voor Rust. Destijds zei Ojeda dat als het gebruik van Rust toch niet blijkt te werken, de ondersteuning zo weer weggehaald kan worden. Sindsdien is de Rust-ondersteuning geleidelijk uitgebreid. Zo wordt momenteel gewerkt aan de op Rust gebaseerde Nova-driver, waarmee Linux-besturingssystemen in de toekomst moderne Nvidia-gpu's beter kunnen ondersteunen.

Reacties (42)

[CloudPrutser]

Rust is de eerste serieuze programmeertaal in decennia die systems programming fundamenteel opnieuw heeft doordacht. Het combineert low-level controle met sterke veiligheids­garanties, zonder concessies te doen aan performance — een combinatie die lange tijd als onmogelijk werd gezien.

Die aanpak blijft niet onopgemerkt. Rust heeft inmiddels officieel zijn intrede gedaan in de Linux-kernel. C++ daarentegen? Dat is daar nooit toegestaan geweest. Alleen dat feit zegt al genoeg over de technische en filosofische impact van Rust.

Steeds meer toonaangevende techbedrijven kiezen Rust voor nieuwe projecten. Niet alleen vanwege memory safety en betrouwbaarheid, maar ook vanuit een langetermijnvisie: onderhoudbaarheid, voorspelbaarheid en toekomstbestendigheid worden steeds belangrijker in complexe systemen.

Rust voelt daarmee niet als “de volgende taal”, maar als een koerswijziging voor systems programming zelf.

En ja — voor sommigen voelt dat bijna als een geloofsafval.

[Powerblast]

Dat is het verkoopspraatje inderdaad. Of Rust op lange termijn een blijvertje valt nog te bekijken. Versta me niet verkeerd, ik zie er zeker de voordelen van en ben daarom ook fan. Maar of het op termijn goed onderhoudbaar blijft kan nog niemand voorspellen. Daar is de taal te jong voor.

Ik blijf het wel veel lastiger vinden om goed de cpu commandos te volgen tegenover iets zoals C. Gewoonweg omdat het een laat abstractie er bovenop legt.

[Reactie gewijzigd door Powerblast op 13 december 2025 12:32]

[Stetsed]

Wat bedoel je met "Om goed de CPU commandos te volgen", rust maakt vaak gebruik van 0 cost abstracties, dit betekent dat wanneer het naar assembly code wordt omgezet dat het juist weinig abstractie laag er boven op heeft.

Dit is juist waarom het voordelen heeft want het kan veel van de fijn heden geven maar veel worden weg gehaald na compilatie wat betekent dat het sneller kan zijn, en omdat de compiler veel extra informatie wordt gegeven(Types, Ownership etc) kan het hierdoor ook redelijk goed optimaliseren op de details.

Maar als je deze optimalisaties allemaal uit zet dan is het in mijn ervaring wanneer ik zat te programmeren op X86_64 en ook op wat STM bordjes redelijk goed te volgen met wat ervaring in C.

[Reactie gewijzigd door Stetsed op 13 december 2025 12:50]

[Powerblast]

Ik ben er waarschijnlijk nog niet genoeg ervaren in maar ik vind op dit moment idiomatic rust code lastiger om zeg maar per regel te weten wat er nu gebeurd dan C. Juist omdat Rust een laagje abstractie heeft wat C in de basis niet heeft. De vele string mogelijkheden zijn daar bijvoorbeeld een voorbeeld van vind ik. Mogelijkheden die je in C ook wel uiteindelijk zal gebruiken maar dan eerst zelf moet voorzien, terwijl Rust het al voor jou paraat heeft.

Ik weet verder niet waarom maar C lees ik en snap ik direct wat er staat. Bij Rust is het toch dat er meer magic achter de schermen gebeurd.

Ik heb trouwens datzelfde probleem maar ik veel grotere mate met c++ ook hoor. Daar is het helemaal gokken wat de compiler er uiteindelijk van maakt. Begrijp me niet verkeerd ik vind op zich Rust een nette taal.

[Reactie gewijzigd door Powerblast op 13 december 2025 15:23]

[cmpxchg]

Gewoon deze entertaining video kijken, en daarna rustig, - rustig - beoordelen hoe je met programmeertalen in de toekomst om wil gaan:

YouTube: C++ is the BEST interpreted language

[Daco]

ik geloof dat rust heel veel potentieel heeft maar er zijn zeker dingen die ik graag nog had gezien (of ondertussen aangepast zijn, its been a while since i played with it )

Ik ga er van uit dat de linux kernel geen crates gebruikt, en puur enkel 'lokale' rust code, en dat maakt inderdaad dat de code een stuk robuster en minder problemen zal hebben in de toekomst dan de oude C code (die jaren aan aanpassingen heeft en zeker refactors kan gebruiken).

maar het feit dat het inderdaad in de linux kernel zit betekend inderdaad dat

1) het betrouwbaar genoeg is voor low-level stuff die bedoeld is om contained te zijn

en/of

2) veel roepen heeft geholpen

dat C++ niet in de linux kernel zit was door veel problemen met de taal die niet geaccepteerd konden worden, maar met latere versies van C++ aangepakt en opgelost zijn. echter is die beslissing van het kernel team nooit herbekeken zover ik weet. Rust in linux heeft een hele boel tegen wind gehad, en krijgt het nog steeds, maar met de populariteit van rust en het feit dat het in general tech-news naar boven kwam heeft het zeker geholpen om in de linux kernel te raken en te blijven, and im for it at this point.

beetje spijtig dat er de asashi/kernel drama nodig was om die push te geven om de kernel development omgeving iets beter te maken voor rust,.

Ik denk vaak of ik niet beter mijn wii iop kernel source zou herwerken in rust, maar dat is misschien voor later als hij feature complete is (aka, probably never)

[Reactie gewijzigd door Daco op 13 december 2025 12:15]

[dmantione]

De vraag bij C++ is wat je van die taal gaat gebruiken. Als je gewoon procedureel programmeert, is C++ t.o.v. C niet zo spannend. Maar, wil je de kernel objectgeörienteerd maken? Wil je de STL gaan gebruiken?

C++ kan met name bij gebruik van de STL een enorme ellende worden om te debuggen: Omdat basisfaciliteiten als strings en dynamische arrays geen onderdeel van de taal zijn, maar in de preprocessor leven, krijg je geen zinnige foutmeldingen meer uit de compiler en kan ontwikkeling op die manier erg vervelend worden.

Het is dan een kwestie van persoonlijke overwegingen wat zwaarder weegt: De kracht die de STL biedt of de ellende van onleesbare foutmeldingen. Mijn inziens is dit een vrij fundamentele kwestie bij C++ en om deze reden zal het altijd wel zo zijn dat veel programmeurs niet van C++ zullen houden.

[Olaf van der Spek]

Omdat basisfaciliteiten als strings en dynamische arrays geen onderdeel van de taal zijn, maar in de preprocessor leven,

Preprocessor?
Je bedoelt iets met templates neem ik aan?

[dmantione]

Jazeker, en wat doe je om een STL-string te kunnen gebruiken?

#include <string>

Het is in de preprocessor die dat include-bestand doorwerkt dat de string ontstaat. Dat betekent ook dat fouten die de programmeur in zijn hoofdcode maakt, past tijdens de expansie die de preprocessor doet, tot foutcondities leiden. Vervolgens zit je dan te kijken naar een foutmelding die gemeld wordt in het include-bestand, en dus niet zegt wat er werkelijk aan de hand is.

[Zezura]

Je krijgt net zo goed een error van een STL gebruikte string als van een C string. Alleen de hoeveelheid meuk dat je in je error log erbij krijgt is niet fijn. Dat kan zeker voor beginnende programmeurs overweldigend zijn. Maar het valt nog steeds prima te debuggen. Zeker als je wat ervaring hebt in C++. C++ is veiliger dan C zolang je bij C++ blijft en je geen gekke fratsen gaat uithalen door C, assembly en C++ door elkaar te gaan gebruiken. Soms voor edge-cases moet het. Maar laat dat aub door een ervaren senior dev doen ofzo.

je moet sowieso als junior dev niet willen starten met C of C++. C# of typescript, of als je moeite hebt met types eerst maar een JavaScript.

Goede (system) programmeurs gebruiken uitzonderlijk try-catch e.d. in mijn opinie. Alleen last resort als je een of andere library moet gebruiken die dat afdwingt 🙄.

[Clemens123]

C en C++ zijn imho ook voor junior devs niet verkeerd. Ik ziet het zelf als voordeel een strictere taal eerst te leren voor je aan bv. Javascript begint. C is ook prachtig in zijn eenvoud en doet je echt nadenken over geheugen. C++ daar heb je wat meer tijd voor nodig en heb je honderden design patterns, daar is voldoende tijd voor nodig (en je moet daar best ook nog zowel klassieke C++ als modernere C++ aanleren)

En try catch heeft veel flaws tov van bv. de mechanismes die Rust gebruikt voor error afhandeling. Het grootste probleem dat ik met try catch heb is dat het je in de meeste talen niet dwingt expliciet errors af te handelen of expliciet verder te throwen...

Als ik een functie gebruik in C++, bv. map.at()...dan gaat mijn compiler me niet zeggen dat ik een mogelijk exceptie mis. Ik moet de documentatie raadplegen en elke mogelijk error daar bekijken. Voor zover ik weet is dat bij C# en Java ook niet anders. Gevolg is dat je errors in het beste geval in je main worden opgevangen en je mag beginnen uitvissen van waar in je programma ze komen (bij bv. Java krijg je wel by default stack traces typisch, bij C++ moet je meer moeite doen als je dat wil). Ik zou try catch al zoveel aangenamer vinden als ik elke error expliciet zou moeten afhandelen van de compiler.

Bij Rust krijg je typisch een Option enum terug die Some of None is waarbij je verplicht bent beide waardes af te handelen.

In de kernel heb je ook geen try catch trouwens maar return int waardes die je manueel juist moet interpreteren (Ik praat nu over C).Vaak in de kernel gecombineerd met goto en de valkuil dat je bij de error paden zaken vergeet vrij te geven of dubbel vrijgeeft (het laatste zorgt dan typisch voor een kernel panic)

[Clemens123]

je weet dat in c net opde zelfde manier code toegevoegd wordt? Is net zo met preprocessor directives. Je doet in C drivers ook gewoon bv. #include <linux/module.h> etc.

De prepoccessor is trouwens iets waar men in C++ komaf van wil maken (gebeurt moeizaam), bij C zal dit denk ik nooit gebeuren.

Daarnaast is het niet zo dat de implementatie in de header file moet zitten: enkel de functie header (naam, return type en argumenten) moet overeen komen met wat je al geprecompiled kunt hebben, de linker zal dit dan kunnen linken. String functionaliteit wordt niet opnieuw gecompileerd als je een string gebruikt in C++, je linked met de standaard library (geldt wel bv. voor templated code)

Maar de preprocessor is dus helemaal geen argument waarom het niet in de kernel gebruikt wordt, want C gebruikt deze net zo.

[dmantione]

Ja, ook C maakt zich daarin schuldig, maar als je C programmeert dan doe je arrays handmatig met malloc en strings doe je met strcpy en de hele rataplan. Daardoor genereert de de compiler nog zinnige foutmeldingen en dat is een reden waarom velen niet van C++ houden.

Talen met ingebouwde facilteiten hebben dat soort problemen niet. Laat ik Pascal maar weer eens noemen:

s:=s+'abcd';

... heeft én geen risico op een bufferoverloop, én als je iets verkeerds tikt, zegt de compiler gewoon exact op de juiste plaats waar je iets verkeerds doet. Dat is de reden om verder te kijken dan C en C++, in dit geval dus Rust.

[Grimm]

Maar, wil je de kernel objectgeörienteerd maken?

De kernel is al object geörienteerd, daar is geen C++ voor nodig.
De Linux kernel bewijst dat je in C prima object geörienteerd kunt programmeren.

[Reactie gewijzigd door Grimm op 13 december 2025 15:43]

[punishedbrains]

Rust lijkt nogal sterk een imago probleem te hebben, mede doordat het bekender werd als de taal gebruikt bij cryptomining (althans toen hoorde ik er pas wat van). Daar komt bij dat programmeurs er heel tevreden mee zijn, dat delen en dat wordt dan weer gezien als zeer overdreven en toxisch (waar er vast ook veel van tussen zit).

Ik ben er gewoon mee begonnen omdat ik 1 blik liet vallen op de compiler output en ik was meteen geinteresseerd. Toen kwam de documentatie en wat een verademing was dat zeg. Genoeg reden om erin te springen en ik denk dat ik nog even door blijf gaan, hopelijk verbeterd het imago ook wat en komen er meer banen bij. Ik ben gelukkig totaal niet emotioneel over welke taal dan ook en kijk gewoon wat ik er van vind. Elke taal heeft zijn nadelen, daar focus ik me simpelweg niet op.

[cnieuweboer]

Misschien het het imago inderdaad door crypto, maar voor mijn leek het iets anders.

Rust is de eerste taal die gebruikt wordt om zo veel projecten te herschrijven. En raakte daardoor verweven in controverses rondom die projecten. Met name System d was voor een groep Linux gebruikers een hot topic.

En als er eenmaal groep "anti rust" is wordt dat een soort van tribal identity.

/edit
En het lijkt er op dat een opvallend groot deel van de rust ontwikkelaars niet "blanke heteroseksueel" is. Dat is tegenwoordig een goede reden om boos te worden.

[Reactie gewijzigd door cnieuweboer op 13 december 2025 14:21]

[ffha]

Bedankt voor de lange AI slop explainer, die miste ik nog.

Heb je zelf ook nog gedachten over dit onderwerp?

[Bitmaster]

Ik stoor me aan de "—" elke 10 seconden in AI-tekst... Een gezonde Nederlander gebruikt dat niet.

[Microwilly]

En ja — voor sommigen voelt dat bijna als een geloofsafval.

— Hahah ja wou deze opmerking ook plaatsen. Ai

[dmantione]

Nou ja, Linus Torvalds heeft in het verleden hele sterke uitspraken gedaan over Pascal, Niklaus Wirth voor van alles uitgemaakt... het is duidelijk dat Linus geen vriend was van een taal met sterke typering. En daarom kan je dit inderdaad wel als een soort geloofsbekering zien: Rust gaat op dit gebied nog verder dan Pascal.

[MSalters]

Pascal gaat zeker niet verder. In Pascal is een string met 5 karakters een ander type dan een string met 6 karakters. Dan heb je dus print(char[5]) en print(char[6]) nodig. In 1980 was dat soort onzin kansloos; de geheugenoverhead van al die functies was dramatisch. In Rust is stringlengte dus een runtime attribuut, geen onderdeel van strong typing, net zoals in elke taal die na Pascal is bedacht.

Pascal past met Algol in het museum - historisch belangrijk maar een doodlopende evolutionaire tak.

[dmantione]

Rust gaat verder dan Pascal op het gebied van sterke typering: Type-interferentie, Ownership/Borrowing en Option<t> zijn concepten die Pascal niet kent.

In het originele Pascal zoals gepubliceerd door Wirth bestonden er inderdaad geen strings, het was een array of char. Pascal heeft zich wat ongeleid ontwikkeld, Pascal-implementaties hadden wel echte strings dat werd zo alomvattend dat een string met als eerste byte het lengte-byte een Pascal-string is gaan heten.

[R4gnax]

Moderne smaken van Pascal hebben vziw gewoon een string type wat zero-terminated is. Geen gezeik met char arrays.

[SG]

Er wordt zeker concessies gedaan betreft safety en performance. Simple reden dat zoals simpel voorbeeld safe auto functdeling( float x , float y); x/y Je check devide by zero , dat wordt dan door de compiler geregeld. En min max voor signed unsigned moet opvangen, dat wordt dan door de compiler geregeld.In loop waar je deze routine intensief gebruikt vreten die checks compute time op. Deze check worden dan in routine gedaan wat bin oplevert die groter is door die checks.

C C++ zijn er toevoegingen de safety naar de functie caller verschuiven zoals concepts ranges . Dus gevalideerde argumenten stuurt in de functie. En je dus compile error krijgt.

Wat die safety rust opvangt is deel van probleem. Nog steeds kan je unsafe code schrijven. Voor C C++ toolchain heb sanity en static checker. En strengere 0 warnings setting om meeste gangbare unsafe problemen op te vangen. De complexere unsaved problemen die niet onder pointer memory buffer overflow lifetime vallen. Heb je nog steeds ook in rust en alle andere talen. Je krijgt schijn veiligheid. Als diepere en volledig perikelen van safe programmeren niet onder de knie hebt.

Het zal wel helpen maar je zal ook inleveren. Maar vaak is dat niet zo probleem. Vaak is het snel genoeg.

[Olaf van der Spek]

C C++ zijn er toevoegingen

Wat is C C++?

[Halfscherp]

Vriend, loop je nu serieus ChatGPT te gebruiken om een korte comment te posten..

[Cilph]

Niet dat ik het oneens ben, maar het valt wel op dat dit door AI geschreven is. Je introduceert het nieuwsfeit opnieuw, alsof men niet zojuist het artikel al heeft gelezen. En natuurlijk, je gebruikt de befaamde — em-dash, die geen enkel mens zelf zou typen.

[.oisyn]

Je hebt duidelijk niet begrepen wat Rust wel en wat het niet claimt te doen. Dan snap ik wel dat je daarvan dan een "broodje aap verhaal" maakt.

Rust is memory safe. Dat betekent dat het (zonder unsafe blokken) niet mogelijk is om bijvoorbeeld buiten buffers te schrijven of te lezen, of geheugen te accessen dat al vrijgegeven is. Dit tacklet een hele klasse van serieuze CVE's, meestal remote code execution bugs.

Wat Rust vooral niet claimt is dat het alle programmeerfouten oplost. Sterker nog, sommige zaken worden tijdens runtime gecheckt, zoals array bounds. En het programma zal dan keihard crashen als zaken niet op orde zijn, wat veiliger is dan willekeurig geheugen overschrijven.

[Powerblast]

Gewoon een vraag maar heb je zelf al eens wat Rust geschreven? Rust is wel degelijk memory safe by default. Je hebt de mogelijkheid om dat(gedeeltelijk) overboord te smijten met unsafe maar je kan perfect zonder.

In vergelijking met c++ waar je letterlijk 12 manieren hebt om iets te doen waarvan er 11,5 obsolete zijn omdat ze niet veilig blijken te zijn, is Rust echt een verademing. Je moet niet zoals in c++ de docs van elk statement gaan lezen om UB te voorkomen.

Dat het geen logica fouten voorkomt is nogal logisch, geen enkele taal kan gokken wat je functioneel bedoelt. Maar technisch kan het dat wel en dat doet Rust dus wel.

[Reactie gewijzigd door Powerblast op 13 december 2025 15:29]

[SuperDre]

De oorspronkelijke programmeertaal, C, heeft namelijk te maken met geheugenkwetsbaarheden

Dat is dus niet waar, dat suggereert namelijk dat er altijd een kwetsbaarheid aanwezig is terwijl dat dat niet het geval is. Het verhoogd hooguit kwetsbaarheden als de ontwikkelaar zich niet bewust is van hoe die deze problemen moet voorkomen, beetje vergelijkbaar met bv SQL-injection, SQL is niet het probleem, de gebruiker is.
En Rust is ook niet heilig of fullproof.

[Olaf van der Spek]

SQL is niet het probleem, de gebruiker is.

SQL injection is vooral een probleem door slechte (client/query) interfaces.

SQL is niet het probleem, de gebruiker is.

Dat wordt al decennia geroepen maar dat lost het probleem niet op.. hetzelfde geldt eigenlijk voor C (en mogelijk C++).

[lvdgraaff]

De oorspronkelijke programmeertaal, C, heeft namelijk te maken met geheugenkwetsbaarheden.

Niet de taal, maar de programmeur heeft te maken met geheugenkwetsbaarheden .

[rbr320]

De waarheid ligt zoals wel vaker het geval is in het midden. Het is de taal die de programmeur toestaat slordig met geheugenbeheer om te gaan. Rust staat het simpelweg niet toe, dus de taal is daarin wel degelijk een grote factor.

[Reactie gewijzigd door rbr320 op 13 december 2025 13:16]

[dmantione]

Het is de taal in combinatie met de runtimelibrary: strcat() strcpy() sprintf zijn bijvoorbeeld functies die buffer-overflows aanmoedigen. Je kunt in C veel oplossen door veilige functies te gebruiken, maar... ieder boek over C beschrijft bovenstaande standaardfuncties, waardoor ze gebruikt blijven worden.

[Wolfos]

Die namen ansich zijn ook wel een artifact uit een andere tijd. Onleesbare afkortingen, en sprintf wat niet in de verste verte beschrijft wat de functie doet. Niet verwarren met printf_s

[RoestVrijStaal]

Ieder boek over C beschrijft bovenstaande standaardfuncties, waardoor ze gebruikt blijven worden.

Als er één boekverbranding mag plaatsvinden. Dan is het wel een waar die boeken in het vuur gaan. En boeken waar C-code en C++-code zonder duidelijke scheiding beschreven worden.

Sowieso is het vandaag de dag niet slim om programmeerboeken te kopen.

Per halve decennia komt er weer iets nieuws in C en C++ bij waardoor oude manieren die boeken beschrijven achterhaald kunnen zijn en/of de nieuwe concepten die de aanvulling van die programmeertalen introduceren, onderbelicht blijven.

[Sandor_Clegane]

unsafe.

[SG]

Het probleem met C C++ is dat ervaren programmeurs de neiging hebben om wild te gaan met pointer truckjes. En er dus ook heel veel legacy code is.

Nieuw C C++ zijn er guidlines maar ivm legacy kan je altijd de oude trucjes blijven doen.

Je hebt nu ranges maar je kan nog steeds C style Array doen in C++23.


Herb Stuart ? Heeft front-end voor C++2X en noemt het C++2 wat safety meer enforced. Is niet officieel.

[Rob vd Hoeven]

Ik vraag me af of de voordelen van Rust in de zeer nabije toekomst nog zo uniek zijn. Ik verwacht dat C en C++ code in de toekomst door AI zeer effectief op potentiële geheugenlekken en buffer overruns kan worden gecontroleerd waardoor C en C++ code net zo veilig zal zijn.

Probleem met Rust is dat alleen een programma dat volledig in Rust geschreven is de unieke voordelen heeft. Zolang een Rust programma nog gebruik moet maken van niet-Rust code zullen geheugenlekken en buffer overruns mogelijk zijn.

[Daco]

en daarom zijn ze enkel kernel components (of modules) aan het schrijven en overzetten naar rust.

een component of module kan je zien als zijn eigen programma binnen de kernel die met de echte kernel zelf communiceert over een api/messaging. info : Wikipedia: Rust for Linux

zie het als volgt. je doet een fopen (file open) van device x in je programma. die doet een syscall die de kernel opvangt (via glibc) en ziet dat je device x wilt open doen. die stuurt de open message/command door naar de component/module van device x via de component/module interface die het zelfde is voor alle linux drivers en components. dat zijn 3 verschillende lagen die alle 3 in verschillende talen kunnen zijn. je fopen kan C++ zijn, de kernel is dan C en je device x component kan volledig rust zijn en alles van rust gebruiken.

[RoestVrijStaal]

Met het drama van BcacheFS in het achterhoofd, vraag ik me af of er niet te snel gehandeld is.

Sinds de introductie van Rust in de kernel in 2021, zijn we pas ~4 jaar verder.