Linux Foundation brengt vroege versie van alternatieve browserengine Servo uit

De Linux Foundation brengt versie 0.0.1 uit van de in Rust geschreven browserengine Servo. De experimentele software is te downloaden vanaf GitHub, voor diverse besturingssystemen en chiparchitecturen. Dit omvat naast Linux, Windows en Android, ook macOS op ARM.

De release van kant-en-klare binaries van Servo voor macOS op ARM-chips is nu geheel nieuw, meldt opensourcetechnieuwssite Phoronix. De beschikbare downloads van versie 0.0.1 zijn equivalent aan de nightly build van 19 oktober, melden de ontwikkelaars van Servo op de GitHub-pagina van het softwareproject. De nieuwe release heeft wel aanvullende, handmatig uitgevoerde tests gehad.

Voor gebruik op Linux en macOS zijn er nog wel wat bekende problemen. Oplossingen daarvoor zijn te vinden op de downloadpagina voor de vooraf aangemaakte nightly snapshots van Servo.org. De alternatieve browserengine, die is voortgekomen uit Firefox-maker Mozilla, is geschreven in de programmeertaal Rust die betere bescherming tegen geheugenbugs biedt dan talen als C en C++. De vrijwilligers die werken aan Servo hebben op de roadmap nog veel plannen en ideeën staan.

Reacties (48)

[Cristan]

Ik voeg me af wat het idee erachter is, maar op servo.org staat het antwoord:

• Memory-safe (vanwege Rust)
• Modular (makkelijk aan te passen, ook dankzij Rust)
• Parallel (van de grond af aan opgebouwd voor multi-core)
• Cross platform (kan oa ook werkend gemaakt worden op embedded systemen)
• Independent (gezien het gemanaged wordt door de Linux Foundation)

[_Thanatos_]

Wat in Rust maakt het memory safe? En waarom kan C(++) dat niet?

[rbr320]

De programmeertaal Rust en de bijbehorende compiler laten bepaalde fouten die te maken hebben met het beheren van geheugen binnen je applicatie simpelweg niet toe. De talen C en C++ zijn dusdanig oud in hun ontwerp en met minder abstractie waardoor diezelfde fouten wel mogelijk zijn.

Een voorbeeld van zo'n fout is het vrijgeven van een stuk geheugen dat je het niet meer nodig hebt, maar er dan later in je code nog wel naar verwijzen. Dit is een zogenaamde "use after free" bug. Het gevaar zit hem er vervolgens in dat een kwaadwillende met controle over andere software op het systeem dit stuk geheugen heeft gevuld met waardes waarvan bekend is dat jouw software er niet mee om kan gaan waardoor het crasht of gevoelige informatie vrijgeeft. Dit soort fouten komen veel voor in software omdat ze in een taal als C of C++ door de complexiteit die inherent is aan een groot softwareproject makkelijk te maken zijn en je er niet tegen wordt beschermd. Rust doet dat dus wel.

Dat wil niet zeggen dat Rust als taal heilig is en inherent veilig, veel andere programmeerfouten zijn nog gewoon mogelijk. Dit type fout echter niet en Rust beschermt je daartegen terwijl de opgeleverde binaries wel ongeveer even snel zijn als wanneer ze geschreven zouden zijn in C/C++.

[juke1349]

Nog een aanvulling, om de impact van Rust nog wat te verduidelijken:

Ongeveer 70% van alle security-relevant bugs (CVE), zijn terug te voeren op geheugen-bugs.

Dit is een van de meest "harde" conclusies in de hele informatica:

• Microsoft stelt dit vast in Windows codebase:
  https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
• Google ziet hetzelfde in Chromium/Chrome.
  https://www.chromium.org/Home/chromium-security/memory-safety/
• Google project Zero (scant belangrijke open source projecten) ziet 69%
  https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html
• Android: 90%
  https://security.googleblog.com/2019/05/queue-hardening-enhancements.html
• Apple MacOS: 76%
  https://langui.sh/2019/07/23/apple-memory-safety/

Als zó veel projecten, op zó diverse code-basissen, hetzelfde zien, moet het aan de gemeenschappelijke factoren liggen: menselijke hersens kunnen niet alle pointer-fijnheden van C (tegelijk) in hun hoofd houden.

Zie ook Prossimo's samenvatting (ISRG/LetsEncrypt hoek)

Geheugenbugs is waarom staatshackers routers en vpns kunnen infiltreren, waarom Pegasus Malware je WhatsApp berichten kan stelen, hoe Iran zijn dissidenten in de gaten houdt, hoe rootkits Windows infecteren, en ga zo maar door.

Anders gezien: door geen C/C++ met handmatig geheugen-management te gebruiken (maar Rust, Java, Go, .Net, etc), is je software een factor 4-5x veiliger tegen hacken, puur door de tool-keuze.

Rust is daarbij de enige taal die zowel "low-level" is, als "safe". Alle andere talen lossen het op de een of andere manier met grote runtimes op. Rust draait ook op een microcontroller, én heeft een goed typensysteem, waarmee je ook structuur in je programma kunt brengen dat de "overige" logica-bugs onwaarschijnlijk maakt.

[Reactie gewijzigd door juke1349 op 21 oktober 2025 12:52]

[rbr320]

Nette aanvulling, ik wilde de ernst van het probleem niet zomaar benoemen zonder de objectieve data er bij te betrekken, dus dank daarvoor.

[peregrine101]

Kleine aanvulling op dit verhaal. C/C++ zijn niet minder memory safe omdat ze oud zijn of fouten in het ontwerp hebben. Ze zijn zo bij design.

Het hele idee van C/C++ is dat je geen beperkingen hebt, maar daardoor ook zelf veel verantwoordelijkheid hebt. De moeilijkheid van deze taalfamilie zit daar ook in en alles rond geheugen is waar iedereen heel veel moeite mee heeft om het goed in de vingers te krijgen. Je kunt geheugen gevuld laten wat niet meer gebruikt wordt (garbage collection is afwezig), je kunt per ongeluk geheugen aanspreken wat niet van jou is (pointers!). Maar als je het in de vingers hebt (heb ik zelf ook niet overigens) kun je ook de meest krachtige programma's schrijven.

Juist om die moeilijkheden te omzeilen zijn later talen als Java en Rust ontstaan. Zij hebben wel garbage collection en voorkomen dat je in geheugen gaat rommelen, waar je geen toegang hebt of wat je al teruggegeven hebt. Dat maakt C/C++ niet minder sterk en oud of deze talen moderner. Het is een andere benadering.

[i-chat]

dat heeft wel degelijk te maken met ouderdom.

bijvoorbeeld email is minder safe omdat men zich in de ontwerpfase niet kon voorstellen dat het OOIT letterlijk in plaats van reguliere post zou bestaan. contracten die vroeger per courier gingen gaan nu gewoon per email ook voor muntinationals en zelfs voor en tussen overheden. als men zich nu bijna 100 jaar geleden zou hebben gerealiseerd dat email zó belangrijk zou worden dan was een standaard als PgP gewoon onderdeel geworden van het SMTP-protocol.

een zelfde soort vergelijkbaar argument valt te maken voor C++ in vergelijking tot Rust. Rust is niet zozeer ontworpen omdat de bedenker ervan zo 'slim' was, rust is simpelweg gewoon een gevolg van de lessen die geleerd zijn uit de onvolkomenheden uit voorgaande talen (zoals dus C++) het is 'makkelijker' om een probleem op te lossen als je weet: wat het probleem is, (en hoe het wordt misbruikt).

en over 20 jaar zal er weer een taal worden ontwikkeld die de inherente ontwerpfouten uit Rust zal proberen op te lossen.

dan kun je wel roepen, dat is by design maar dat is echt een false narative.

C++ is niet memory unsafe by design, C++ is Compleet vrij By design, en dien ten gevolgen dus memory unsafe. C++ was een antwoord op de vraag hoe 'we' meer uit de hardware konden halen en programma's beter gebruik konden laten maken van de beschikbare hardware. men was tot de ontdekking gekomen dat je niet zomaar alles aan de compiler kon overlaten.

net als dat je geen autosnelwegen bouwt om ongelukken te veroorzaken, je bouwt zo om hard te kunnen rijden, en daardoor ontstaan er ongelukken: met als gevolg dat we in de loop door jaren steeds meer regels voor die snelwegen zijn gaan bedenken, Max snelheid, niet rechts inhalen, matrixborden, snelheidsbeperkingen bij slecht weer etc.

[Reactie gewijzigd door i-chat op 21 oktober 2025 09:04]

[cdwave]

E-mail is minder safe omdat de e-mail programma's van kleine short-lived terminal applications zijn verworden tot gigantische mastodonten met halve web-browser.

Dat heeft niks te maken met de hoeveelheid mail, maar met de ontwikkeling van de programma's zelf.

[Oerdond3r]

Kleine correctie op jouw post: Rust heeft geen garbage collection zoals Java in de zin van dat het op een random moment een reference count doet op objecten om ze vervolgens op te ruimen.

Rust is op zo'n manier gemaakt dat je met de taal op een bepaalde manier moet programmeren zodat er geen memory leaks ontstaan. Doe je dat wel dan compiled het niet. Dat is lastig, maar daar tegenover staat wel dat er hulpmiddelen zijn binnen de taal om op deze bepaalde manier te programmeren, en de compiler is ontzettend behulpzaam wanneer het een fout detecteert.

Daarom wordt Rust ook zo vaak vergeleken met C/C++ als 'vervanger'. Doordat er runtime geen garbage collection plaats hoeft te vinden, kan het in theorie net zo snel draaien als een C/C++ programma. Natuurlijk is Rust niet perfect en bestaat er nog steeds slechte Rust code (je kan bv. alsnog memory leaks maken met de [unsafe] attribute).

[cdwave]

Je kunt wel degelijk memory-safe programmeren in C++ (en zelfs in C), maar dat is moeilijk en vraagt niet alleen discipline maar ook kennis van zaken van de programmeur.

Groot voordeel van Rust is dat het compileert naar machine-code, en dus voor het operating system duidelijk is wat "data" is en wat "code". Dat scheelt niet alleen heel veel resources, het zorgt ook nog voor extra veiligheid.

[i-chat]

Dat klinkt best wel hoopvol

Het enige probleem waar ik mee zit is content

Als je zie hoe puristisch de LF doorgaans is vrees ik dat closedsourse plugins wel eens lastig kunnen worden

Mrt dat in het vooruitzicht hebben we een probleem

Stel dat deze browser in een stroomversnelling komt en we over 2 jaar een nieuwe browser war krijgen (let op dat Firefox ook in beta was toen het de strijd aanging met IE)

Hoe gaan we dan Netflix kijken zonder drm
Gaat er iemand een opensource drm staandaard bouwen die kan wedijveren met eidevine?

[ManIkWeet]

De enige browser die ècht Netflix kan kijken is Edge (is de enige die 1080p doet), de rest heeft al lagere resolutie.

Dus ik neem aan dat het voor deze browser hetzelfde zal werken: werkt wel, maar niet de resolutie waarvoor je betaald.

[xxdeb]

Ziet er cool uit, laat de browser war voor linux maar uitbarsten(hopelijk). Ik ben er nieuwsgierig naar. Ook omdat het cross platform is. Misschien gaan linux distros hun eigen browsers nu ook maken.

[Reactie gewijzigd door xxdeb op 20 oktober 2025 20:00]

[musiman]

Niet alleen voor Linux. Ook Windows gebruikers kunnen wel een onafhankelijke engine gebruiken, gezien de recente onzekerheden omtrent de nieuwe gebruiksvoorwaarden van Firefox. linkje

[Reactie gewijzigd door musiman op 21 oktober 2025 08:47]

[SilentLucidity]

Modulairiteit komt niet zozeer door Rust maar door Rust Crates, vergelijkbaar met zoals een nuget package, npm package, een gem. Ik programeer geen C, maar blijkbaar is dit ook logischer, makkelijker of sneller dan gebruik maken van c libraries.

[Henk Poley]

Bij Mozilla was dit een soort proef-tuintje om slechte onderdelen van Firefox op een beter manier in te herschrijven. Zodat ze dan later overgenomen konden worden in Gecko (Firefox). Management snapte die aanpak op een geven moment niet meer. Maar dat is de originele herkomst. Het was nooit echt bedoeld om een hele goede browser te worden, maar om ideeën in uit te proberen.

[Nark0tiX]

Straks eindelijk een browser die geen 8gb ram gebruikt !

[joint_me]

Ik post dit bericht vanaf Servo!

- De homepage zag er gaar uit
- De layout van deze pagina is iets beter
- De wysiwyg editor werkt niet
- Ik kan wel inloggen, maar niet met tab door de formuliervelden

Heb wat andere sites bezocht, maar vooral op het gebied van layout gaat er nog vele mis. Wel vet dat LadyBird en Servo zo aan de weg timmeren.

[R_Zwart]

Niet slecht voor een 0.0.1 versie.

[locke960]

Het project startte in 2012 en heeft nu versie 0.0.1 geleverd. Nog iets te vroeg om te juichen dus.

De overgang van Mozilla naar de Linux Foundation zal de nodige vertraging hebben veroorzaakt, maar toch, 13 jaar.. Afwachten dus hoelang het duurt voor het serieus bruikbaar wordt.

[_Thanatos_]

Ah dus over nóg 13 jaar, rond de deadline voor het 2038 probleem, hebben we 0.0.2

[yuckywucky]

pull requests tonen of zwijgen

[Christoxz]

Er is ook wel een hoop gebeurd tussen 2012 en nu. In 2023 is het pas weer serieus opgepakt, geen idee want de staat toen was vergeleken nu, maar nu dat er een foundation achter zit, en dus ook de community, kan het best een boost krijgen.
Rome is niet op één dag gebouwd, want we nu (nog) niet hebben, kan later alsnog heel bruikbaar zijn.

[markjanssen]

Yuh, draaide hier ook out-of-the-box, wel idd nog met de nodige issues, maar niet slecht voor een erg vroege versie. Eens zien waar ze over een paar maanden staan, zodra ex extensions zijn voor mijn passwordmanager en ublock-origin zal ik 't zeker proberen.

Zo te zien kan ik textvelden nog niet editen, dus een typo fixxen in je comment is best ruk.

[Damic]

Ha de ervaring van de eind jaren 90 browser wars :+

[hachee]

- Zover geen ondersteuning voor de weergave van de Tweakers advertenties

[BasHouse]

Als je een goeie build omgeving wil bouwen is dit wel een mooi project!

Begin hier:

https://book.servo.org/hacking/setting-up-your-environment.html

dan hier:

https://book.servo.org/hacking/building-servo.html

en dan hier:

https://book.servo.org/hacking/profiling.html

Altijd leuk om je eigen browser te bakken en natuurlijk een beetje te rebranden en aan te passen.

In git bash:

git clone https://github.com/servo/servo.git

cd servo

./mach bootstrap

./mach build --profile profiling --with-frame-pointer

copy de exe en de dll's (in target profiles) en je hebt een werkende browser!

Hij doet het!! Wauw!l!

I love Rust

Bedenk even de mogelijkheden. Je kan hiermee een "browser integrated" app bouwen. Cool toch?

Hmm, merk wel dat niet alle websites goed laden, work at the shop

[BasHouse]

Next level is chromium compilen. Duurt 2 uur en je bent 200 Gb rijker 2 miljoen bestandjes

[Reactie gewijzigd door BasHouse op 7 november 2025 03:26]

[rustycrab]

Betekent dit dan ook dat Firefox in de toekomst Servo als engine gaat gebruiken? Of doen ze dat al?

[- peter -]

Servo is afgesplitst van Mozilla. Ik vermoed niet dat ze nog interesse hebben (helaas).

[markwiering]

Hoezo "helaas"?

Ik ben juist blij als er diversiteit is in webbladeraarmotoren. Laat Gecko en Servo naast elkaar bestaan i.p.v. te fuseren. Die eindeloze fusies hebben ertoe geleid dat bijna elke webbladeraar nu draait op Chromium.

Opera stapte over van Presto naar Chromium. Microsoft stapte over van Internet Explorer naar Chromium. Nieuwe opkomers (Vivaldi en Brave) gebruiken ook Chromium. Alles is nu Chromium. De enige tegenhanger is nu Gecko. Meer tegenhangers betekent meer concurrentie en meer diversiteit.

Dat is hard nodig, want Chromium is zéér slecht geoptimaliseerd. Ik kan geen enkele Chromiumbladeraar gebruiken op mijn computer uit 2003 met 1 GiB werkgeheugen omdat het systeem dan gewoon vastloopt tot ik de webbladeraar geforceerd sluit. Mozilla Firefox en PaleMoon daarentegen (allebei Gecko) werken perfect. Alleen daarmee kan ik het Internet op op mijn oudere computer.

[i-chat]

Totaal oneens met deze stelling

Een uniforme ervaring op het web is essentieel

Denk aan onze overheid die moet de pagina voor belasting aangifte straks voor 20 verschillende webengins optimaliseren als jou wensen uitkomen

Alle browsers op chromium zou prima zijn als deze engine niet zo sterk onder één paar vleugels hing

Microsoft, Netscape Mozilla google


Een betere oplossing zou zijn als servo inderdaad dominant wordt en al deze bedrijven en browsers er gebruik van gaan maken en ook aan deze engine gaan bijdragen in de vorm van patches en technology

Elke website die meer dan één broweser moet ondersteunen wordt minstens 50procent duurder en de consument betaald daarvoor met meer privacy grotere sdds of hogere abonnementen

[Seal64]

Een uniforme ervaring is essentieel, ja. Daarom hebben we met zijn allen de HTML5 standaard gemaakt.

Maar nu is het probleem dat de grootste renderengine beheerd wordt door een bedrijf dat tevens een dikke vinger in de pap heeft bij de HTML5 standaard, en zijn koppositie maar al te graag gebruikt om daar nieuwe zaken aan toe te voegen.

En daarbij doen ze de volledige ontwikkeling in hun eigen browser, dus die beschikt al over die features nog voordat ze onderdeel van de standaard worden en dus nog voordat de andere browserengines (Gecko, WebKit, en nu dus Servo) daarmee aan de slag kunnen. Wat weer leidt tot de ervaring dat grote, veelgebruikte websites, die toevallig óók door dat bedrijf worden beheerd, allerlei nieuwe snufjes kunnen gebruiken voordat andere browsers daarmee overweg kunnen.

En tenslotte is het dan ook zo dat het niet ongebruikelijk is dat die nieuwe snufjes per ongeluk expres met opzet toevallig bagger performance hebben op engines die daar niet mee compatible zijn.

Dus ja, uniformiteit is goed. Maar dan moet dat niet de uniformiteit zijn zoals bedacht door één bedrijf. Dit is gewoon IE6 all over again.

[i-chat]

Een uniforme ervaring is essentieel, ja. Daarom hebben we met zijn allen de HTML5 standaard gemaakt.

Maar nu is het probleem dat de grootste renderengine beheerd wordt door een bedrijf dat tevens een dikke vinger in de pap heeft bij de HTML5 standaard, en zijn koppositie maar al te graag gebruikt om daar nieuwe zaken aan toe te voegen.

En daarbij doen ze de volledige ontwikkeling in hun eigen browser, dus die beschikt al over die features nog voordat ze onderdeel van de standaard worden en dus nog voordat de andere browserengines (Gecko, WebKit, en nu dus Servo) daarmee aan de slag kunnen. Wat weer leidt tot de ervaring dat grote, veelgebruikte websites, die toevallig óók door dat bedrijf worden beheerd, allerlei nieuwe snufjes kunnen gebruiken voordat andere browsers daarmee overweg kunnen.

En tenslotte is het dan ook zo dat het niet ongebruikelijk is dat die nieuwe snufjes per ongeluk expres met opzet toevallig bagger performance hebben op engines die daar niet mee compatible zijn.

Dus ja, uniformiteit is goed. Maar dan moet dat niet de uniformiteit zijn zoals bedacht door één bedrijf. Dit is gewoon IE6 all over again.

ik snap niet waarom je 'mijn eigen punt' tegen me probeert te maken en daar dan nog een +2 voor krijgt ook.

mijn letterlijke post zegt.
>nee meerdere engines zijn niet goed, want webontiwkkelaars gaan die (of maar half ondersteunen, of de prijzen gaan omhoog vanwege meer arbeid.
> alles op chromium zou geen probleem zijn als het niet in handen was van één partij (google).
> bovendien zou het ook niet uitmaken als we nu ineens firefox weer dominant maken want mozilla is evengoed een probleem (want bedrijf).

dan kun je wel roepen, HTML 5 dus er is al een standaard. maar hoelang heeft het geduurt om van html 4 naar 5 te gaan - lees; hoeveel jaar heeft men daarover onderhandeld in een tijd dat bedrijven als youtube (toen nog onafhankelijk) proberen een dienst aan te bieden? die hele HTML standaard is verdomd waardeloos als je je bedenkt dat het gemiddeld minstens 5 jaar achter de feiten aanloopt.

en ja ik ben het volledig met je eens, chromium is een probleem nu er steeds meer features uit de opensource engine verdwijnen en richting de closesource google-fork verhuizen. evenmin zou ik het een probleem vinden als firefox compleet zou verdwijnen. ware het niet dat chrome of chromium dan wel eerst moet worden afgesplits van de rest van google. en dat er een onafhankelijke organisatie over moet gaan beslissen. en dat er een nieuwe (volledig opensource) DRM moet worden ontwikkeld die ook op custom OSén te implementeren is. zodat je niet meer afhankelijk bent van een google of microsoft build van de chromium browser.

en als we in plaats daarvan exact hetzelfde doen met een nu nog niet bestaande engine die in rust is gebouwd is me dat even goed zolang er maar 'slechts één engine is waaraan iedereen evenveel kan en mag bijdragen. liefst met een licentie doe closed-source forks (van de engine, niet de browser) onmogelijk maakt.

[Reactie gewijzigd door i-chat op 21 oktober 2025 09:21]

[curkey]

Ik zou toch zeker twee onafhankelijke engines minimaal willen hanteren. Mocht er eens een serieuze zero day optreden, dan is er nog een back-up. Tevens geeft de drive van twee makers een betere ontwikkeling, in plaats van alleen maar verdere enshittification door luiheid.

[TeleMax]

Daar bestaan standaarden voor. De implementaties zijn daar ondergeschikt aan.

[- peter -]

Meer helaas in dat ze hun resources er niet voor hebben ingezet. Ik vind t concept van een Rust based browser erg nice, maar zoals je kan lezen hier is er nog een lange weg te gaan. Als Mozilla het als opvolger had gezien qua engine zou t project veel verder zijn.

[markwiering]

Als Mozilla Servo had gezien als een opvolger, zou Servo nu inderdaad veel verder geweest zijn in ontwikkeling, maar dan zouden wij ook Gecko kwijtraken als bladermotor.

Het is nog maar de vraag of Servo dan ook echt beter zou zijn dan Gecko of niet. Zo niet - als Servo blijkt tegen te vallen - kun jij moeilijker terugstappen naar Gecko, omdat Gecko dan een verlaten project is.

Ik heb daarom liever het huidige systeem, waarbij Servo en Gecko onafhankelijk van elkaar blijven bestaan.

[juke1349]

Kritische onderdelen van Servo lopen al jaren in Firefox (2017).

Mozilla heeft Servo als "lab omgeving" gebruikt, en iedere keer als een module "af" was, ge-back-port in Firefox.

Project "Quantum": https://blog.mozilla.org/en/mozilla/introducing-firefox-quantum/

• "stylo css" is de Servo css module, opgenomen in firefox.
• "WebRender" is de gpu-gedreven render engine, die in Servo is ontwikkeld, en sinds 2020 Firefox aandrijft.

Zie ook Firefox "project Oxidation"

[Reactie gewijzigd door juke1349 op 21 oktober 2025 10:22]

[Flex-Able]

De industriële en embedded functies van de Servo browserengine bieden aantrekkelijke voordelen. Servo is ontworpen als een lichtgewicht en modulair web rendering platform dat ideaal is voor embedding in applicaties, waaronder embedded devices. Ik ben Enthousiast.

[J_van_Ekris]

Kan het al in Kiosk mode runnen? Ik ben package maintainer van een app die een kioskmode gebruikt, maar Chrome is te CPU intensief, en Firefox werkt lastig op de Pi Zero 2W (dingetje met te weinig geheugen).

[_Thanatos_]

Je zou verwachten dat Chrome de memory hog is...

[J_van_Ekris]

Je zou verwachten dat Chrome de memory hog is...

Ongetwijfeld, maar die gaat volgens mij gelijk de swap in en klaagt er niet over. Firefox geeft pop-up foutmeldingen, wat gebruikers irriteert.

[Aardedraadje]

Gaaf dat dit nog steeds doorontwikkeld wordt. Het nieuws over Servo kwam inmiddels al meer dan 10 jaar geleden. Volgens mij heeft Firefox aan Servo ook zijn modernisering te danken, althans in die zin dat ze in diezelfde periode aan Project Quantum hebben gewerkt en Firefox sinsdien (2017 alweer) veel sneller en stabieler draait dan het oude Firefox, en nog steeds goed meekomt met de concurrentie.

[PixelPhobiac]

Prachtig initiatief. Dit ga ik zeker blijven volgen!

[haagsepracht]

Servo op Android brak mooi door de DPG media wall heen, waardoor ik instaat was om nieuwsartikelen te lezen zonder (niet) akkoord te gaan met het plaatsen van cookies.

[Hydranet]

Onder Arch Linux kan je 'm via de AUR installeren

https://aur.archlinux.org/packages/servo

https://aur.archlinux.org/packages/servo-bin

https://aur.archlinux.org/packages/servo-nightly-bin

https://aur.archlinux.org/packages/servo-git

[Reactie gewijzigd door Hydranet op 21 oktober 2025 08:23]

[Thundernerd]

Dit is een serieuze vraag voor mensen die verstand hebben van Rust:

Hoe memory-safe is Rust nou eigenlijk zodra het `unsafe` keyword wordt geintroduceerd in de codebase? Is het dan niet meteen niet meer memory-safe?