Nginx-oprichter Igor Sysoev verlaat het bedrijf achter webserversoftware

Igor Sysoev, oprichter en ontwikkelaar van webserversoftware Nginx, trekt zich terug bij Nginx en netwerkbedrijf F5, dat sinds 2019 eigenaar is van Nginx. Sysoev wil meer tijd vrijmaken voor familie en vrienden en zich richten op persoonlijke projecten.

Sysoev schreef in 2002 de eerste versie van webserversoftware Nginx. In 2004 maakte hij de software open source en ontwikkelde het door tot een 'Zwitsers zakmes' voor webapplicaties en diensten, schrijft Nginx in een blogpost. In 2011 richtte hij Nginx Inc. op, het bedrijf achter de software, samen met twee anderen, met een hoofdkantoor in San Francisco en verschillende kantoren wereldwijd. Inmiddels maken volgens Netcraft honderden miljoenen websites gebruik van Nginx-software.

Igor Sysoev

Nginx werd in 2019 overgenomen door het Amerikaanse netwerkbedrijf F5 Networks voor 670 miljoen dollar. Sysoev bleef achter de schermen aan, onder meer als cto, en bemoeide zich met de visie van Nginx, en waarborgde het opensourcekarakter van de software. In 2019 werd Sysoev gearresteerd door de Russische autoriteiten om mogelijke auteursrechtenschending, omdat Sysoev de Nginx ontwikkelde toen hij in dienst was van de Russische zoekmachine Rambler.ru als systeembeheerder en webserverontwikkelaar. Eind 2019 werd de aanklacht door het Rambler-bestuur ingetrokken.

Wat Sysoev nu gaat doen, dat is nog niet bekend. Hij heeft nog geen nieuwe projecten aangekondigd. Nginx zegt dat hij meer tijd wil vrijmaken voor familie en vrienden en zich wil richten op persoonlijke projecten.

Reacties (90)

Inmiddels maken volgens Netcraft honderden miljoenen websites gebruik van Nginx-software.

Kleine kanttekening hier bij: Nginx wordt vaak als reverse proxy gebruikt en overschrijft de HTTP header "Server" hier met de waarde "Nginx". Andere reverse proxies zoals Apache HTTPd, Varnish en HAProxy doen dit niet.

Achter de Nginx proxy draait dan vaak de echte applicatie. Dat kan Apache Tomcat zijn of Apache HTTPd of webserver X.

Daarbij ontstaat een scheef beeld dat Nginx de meest populaire webserver is terwijl het vaak gewoon 'maar' een reverse proxy is.

[Reactie gewijzigd door Snow_King op 26 januari 2022 10:41]

Hoezo een scheef beeld? Er wordt toch daadwerkelijk Nginx gebruikt, al dan niet als reverse proxy?
Het staat iedereen vrij om elke reverse proxy te gebruiken, dus ze hadden ook voor Apache kunnen kiezen, of Caddy, of wat dan ook. Maar er wordt Nginx gebruikt.

En je kunt gewoon instellen dat de server header niet wordt overschreven, of dat je doorzet wat de eindserver gebruikt als je dat zo belangrijk vind.

En waarom zou je Nginx voor een Apache of Apache Tomcat zetten? En niet gewoon meteen die aan het net hangen? Daar zal dan wel een goede reden voor zijn denk ik.

Ik vind dat deze discussie afdoet aan het artikel zelf betreffende de bedenker van Nginx.

Daarbij ontstaat een scheef beeld dat Nginx de meest populaire website is terwijl het vaak gewoon 'maar' een proxy is.

Ik neem even aan dat je webserver bedoelt.

Je kan het zo zien dat waar een browser een HTTP verbinding mee maakt, dat dat de webserver betreft. Dat er op de achtergrond statische bestanden, dynamische PHP pagina's of content van een andere webserver wordt aangeboden doet daar niets aan af. Vanuit het perspectief van de browser is er maar één server waar HTTP tegen gepraat wordt en die web content aanbiedt.

Het begint wat wateriger te worden als we een onderscheid gaan maken met reverse proxies zonder TLS offloading. Immers doet NGINX dan bijvoorbeeld niets met (versleutelde) HTTP content, behalve het één-op-één doorgeven.

[Reactie gewijzigd door The Zep Man op 26 januari 2022 10:33]

Ik snap helemaal wat je bedoeld over het perspectief van de browser. Ik vind het echter een scheef beeld omdat de 'heavy lifting' vaak niet door Nginx wordt gedaan maar door een andere applicatie server daar achter.

Ik stoor mij al jaren aan het feit dat Nginx de 'Server' header overschrijft in zijn responses. Dit is gewoon echt niet OK. Een reverse proxy heeft van de headers af te blijven tenzij anders geconfigureerd.

Dus je moet persee zwaar werk verrichten om web server genoemd te mogen worden? Ik gebruik enkel nginx en niet alleen als reverse proxy, ook gewoon icm php-fpm en zo wordt het veel gebruikt. Als je eenmaal nginx hebt gebruikt wil je echt niet meer terug naar Apache.

Dus je moet persee zwaar werk verrichten om web server genoemd te mogen worden?

Als je een webserver draait en 99% van het werk wordt gedaan door Apache en 1% door Nginx, is het dan eerlijk te zeggen dat de website draait op Nginx?
Een totaal ander discussie maar vergelijkbare discussie; als iemand op de IC ligt vanwege een gebroken rug, maar ook positief test op Corona, ligt die patiënt dan op de IC mét of door Corona?

En als je Apache als webserver draait, maar 90% van het werk wordt door de MySQL back-end gedaan, is het dan eerlijk om te zeggen dat de website op Apache draait? En kun je PHP niet ook met Apache / NginX serveren terwijl PHP in een eigen process draait?

Ik denk dat je in het geval van NginX vs Apache best wel kunt zeggen dat bijvoorbeeld 70% NginX gebruikt en 70% Apache en er dus een grote overlap is waar beide producten worden gebruikt.

En als je Apache als webserver draait, maar 90% van het werk wordt door de MySQL back-end gedaan,

Goed punt, het gaat er inderdaad meer om wat ze doen dan hoeveel werk het kost. Een database serveert geen websites. Een (reverse) proxy volgens mij ook niet; die geeft ze door.

Tja, het is vooral een semantische discussie.
In een Nginx <- Apache <- Php <- Mysql opstelling, serveert dan php hetgeen uit wat het meeste lijkt op een website terwijl Nginx en Apache slechts doorgeven wat ze aangeleverd krijgen vanuit eerder in de pijp?

Ik denk dat het punt van de auteur was dat nginx zich meestal op de publieke zijde bevindt, en de server-header overschrijft. Hierdoor krijg je eigenlijk een vertekend beeld, omdat je niet langer weet wat er werkelijk op de backend draait.

Het is een probleem voor mensen die om de statistiekjes geven, maar ook niet meer of minder dan dat.

In jouw voorbeeld:

zonder nginx kan de website nog steeds draaien (intern te benaderen), zonder apache niet (er worden geen request naar PHP gestuurd). Anders kunnen we ook gaan zetten dat de website op de router draait

-aanvulling- ja je kunt php ook direct uitvoeren maar de output is dan niet via de browser leesbaar (daar gaat het over, een website draaien) en het werkt in sommige gevallen simpelweg niet omdat de servervariabelen van apache niet beschikbaar zijn

[Reactie gewijzigd door P-e-t-j-e op 26 januari 2022 15:19]

en totaal ander discussie maar vergelijkbare discussie; als iemand op de IC ligt vanwege een gebroken rug, maar ook positief test op Corona, ligt die patiënt dan op de IC mét of door Corona?

Dat ligt eraan of die héééél hard moest niezen

[Reactie gewijzigd door Waah op 26 januari 2022 15:12]

In proxy modus heb je als proxy van de HTTP headers af te blijven.

Als je Nginx met php-fpm gebruikt is het uiteraard prima dat de Server header de waarde nginx bevat.

Gebruik je Nginx als reverse proxy om daar de TLS configuratie te doen is het een prima stuk gereedschap in de keten, maar het is niet de bron van de content die je serveert aan de client. Dan heb je van alle headers af te blijven.

Nginx gaat ook niet de Date header aanpassen als voorbeeld. Nee, de Server header wordt met opzet overschreven om zo in de statistieken van oa Netcraft veel hoger te staan. Dat is gewoon niet correct.

Ik werk zowel met Nginx, Apache HTTPd, HAProxy, Varnish en Traefik en het zijn allemaal prima stukken software. Elke proxy die ik hier boven noem blijft netjes van zijn headers af behalve Nginx.

Maar nginx is geen proxy server. Het is een webserver die als reverse proxy kan worden ingezet. Anders dan bij HAProxy en varnish die echt proxy als doel hebben.

Maar als het als reverse proxy wordt ingezet moet het zich ook gedragen als reverse proxy.

Je noemt een switch die router mogelijkheden heeft toch ook geen router als je die mogelijkheden niet gebruikt?

Anders kun je ook argumenteren dat het OS de webserver is. Je kan er namelijk software op draaien die dat mogelijk maakt.

Maar nginx is geen proxy server. Het is een webserver die als reverse proxy kan worden ingezet. Anders dan bij HAProxy en varnish die echt proxy als doel hebben.

De ontwikkelaars van nginx lijken reverse proxy toch wel als hoofddoel te zien.

De eerste omschrijving op nginx.com is: "The open source all-in-one load balancer, content cache, and web server". Let er op dat ze web server als laatste noemen en dat een load-balancer (in dit geval) een reverse proxy is. De commerciele variant NGINX Plus wordt omschreven als "Software load balancer, API gateway, and reverse proxy". Ze noemen webserver niet eens.

Op nginx.org is het "nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev". Daar komt HTTP wel op de eerste plek maar maar de andere 3 punten gaan allemaal over proxy functionaliteit.

Of het "echt" is zit natuurlijk vooral tussen de oren. Ik ben het wel met je eens dat haproxy en varnish vanaf het eerste moment en in de eerste plaats als proxy zijn ontwikkeld en dat nginx de eerste jaren toch vooral een webserver leek te willen zijn. Wel met die aantekening dat het, zeker in het begin, ook altijd een hele simpele webserver is geweest die vooral heel goed is in simpele dingen snel doen en zodra het wat lastiger wordt het "echte" werk aan een ander stuk software over te laten, bv php-fpm.

Maar na zoveel jaren van ontwikkeling wil ik niet te hard vasthouden aan het oorspronkelijke ontwerp van versie 0.1, inmiddels kan alles totaal anders zijn.

Maar nginx is geen proxy server. Het is een webserver die als reverse proxy kan worden ingezet. Anders dan bij HAProxy en varnish die echt proxy als doel hebben.

Da's onzin.
Apache is ook geen proxy server, maar een webserver. Je kunt Apache echter wel ook als reverse proxy gebruiken, net zoals bij nginx het geval is.

Daarvoor hebben ze Nginx Pro, die blijft netjes van je headers af na betaling.

Maar zo heeft Apache ook zijn quirks met de Authentication header. Die is gewoon pleite als deze niet de basic auth format aanhoud. Kan je weer omzeilen met een rewrite rule die expliciet die header weer terug zet…

Maar hoezo dan, wat is er beter aan Nginx? Ik wil het best geloven, maar je beschrijft het niet.

De configuratie is veel simpeler en de performance is stukken beter. Het laden van websites gaat gewoon sneller/smoother. Bovendien is het beter bestand tegen DoS aanvallen, Apache slowloris en al die ongein.

Heb bij Apache altijd het gevoel van een log containerschip wat heel veel kan meenemen maar minder wendbaar is. Nginx is wat dat betreft meer lightweight en voelt flexibeler aan. Ik gebruik het zelf hobbymatig als beheerder om een forum en een grote wiki site te hosten en dat werkt prima. Met Apache had ik dat ook kunnen doen, maar qua resource gebruik is het minder vriendelijk is mijn ervaring. Waar hem dat precies in zit weet ik niet, daar ken ik de internals van Apache te weinig voor. Ik weet wel dat ik de configuratie van Nginx meer straightforward vind dan van Apache en ik voor mijn gevoel veel minder dependencies nodig heb qua packages, etc. Nu draai ik gewoon Nginx met php-fpm, nog wat aanvullende php packages en that's it. Prima op een VPS om wat sites te draaien en qua performance is het ook nog eens prima te doen.

Zoals @Marve79 noemt is de configuratie simpel, en het is flexibel inzetbaar en goed ondersteund op alle distributies. Prestaties zijn ook goed.

Er zijn een paar edge cases waarbij ik HAProxy prefereer, maar NGINX is gewoon een goed product dat doet wat het moet doen.

Ik ga er eens wat beter naar kijken. Ik heb het alleen als rp gebruikt tot nu toe, maar eigenlijk pak ik tegenwoordig altijd gewoon Apache als rp. Bv. laatst voor Telegraf metrics, via een https rp via internet binnen krijgen.

"Als je eenmaal nginx hebt gebruikt wil je echt niet meer terug naar Apache. "
Niet helemaal mee eens. Ik beheer zowel Nginx als Apache webservers. Veel webapplicaties leunen op .htaccess bestanden die niet door Nginx worden ondersteund, dat is voor mij een belangrijke rede om Apache te blijven gebruiken.

Ik weet dat we handmatig de regels uit .htaccess om kunnen zetten naar Nginx configuratie, maar dat vereist iedere keer handmatig onderhoud (controleren van alle .htaccess bestanden, en zo nodig bijwerken van de Nginx config) bij een update van de webapplicatie.

Veel webapplicaties leunen op .htaccess bestanden die niet door Nginx worden ondersteund,

Dat is een van de redenen waarom Nginx zoveel lichter is. Hij leest één keer zijn configuratie in, en dat is het, terwijl Apache in theorie voor iedere geserveerde file alle directories tot aan de webroot moet controleren op een .htaccess die iets over die file te zeggen heeft. In de praktijk zal er wel wat gecached worden.

AllowOverride None

Allemaal in te stellen.

Exact. Het zit hem in de configuratie opties. Apache HTTPd kan super snel zijn mits goed ingezet.

Dat vind ik dus ook, ik weet niet wat het is, Apache en nog wel meer oudgedienden worden door velen niet meer goed begrepen laatste jaren lijkt het wel. Of het ligt aan mij, maar er worden vaak heel makkelijk gewoon beweringen gedaan die niet kloppen.

Ja, dat merk ik ook. Genoeg discusses gehad waarin mensen beweerden dat Nginx zo veel sneller was dan Apache HTTPd. Maar daar deden ze benchmarks tegen mpm_prefork vs Nginx.

Gebruik dan ook mpm_worker icm AllowOverride=None en je hebt ongeveer de zelfde performance.

Zonde om te zien, want het zit hem allemaal in het gebruik van kennis. HTTPd is niet hip, maar wel erg betrouwbaar en breed inzetbaar.

Dat klopt wel, sommige leveranciers ondersteunen (helaas) enkel Apache en dan heb je geen keuze. Anders krijg je vaak niet eens support.

Op PHP na is er geen enkele moderne programmeertaal waarmee je je web applicatie direct door een web server zoals nginx kunt laten serveren. Dat maakt nginx niet nutteloos of webserver-onwaardig omdat het toevallig niets meer is dan reverse-proxy. Uiteindelijk is nginx wat ervoor zorgt dat web applicaties via HTTP beschikbaar komen voor de buiten wereld, en in veel gevallen ook zorgt voor de TLS-verbinding tussen browser en server.

Dat de daadwerkelijke HTML die geserveerd wordt gegenerereerd is door een andere applicatie of docker-container boeit niet toch? NGINX gedraagd zich als de web-server voor de buitenwereld.

Mja mij het boeit wel, omdat altijd maar weer gezegd wordt dat Apache trager is en Nginx leaner etc. Terwijl irl Apache bijna altijd het harde werk opknapt achter de reverse proxy, bv. zoals jij zegt de opcode rendert en Nginx alleen de ontstane html doorgeeft.

Waarom zou je in godsnaam Apache gebruiken op je servers en er dan nginx voorzetten? Dit is echt compleet onlogisch, je kan met nginx doen wat je ook met apache kan doen dus waarom zou je die er nog tussen hebben?

Ik ken eigenlijk bijna geen systemen waar er van nginx gebruikt gemaakt word en apache.

Ik denk dat je je vergist met PHP trouwens, gezien je het over opcodes renderen hebt. PHP render je niet door apache, php render je (bijvoorbeeld) door php-fpm

Mod-php nooit van gehoord? Doet apache dat niet zelf? Ik zal me wel vergissen

Volgens mij doet de module die functionaliteit dan, en niet apache hoor

Zie het verschil niet met php-fpm met nginx combineren, anders dan dat deze twee compleet losse processen zijn met de voordelen van dien.

Daarnaast als jij het logisch vind om apache+mod-php te draaien en er dan nginx voor te zetten, dan weet ik niet helemaal wat je aan het doen bent...

Mod-php zal zeker nog vaak gebruiken, maar is absoluut niet meer de standaard voor professionele PHP applicaties.

Ik loop inderdaad wat achter denk ik, is het tegenwoordig allemaal FPM ?

Meest gebruikelijke is Nginx icm php-fpm. Er is niet echt iets mis met Apache icm modphp als je dat gebruikt, maar het is in de meeste situaties wat logger en minder performant.

Heel veel sites die Varnish gebruiken doen dit zo. Omdat Varnish geen SSL ondersteuning heeft staat nginx ervoor. Apache is dan de backend.

Apache die het harde werk opknapt achter de reverse proxy? Ik krijg hier nogal grote cowboy gevoelens bij. Zoals ik het zelf in het verleden heb gezien en gedaan is dat NGINX de requests direct naar applicaties stuurt. Bijvoorbeeld een .NET applicatie die geserveerd wordt door de ingebouwde kestrel-server. Er komt niet eerst nog apache tussen.

Ik denk dat we technisch een heel andere taal spreken.

Achter die ene nginx server kan je wel 500 apache servers draaien zodat iedere apache server wss bijna niks hoeft. Allemaal met 1 nginx servertje ervoor.

Out of the box is NGINX geconfigureerd als web server, met eigen Server header. Zet je NGINX in als reverse proxy dan kan je 'proxy_pass_header Server;' toevoegen om de Server header van het achterliggende proces door te geven. Wil je niet doorgeven en ook geen 'nginx' zien dan gebruik je 'server_tokens '';'

Overigens leent de open source versie van NGINX zich helemaal niet zo goed als reverse proxy. Alles wat een beetje interessant is mbt load-balancing etc. vind je alleen in het commerciele NGINX Plus terug. Ik gebruik NGINX dan ook alleen als front-end voor PHP-FPM. Haproxy is wat mij betreft geschikter als reverse proxy.

Al het volk dat naar de upstream servers gaat, moet langs nginx komen. Ook al dat bv apache op de achtergrond 99% van de 'echte' werk doet. Die apache kan men lekker verdelen, over 20 servers om de load te spreiden waar nginx het volle pond krijgt.

Doet ondertussen nog caching als je dat wil en meer.

Die header is gewoon reclame voor het feit dat ze een betaalde Plus licentie hebben. Zoveel mogelijk in logs opduiken aub zeggen ze daar bij de sales.

[Reactie gewijzigd door NimRod1337 op 26 januari 2022 10:58]

Ik gebruik Nginx als reverse proxy voor Varnish én Varnish praat dan weer tegen een 'normale' Nginx server.

Dit komt vaker voor dan dat Nginx als reverse proxy wordt gebruikt en dat iemand daarachter een Apache server heeft opgetuigd.

Hitch+Varnish zijn een mooie combinatie.

Maar Nginx is al een tijdje hip, maar vergeet niet hoe groot de installed based van Apache HTTPd is en hoe veel applicaties daar nog steeds het beste mee werken. Heel, heel, heel veel.

Zeker, maar voor de termination is Nginx in ieder geval voor mij goed genoeg.

Is verder het marktaandeel van Nginx en Apache inmiddels niet ongeveer gelijk? Of is dat beeld troebel vanwege de grotere inzet van Nginx als reversed proxy, zoals hierboven aangegeven?

Correct. Dat is mij hele punt ook. Enkel Nginx overschrijft de Server header en komt hierbij in statistieken hoger naar boven toe. Slim van de developers, maar ik vind dat het een scheef beeld geeft.

Klein zeikerig detail: reverse proxy, niet proxy.

Je hebt helemaal gelijk :-)

De "Server" header is default gedrag van OSS versie (vermoedelijk ook van de betalende varianten).
Je kan bvb met:
https://github.com/openresty/headers-more-nginx-module#name
alle headers gemakkelijk manipuleren.
Doorgaans wil je vaak ook de "Server" header gewoon nooit terug sturen naar de client (vanuit een secuirty perspectief), maar is natuurlijk use case afhankelijk.

Ja, je kan het uit zetten. Ik vind echter dat Nginx van die header af moet blijven in proxy modus en deze enkel mag zetten als Nginx bijv via php-fpm iets serveert.

Achter de Nginx proxy draait dan vaak de echte applicatie. Dat kan Apache Tomcat zijn of Apache HTTPd of webserver X.

Als je achter NGINX, apache gaat draaien ben je niet de meest slimme beheerder. Apache is echt tergend traag voor bijvoorbeeld PHP.... Php-fpm werkt echt veel beter (in combinatie met NGINX).

Is er een use-case die ik heb gemist? Waarom je Apache achter NGINX zou draaien.

Legio voorbeelden te verzinnen voor applicaties, ik noem gewoon even wat op: mod_wsgi, mod_perl, CGI, mod_php5, mod_auth_ldap.

Apache Tomcat wordt ook nog veel gebruikt. Nginx doet dan de TLS afhandeling en proxied het request door naar de Tomcat server er achter.

Apache HTTPd bestaat ook al heel erg lang en heel, maar dan ook heel veel oudere applicaties werken daar gewoon het beste onder.

De Apache webserver is volgens mij zo goed als obsolete. Websites gebruiken al enkele jaren voor nieuwe projecten een reverse proxy zoals Nginx, Traefic of Envoy voor een async application server geschreven bijvoorbeeld in node.js, golang, fastapi/python, Java, .Net core, etc. etc.

Nginx is geweldig. We gebruiken het als WAF en hebben servers draaien met 100k+ concurrent HTTPS connections waarbij nginx slechts 150-200% van een CPU core gebruikt.

Apache HTTPd is verre van obsolete. Het is een goed werkende webserver. Modulair en ook snel. Ja, Apache HTTPd is snel mits je de juiste worker gebruikt!

Uiteindelijk moet je het gereedschap kiezen wat het beste past bij de taak.

Wordt het vaak voor gebruikt, maar Apache zelf kan ook met zelfde gemak een reverse proxy draaien. Terwijl de applicatie in de zelfde Apache instance draait.

Tip: zet er lekker IIS10.0 in o.i.d. Net als dat wanneer je een beveiligingssysteem nooit de sticker uit de doos moet gebruiken en hoogstens de sticker van een andere leverancier.

Dat deed ik vroeger omdat ik het leuk vond :-) Nu eigenlijk al tijden niet meer.

Maar ook een proxy serveert gewoon content. Vaak wordt zo'n reverse proxy zelfs verwezen naar bijv. een docker container waar intern weer een service draait, die in veel gevallen ook weer nginx gebruikt om content te serveren.

Ze zeggen niks over Apache, maar ook Apache wordt in veel gevallen als niet meer dan een reverse proxy (vaak voor PHP) gebruikt. Kan me dus niet voorstellen dat het verschil in use cases erg groot is. De statistieken zullen echt niet (alleen) komen van het crawlen van websites en kijken of de headers Nginx bevatten.

Het is de meest populaire port 80 http(s) server. Het is simpel, snel en super goed te combineren met mini applicaties die ook weer als service draaien. Inderdaad dan als proxy. Maar dan wel dusdanig dat alle caching, https security, certificaten bij nginx liggen en de applicaties dom blijven.
Ideaal voor snel en simpel schalen.
Ik heb laatst apache weer eens geprobeerd. Maar dat blijft toch een gedrocht. Nginx is de ultieme tool met nul gebreken.

Dan nog klopt de zin:

maken... gebruik van Nginx-software.

Zelfs als het alleen als reverse proxy wordt gebruikt, er wordt gebruik van gemaakt.

Het mooie aan nginx is ook dat het in C geschreven is en ook nog als veilig bestempeld wordt. Wat echt niet makkelijk is.

Ach, alles is relatief.

Een groot deel van die resultaten zijn applicaties waar NGINX een onderdeel van is en waar de auteur een configuratiefout gemaakt heeft.

Hier de echte NGINX CVE's;
https://www.cvedetails.co...id-17956/Nginx-Nginx.html

Zo goed als al die kwetsbaarheden zitten in producten die nginx gebruiken of in dependencies van nginx. Nginx zelf lijkt er inderdaad vrij goed vanaf te komen.

Precies. Ik zou software dat het publiek bedient niet per se als 'veilig' bestempelen. Misschien 'veilig genoeg' (mits er niet al te grote flaters gemaakt worden, en updates vlot uitkomen en geïnstalleerd worden).

Beter dan Java, toch?

Jokes aside, is niet vrij veel in C geschreven software veilig? Ik weet er niet veel van, behalve dat C geen garbage collector heeft en (dus) voor memory problemen kan zorgen.

Het niet hebben van een garbage collector leidt niet tot geheugenproblemen. Slecht programmeren wel. Een garbage collector is dus eigenlijk een vangnet voor het broddelwerk van slechte programmeurs.

We hebben higher level programmeertalen om het programmeren van computer eenvoudiger te maken. Dus het belangrijkste doel van een higher level programmeertaal is het creëren van een taal die eenvoudiger dan machinetaal is te begrijpen/gebruiken voor mensen, en tegelijkertijd op een stabiele manier te vertalen is naar machinetaal die rechtstreeks uitgevoerd kan worden door een CPU.

De reden dat programmeertalen met garbage collectors zo populair zijn is omdat de productiviteit van dat soort talen meestal hoger is. Tegelijkertijd is zo'n taal niet voor iedere use-case geschikt. Bijvoorbeeld, voor real time programmeren, of waar je met relatief weinig resources te maken hebt.

Dus is het slecht programmeren? Dat zou ik zo niet noemen. Maar in bepaalde gevallen is een taal zonder garbage collector geschikter.

We hebben higher level programmeertalen om het programmeren van computer eenvoudiger te maken.

Eenvoudiger of toegankelijker? Want gezien de puinhopen is het blijkbaar niet eenvoudiger, alleen wel toegankelijker omdat iedere prutser er mee aan de slag kan en tot "een" resultaat komt.

Inderdaad, je zou kunnen zeggen dat er geen slechte programmeertalen zijn maar wel slechte programmeurs.

Op een eenwieler vallen meer mensen om dan op een fiets of driewieler.

Zijn er dan geen instabiele voertuigen, enkel slechte fietsers?

Enkel slechte fietsers en eenwielers.

Eigenlijk gaat dit verhaal alleen maar op als je relatief kleine applicaties helemaal zelf schrijft, waarbij het hele mentale model compleet in jouw hoofd past en je nooit te maken hebt met andere programmeergewoontes van andere programmeurs die bijdragen aan het project waarbinnen jij werkt.

Een programmeertaal die meer garantie geeft over types en welk stukje code wat met welk stukje geheugen kan doen levert bij het zelfde niveau van de programmeur aantoonbaar betere code op, zeker als de schaal van een project toeneemt. Slechte programmeurs kunnen rotzooi schrijven in iedere taal, al maken sommige talen het wel een stuk makkelijker om die rotzooi ook nog te laten werken.

In theorie zou je een C-achtige taal kunnen hebben met garbage collection die nog steeds memory unsafe is, die twee dingen hebben slechts indirect iets met elkaar te maken.

Zucht... weer dat elitair toontje...

De realiteit is dat memory management moeilijk is bij grotere projecten. Het is niet voor niks dat er zoveel memory-management libraries zijn voor C. Ben je dan ook een slechte programmeur als je daar gebruik van maakt?

Neen, garbage-collectors kunnen veel problemen oplossen en de tijd die een programmeur wint hierdoor is ook kostbaar.

Een een "goede programmeur" (sic) weet meestal ook hoe hij/zij in een garbage-collected omgeving de memory cleanups tot een minimum te herleiden zodat de efficientie van de applicatie niet in het gedrang komt. Meestal door gebruik te maken van memory-pooling, dit lukt zowel in Java, Golang als .NET. En het is een pak eenvoudiger en minder tijdrovend dan manueel memory-management.

[Reactie gewijzigd door Anoniem: 368883 op 26 januari 2022 12:29]

Jokes aside, is niet vrij veel in C geschreven software veilig?

Software in C kan veilig zijn, net als in veel andere programmeertalen. C heeft echter ook veel valkuilen, waarschijnlijk meer dan 'hogere' talen.

C is één grote valkuil met scherpe spiesen op de bodem, met een dunne gammele plank waar je precies over het midden moet lopen om er niet in te vallen. In het donker.

Dat is dan ook precies de reden waarom veel bedrijven voor nieuwe code over aan het stappen zijn op Rust. De Rustc compiler compileert naar LLVM intermittent language, net als Clang, dus programma's geschreven in Rust zijn net zo snel als programma's geschreven in C.

Het voordeel is echter dat Rust veiligheidsgaranties heeft op het gebied van geheugen- en threadingveiligheid.

Vroeger heb ik zelf veel in C geschreven, en ik was er goed in. Het was echter een precies priegelwerk om goed bij te houden hoe en waar je welk geheugen beheerde. Ik probeerde, indien nodig, geheugen aan te maken en weer vrij te geven in dezelfde functie, of minimaal bij het starten en stoppen van het programma. Dingen als pointers teruggeven vanuit functies heb ik zelden gedaan, omdat dan het aanmaken en vrijgeven van het geheugen niet op dezelfde plek zit, en je snel dingen over het hoofd kunt zien. In Rust kun je niet zomaar een pointer of referentie terug geven; je zult dan aan de compiler meoten bewijzen dat dit goed gaat, en dat is niet altijd triviaal om dat voor elkaar te krijgen.

Nadat ik een persoonlijk stukje software in Rust heb geschreven, ben ik niet van plan om nog ooit met C te werken als ik het kan voorkomen. (En ook niet met Go, want dat is net "C voor het internet"; het heeft veel van dezelfde valkuilen, al worden die in Go weggewerkt met behulp van een garbage-collector. Daarom is die taal dan ook relatief traag in vergelijking tot C en Rust.)

Bij het eerste deel van je zin zaten mijn gedachten meteen weer in Prince of Persia!

Expliciet: de taal C heeft de volgende valkuilen:

• dangling pointers
• memory leaks
• buffer overruns

De C string library is een voorbeeld van de laatste bullet met veel functies (e.g. strcpy; strcat) waar naar een buffer wordt geschreven zonder op de grenzen te letten. Microsoft heeft als reactie hierop een library gemaakt met safe varianten.

Met C kan je dus ook prima safe software schrijven maar je moet wel iets meer zelf doen. Het gebruik van (je eigen) safe wrappers is een start.

Er zijn een paar dingen wat in C tot risico's kan leiden en waar een garbage collector soms een oplossing zou kunnen zijn.

1. Geheugen voor het vrijgegeven niet leeggemaakt wordt (bijv. allemaal 0 schrijven). Als er bij een nieuwe allocatie toevallig naar hetzelfde geheugengebied wordt verwezen, dan kan de data niet is opgeruimd alsnog gelezen worden. Dat is wat veel veiligheidsissues veroorzaakt. Dit doen garbage collectors over het algemeen ook niet. Geheugen wordt dus meestal niet eerst leeggemaakt voordat het wordt teruggegeven. Hier moet je als programmeur dus alert op blijven.

2. Geheugen dat wordt gereserveerd, maar waarvan er meer wordt gebruikt dan aangegeven. Bijv. je reserveert 16bytes geheugen, maar schrijft er 20bytes naartoe. Als je kan garanderen waar die overige 4 bytes landen, dan heb je ook een veiligheidsissue. C++ Strings mitigeren dit door automatisch meer geheugen te alloceren als er meer wordt geschreven dan van te voren aangegeven.

Wat echter veel vaker gebeurt is dat geheugen niet wordt vrijgegeven waardoor je een geheugenlek hebt. Ergste wat er dan kan gebeuren is de software crashed omdat op gegeven al je geheugen van je systeem in gebruik is. Dat is echter alleen echt relevant als je software hebt dat continue zou moeten draaien of wanneer er zoveel wordt gelekt dat je kort draaiende software zijn taak niet voltooid, omdat het voor die tijd crashed.

Een goede garbage collector zorgt er wel voor dat je nooit geheugen lekt, maar kan wel weer voor overhead zorgen. Soms heb je de luxe niet voor die overhead zoals in microcontrollers

Puntsgewijs:
Het leegmaken van geheugen is een serieuze performance impact, ongeacht de programmeertaal.

C++ in inderdaad iets veiliger, maar C++ strings kun je nog steeds out-of-bounds schrijven. Het is echter een stuk moeilijker. Een stukje code als filename += ".wav" reserveert wel atuomatisch het benodigde geheugen, maar filename[9999]='!' is een unchecked write.

Geheugen wat niet vrijgegeven wordt kan in alle talen voorkomen. In C gebeurt dat als je een pointer vergeet te free-en, in Java als je vergeet een pointer te overschrijven.

Elk stuk software in elke taal kan "veilig" zijn En elk stuk software in elke taal kan ook "onveilig" zijn.

En sommige talen maken het een stuk makkelijker dan andere om veilige software te maken.

En C hoort daar niet bij

De reverse proxy gebruik ik thuis om vrijwel alle webservices een SSL certificaat te geven. Ook als ze vanuit de basis helemaal geen SSL ondersteunen. Alleen dat maakt het al een prachtig stukje software.

In 2019 werd Sysoev gearresteerd door de Russische autoriteiten om mogelijke auteursrechtenschending, omdat Sysoev de Nginx ontwikkelde toen hij in dienst was van de Russische zoekmachine Rambler.ru

Flinke Silicon Valley (S02E09) vibes, waar ook gesproken werd over twijfel van eigendom, omdat het (o.a.) gebouwd was gedurende kantooruren van zijn oude werkgever.