Een nieuwe opensource browserengine

Ladybird-maker over alternatief Chromium en WebKit

Een nieuwe opensource browserengine - Andreas Kling over zijn project Ladybird

De hedendaagse internetgebruiker heeft de keuze uit tientallen welbekende browsers, maar onder de motorkap zijn verreweg de meeste daarvan gebaseerd op een van de drie grote engines: Googles Chromium, Apples WebKit en Mozilla's Gecko. De Zweedse ontwikkelaar Andreas Kling werkt aan een alternatief: de van de grond af gebouwde browser Ladybird met een eigen opensource browserengine. In een interview deelt hij zijn plannen voor het jonge project in prealfastadium, dat ooit tegenwicht moet gaan bieden aan de grote drie.

Diep persoonlijk van oorsprong

De naam Ladybird, lieveheersbeestje

De naam van de browser heeft net als die van het besturingssysteem alles te maken met Kling. Ladybird is vernoemd naar zijn Hongaarse vrouw Katalin. Haar koosnaam is 'Katica', wat Hongaars is voor 'lieveheersbeestje'.

Ladybird is een browser die in vele opzichten moet verschillen van alle grote browsers in het huidige internetlandschap. De oorsprong van het project ligt in 2018. Kling werkte aan een eigen besturingssysteem, SerenityOS, een modern, op Unix gebaseerd OS met een visuele stijl, vergelijkbaar met een retrobesturingssysteem uit de jaren negentig. SerenityOS was volgens de Zweed een manier om met zijn drugsverslaving om te gaan en hem rust te bieden, vandaar de Engelse naam voor sereniteit. Maar het hobbyproject groeide uit tot iets serieus en in 2021 ging hij fulltime aan het OS werken.

Bij dat besturingssysteem hoorde een ander hobbyproject: de opensourcebrowser Ladybird. Sinds de zomer van 2024 is er daarentegen niet meer van een hobbyproject te spreken. Kling forkte de browser en richtte de stichting Ladybird Browser Initiative op. Die organisatie ontving een miljoen dollar als donatie van Chris Wanstrath, oud-ceo en medeoprichter van GitHub, en ook bestuurslid en medeoprichter van de stichting. Sindsdien zit er niet alleen een groepje van zes toegewijde ontwikkelaars, maar ook een smak geld achter het project.

Tegenwicht tegen Google en Apple

Dat project heeft een duidelijke missie, aldus Kling: "Het doel is om diversiteit aan het browserecosysteem toe te voegen door een gratis en opensourcebrowser voor een groot publiek te maken." Daaraan ligt een concrete tegenbeweging tegen de grote browserengines ten grondslag, want volgens hem is praktisch iedere gangbare browser uit dezelfde bouwstenen opgebouwd. Apples WebKit-engine is bijvoorbeeld een fork van Khtml. Google Chromiums Blink is weer een fork van WebKit. Daarmee zijn praktisch alle grote browsers, waaronder Safari, Chrome, Edge, Opera, Brave en Vivaldi, verre familie van elkaar. Alleen Gecko staat daar relatief los van.

Wat doet een browserengine?

De browserengine is het onderliggende gedeelte van de webbrowser dat verantwoordelijk is voor het vertalen van informatie van internet in een visueel element. In Klings woorden: "Browserengines zijn zeer gecompliceerd. In een notendop: de software vertaalt HTML en CSS, rendert dat naar een bitmap en toont het resultaat op het scherm." Volgens hem staan browserengines verder vrij los van het onderliggende systeem. "Het grootste gedeelte van een engine komt nooit in aanraking met het platform. Er zijn slechts een aantal interactiepunten tussen de engine, de pc en het besturingssyteem."

Kling wil naar eigen zeggen een stap terug doen en zijn engine zonder alle 'door de jaren heen ingebakken en vaak onnodige functies' opbouwen. Hij neemt daarvoor de huidige engines als voorbeeld, maar negeert de functies en eigenschappen waar de meeste gebruikers geen baat bij zullen hebben. Ladybird moet volgens de maker meer als een videogame ontwikkeld worden, wat betekent dat vooral naar de toekomst gekeken wordt. "We maken de engine niet voor oudere hardware. Een twintig jaar oude computer, daar houden we geen rekening mee. Misschien laten we toestellen met 1GB ram, een heel klein scherm of met legacybesturingssystemen van acht jaar oud ook achterwege."

Met andere woorden, hij neemt aan dat het geavanceerde ontwikkelaarssysteem dat hij nu gebruikt, over een paar jaar een 'gewoon' systeem is van de gemiddelde gebruiker. Dat zou volgens hem in contrast staan met de grote enginemakers, die hun browserfundament ook voor oude toestellen en nichesystemen willen ontwikkelen. Dat staat in het verlengde van het onderliggende doel van Google en Apple: respectievelijk een 'advertentieplatform onderhouden en hardware verkopen'.

De 'goede buur'-filosofie

Dat wil niet zeggen dat hij niets van de grote drie heeft geleerd. Sterker nog, Kling werkte zeven jaar bij Apple aan WebKit, specifiek aan de impact van de browserengine op de accuduur van een toestel, iets wat hij een 'ondergewaardeerde prestatiemaatstaf' noemt.

Je zou wellicht denken dat optimaliseren voor accuduur, ofwel het zo efficiënt en zuinig mogelijk maken van een applicatie, alleen van toepassing is op software voor draagbare apparaten. Maar Kling werd duidelijk door deze ontwerpfilosofie beïnvloed, ook wat de desktopversie van Ladybird betreft. "Ik vind dat software altijd een 'goede buur' moet zijn; applicaties moeten beleefd zijn naar elkaar en het gedeelde systeem. Je wil niet dat een programma onnodig alle middelen opeist."

"Je wil niet dat een programma onnodig alle middelen opeist."

Dit is direct ook een uitdaging voor hem als onafhankelijke ontwikkelaar. Apple heeft als hard- en softwaremaker heel veel mogelijkheden om die losse systemen met elkaar te laten samenwerken, Kling niet. Hij stelt: "Besturingssystemen zouden meer moeten doen om te duiden welke middelen beschikbaar zijn. Er zijn wel api's die dat mogelijk maken, maar de informatie die daaruit voortkomt, is vaak heel 'korrelig' en onduidelijk."

Onveilig fundament

Dat is overigens lang niet de enige uitdaging die hij moet zien te trotseren. Zo is de browserengine grotendeels in de relatief onveilige programmeertaal C++ geschreven. Volgens de GitHub-pagina van Ladybird gaat het om zo'n 85 procent van de volledige codebasis. Dat was niet zozeer een bewuste keuze, geeft Kling toe. "Ik begon met SerenityOS en Ladybird als een hobby, dus koos ik gemakshalve C++; die taal beheerste ik al."

Het probleem is dat C++ een memory unsafe-programmeertaal is, wat wil zeggen dat de taal fundamenteel kwetsbaar is voor bugs en aanvallen die met geheugentoegang te maken hebben. Of zoals Kling het beschrijft: "C++ heeft geen vangrails. Je kunt het vertellen om iets te doen wat het niet zou moeten doen en dan doet de taal dat gewoon. Modernere talen (zoals Rust, Swift en C#, red.) maken dit moeilijker.""C++ heeft geen vangrails."

Software vertalen in een volledig andere programmeertaal is echter niet eenvoudig. Het team achter Ladybird is nog bezig met het zoeken naar een geschikte programmeertaal en wil dan in eerste instantie stapsgewijs de kwetsbare onderdelen van de engine vertalen die bijvoorbeeld in aanraking komen met untrusted netwerken.

Project in kinderschoenen

Hij benadrukt dat het project echter nog in de kinderschoenen staat en dat de stichting voorlopig bezig is met het introduceren van basisfuncties in de browser en onderliggende engine. "We zullen nooit het budget van Google hebben en moeten onze strategie daarop aanpassen." Hij typeert Google dan ook als een bedrijf dat heel progressief nieuwe functies in de engine implementeert en ontwikkelaars daar snel mee laat experimenteren. "Wij doen het rustiger aan en kijken kritisch welke functies we wel en niet nodig hebben."

Daar komt ook nog een heel praktische beperking bij kijken: de grootte en kennis van het team. Het welbekende probleem van opensourceprojecten is namelijk dat er niet op grote schaal werknemers ingehuurd kunnen worden. Bij de aankondiging van Ladybird als losstaande browser werden dan ook macOS en Linux als doelplatforms genoemd, terwijl het dominante Windows achterwege bleef. Daarover zegt Kling: "Ik ken Windows niet goed genoeg om het project effectief te porten naar dat besturingssysteem. We hebben geen werknemers die dat kunnen." Hij belooft dat de browser op den duur uitkomt voor Windows, maar dat het team zich vooralsnog op basisfuncties wil richten. "Porten naar Windows kan op ieder moment in het proces."

Over de toekomst gesproken, het Ladybird Browser Initiative heeft, inclusief een recente donatie van 200.000 dollar van de FUTO-organisatie, genoeg financiële middelen voor nog ten minste 1,5 jaar. Kling breidt zijn team naar eigen zeggen met die overlevingstermijn in het achterhoofd uit en groeit niet zo 'snel en explosief als een start-up dat zou doen'. Volgens de huidige planning moet van Ladybird ergens in 2026 een alfaversie uitkomen, met een bètarelease in 2027. De volledige releaseversie moet in 2028 uitkomen.

Reacties (119)

[svennd]

Om c++ nu als inherent onveilige taal te beschrijven vind ik nu toch ook heel sterk overdreven... er zijn beperkt vangrails maar iedere programmeertaal kan verkeerd gebruikt worden en veiligheid in gedrang brengen.

[LOTG]

Ik vind het ook wat raar om C++ inherent onveilig te noemen, maar ik vind het ook wat kort door de bocht om te zeggen dat elke taal verkeerd gebruikt kan worden.

Het gaat hier niet om verkeerd gebruiken, maar om problemen door iets kleins te missen. Overigens zijn er ook al jaren libraries waarmee je smart pointers kunt gebruiken die het een stuk simpeler maken om het goed te doen.

Ook niet 100% water dicht maar komt wel dicht in de buurt van memory managed op sommige vlakken.

Ik denk ook dat het niet mee helpt in de perceptie dat unmanaged memory unsafe word genoemd in die context. Het is niet onveilig perse, maar je moet er zelf voor zorgen dat het veilig gebruikt word.

[ikt]

Moderne C++ leunt vrij hevig op zeer goede reviews om issues te spotten die er redelijk makkelijk in te sluipen zijn. Dingen als handmatig geheugen alloceren is al een tijd de wereld uit, maar een zeer recent voorbeeld van een high-impact derp is bijvoorbeeld ongeïnitialiseerd (of niet geïnitialiseerd zoals verwacht) geheugen. Er zijn letterlijk meer manieren dan je op je handen kunt tellen om een ding te initialiseren en enkele ervan gedragen zich anders bij verschillende types dat ze zijn.

Ik ben vrij groot fan van C++, maar het is alles behalve inherent veilig.

[kevints]

Ik vind het alsnog onzinnig om dit op deze manier te benoemen in een Tweakers-artikel. Een van de meest gebruikte talen af schrijven als "onveilig" klinkt als iets wat een nu.nl zou schrijven over iets waar weinig verstand van is. Ik zie ook geen "waarschuwing" staan dat Java "inherent traag" is wanneer er nieuws is over iets wat in die taal is gebouwd

[Grauw]

Tweakers schrijft gewoon op waar in het interview over gesproken is.

En het is de misschien oncomfortabele waarheid: het is ontzettend makkelijk om in C++ bijv. out of bounds of use after free fouten te maken die random memory corruption tot gevolg hebben. Dat is geen skill issue. Memory safety problemen veroorzaken de meerderheid van de CVEs, en dat is een groot probleem. C++ wordt al door door bepaalde overheidsinstanties (zoals de Amerikaanse) sterk afgeraden, en loopt het risico om op termijn helemaal verboden te worden voor bepaalde kritieke systemen.

De taal moet veiliger worden wil hij overleven. Bjarne Stroustrup himself heeft er recent de keynote van CppCon 2023 aan gewijd.

[Reactie gewijzigd door Grauw op 25 juli 2024 09:28]

[YannickSpinner]

Ten eerste staat er dat C++ een 'relatief onveilige programmeertaal' is en daarna wordt door de bron uitgelegd waarom hij dat vindt, met de kanttekening dat het om een memory unsafe-taal gaat. Dit is een algemeen geaccepteerde eigenschap van C++. Als je die term opzoekt, zal je C++ altijd als voorbeeld daarvan tegenkomen. Ik snap dat je reageert vanuit een vraag naar nuance, maar die komt mijns inziens in het artikel prima naar voren!

[Reactie gewijzigd door YannickSpinner op 25 juli 2024 16:28]

[Memori]

Het is vooral belangrijk om goed de documentatie te lezen van de verschillende functies, ongeacht de taal die je gebruikt. Vatbare code ontstaat vooral doordat programmeurs stukjes code copy-pasten van de documentatie of stackoverflow (en nu ook AI), of doordat programmeurs denken dat ze precies weten wat de functie doet.

Sowieso kent programmeren een lange historie van talen ontwikkelen die het makkelijker zou maken voor "de gewone mens" of voor een speciale doelgroep (wetenschappers). Maar laten we niet vergeten dat programmeren zelf een zeer gespecialiceerd vak is, en voor echte specialisten zal "veilige" of "onveilige" taal geen afweging zijn.

Wat dat betreft mogen de opleidingen van programmeren wel wat strenger, want op dit moment leveren ze wellicht professionals, maar geen specialisten.

[84hannes]

Vatbare code ontstaat vooral doordat programmeurs stukjes code copy-pasten van de documentatie of stackoverflow

Kun je deze bewering onderbouwen? Ik denk dat de meeste C/C++ prima in staat zijn zelf onveilige code te schrijven, daar hebben ze echt geen stack overflow voor nodig.

[Memori]

Bewering is vooral anekdotisch. In development kantoren waar ik binnen loop, of de programmeurs die ik spreek, gebruiken stack overflow veelvuldig. Helemaal niets mis mee natuurlijk, maar waar de grens tussen professionals en specialisten zit is dat specialisten zorgvuldig zijn en de documentatie goed te doorlezen en te begrijpen in plaats van blind copy-pasten, snel te willen doen, of de documentatie skimmen.

Zo weet ik (zonder namen te nomen) van een bepaalde AAA spel met budget van 100 miljoen, volgens de
programmeurs zelf, voornamelijk is gebouwd met stack overflow antwoorden.

[turbojet80s]

Je kunt stackoverflow gebruiken terwijl je heel goed kunt lezen en begrijpen wat er staat? Netzoals je een voorbeeld brief van het internet download en deze naar eigen wens aanpast. Als je de taal goed beheerst en de taal goed in elkaar zit dan hoeft dit niet per se een probleem te zijn.

[Memori]

Uiteraard. Maar mijn punt is dat velen antwoorden en voorbeelden zullen copy-pasten & zien of het compiled, zonder de tijd te nemen om de documentatie van functies in kwestie goed te doorlezen en te begrijpen, en na te denken over wat voor effect het op de huidige code heeft.

Al kan het ook zijn dat ik gewoon in een bubbel leef waar dit veel gebeurt. Zoals ik al heb gezegd: het is anekdotisch.

[84hannes]

gebruiken stack overflow veelvuldig

Dat ontken ik niet. Maar een use-after-free of out-of-bounds is zo makkelijk in C, daar heb je geen bronnen voor nodig.

[biteMark]

Hoe meer valkuilen er in de weg zitten, hoe gevaarlijker de weg is om te bewandelen. Software bevat fouten, zelfs in Hello World kan een fout zitten ("HELLORLD" ~ Usagi), dus het is belangrijk om een taal te kiezen die je helpt om de gevaarlijkste fouten te voorkomen.

[Powerblast]

C++ is in de bron zo onveilig als het kan. Het laat je alles toe en vertrouwt erop dat jij als programmeur het wel beter zult weten. Dat is ook één van de redenen dat het een zo snelle taal is, geen safe guards of amper.

Ik heb er zelf niet erg veel ervaring mee, maar elke keer als ik in c++ begin moet ik letterlijk bij elke regel code gaan nadenken of ik geen bug schrijf. Probleem is vooral vind ik dat elke regel potentieel verkeerd kan zijn maar dan op technisch niveau (geheugen niet gealloceerd, verkeerd gealloceerd, niet vrijgegeven , dubbel vrij gegeven, enz..). Bij andere talen gaat het in mijn ervaring meer over functionele fouten, het programma doet niet exact wat je wil. Zal natuurlijk ook een kwestie van ervaring op doen zijn.

Ik denk dan wel bij mezelf, dit wil ik precies niet in productie gebruiken . Mijn ervaring is in ieder geval dat je erg goed moet weten wat je doet in c++ en dat "learning on the job" daar veel gevaarlijker uit kan draaien dan bij andere talen.

[Reactie gewijzigd door Powerblast op 22 juli 2024 18:32]

[juke1349]

Ik vind het volledig normaal om C én C++ inherent onveilig te noemen.
het probleem aan beide is dat hun pointers oppermachtig zijn, en je er op geen enkele manier beperkingen aan kunt opleggen. Als er ook maar érgens in je één foutje is, is je hele state space in gevaar.

En zelfs als jij braaf over 'moderne' smart pointers gebruikt, een van je dependancies heeft vást nog wel een of-by-one error in zijn legacy pointers, en hoppa, overschrijft je stack-frame. Remote Code Execution is dan vrijwel altijd mogelijk.

Kortom, tenzij 100% van je héle codebase 100% in 'modern' C++ geschreven is, én niemand een van de duizenden obscure Undefined Behaviour regels over het hoofd heeft gezien, heb je nul garantie, en niet eens een manier om het vast te stellen.

Dit in tegenstelling tot Python, Java, Swift, Go, en Rust, waar dit soort pointer-magie opt-in is (evtl achter "native" extensies verstopt) . Als je dat niet gebruikt, heb je dus wél garantie.

[MSalters]

In een modern C++ programma zijn verreweg de meeste pointers smart pointers, en daar kun je zeker wel beperkingen aan opleggen. Je hebt ook veel minder pointers nodig dan in C, omdat C++ iterators gebruikt waar je in C pointers nodig hebt om door collecties heen te lopen.

Ik ben het helemaal met je eens om het te hebben ove "moderne" smart pointers, want die zijn al een kwart eeuw oud. Maar als jij denkt dat Remote Code Execution een gevolg is van verkeerde pointers, dan heb je ook al een vergelijkbare periode aan ontwikkeling gemist. "W^X" (write xor execute) stamt uit 2003. Dat blokkeert al 95% van de RCE vulnerabilities in ouderwetse C code.

En "duizenden obscure Undefined Behavior regels"? Ik durf het geen handjevol te noemen, maar het zijn er een paar dozijn. Obscuur? Variabelen initialiseren voor gebruik, threads synchroniseren, het is voor een groot deel redelijk vanzelfsprekend. Ja, er zitten wat obscure hoekjes voor backwards compatibility met C, maar dat geeft in normaal gebruik niet zo'n probleem.

[Creesch]

Specifiek memory unsafe, wat simpelweg klopt. Memory safety in een programmeertaal betekent dat de taal mechanismen biedt om veelvoorkomende memory-gerelateerde fouten te voorkomen, zoals buffer overflows, dangling pointers en arbitrary memory access. Dit zijn specifiek het soort fouten die kunnen zorgen tot onvoorspelbaar gedrag, crashes en dus ook veiligheidslekken. Memory safe talen dwingen regels af om ervoor te zorgen dat programma's geen illegale geheugenbewerkingen uitvoeren.

Er zijn veel talen die wel memory safe zijn. Rust hoor je tegenwoordig vaak als taal die veel gekozen wordt ipv C++ maar er zijn meer talen zoals Java, C#, Swift, Go, Haskell, etc.

In die context is C++ potentieel minder veilig. Of om het iets anders te verwoorden, het is in C++ makkelijker om onveilige zaken te implementeren. Nu kan dit enigszins worden gemitigeerd met ervaring en een goed review proces. Dat neemt niet weg dat het nog steeds mogelijk is dat er fouten in sluipen op dit gebied. Bij een het gebruik van een memory safe taal is dit een factor die minder meespeelt.

[nst6ldr]

Dit zou overigens echt geen issue mogen zijn vandaag de dag, als je een beetje respectabel ontwikkelaar bent heb je een deftige CI/CD pijplijn met in ieder geval statische code analyse als geautomatiseerde controlestap. Laatstgenoemde gaat echt wel klagen over het slordig aanwenden van geheugen, waardoor je überhaubt niet kan mergen naar de master branch.

[Creesch]

Laatstgenoemde gaat echt wel klagen over het slordig aanwenden van geheugen, waardoor je überhaubt niet kan mergen naar de master branch.

Een static code analyse tool zal de meest voor de hand liggende zaken inderdaad detecteren. Maar echt niet alles, deze tools zijn dan ook niet heilig. Zeker een essentieel hulpmiddel om het risico te verminderen, maar je neemt het er niet mee weg.

[CAPSLOCK2000]

Dit zou overigens echt geen issue mogen zijn vandaag de dag, als je een beetje respectabel ontwikkelaar bent heb je een deftige CI/CD pijplijn met in ieder geval statische code analyse als geautomatiseerde controlestap. Laatstgenoemde gaat echt wel klagen over het slordig aanwenden van geheugen, waardoor je überhaubt niet kan mergen naar de master branch.

Het hoeft geen groot issue te zijn maar fundamenteel gezien wil je het hele proces zo simpel mogelijk houden. Iedere extra stap levert extra werk en extra kans op fouten op. Voorkomen is beter dan genezen.

[Halfscherp]

Leuk verhaal, maar als zelfs puissant welvarende bedrijven als Google, Meta en Microsoft hele sloten aan CVEs hebben, en ~80% van die CVEs memory-gerelateerd zijn…

Je moet een vrij hoge pet van jezelf ophebben als je denkt dat het jou niet overkomt.

[nst6ldr]

Bijzonder interessant hoe je bij die bedrijven gewerkt hebt, proficiat. Toevallig weet ik in ieder geval van Microsoft en Meta dat inderdaad niet alle projecten met zo'n robuuste repository worden opgezet. Het zal je niet verassen dat tenslotte ook daar gewoon mensen werken met verschillende niveaus van expertise, net als bij andere bedrijven. Bij Google heeft bijvoorbeeld Android dermate laag aanzien dat de sterspelers van het bedrijf er liever niet ingedeeld worden.

[Powerblast]

Moest het zou eenvoudig zijn, dan zou de algemene trend niet zijn om meer en meer van c++ weg te "willen" navigeren. Het lukt op dit moment nog niet omdat de alternatieve nog niet echt er klaar voor zijn in mijn beeld. Maar ik denk dat eens er een taal komt die én de snelheid van c++ bied én de safety van een managed taal, maar dan zonder GC er weinigen zullen zijn die niet over willen.

Rust is nu die weg wel aan het opgaan maar op dit moment naar mijn mening niet echt beginner friendly. Syntax wijkt me ook iets teveel af van wat ik in c style languages gewend ben.

Ik deel zelf de talen die ik gebruik ook nog eens in in twee categorieën:
1. ééntje die ik als hobby wil gebruiken
2. ééntje waar ik productie code mee schrijf

C++ is natuurlijk meer dan production ready. Maar ik ken die gewoonweg niet goed genoeg om ff wat productie code te schrijven.

[Reactie gewijzigd door Powerblast op 22 juli 2024 18:52]

[nst6ldr]

Dat ik het kan samenvatten in een reactie wil niet zeggen dat het eenvoudig is.

[The Zep Man]

Verschillende programmeertalen hebben verschillende aanleg voor beginnersfouten. Natuurlijk kan een beginner fouten maken in een "managed" taal. De kans is een stuk groter dat een beginner (meer) fouten maakt in een "unmanaged" taal, zoals C/C++.

[Alfa1970]

Voor dergelijke producten zet je geen beginners in.
Dit zijn projecten met een enorm exposure oppervlak, dat laat je aan je veteranen over.

GC's zijn ook geen garantie dat je geheugen problemen oplost.
Er zijn ook nieuwe zwakheden die je ermee introduceert.
En met een product als een web browser zijn dit soort zwakheden relatief makkelijk uit te buiten.

Daarnaast, static code analyzers zijn tegenwoordig heel goed in staat om problemen met memory management te vinden.
Kijk maar naar Rust waar de compiler dat feitelijk standaard doet (nog buiten het hele ownership verhaal om).

[Reactie gewijzigd door Alfa1970 op 22 juli 2024 15:21]

[Yoshi]

mja, dat is wel gewoon de tendens ivgl met talen zoals Rust. Daar kan je ook onveilige (geheugen) zaken doen en maken maar hoe de taal is opgezet maakt dat je het sneller bewust moet doen en dat is niet zo bij c++. Ze omschrijven het ook niet als inherent onveilige taal (ze gebruiken ook het woord relatief...), ze plaatsen daar netjes context bij (die van de vangrails vind ik wel netjes) dus mij lijkt, als je de volledige alinea leest, wel gewoon correct neergeschreven te zijn.

[Harm_H]

Goed artikel inderdaad. Alleen die paragraaf over vangrails stootte me ook tegen het zere been. C++ lijkt me juist mooi omdat het zo goede performance kan geven mits goed ingericht. Het is meer een extra developer uitdaging dan een security issue bijvoorbeeld.

[blorf]

Als de kans op non-terminated strings een probleem is verbiedt je dat toch gewoon voor de compiler? Alles met chars < 32 voor de terminator = errort...
Het "probleem" is wat een C++ compiler allemaal kan als het onder admin/root draait. Dat kunnen for-profit platformen niet goed verdragen omdat op die manier iedereen alles zelf kan regelen zonder een serieus limiterend app-framework nodig te hebben.

[MSalters]

Sorry, maar wat je schrijft heeft erg weinig met C++ te maken.

Je compiler ziet je runtime input per definitie niet. "chars<32" ? Je compiler heeft geen idee wat er in argv[] gaat zitten. Maar wat boeit dat? Null-terminated is chars <1, niet <32. En argv[] is null-terminated. Verder in je programma heb je gewoon std::string, en die kan prima tegen embedded nullen.

En een C++ compiler draait dus ook helemaal niet met admin/root. Het vertaalt Unicode sources naar binary. Dat hoeft niet eens lokaal uitvoerbare binary code te zijn; ARM cross-compilers op x86 produceren ARM code die de x86 CPU niet eens snapt.

En for-profit platformen? Ik heb niet eens een ruw idee wat je daar probeert te zeggen.

[blorf]

Waar ik met een enkel voorbeeld op doelde is dat mogelijke problemen door het memory-unsafe zijn van een C/C++ compiler zowel met code als met externe programmatuur uitgesloten kan worden via dezelfde route als de problemen binnen kwamen. Het bezwaar is eigenlijk gewoon dat het te complex is en/of teveel tijd kost. Misschien speculatief, maar ik zeg economische propaganda uit de ecosystemen-markt. Low-level is teveel controle voor de stomme eindgebruiker. Die moet in de zandbak blijven, ver van de machine.

[MSalters]

Wat boeit het dat de C++ compiler memory unsafe zou zijn? Overigens kun je prima een C++ compiler in Rust of zo schrijven. Het is uiteindelijk maar een data transformatie. Instructies vertalen naar andere instructies.

En ook hier weer, ik heb geen idee waar je met de ecosystemen heen wil. C++ is efficiënt ja. Dat is vooral handig in de embedded wereld.

[blorf]

Mij niks. Het kwam hier voorbij als gerelateerd onderwerp.Waarom ga je er op in als je het totaal niet volgt?

[Alxndr]

de relatief onveilige programmeertaal

Nogal een belangrijk woord wat je weglaat of parafraseert. Of wil je tegenspreken dat C++ een memory unsafe-programmeertaal is?

"...maar iedere programmeertaal kan..."
Dit is geen argument maar is een drogreden: tu quoque (jij-bak).

[berchtold]

Iedere taal kan verkeer gebruikt worden maar van alle talen is c++ wel degene die al kapot kan gaan als je er al verkeerd naar kijkt.

[nandervv]

Daarom noemt één van de makers van C null pointers zijn billion dollar mistake. Alles met nullpointers, pointer-arithmetic etc is inherent onveilig.

[analogue]

Ik juich dit van harte toe en ik snap eigenlijk niet zo goed waarom "we" het zo hoog laten oplopen. Die dominantie op de browsermarkt is al jaren een onderwerp van zorg en er wordt wel veel over gesproken maar tot nu toe is het nog niemand gelukt om zover te komen.
Nu snap ik wel dat een browser maken geen makkelijke taak is, commerciële partijen zullen het niet aandurven vanwege een gebrek aan verdienmogelijkheden en hoge kosten. Voor open source projecten in het misschien normaal gesproken een veel te grote kluif.

M.a.w. ik heb zeer veel respect voor deze mensen en hoop dat ze alle steun zullen krijgen die ze nodig hebben.

[Creesch]

Ik juich dit van harte toe en ik snap eigenlijk niet zo goed waarom "we" het zo hoog laten oplopen.

Omdat de lat simpelweg erg hoog ligt. Een browser is tegenwoordig praktisch een besturingsysteem op zich qua functionaliteit. Naast het "simpele" tekst renderen (wat al niet simpel is) moet een browser media kunnen afspelen, 3d renderen, een javascript engine bezitten, etc, etc.

Zelfs als we een hoop legacy negeren is het maken van een browser simpelweg een grote uitdaging.

[analogue]

Ja je omschrijft met meer woorden wat ik in deel twee van mijn reactie ook schreef. Ik snap de technische uitdagingen en de hoge kosten. Maar tegelijkertijd is die discussie rondom browserdominantie niet van vandaag en zelfs niet van gisteren. We zijn wel bereid om heel veel energie te steken in allerlei andere software zoals nieuwe programmeertalen, de zoveelste linuxvariant en doe nog maar een indiegame. Maar datgene wat de integriteit van het internet kan beschermen laten we het wel een beetje afweten vind ik.

[Creesch]

Ik denk oprecht dat je inschatting van effort nog steeds erg laag is.
Het ontwikkelen van een nieuwe programmeertaal is in veel opzichten simpeler dan een browser ontwikkelen. Ook het maken van een linux variant is relatief gezien peanuts. Dat staat ongeveer op het niveau van een browser op basis van Chromium ontwikkelen.

En een indiegame ontwikkelen is ook vele malen toegankelijker dan een browser ontwikkelen.

In bijna alle gevallen ben je ook veel eerder op een punt waar meer mensen je product kunnen gaan gebruiken.

[analogue]

Ik denk dat het vooral een probleem van organisatie is. Ik loop al lang mee in de foss wereld en het is lastig om mensen langdurig vast te houden. Mijn punt is dan ook dat als men zoveel energie steekt in dergelijke projecten dan zou een dergelijke groep gezamenlijk over de loop der jaren prima in staat zijn geweest om een 4e of 5e browser te ontwikkelen.

Dus ja ik praat misschien wat makkelijk over wat jij effort noemt, maar als dit zo belangrijk is voor techminded mensen en met name mensen in de foss wereld dan zou je toch verwachten dat die beweging wel ooit gemaakt zou zijn?

Of we vinden het toch allemaal wel best met die browsers en hechten een stuk minder aan een onafhankelijk internet dan we doen blijken.

[Werelds]

Organisatie of wil is echt het probleem niet.

Een browser vanaf de grond af ontwikkelen is zoals @Creesch zegt veel moeilijker dan allerlei andere projecten die velen als moeilijk beschouwen omdat het juist veel van dat soort andere projecten omhelst. Programmeertaal ontwerpen? Nee, maar je moet wel een hele berg aan talen (programmeertalen en markuptalen) af handelen. Enkel al XML/HTML, CSS en JS geeft je al zat te doen. Dan hebben we het nog niet gehad over de verschillende gestandaardiseerde API's; relatief simpele dingen zoals datums, maar ook Intl, WebGL, WASM en ga zo maar door.

En dan heb je nog niets van dat alles op je scherm, laat staan dat het allemaal correct (spec-compliant), geoptimaliseerd én veilig is.

Om de vergelijking met je voorbeelden te trekken: een programmeertaal stelt echt niet zo veel voor in verhouding, dat moet je voor een browser meerdere malen doen. Een Linux variant? Zou je die vanaf de grond op bouwen zonder het te baseren op een bestaande distro of gebruik te maken van een bestaande DE, tuurlijk. Maar de meeste Linux varianten zijn inderdaad hetzelfde als de zoveelste Chromium-browser maken. Een indiegame maken? Zelfde principe, je kiest een engine en je gebruikt hun tools. Hoe dat ding rendert maak je je geen zorgen over. Had je nou gezegd zelf een volwaardige game engine maken was het een ander verhaal geweest, maar dat gebeurt tegenwoordig ook nauwelijks meer. Als indiedev ga jij gewoon Unity, Unreal of Godot gebruiken

[analogue]

Ik krijg spijt van die vergelijking met programmeertalen e.d. Want die leidt af van wat ik er mee wil zeggen. Laat ik het nog eens proberen, je bent een dev met wat vrije tijd over. Ga je dan aan een project werken waar je snel(ler) meters kunt maken of ga je aan zo'n monsterklus werken als een browser?

Die beren die je noemt zijn problemen die die developers ook zien en dus starten ze zo'n project niet. Mijn hypothese is dat met goed organisatie je die mensen wel degelijk zou kunnen verleiden om aan een dergelijk project te gaan werken. Organisatie is dus, iemand met een visie die weet hoe hij/zij mensen kan binden, motiveren en ook eventueel financiële zaken op orde kan maken, zij het door donaties/sponsoring/pick your poison.

Om even wat meer te duiden dat ik echt wel snap hoe complex zo'n browser is, ik ben zelf ook developer en package maintainer (geweest) bij diverse linux distro's en heb dus ook regelmatig met exact dit probleem te maken gehad op andere vlakken.

[Mellow Jack]

Als je het niet over de financiële kant kan oplossen heb je een gedeeld probleem nodig wat je wilt oplossen. Op dit moment heb je die niet echt in de browser wereld. Tenminste, ik zie het probleem niet echt.

[mac1987]

Eens, en de potentiële impact op de wereld is bij een fatsoenlijke FOSS browser een stuk groter dan niche Linux variant 321. Misschien iets om via crowdfunding goed op de rails te krijgen?

[Horatius]

Nieuwe software/programmeertaal en een nieuwe browserengine kan je ook naar mijn mening niet vergelijken. Want ja het is technisch complex maar het aandeel wat het veel moeilijker maakt is niet het technische gedeelte an sich.

Een browser moet supersnel zijn en wordt continu gebruikt met een gigantische brede scope. Wanneer je een nieuwe programmeertaal leert of andere generiekere software dan leer je met de quirks omgaan of ga je er omheen.
Bij een browser is dat simpelweg veel moeilijker, de gebruikers doen continue dezelfde actie en dat is een webpagina laden. Dit moet zo snel mogelijk zijn, dat alleen al is technisch enorm lastig. Als je hierop niet concurreert is je browserengine bijna nutteloos.

Het eindproduct is voor zo een gewone consument zo belangrijk dat een userbase voor zoiets krijgen enorm lastig is. Kijk naar Firefox, concurreert enorm goed maar bijna al mijn mededevlopers gebruiken edge of Chrome omdat het simpelweg beter werkt voor hun. En dat zijn juist de mensen die fanatiek hierover zijn.

[morrowyn]

Het is aan de politiek en wetgeving wat de integriteit van het internet moet beschermen.

Neem b.v. netneutraliteit of privacy, concepten waar heel wat belangen met elkaar botsen.

Een browser kan daar zeker in helpen, maar het is niet de oplossing, die ligt bij burger, consument, producent en overheid.

[The Zep Man]

Omdat de lat simpelweg erg hoog ligt. Een browser is tegenwoordig praktisch een besturingsysteem op zich qua functionaliteit. Naast het "simpele" tekst renderen (wat al niet simpel is) moet een browser media kunnen afspelen, 3d renderen, een javascript engine bezitten, etc, etc.

Ik erken dat een browser complex is, maar het is niet praktisch een besturingssysteem. Het doel van een besturingssysteem is om als de tussenlaag tussen hardware en andere software te dienen. Browsers gedragen zich vanuit het perspectief van een besturingssysteem gewoon als user-space applicatie (inclusief beperkte rechten). Er wordt wel op veel punten ingehaakt (invoer, netwerk, beeld, geluid, en wat meer exotische zaken zoals NFC-lezers en Bluetooth), maar al die punten worden nog steeds gefaciliteerd door het besturingssysteem aan een applicatie en niet door directe interactie met hardware.

[Creesch]

Technisch gezien heb je hierin gelijk. Waar het om mij omgaat in die vergelijking is dat naast besturingssystemen er weinig andere software is die een dergelijke complexe diversiteit aan functionaliteit afhandelt. Zeker geen software wat in feite ook een platform is voor andere software om op te draaien. In die zin is het een prima vergelijking om aan te duiden hoe complex een browser is.

[Mellow Jack]

Toch precies hetzelfde wat een browser doet? Het gooit een abstractie laag over het OS heen. Het regelt audio, video en input. Vanuit applicatie perspectief zie ik weinig verschil. Bottom up is het idd compleet iets anders maar top down zijn er weinig verschillen.

[CAPSLOCK2000]

Ik juich dit van harte toe en ik snap eigenlijk niet zo goed waarom "we" het zo hoog laten oplopen.

Ik denk dat je nadruk op het woord "we" al aangeeft waar het probleem zit. Er is niet één "we".

De grote techbedrijven ontwikkel(d)en browsers in hun eigen belang en hebben verschillende manieren om gebruikers daar naar toe duwen. Wat dat betreft is het tekenend dat MS en Apple zijn gestopt met hun eigen engines en die van Google zijn gaan gebruiken. Ik weet nog steeds niet of dat is omdat ze de kwaliteit van hun product verbeteren niet belangrijk vinden of omdat ze denken dat concurrentie met Google onmogelijk is.

Daarmee is het grootste deel van de softwaremarkt al uitgeschakeld.

Browsers als Firefox en Ladybird lopen er ook tegen aan dat er steeds meer technologie is die ze eigenlijk niet zelf kunnen of willen implementeren. Zaken als DRM en Manifest V3 zijn er niet in het belang van eindgebruikers maar voor de zakelijke belangen en partners van de techreuzen. Dat levert moeilijke keuzes op zoals de vraag of het beschermen van de privacy van je gebruikers belangrijker is dan een werkende website. Of de vraag hoe je om moet gaan met commerciele codecs in een gratis browser. Het concept van een vrije & gratis browser valt om als alsnog moet betalen voor codecs. Soms kun je codecs van het OS gebruiken maar dat is geen gegeven.

Het gaat beter als er wordt gewerkt via open standaarden die iedereen kan implementeren, maar het wordt steeds meer een eenzijdig Google-feestje waarbij Google het tempo en de richting van nieuwe ontwikkelingen bepaalt en de rest achter een bewegend doel aanrent.


De andere "we" die de middelen heeft om zo'n project te draaien is de overheid. Ik voel wel wat voor een "Publieke Softwaredienst", net zoals we een Publieke Omroep hebben die televisieprogramma's maakt (of laat maken) in het algemeen belang als de commerciele omroepen dat niet doen.
Die dienst moet er op toen zien dat essentiele software zoals een webbrowser voor iedereen beschikbaar is zonder afhankelijk te worden van een enkel bedrijf. Ofwel door het zelf te (laten) maken ofwel via wetgeving, net zoals we er voor zorgen dat iedereen toegang heeft tot riolering en drinkwater.

[Creesch]

Wat dat betreft is het tekenend dat MS en Apple zijn gestopt met hun eigen engines en die van Google zijn gaan gebruiken.

Die klopt niet helemaal. Apple maakt voor Safari nog altijd gebruik van hun versie van WebKit. Wat niet gebaseerd is op Chromium. Sterker nog, Blink de render engine van Chromium (en dus Chrome) is een fork van WebKit.

[Jasperrr]

Codecs zijn maar een kleine deel van de rekensom. Een veel groter probleem is de implementatie van CSS standaarden. Dit gaat op dit moment al moeizaam genoeg met een zwaar achterstallige werkwijze van W3C over het opstellen en vervolgens een ellendig lange periode voordat zaken in browser engines opgenomen worden. Vervolgens duurt het nog jaren voordat iets echt gebruikt kan worden omdat je tot die tijd met achterstallige browsers zit die je wilt blijven ondersteunen. (Of je moet polyfills gebruiken die lang niet altijd stabiel zijn). Laat ze daar maar eerst met betere oplossingen voor komen.

[Blokker_1999]

Alleen wisselt de dominantie elke paar jaar wel. In de jaren 90 was het Netscape, daarna werd het IE en vandaag is het Chrome. Niemand kan zeggen wie over 10 jaar overheerst.

[marcelvb]

Ik vind het vooral jammer dat wij, tweakers, ook niet een beetje beter ons best doen om te zorgen dat er geen browser dominantie komt. Dat iemand die een telefoon of laptop koopt, de (de facto) standaard browser van het OS gebruikt kun je ze niet kwalijk nemen. Maar dat webdevelopers features gebruiken die alleen maar in een bepaalde browser werken is erg jammer. Is er iemand die nog wel eens op w3c.org kijkt en de html of css specs leest?

[Jasperrr]

Ik denk dat zeer weinig mensen de specs direct op W3C lezen, dat is vaak ook vrij overbodig. Leuk als je echt wilt weten hoe zaken onderwater werken maar het zegt weinig over de daadwerkelijke beschikbaarheid. Daarvoor kan je veel beter terecht op bijv een caniuse.com. Van mijn developers verwacht ik dan ook wel dat ze standaarden gebruiken die door alle grote browsers ondersteund worden.

[Remzi1993]

Maar dat webdevelopers features gebruiken die alleen maar in een bepaalde browser werken is erg jammer.

Dit wordt steeds minder omdat de dominate browser engines daarover afspraken hebben gemaakt dat die sinds jaren achter een feature flag zitten (dus een gebruiker moet het expliciet aanzetten) om het te kunnen testen. Dit zorgt ervoor dat we niet meer die taferelen hebben zoals --webkit en andere vendor specifieke CSS en dergelijke.

[blorf]

Probleem is de reclame-markt. Een browser die zich niet leent voor het systematisch pushen van commercie doet gewoon niet mee.
In dit geval heb ik ook weinig vertrouwen. Ze hebben het over budget en financiering. Het is gewoon een business-model. Waarschijnlijk hopen ze op Google of MS, als die er niet al in zitten, en zo niet, gaat het niet door.

[Reactie gewijzigd door blorf op 23 juli 2024 06:49]

[wsn1979]

C++ is wel heel erg krachtig, geheugen bescherming kán wel, echter vrij beperkt en grotendeels voorbehouden aan userland-functies. Een grote C++ codebase transformeren of compatibel maken voor Windows (.NET / C#) is een flinke klus inderdaad. Het zou fijn zijn als er meer keuze is en dit project goed van de grond komt.

[GertMenkel]

De Ladybird codebase gebruikt voor zover ik hem gelezen heb de moderne C++-features (C++23 als minimum) om dat risico te beperken, daar waar het mogelijk is. Het jammere van al die moderne features is dat je de oude features niet uit kunt zetten, dus hoeveel moeite je ook steekt in het tracken van lifetimes, iemand kan nog steeds ergens een wilde malloc() in gooien.

Dat gezegd hebbende, is loopt de Microsoft-compiler tegenwoordig op kop qua support van nieuwe features. Als je standaard-C++ schrijft (en dus geen G++-C++ of Clang-C++, ondanks de handige trucs die ze aanbieden), is compilen voor Windows niet zo'n drama. Wat betreft moderne toolkits zijn we gelukkig ver voorbij de tijd van MSVC++6.

.NET kan met allerlei manieren samenwerken met C++, dus ik denk dat dat wel te doen valt als men een .NET-wrapper maakt. Daarnaast wordt er gebruik gemaakt van Qt voor de GUI op Linux, wat ook een Windows-versie heeft; die aanpak lijkt me een stuk praktischer.

Of ze schrijven een wrapper in Visual C++, dan kunnen ze C++ voor .NET schrijven, the worst of both worlds

[MSalters]

Voor een dergelijk project is het niet heel moeilijk om malloc() in de linker uit te zetten. "operator new" kun je realistisch tegen de onderliggende OS API implementere, zonder malloc. Maar goed, dan verschuif je het probleem een beetje. "new int;" lekt alsnog geheugen.

[Hawkysoft]

echter vrij beperkt en grotendeels voorbehouden aan userland-functies

Je bedoelt dat de ontwikkelaar zelf zijn geheugenbeheer moet doen, zoals elke C/C++ ontwikkelaar zou moeten doen, in plaats van een garbage collector te gebruiken die dat voor je regelt?

[wsn1979]

Eigenlijk wel ja

We zijn ook zo verwend tegenwoordig met C#

[bigbadbull]

klopt ik hoor veel mensen klagen over pointer en memory problemen in C++, echter in 20 jaar tijd heb ik daar slechts 18 maand last van/met gehad.
Die 18 maand, was toen ik bezig was met 'onze' api/library te herschrijven voor een nieuwe database (van sequentiele database naar een relationele ) en van client server naar een hosted applicatie.
In onze eigen api deden we altijd alles op dezelfde manier en hoefden we er nooit meer bij stil te staan hoe de data in het geheugen verwerkt werd.
Na 25 jaar id de applicatie eindelijk vervangen door SAP.

[Creesch]

transformeren of compatibel maken voor Windows (.NET / C#)

Om een applicatie voor windows geschikt te maken hoef je geen gebruik te maken van .NET. C++ kan prima compileren voor windows. Neemt niet weg dat er wel windows specifieke aanpassingen gedaan zullen moeten worden. Maar dat is niet zo ingrijpend als omschrijven naar een andere taal.

[:murb:]

Het is interessant dat deze browser uit het niets zo ver komt. Servo, een project dat Mozilla jaren geleden begon om Gecko te vervangen (maar los heeft gelaten) en welke geschreven is in het veiliger geachtte Rust, is (in ieder geval wat betreft visuele presentatie) ondanks de voorsprong in tijd minder ver, zie deze screenshots (via een hackernews thread

* BBC homepage
* Wikpedia

(nb. De screenshots zijn ongeveer vijf maanden oud, maar Servo is echt niet veel beter geworden (net nog even gecontroleerd)).

Het kan natuurlijk zijn dat de architectuur van Servo meer doordacht is, en meer future proof is (of in theorie), vanwege de ervaringen met de Gecko engine, maar vanwege Andreas King's ervaring met de Webkit engine is er misschien nog iets anders aan de hand.

[Reactie gewijzigd door :murb: op 22 juli 2024 13:17]

[84hannes]

, een project dat Mozilla jaren geleden begon om Gecko te vervangen (maar los heeft gelaten) en

Volgens mij zijn grote delen van Servo weldegelijk in Firefox terecht gekomen.

Ik vind de manier waarop Gecko word afgeserveerd in dit artikel ook heel vreemd. Het nadeel van andere browsers is dat ze familie van elkaar zijn, al is Gecko de uitzondering. Browsers worden in onveilige talen geschreven, al is Gecko de uitzondering. Browsers worden gemaakt door advertentiebedrijven, als is Gecko wederom de uitzondering. Er wordt iets echt een reden genoemd waarom Kling niet gewoon bijdraagt aan Gecko, waardoor ik het gevoel krijg dat het louter eigenwijsheid is. Accugebruik wordt alleen als unique selling point genoemd omdat de auteur daar toevallig ervaring mee heeft, maar eigenlijk zie ik geen reden waarom deze engine beter is dan wat we al kennen. Maar we zullen zien.

[Ed Vertijsment]

Gecko is toch op enkele uitzonderingen na ook (grotendeels) in c++ geschreven?

En webkit is toch niet gemaakt door een advertentieboer?

[R4gnax]

Apple heeft z'n eigen advertentiedienst - weliswaar niet zo groot als MS of als koning-der-aarde Google, maar ze hebben er wel eentje.

En Gecko is grotendeels origineel geschreven in C++ maar wordt mondjesmate, onderdeel voor onderdeel omgezet naar Rust en andere veiligere talen. Een ander concept wat Mozilla gebruikt is om C++ door een transpiler heen te halen naar WebAssembly (WASM) en dat vervolgens weer naar C++ of Rust te transpileren. Door de tussenliggende stap met een WASM virtuele machine bewerkstellig je 'goedkoep' dat je geheugen en OS-API isolatie hebt. Goedkoper in veel gevallen waar er sprake is van 'talky' communicatie, dan met een formele sandbox. Want deze code kan in-process draaien, in tegenstelling tot een klassieke sandbox die out-of-process moet leven en waar dus marshalling (dure overhead!) gebruikt moet worden voor data-communicatie.

[Ed Vertijsment]

iAd bedoel je? Da’s toch uitgegaseerd, op wat kleine dingen na? Om Apple een advertentieboer te noemen vind ik wat ver gaan. En dat Gecko naar rust gaat klinkt leuk maar op basis van wat ik zie is dat slechts een paar procent. En ja ze zullen een slimme build toolchain hebben, ik sluit niet uit dat de Chromium/Blink of WebKit devs die ook hebben.

Mijn punt was dat Firefox niet zo “uitzonderlijk” was als werd voorgesteld.

[Reactie gewijzigd door Ed Vertijsment op 23 juli 2024 07:56]

[84hannes]

Mijn punt was dat Firefox niet zo “uitzonderlijk” was als werd voorgesteld.

Ik had na project QUnatum ook eigenlijk verwacht dat een iets hoger percentage Firefox/Gecko-code in Rust was geschreven.

[JonKoops]

Het is opzich niet zo vreemd dat Servo achter loopt, het project is een lange tijd verwaarloosd nadat Mozilla het heeft afgestoten. Het is pas recentelijk dat er weer meer activiteit is onder de sturing van de Linux Foundation Europe.

[Robbie T]

Leuk zo'n project maar wat ik mis is een beetje wat het voor "ons" als gebruiker toevoegt. Er zijn nu 3 grote browserengines en vele browser die allemaal zich ergens op richten zoals privacy.

Wat is precies de toegevoegde waarde van nog een browserengine?

[marcelvb]

Dat dachten we een aantal jaren geleden ook met Internet Explorer 5. Toen dacht ook iedereen, wow, dit is handig: standaard geïnstalleerd, simpel, snel je kunt allerlei Microsoft technologieën direct gebruiken. En toen... toen stond het internet 10 jaar stil. En hadden we opeens allemaal verschrikkelijke security issues. En nu hebben we hetzelfde maar de Microsoft van nu is Google. En dan moet je je realiseren van Google een advertentiebedrijf is en jij het product bent.

[Robbie T]

En dan installeer je iets als Brave Browser en ben je niet meer het product. Ik ben vooral benieuwd waarom we behoefte hebben aan een nieuwe browserengine.

[R4gnax]

En dan installeer je iets als Brave Browser en ben je niet meer het product.

Wikipedia: Brave (web browser)

Brave draait net zo goed op advertentie-inkomsten, en is in het verleden zelfs meedere malen in controverses belandt dankzij hun streken die met schering en inslag nogal schimmig bleken te zijn.

[marcelvb]

Waarom zit Google achter standaarden als HTTP/2? Is dat uit de goedheid van hun hart? Het web is is erg traag geworden door alle tracking en advertenties (van Google). M.a.w. zij maken de browser engine zo dat het goed is voor Google. Niet per se dat het goed is voor ons, gebruikers.
En daarnaast, developers testen hun websites in de meest voorkomende browser, Chrome. Dan werken websites ook beter in Chrome. Daardoor gaan meer mensen Chrome gebruiken. Daardoor gaan meer websites alleen Chrome ondersteunen. Nog even en mensen willen geen iPhone meer want "het internet werkt niet" goed op een iPhone. Dit is vendor lock-in op wereldschaal.

[84hannes]

zij maken de browser engine zo dat het goed is voor Google. Niet per se dat het goed is voor ons, gebruikers.

Dit ben ik helemaal met je eens, maar dat probleem pakt Firefox al aan. Echter

Nog even en mensen willen geen iPhone meer want "het internet werkt niet" goed op een iPhone.

Dat kan WebKit niet voorkomen, dat kan Gecko niet voorkomen. Wat ik niet snap is waarom iemand zou denken dat Ladybird dat wel kan voorkomen.

[FrostyPeet]

Die browser functie zal er wel komen in dit project.

Waar ik mij meer zorgen om maak is het "dichttimmeren" van de browser. Ik stel mij voor dat het interessant is om allerlei kwetsbaarheden te ontdekken en misbruiken in elke browser. De "grote drie" zijn ondertussen al "slagveldwaardig" op het "gevaarlijke internet".

[BoerBart]

Het beveiligen van elke software blijft altijd een kat- en muisspel, dat zal inderdaad voor de Ladybird browser niet veel anders zijn. Echter heeft de GitHub repo al meer dan 1000 contributors, dat betekent in ieder geval dat er veel ogen naar kijken. Een Open Source project geeft in ieder geval de zekerheid dat de goede ogen er naar kunnen kijken i.r.t. het vinden van bugs, hoewel dat uiteraard ook geldt voor de kwade ogen. Met de nodige tijd en juiste personen, zal het m.i. niks afdoen aan de "grote drie".

[ErnstvV]

Bijzondere keuze om een webbrowser te maken ontworpen voor toekomstige hardware. Ik vind de huidige browser als zo extreem resource hongerig, en dan zijn die volgens hem nog ontworpen om ook te draaien op oudere systemen. Krijgen we dan een browser die bij opstarten al gelijk al je geheugen claimt en 100% cpu load genereert? Dat vind ik niet echt een vooruitgang.

[svennd]

Dan heb je toch het deeltje 'goede buur' niet gelezen ...

[ErnstvV]

Dat vind ik dus het tegenstrijdige aan zijn verhaal. Net als aangeven dat het doel van Apple is hardware verkopen. En dan zelf een browser maken op blijkbaar een zwaar ontwikkelaarsstartion met het idee dat over een paar jaar iedereen zo’n systeem thuis heeft. Maar vervolgens zich wel richten op batterijverbruik. Dat zijn nu niet echt systemen die bekend staan om laag energie verbruik.

[kozue]

Je mist het punt denk ik. In huidige browsers zit een hoop legacy om oude systemen te ondersteunen. Cpu’s die bepaalde instructiesets missen, 32bit hardware, quirks mode, tls 1.0, deprecated tags, etc. Een compleet nieuwe browser kan zich alleen richten op huidige hardware en moderne websites, er vanuit gaand dat alle relevante websites er tegen de tijd dat het uitkomt aan voldoen, en alle legacy achterwege laten. Dat betekent niet automatisch dat het al je geheugen op gaat slokken of je cpu opstoken.

[svennd]

bwa ik lees het eerder als we gebruiken nieuwe cpu flags die bijvoorbeeld niet beschikbaar zijn op een 6'de generatie intel cpu's. Daar houden de grote wel rekening mee en voorzien workaround, die tijd, geld en soms minder efficiënt zijn dan als de cpu het native kan.

De kans dat in 2028 deze cpu's nog gebruikt worden is relatief klein. of althans niet door een grote groep gebruikers.

[fjwillemsen]

Nu een browserengine van scratch maken kan wel degelijk efficiënter zijn dan allerlei oude features blijven ondersteunen. Voorbeeld: pas in 2021 is Adobe Flash ondersteuning uit Chromium gehaald.
En wat met "hij neemt aan dat het geavanceerde ontwikkelaarssysteem dat hij nu gebruikt, over een paar jaar een 'gewoon' systeem is van de gemiddelde gebruiker" bedoelt wordt staat letterlijk in de zin er boven: "Een twintig jaar oude computer, daar houden we geen rekening mee. Misschien laten we toestellen met 1GB ram, een heel klein scherm of met legacybesturingssystemen van acht jaar oud ook achterwege.". Hij bedoelt gewoon dat ze zich richten op moderne architecturen en hardware die 95% van de gebruikers heeft, aangezien juist de uitzonderingen daarop een hoop werk en energie kosten.
Dat ze ontwikkelen op een "zwaar ontwikkelaarsstation" heeft niets te maken met hoe geoptimaliseerd iets is voor batterijverbruik, dat is alsof je zegt dat een gebouw 1:1 moet passen op de tekentafel van de architect.

[FreezeXJ]

Vergeet niet dat de bestaande browsers ook nog kilolines aan oude 'features' moeten opstarten, omdat ze wellicht ook wel eens op een 32-bit systeem moeten draaien, of opeens gevraagd kunnen worden een oude IE6-pagina goed te tonen. Dat hoeft een nieuwe browser niet te kunnen, en daarmee hou je em klein, en kun je beter optimaliseren.
Dat probleem zie ik sowieso teveel bij code; 'start maar want je weet nooit waar het goed voor is'. En daarmee gooi je resources weg die iedereen toch in overvloed heeft, want als je computer 'traag' is... koop je een snellere, toch?

[Mijzelf]

Vergeet niet dat de bestaande browsers ook nog kilolines aan oude 'features' moeten opstarten, omdat ze wellicht ook wel eens op een 32-bit systeem moeten draaien,

Een 64 bits browser hoeft nooit op een 32 bits systeem te draaien. Dat is compiletime al vastgelegd, en je kunt dus alle code die daarvoor nodig is compiletime al weglaten.

[Zer0]

Bijzondere keuze om een webbrowser te maken ontworpen voor toekomstige hardware.

Is het vreemd om vooruit te kijken? Er wordt niet verwacht dat de browser binnenkort beschikbaar is, dus is het logisch om het target te verleggen naar hardware die over een paar jaar gemeengoed is.

[spnw]

Het YouTube kanaal van deze man is heel interessant voor iedereen die ook maar een beetje in aanraking komt of interesse heeft in (C++) programmeren en open source project management: https://youtube.com/andreaskling

[PorcupineTree]

Voor degenen die de link naar de website van Ladybird zoeken: https://ladybird.org/

[MatiasG]

Amusant dat ze geen screenshot van Tweakers.net laten zien omdat de DPG cookiewall niet werkt.

[YannickSpinner]

Die functionaliteit heeft de huidige versie van de browser simpelweg inderdaad nog niet