Roland McGrath stopt na 30 jaar met zijn werk aan GNU C Library

Ontwikkelaar Roland McGrath heeft bekendgemaakt dat hij stopt met zijn werk aan de GNU C Library, ook wel bekend als glibc. Hij startte zijn werk ongeveer dertig jaar geleden, toen hij zelf nog een tiener was.

In zijn aankondiging schrijft McGrath dat hij twee derde van zijn leven aan het project heeft gewijd en dat dit volgens hem genoeg is. Hij stelt dat hij erachter kwam dat hij in de loop van de tijd steeds verder van het project verwijderd is geraakt. De afgelopen maanden en jaren zouden aangetoond hebben dat hij niet meer nodig is. Hij verklaart zichzelf dan ook tot 'maintainer emeritus'.

De GNU C Library is een implementatie van de standaardbibliotheek voor de programmeertaal C voor het GNU Project. Het project, dat is opgestart door Richard Stallman, stelt zich tot doel om gebruikers vrijheid te bieden om computers te gebruiken op de manier die zij zelf willen. Het staat gebruikers dan ook vrij om GNU-software te kopiëren, aan te passen en te verspreiden.

De ontwikkeling van glibc stond tussen 2001 en 2012 onder toezicht van een steering committee, wat destijds een controversiële beslissing was. Daarna volgde een andere aanpak, waarbij de ontwikkeling meer vanuit de community zelf voorkwam. McGrath refereert aan deze periode door onder meer zijn dank te betuigen voor de personen die 'door alle beproevingen heen deel bleven van het project'.

McGrath is sinds 2011 werkzaam voor Google, waar hij naar eigen zeggen werkt aan de Google Native Client. Daarvoor werkte hij voor Red Hat.

Reacties (27)

[CAPSLOCK2000]

Roland McGrath bedankt! GNU LibC is misschien niet het meest glamoureuze project maar het is wel een van de belangrijkste stukken software die we hebben. Het aantal applicaties dat er gebruik van maakt is werkelijk niet te tellen. Nu zijn er wel meer GNu/Linux-onderdelen waar je dat van kan zeggen maar glibc is toch wel beetje de basis voor al het andere.

[Schnupperpuppe]

Roland is een held!
Ik denk dat glibc met gemak in de top 10 van meest gebruikte software op deze planeet staat.
Misschien zelfs wel op nummer 1?
Je ziet het niet, maar het is er wel. Overal :-)

[Mijzelf]

Veel gebruikt, ja. Nummer 1? Ik denk het niet. Bij mijn weten wordt glibc vrijwel alleen op Linux gebruikt. De BSD's (en dus ook Apple) gebruiken een andere libc variant. Ik denk dat Debian GNU/kFreeBSD de enige belangrijke niet-Linux distro is die glibc gebruikt. Die ben ik nog nooit in het wild tegengekomen.

Veel embedded Linux systemen gebruiken uClibc of musl libc.

Conclusie: De Linux kernel wordt vaker gebruikt dan glibc, en glibc kan dus niet nummer 1 zijn.

[[Yellow]]

Embedded Linux gebruikt standaard glibc. Behalve Android, die gebruikt bionic. Wat weer een uitgeklede glibc variant is.

uClibc wordt nog maar erg weinig gebruikt. Het enige voordeel ervan is dat je CPU geen MMU nodig heeft, en aangezien elke ARM een MMU heeft is het niet meer nodig om jezelf te beperken.

En voor degenen die VxWorks noemen heb ik één vraag: why?

[Mijzelf]

Embedded Linux gebruikt standaard glibc.

Sinds wanneer is Embedded Linux een standaard? De versies waar ik het meest tegenaan loop (consumenten routers e.d.) houden zich aan geen enkele standaard. (En draaien zelden glibc)

uClibc wordt nog maar erg weinig gebruikt. Het enige voordeel ervan is dat je CPU geen MMU nodig heeft

Het enige voordeel? Wat dacht je van een minder dan een tiende zo grote lib file?

aangezien elke ARM een MMU heeft is het niet meer nodig om jezelf te beperken.

Maar ja, vrijwel alle (budget) consumenten routers draaien Mips. Pas sinds kort is OpenWRT overgestapt van uClibc naar musl.

En voor degenen die VxWorks noemen heb ik één vraag: why?

Da's niet zo moeilijk. VxWorks kan hetzelfde doen met de helft van het geheugen. (zowel ram als rom). Èn je hoeft je broncode niet beschikbaar te stellen.

[[Yellow]]

Sinds wanneer is Embedded Linux een standaard? De versies waar ik het meest tegenaan loop (consumenten routers e.d.) houden zich aan geen enkele standaard. (En draaien zelden glibc)

Buildroot, Yocto en OpenEmbedded gebruiken in de standaard instelling glibc. Zijn toch de meest gebruikte omgevingen om een embedded Linux systeem mee te bouwen.
Verder kijk ik niet vaak naar router builds, maar dat zal ik vanaf nu eens wat vaker gaan doen

Èn je hoeft je broncode niet beschikbaar te stellen.

Broncode vrijgeven hoeft bij Linux ook niet voor de binaries die je zelf maakt en op het systeem runt. En aangezien daar je kennis zit is dat nooit een probleem voor bedrijven. Zelfs een kernel driver hoef je niet vrij te geven als je hem als module gebruikt.

[Reactie gewijzigd door [Yellow] op 26 juli 2024 02:35]

[Schnupperpuppe]

Oeps. Ik had voor het gemak even Android meegerekend, maar die blijkt een eigen variant te gebruiken. Dat scheelt wel een paar miljoen instances ;-)

Sommige media-boxen gebruiken trouwens wel glibc. Die van mij tenminste wel (Enigma2).

[royb3]

Dus hij begon hiermee toen hij 15 was? Damn

[vanaalten]

Dus, ehmm, als hij is begonnen toen hij ongeveer 15 was en er nu 30 jaar aan werkt, is 'ie nu dus ~45 jaar oud. En hij stelt dat dat tweederde van z'n leven is. Blijkbaar geen plannen om oud te worden...

[Barsonax]

30 van 45 is toch tweederde?

[vanaalten]

Ah! Ik rekende de andere kant op... dat 'ie nu 45 is, dat dat tweederde is en hij dus 67.5 jaar oud verwacht te worden. Nee, nu snap ik 'm, klinkt een stuk zinniger zo.

[Zer0]

Nee, je snapt het nog niet
Hij heeft tweederde van zijn leven (tot nu toe) aan glibc besteed, die uitspraak zegt helemaal niks over hoe oud hij gaat worden.

[chaozz]

Niet helemaal ontopic, maar toch erg interessant is de documentaire Revolution OS. Over het ontstaan van GNU en Linux (en GNU/Linux als je Stallman moet geloven).

[tweaknico]

Android != GNU/Linux...
OpenWRT != GNU/Linux

Linux + GNU stack dat is GNU/Linux.

[echtwaarisdatzo]

Ik ga de docu desondanks een poging geven, erg interessant idd.

[morphje]

Lennart verdient die stortvloed van negativiteit niet. Zelfs Debian past nu systemd toe, als je het over een stel recalcitrante nerds hebt, dan zitten die bij Debian. Dat betekend voor mij toch wel dat systemd (en lennart) toch een goede visie heeft. De huidige (oude) startup scripts waren simpelweg crap en paste niet meer bij een modern OS. SysV was op elke linux anders, upstart was meer van hetzelfde, maar systemd is echt herdacht en coherent.

Toegegeven, systemd trekt misschien veel naar zich toe, meer dan strikt noodzakelijk voor een startup systeem, maar desondanks is het ontwerp en visie van systemd wel vooruitstrevend te noemen. Lennart stak zijn handen in het vuur en hield vol. Daarvoor krijgt hij kudo's.....

Maar zoals altijd. Kan je het beter, doe het dan beter. Maar enkel een goede autist zal in staat zijn om zoiets dergelijks te ontwerpen en te implementeren. Helaas gaat de visionaire autist altijd gepaard met wat eigenaardige persoonlijkheids trekjes. Learn to live with it.

[tweaknico]

Dat iedereen achter systemd aanholt wil nog iet zeggen dat het goed is...
openrc kan minimaal de bedoeling (snelle startup) bereikbaar maken en dat ZONDER invasie van tooling en zonder afbreuk aan andere tooling.

systemd trekt inderdaad veel meer naarzich toe dan nodig is.
is er al een een volledige security audit op systemd gedaan (en vervolgens bij elke nieuwe release weer?) of wordt dat te veel werk.
voor een PID=1 proces (met omgeving is dat wel een vereiste).

Het lijkt meer op een win32 replacement voor linux... alleen de grafische schil is er nog niet, maar ook daar wordt aan gewerkt. (Wayland?)

[Reactie gewijzigd door tweaknico op 26 juli 2024 02:35]

[kozue]

Als je denkt dat snelle startup het enige doel is van systemd moet je je nog eens gaan inlezen. Belangrijker dan een snelle startup is een betrouwbare startup, met bijbehorende flexibiliteit. En dat krijg je niet met het doormodderen met shellscripts alsof de jaren 80 nog niet over zijn...

[gekkie]

Als systemd het summum van betrouwbaarheid en flexibiliteit is, waarom hanteert en raad Debian dan nog steeds sysvinit aan om als backup te dienen ?
(bijvb omdat binaire logging zuigt als je tijdens het booten problemen hebt, met een minimale busybox shell en een text editor en scripts kun je nog wel een eind komen.)

Daarnaast is de omgang met bugs niet echt een plezant geheel (vrij gauw een "won't fix" want wij hebben er geen last van benadering).

De hoofdreden dat het overal uiteindelijk toch omarmd is lijkt de "my why or the highway" benadering te zijn en de uiteindelijke dependency van udev en gnome op systemd.

Is er dan niets goeds aan systemd (cq was er niets te verbeteren aan sysvinit / openrc / upstart) ? Tuurlijk wel, maar een hoop van de verbeteringen hadden ook op een meer modulaire wijze aangepakt kunnen worden. Probleem is dat dat lastiger is omdat modulair werken betekend dat er veel interfaces zijn die je expliciet moet maken. Bij systemd hoeft dat allemaal niet omdat het een monolitisch geheel is wat in lockstep ontwikkeld wordt, maar dat gemak qua ontwikkelen heeft ook wel een prijs.

[kozue]

Waar raad Debian dat aan? Dat heb ik nog nooit gehoord. Je kunt namelijk niet 2 init systemen naast elkaar draaien, dus heb je ook geen "backup".

En systemd kan heus nog flink wat verbeteren (zelf vind ik de omgang met user-level services nauwelijks bruikbaar te noemen), maar vergeleken met de oude manier van allemaal losse shell scriptjes die allemaal een eigen idee hebben over hoe een service gedraaid moet worden is het wel een flinke verbetering. De overstap van sysv naar systemd is geen eindstatus maar gewoon een van de vele stapjes in software evolutie. Over 20 jaar weet niemand meer wat systemd was en heb je weer iets moderners dat op zijn beurt weer ontworpen is om de tekortkomingen van systemd op te lossen.

[gekkie]

Kan het op dit moment zo even niet vinden, behalve de mention bij sysvinit package om sysvinit te behouden tot je zeker weet dat booten met systemd werkt.

Edit: toch nog gevonden (https://wiki.debian.org/systemd):

HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!

Het gaat er ook niet om dat je 2 init systemen naast elkaar draait, het draait er wel om dat als systemd loopt te bokken (bijvb over je root device met een onmogelijke foutmelding die niet duidelijk refereert naar het onderliggende probleem) je prima kunt booten met sysvinit door init=/lib/sysvinit/init als kernel parameter op te geven. Ook kun je dan weer gewoon "debug" meegeven voor meer kernel info, zonder dat systemd je console volledig vol gaat spammen met z'n eigen zut, achja ieder zo z'n ding.

Uiteindlijk denk ik dat systemd net zo'n brij wordt voor zover het het al niet is.
Voor dezelfde functionaliteit krijg je uiteindelijk namelijk een schier oneindig aantal hooks / opties in de C code om toch weer overal in het proces in te kunnen grijpen als ware het een script.
Kortom een benadering van de andere kant, die uiteindelijk de kans heeft hetzelfde te eindigen.

Kan het op zich Lennart niet kwalijk nemen, de Debian ontwikkelaars echter wel, wat mij betreft is het te snel en te vroeg ingevoerd als default en was het zeker te vroeg om alle schepen verder te verbranden en het niet alleen als default te nemen, maar eigenlijk defacto als enige (ook al werkt sysvinit ook met stretch tot nu toe nog prima met de applicaties die ik gebruik).

[Reactie gewijzigd door gekkie op 26 juli 2024 02:35]

[tweaknico]

DEVUan is nog een mogelijkheid: https://devuan.org/
de Debian ontwikkelaars die systemd niet zagen zitten.

Gentoo is een andere. https://gentoo.org

Recentelijk was er een security probleem (privilege escalation) omdat een systemd module voor DNS-lookups een buffer overflow had..., so much voor auditing van ALLE systemd code, juist omdat het monilitisch is.

sysv klopt dat was een probleem, openrc is echt iets heel anders, de voordelen van systemd zonder de ellende.
Ach en ik was co-maintainer voor een paar zaken ergens maar heb het opgegeven om voor systemd opstart scripts te maken. systemd was niet in staat om op een efficiente manier vanuit een template te werken. (let wel 2 jaar geleden, maar zoveel is er niet aan de structuur veranderd)...
Het kwam er op neer dat voor elke element een aparte service moet worden gedefinieerd.

[himlims_]

is dat niet mooi; bevalt het je niet, kan je het weer distribueren of aanpassen zodat het wel in lijn ligt met jouw filosofie of beleid. gnu toch mooi he