De Devschuur Coffee Corner - Iteratie ⑬

[Lethalis]

ElkeBxl schreef op woensdag 21 oktober 2026 @ 16:28:
Iedereen een toffe werkdag gehad met het hele PHP gedoe vandaag?

Ik ging kijken om het nieuwe advent of code topic aan te maken maar https://adventofcode.com/2026 geeft nog een 404 dus nog geen info wat het dit jaar wordt qua aantal dagen en dergelijke.

Nou ik ben eigenlijk vrij vandaag, maar moest wel even een NextCloud instantie offline halen. Impact valt op zich wel mee, want het wordt alleen door onszelf gebruikt. Is alleen even onhandig.

Ik kijk morgen op de zaak wel hoe ik het op het nieuwste patchniveau krijg en het weer online breng.

Voor de rest gebruiken we gelukkig geen PHP. Al onze eigen software en websites zijn met .NET gemaakt.

[DaFeliX]

ElkeBxl schreef op woensdag 21 oktober 2026 @ 16:28:
Iedereen een toffe werkdag gehad met het hele PHP gedoe vandaag?

[...]

Ik hoop dat ik vandaag een rustigere dag dan gisteren heb...

[RobertMe]

DaFeliX schreef op donderdag 22 oktober 2026 @ 07:28:
[...]

Ik hoop dat ik vandaag een rustigere dag dan gisteren heb...

"Tnet devver", maar Kees had de website offline gehaald in de load balancers. Dus waarom had je als dev dan geen rustige dag?

[DaFeliX]

RobertMe schreef op donderdag 22 oktober 2026 @ 07:52:
[...]

"Tnet devver", maar Kees had de website offline gehaald in de load balancers. Dus waarom had je als dev dan geen rustige dag?

Omdat ik een deel van mijn tijd devops en security doe

edit:
en helaas deed GitLab het nog wel, dus verifywerk ging wel door

[ Voor 12% gewijzigd door DaFeliX op 22-10-2026 07:56 ]

[Webgnome]

DaFeliX schreef op donderdag 22 oktober 2026 @ 07:28:
[...]

Ik hoop dat ik vandaag een rustigere dag dan gisteren heb...

Dat hoop ik ook, dan heb ik dat ook namelijk

[Firesphere]

Ealanrian schreef op woensdag 21 oktober 2026 @ 16:31:
De werkdag is nog niet voorbij en ik heb niks met php te maken. Helaas wel cve 2026-111943...

Volgens noai.DuckDuckGo is dat -109917

[Ealanrian]

Firesphere schreef op donderdag 22 oktober 2026 @ 08:12:
[...]

Volgens noai.DuckDuckGo is dat -109917

Dat komt ongeveer overeen met mijn energie niveau vandaag. Even alle componenten updaten en een uitrol doen kost toch best veel energie als je halverwege de dag begint.

[Firesphere]

ElkeBxl schreef op woensdag 21 oktober 2026 @ 16:28:
Iedereen een toffe werkdag gehad met het hele PHP gedoe vandaag?

Gewoon PHP4 gebruiken. Super veilig, want 4 is groot genoeg voor een private key, en de zwaktes zitten in 5 en hoger

[ElkeBxl]

DaFeliX schreef op donderdag 22 oktober 2026 @ 07:28:
[...]

Ik hoop dat ik vandaag een rustigere dag dan gisteren heb...

Mijn dag was gisteren begonnen met een API van een externe partner die offline was getrokken omdat het in PHP geschreven was. Ik dacht eerst van "Och, zo erg kan het toch niet zijn?". En dan zag ik tweakers ineens onbeschikbaar en had ik een "Shit just got real" moment Hopelijk idd een rustigere dag vandaag!

[SPee]

Mijn klant had gisteren alle systemen uit voorzorg offline gehaald. Ook die ik ontwikkel. Maar ik gebruik helemaal geen PHP!
Naar mijn idee was het geen "Shit just got real", maar meer "blinde paniek". Normaal moeten de systemen 24/7 beschikbaar moeten zijn, maar nu trokken ze opeens de stekker van alle systemen eruit. Dat had wel veel zorgvuldiger gemoeten.

[alt-92]

SPee schreef op donderdag 22 oktober 2026 @ 14:17:
Normaal moeten de systemen 24/7 beschikbaar moeten zijn, maar nu trokken ze opeens de stekker van alle systemen eruit. Dat had wel veel zorgvuldiger gemoeten.

Noem het digital detoxing en iedereen blijft happy

[.oisyn]

(s/php/whatever_language, still funny)

[ Voor 5% gewijzigd door .oisyn op 22-10-2026 21:42 ]

[Firesphere]

Omdat het blijkbaar helaas nog steeds "grappig" wordt gevonden om op anderen af te geven, heb ik maar even van me af geschreven.

Het verbaasd me hoeveel er nog steeds "grappig" word gedaan, vooral in de categorie "mijn taal is beter dan jouw taal"

[.oisyn]

@Firesphere: Als dat een reactie op mij was, lees dan ook even de voettekst:

.oisyn schreef op donderdag 22 oktober 2026 @ 21:26:
(s/php/whatever_language, still funny)

[Firesphere]

.oisyn schreef op donderdag 22 oktober 2026 @ 23:41:
@Firesphere: Als dat een reactie op mij was, lees dan ook even de voettekst:

[...]

Niet specifiek op jou, sterker nog, niet eens specifiek als reactie op iets hier op t.net.

Het leek me, in alle posts op FP, echter wel (deels) relevant genoeg om hier te delen.

[eheijnen]

Firesphere schreef op donderdag 22 oktober 2026 @ 23:52:
[...]

Niet specifiek op jou, sterker nog, niet eens specifiek als reactie op iets hier op t.net.

Het leek me, in alle posts op FP, echter wel (deels) relevant genoeg om hier te delen.

Een flinke rant, zeg.
Gaat het weer een beetje nu.... ?

[Firesphere]

eheijnen schreef op vrijdag 23 oktober 2026 @ 08:03:
[...]

Een flinke rant, zeg.
Gaat het weer een beetje nu.... ?

Dat was geen rant, dus als je even uitlegt wat jij als rant kwalificeert, zal ik dat voortaan niet meenemen in mijn schrijfsels, okay?

[Webgnome]

Firesphere schreef op donderdag 22 oktober 2026 @ 22:40:
Omdat het blijkbaar helaas nog steeds "grappig" wordt gevonden om op anderen af te geven, heb ik maar even van me af geschreven.

Het verbaasd me hoeveel er nog steeds "grappig" word gedaan, vooral in de categorie "mijn taal is beter dan jouw taal"

[eheijnen]

Firesphere schreef op vrijdag 23 oktober 2026 @ 08:06:
[...]

Dat was geen rant, dus als je even uitlegt wat jij als rant kwalificeert, zal ik dat voortaan niet meenemen in mijn schrijfsels, okay?

Laten we zeggen: es effe lekker tekeer gaan...

[Voutloos]

Als het oplucht, good for you. Maar voor lui die blind op $taal afgeven of bij Nu.nl reageren zal het nooit iets doen, dus inhoudelijk ben je enkel trolls aan het voeden.

[ Voor 72% gewijzigd door Voutloos op 23-10-2026 10:02 ]

[Voutloos]

En PHP ‘again’ moet je sowieso niets van aantrekken; afgelopen jaren was dat niet zo, PHP de taal is niet eenzijdig verantwoordelijk voor domme foutjes in usercode (kuch Wordpress, en fucking Magento)

En ook wat zaken die qua PR bijna verdacht gunstig getimed zijn: Java en Node melden grote patches vlak nadat meeste aandacht al naar PHP2shell gegaan.

Maar uiteindelijk heeft elk platform nog genoeg issues om te ontdekken. Hoe het afgehandeld wordt is wat uitmaakt, en dat was vrij goed (maar fuck Chainguard)

[Basje]

Firesphere schreef op donderdag 22 oktober 2026 @ 22:40:
Omdat het blijkbaar helaas nog steeds "grappig" wordt gevonden om op anderen af te geven, heb ik maar even van me af geschreven.

Het verbaasd me hoeveel er nog steeds "grappig" word gedaan, vooral in de categorie "mijn taal is beter dan jouw taal"

Ach ja, het stigma van werken in PHP. Eind jaren '90 ben ik begonnen met websites bouwen en was het de meest toegankelijke keuze om in PHP3 te werken. Uiteindelijk zou het ruim 20 jaar mijn hoofdtaal zijn.

Mijn werk is inmiddels het beoordelen van onder andere broncode van software bij fusies, overnames en investeringen. Niet geheel verrassend zitten daar veel PHP-oplossingen tussen, net zoals veel TypeScript/JavaScript, en veel C#/.NET. De rest een stuk minder. Ik zie tientallen oplossingen per jaar, en doe dit werk alweer een tijdje. Mijn professionele mening is dat PHP niet onderdoet voor enige andere taal. En in elke taal kan je troep schrijven. Het is meer het resultaat van de bedrijfscultuur dan van de technologie die je kiest.

[eheijnen]

Dat zijn die eikels die altijd al op de loer liggen voor een binnenkoppertje...

[DevWouter]

Voutloos schreef op vrijdag 23 oktober 2026 @ 10:00:
Maar voor lui die blind op $taal afgeven of bij Nu.nl reageren zal het nooit iets doen, dus inhoudelijk ben je enkel trolls aan het voeden.

Aan de andere kant, als je stil blijft dan wordt mening werkelijkheid.

[Firesphere]

eheijnen schreef op vrijdag 23 oktober 2026 @ 09:19:
[...]

Laten we zeggen: es effe lekker tekeer gaan...

Dat was het dus ook niet. Wat is er "tekeer gaan"? Want ik begrijp nog steeds niet waar je't in hemelsnaam over hebt.

Voutloos schreef op vrijdag 23 oktober 2026 @ 10:11:
En PHP ‘again’ moet je sowieso niets van aantrekken; afgelopen jaren was dat niet zo, PHP de taal is niet eenzijdig verantwoordelijk voor domme foutjes in usercode (kuch Wordpress, en fucking Magento)

Je hebt helaas geen woord begrepen van wat ik heb geschreven.

Basje schreef op vrijdag 23 oktober 2026 @ 10:12:
[...]

Ach ja, het stigma van werken in PHP. Eind jaren '90 ben ik begonnen met websites bouwen en was het de meest toegankelijke keuze om in PHP3 te werken. Uiteindelijk zou het ruim 20 jaar mijn hoofdtaal zijn.

Het is geen stigma, het is minachting, en het is helaas dus nog steeds structureel en cultureel.

Welke taal er voor gebruikt word om die minachting kenbaar is totaal irrelevant.

[Kalentum]

Firesphere schreef op vrijdag 23 oktober 2026 @ 10:26:
[...]

Dat was het dus ook niet. Wat is er "tekeer gaan"? Want ik begrijp nog steeds niet waar je't in hemelsnaam over hebt.

Ik ga er zonder meer vanuit dat je het met mij oneens zal zijn, maar:

"Shut up. Really, I'm serious. Shut the hell up."

"But I've never seen such a problem in my language!, so what? So what that you haven't seen it?"

Als je zo tegen mij zou praten zou ik vragen of je even kan kalmeren. Tot tien tellen enzo.

Mijn mening: je boodschap is goed maar je stijl doet afbreuk aan de boodschap.

[Firesphere]

Kalentum schreef op vrijdag 23 oktober 2026 @ 10:35:
[...]


Ik ga er zonder meer vanuit dat je het met mij oneens zal zijn, maar:

"Shut up. Really, I'm serious. Shut the hell up."

"But I've never seen such a problem in my language!, so what? So what that you haven't seen it?"

Als je zo tegen mij zou praten zou ik vragen of je even kan kalmeren. Tot tien tellen enzo.

Mijn mening: je boodschap is goed maar je stijl doet afbreuk aan de boodschap.

Is het echt zo moeilijk te lezen?

De eerste: Het staat letterlijk tussen aanhalingstekens, een (geanonimiseerde) quote, waarop ik reageer met "nou en?"
De tweede: "I'm parroting Aurynn here", ook wel bekend als een quote, zei het minder letterlijk

[ Voor 3% gewijzigd door Firesphere op 23-10-2026 10:43 ]

[eheijnen]

Firesphere schreef op vrijdag 23 oktober 2026 @ 10:26:
[...]

Dat was het dus ook niet. Wat is er "tekeer gaan"? Want ik begrijp nog steeds niet waar je't in hemelsnaam over hebt.


[...]

Je hebt helaas geen woord begrepen van wat ik heb geschreven.


[...]

Het is geen stigma, het is minachting, en het is helaas dus nog steeds structureel en cultureel.

Welke taal er voor gebruikt word om die minachting kenbaar is totaal irrelevant.

Je bezigt het engelse begrip "Tosser" en zegt dat ze hun waffel moeten houden (Shut up).
Ik vind het een, laten we zeggen, krachtige en emotievolle uiting naar deze personen toe.

[ Voor 3% gewijzigd door eheijnen op 23-10-2026 10:52 ]

[mrdemc]

Firesphere schreef op vrijdag 23 oktober 2026 @ 10:42:
[...]

Is het echt zo moeilijk te lezen?

De eerste: Het staat letterlijk tussen aanhalingstekens, een (geanonimiseerde) quote, waarop ik reageer met "nou en?"
De tweede: "I'm parroting Aurynn here", ook wel bekend als een quote, zei het minder letterlijk

Ik moet zeggen dat ik je reacties hier nou ook niet heel vriendelijk vind overkomen, net als de rant inderdaad, hoewel ik het wel eens ben met de boodschap. Ik hoor m ook vaak en ga er dan ook tegenin maar probeer dat wel altijd opbouwend te doen.

[SPee]

Ach, zelfs over "mijn" taal, worden onvriendelijke opmerkingen gemaakt.
In dit geval zelfs een artikel hier + presentatie: Dev Summit 2026 met Adele Carpenter: 'Java sucks, maar hoeft niet weg' - IT Pro - .Plans - Tweakers

[Firesphere]

eheijnen schreef op vrijdag 23 oktober 2026 @ 10:51:
[...]

Je bezigt het engelse begrip "Tosser" en zegt dat ze hun waffel moeten houden (Shut up).
Ik vind het een, laten we zeggen, krachtige en emotievolle uiting naar deze personen toe.

Dat lees jij er in.

Tosser:
A word for an unpleasant person
An idiot

Yep, er zijn meerdere lezingen mogelijk, maar zelfs dan nog, als je de minst plezante wilt nemen, sta ik nog steeds achter mijn woorden.

Verder is zeggen dat iemand z'n waffel moet houden niet emotioneel. Krachtig of hard, ja. Niet emotioneel.

mrdemc schreef op vrijdag 23 oktober 2026 @ 12:16:
[...]


Ik moet zeggen dat ik je reacties hier nou ook niet heel vriendelijk vind overkomen, net als de rant inderdaad, hoewel ik het wel eens ben met de boodschap. Ik hoor m ook vaak en ga er dan ook tegenin maar probeer dat wel altijd opbouwend te doen.

Als je mijn reacties in proberen te begrijpen waar men het in hemelsnaam over heeft onvriendelijk vindt, denk ik dat je er meer in leest dan de letterlijke vragen.

Anyway, fijn dat iedereen een mening heeft over mijn taalgebruik, ik zal er niets mee doen

[Voutloos]

DevWouter schreef op vrijdag 23 oktober 2026 @ 10:19:
[...]

Aan de andere kant, als je stil blijft dan wordt mening werkelijkheid.

Daar geloof ik inmiddels niet meer in, zonde van energie, ook zonde om je te laten beïnvloeden door dat soort opinie.

Of het nou ‘Php bad’ roeptoeteren, of klimaatontkenner, vaccinaties, politieke polarisaties etc.. is: Er op reageren geeft het alleen maar meer podium, maar zal zeer vaak verspilde moeite zijn, want men heeft al zijn waarheid/bubbel/oordeel gekozen. Dus ik probeer (blijft lastig!) het meer te laten gaan.

[ Voor 5% gewijzigd door Voutloos op 23-10-2026 12:51 ]

[Lethalis]

Firesphere schreef op donderdag 22 oktober 2026 @ 22:40:
Omdat het blijkbaar helaas nog steeds "grappig" wordt gevonden om op anderen af te geven, heb ik maar even van me af geschreven.

Het verbaasd me hoeveel er nog steeds "grappig" word gedaan, vooral in de categorie "mijn taal is beter dan jouw taal"

Er kleeft gewoon een stigma aan PHP.

Maar goed, ik kan het aan de andere kant ook niet haten, want toen ik ooit aan mijn eerste websites begon in 1998 ofzo, toen was PHP een zegen vergeleken met Perl of andere cgi scripts / programma's. Ineens kon ik van alles bouwen op het web en het snel doen ook. Heb daar toen zelfs een boek voor gekocht.

In 2003 ben ik .NET developer geworden en heb ik PHP achter mij gelaten. Maar ja, dat was voor iets dat we tegenwoordig ook verschrikkelijk vinden, namelijk ASP.NET WebForms

Toch heeft PHP voor mij de basis gelegd als web developer. Overigens heb ik altijd een veel grotere hekel aan JavaScript gehad dan aan PHP Tegenwoordig hebben we gelukkig TypeScript in strict mode en vangen we met een build step veel stommiteiten af.

Maar er is een tijd geweest dat ik uren zat te zoeken waarom JavaScript code iets niet deed en dan bleek het door een hoofdletter ofzoiets idioots te komen.

Ach ja. En dan hebben we tegenwoordig zoveel mooie tools en dan gaan collega's ineens massaal AI gebruiken en lezen de code niet eens meer zelf. Dat gaat bij mij nog een keer een breekpunt worden hoor. Dat ik echt schijt aan alles krijg en ermee stop. Dan past dit werk gewoon niet meer bij mij, want ik wil er op deze manier gewoon niet meer verantwoordelijk voor zijn.

[Marc3l]

Ach de haters roeptoeteren maar wat weg.
Kan er nog steeds financieel goed mee rondkomen, heb er (vaak) plezier mee, al +20 jaar.
Dus waarom zou ik niet meer met PHP werken, omdat andere het niets vinden? 😂

[eheijnen]

Firesphere schreef op vrijdag 23 oktober 2026 @ 12:33:
[...]

Dat lees jij er in.

Tosser:
A word for an unpleasant person
An idiot

Yep, er zijn meerdere lezingen mogelijk, maar zelfs dan nog, als je de minst plezante wilt nemen, sta ik nog steeds achter mijn woorden.

Verder is zeggen dat iemand z'n waffel moet houden niet emotioneel. Krachtig of hard, ja. Niet emotioneel.


[...]

Als je mijn reacties in proberen te begrijpen waar men het in hemelsnaam over heeft onvriendelijk vindt, denk ik dat je er meer in leest dan de letterlijke vragen.

Anyway, fijn dat iedereen een mening heeft over mijn taalgebruik, ik zal er niets mee doen

Ah ja, ik vond het geen slechte hoor, daar niet voor.
Ik denk je nog wel enkele synoniemen kent voor tosser die wat minder elegant zijn ;)
Persoonlijk prefereer ik ook tosser i.p.v. wanker.

Zoals gezegd.
Dat zijn die eikels die altijd al op de loer liggen voor een binnenkoppertje...

[ Voor 3% gewijzigd door eheijnen op 23-10-2026 13:38 ]

[eheijnen]

En daarom wordt php zoveel gebruikt, nog steeds... ook nog vandaag...na die bug

[.oisyn]

eheijnen schreef op vrijdag 23 oktober 2026 @ 13:36:
En daarom wordt php zoveel gebruikt, nog steeds... ook nog vandaag...na die bug

Die bug is compleet irrelevant in dat verhaal. Het lag niet intrinsiek aan PHP, elk stuk software had een gelijkwaardige bug kunnen hebben.

[Lethalis]

eheijnen schreef op vrijdag 23 oktober 2026 @ 13:36:
En daarom wordt php zoveel gebruikt, nog steeds... ook nog vandaag...na die bug

Mij is altijd bij gebleven dat iemand ooit schreef:

"While you are arguing amongst yourselves which is the best programming language, somewhere somebody is building the next Facebook in PHP"

[Lethalis]

.oisyn schreef op vrijdag 23 oktober 2026 @ 14:16:
[...]

Die bug is compleet irrelevant in dat verhaal. Het lag niet intrinsiek aan PHP, elk stuk software had een gelijkwaardige bug kunnen hebben.

Klopt. Het enge hiervan is eigenlijk dat er een enorme hoos aan issues op ons af gaat komen, omdat nu iedereen met AI tools de boel aan het auditen is.

Het was ook niet alleen PHP deze week. NodeJS en Java hadden ook CVE's ondere andere.

[eheijnen]

.oisyn schreef op vrijdag 23 oktober 2026 @ 14:16:
[...]

Die bug is compleet irrelevant in dat verhaal. Het lag niet intrinsiek aan PHP, elk stuk software had een gelijkwaardige bug kunnen hebben.

Dat werd wel aangegrepen, als ik het goed door hem, om php (developers) voor schut te zetten. Dat komt eigenlijk ook uit zijn stukje naar voren. Daar begon het dan.

En dat is ook zo, daar zijn nog wel meer van zulke dingen gebeurd. Maar dit werd dan weer breed uitgemeten in de media alsof het de eerste keer was.

Daarom (op zijn engels): take life with a pinch of salt....

[Webgnome]

eheijnen schreef op vrijdag 23 oktober 2026 @ 13:36:
En daarom wordt php zoveel gebruikt, nog steeds... ook nog vandaag...na die bug

• ben je log4shell vergeten?
• ben je tls problematiek in Java vergeten?
• en nodejs kan er ook wat van (node2shell)

ma.w. elke software kan bugs hebben en zolang die worden gepatched is dat niet erg. Dat maakt niet dat we er vanaf moeten stappen. En ja, in de blogpost kwam dit naar voren. Is niet heel gek natuurlijk want het was een PHP bug en PHP heeft van oudsher een heel slechte naam en veel mensen grijpen dit elke keer aan om PHP te slaan ook al is het totaal niet logisch om het te doen.

Als je het wil doen, doe het dan op daadwerkelijke codebases of als er binnen nu en een paar weken blijkt dat het echt zo lek is als een mandje en niet meer gebruikt zou mogen worden

[ Voor 31% gewijzigd door Webgnome op 23-10-2026 15:12 ]

[eheijnen]

Webgnome schreef op vrijdag 23 oktober 2026 @ 15:10:
[...]

• ben je log4shell vergeten?
• ben je tls problematiek in Java vergeten?
• en nodejs kan er ook wat van (node2shell)

ma.w. elke software kan bugs hebben en zolang die worden gepatched is dat niet erg. Dat maakt niet dat we er vanaf moeten stappen. En ja, in de blogpost kwam dit naar voren. Is niet heel gek natuurlijk want het was een PHP bug en PHP heeft van oudsher een heel slechte naam en veel mensen grijpen dit elke keer aan om PHP te slaan ook al is het totaal niet logisch om het te doen.

Als je het wil doen, doe het dan op daadwerkelijke codebases of als er binnen nu en een paar weken blijkt dat het echt zo lek is als een mandje en niet meer gebruikt zou mogen worden

Is wat minder goed geformuleerd. Ik ben allerminst een tegenstander van welke taal dan ook en wie wat gebruikt om zijn ding te doen.
Hier staat het wat beter.
eheijnen in "De Devschuur Coffee Corner - Iteratie ⑬"

Maar eigenlijk was dat wat gechargeerd bedoeld. Want er wordt veel geschreven in PHP, al god weet hoe lang. En ik heb nog geen berichten gezien na de bug dat (bv.) Drupal en Wordpress overgaan op een andere taal.... -> dus morgen ook weer PHP...

[DevWouter]

Lethalis schreef op vrijdag 23 oktober 2026 @ 14:17:
[...]

Mij is altijd bij gebleven dat iemand ooit schreef:

"While you are arguing amongst yourselves which is the best programming language, somewhere somebody is building the next Facebook in PHP"

Waarbij ik dan denk aan de quote: Het gaat nooit om de code/technologie, de merknaam is veel belangrijker.

[DevWouter]

Voutloos schreef op vrijdag 23 oktober 2026 @ 12:50:
[...]

Daar geloof ik inmiddels niet meer in, zonde van energie, ook zonde om je te laten beïnvloeden door dat soort opinie.

Of het nou ‘Php bad’ roeptoeteren, of klimaatontkenner, vaccinaties, politieke polarisaties etc.. is: Er op reageren geeft het alleen maar meer podium, maar zal zeer vaak verspilde moeite zijn, want men heeft al zijn waarheid/bubbel/oordeel gekozen. Dus ik probeer (blijft lastig!) het meer te laten gaan.

"The only thing necessary for the triumph of evil is for good men to do nothing"

Maar inderdaad, het is wel handig om niet overal ten strijde te trekken. Er zijn namelijk te veel idioten in de wereld.

[Webgnome]

het krijgt een staartje.. Net even gecheckt maar volgens mij hebben we bij onze systemen gelukkig geen noodzaak om de ini setting aan te passen

nieuws: Makers van PHP raden alsnog mitigatie aan voor minder gevaarlijke potentiële bug

[RobertMe]

Webgnome schreef op vrijdag 23 oktober 2026 @ 16:31:
het krijgt een staartje.. Net even gecheckt maar volgens mij hebben we bij onze systemen gelukkig geen noodzaak om de ini setting aan te passen

nieuws: Makers van PHP raden alsnog mitigatie aan voor minder gevaarlijke potentiële bug

"volgens mij" lijkt me geen goed antwoord in dezen?

Ik ga er ook niet vanuit dat de aanpassing nodig is, maar ik heb het net wel toegepast. Beter onnodig aanpassen dan achteraf er achter komen dat je er naast zat.

[Lethalis]

Ik vind het trouwens grappig hoeveel (pogingen tot) rewrites er van PHP in Rust zijn.

Dat is namelijk de eerste gedachte die in mij opkwam. Niet "PHP is k*t", maar "kunnen ze die interpreter niet gewoon in een memory safe taal herschrijven?".

Maar goed, geen van de (AI slop) implementaties werkt volledig uiteraard. Of heeft nog serieuze performance issues.

[ Voor 6% gewijzigd door Lethalis op 23-10-2026 17:14 ]

[RobertMe]

Lethalis schreef op vrijdag 23 oktober 2026 @ 17:13:
Ik vind het trouwens grappig hoeveel (pogingen tot) rewrites er van PHP in Rust zijn.

Dat is namelijk de eerste gedachte die in mij opkwam. Niet "PHP is k*t", maar "kunnen ze die interpreter niet gewoon in een memory safe taal herschrijven?".

Maar goed, geen van de (AI slop) implementaties werkt volledig uiteraard. Of heeft nog serieuze performance issues.

Zijn andere talen dan ook herschreven? Volgens mij is .NET op een gegeven moment wel in .NET geschreven (incl compiler en al)? Maar geldt dat bv ook voor Java? Python? ...

[Webgnome]

RobertMe schreef op vrijdag 23 oktober 2026 @ 17:10:
[...]

"volgens mij" lijkt me geen goed antwoord in dezen?

Ik ga er ook niet vanuit dat de aanpassing nodig is, maar ik heb het net wel toegepast. Beter onnodig aanpassen dan achteraf er achter komen dat je er naast zat.

ik pas niet zo maar onnodig iets aan zonder dat ik weet wat het kapot maakt. 'volgens mij' stond wat klungelig. Met de kennis die ik nu heb na wat checks is het niet nodig.

[SPee]

Lethalis schreef op vrijdag 23 oktober 2026 @ 14:17:
[...]

Mij is altijd bij gebleven dat iemand ooit schreef:

"While you are arguing amongst yourselves which is the best programming language, somewhere somebody is building the next Facebook in PHP"

Maar die kreeg toen media aandacht, opeens tienduizenden bezoekers en crashte vanwege de toestroom en kosten om hun servers te betalen. Daarbij: hoeveel maken hun hobbyproject ook echt af?

Maar die quote kan naar het archief. De nieuwe quote is:

"While you are arguing amongst yourselves which is the best programming language, somewhere somebody is vibecoding the next Facebook with Claude"

[SPee]

Lethalis schreef op vrijdag 23 oktober 2026 @ 17:13:
Ik vind het trouwens grappig hoeveel (pogingen tot) rewrites er van PHP in Rust zijn.

Dat is namelijk de eerste gedachte die in mij opkwam. Niet "PHP is k*t", maar "kunnen ze die interpreter niet gewoon in een memory safe taal herschrijven?".

Maar goed, geen van de (AI slop) implementaties werkt volledig uiteraard. Of heeft nog serieuze performance issues.

Maar ook Rust is niet (100%) veilig.

Maar: waarom PHP herschrijven in Rust? Wil je niet eerder de programma's/websites die met PHP zijn gemaakt herschrijven? (naar React )

[ Voor 9% gewijzigd door SPee op 23-10-2026 19:02 ]

[Webgnome]

Aangezien deze twee CVE's in de ZEND engine zaten heeft dat geen zin zeg maar. Het is altijd goed om te kijken of de tools die je gebruikt de juiste zijn. En dan kan PHP nog steeds gewoon de juiste keuze zijn.

[hackerhater]

Lethalis schreef op vrijdag 23 oktober 2026 @ 17:13:

Dat is namelijk de eerste gedachte die in mij opkwam. Niet "PHP is k*t", maar "kunnen ze die interpreter niet gewoon in een memory safe taal herschrijven?".

Nope, want een taal als PHP moet geheugen direct kunnen manipuleren.
Om objecten aan te maken en weer te kunnen verwijderen.
En foutafhandeling te doen.

Net als de Java en .NET runtimes "unsafe" dingen moeten kunnen doen,

[ Voor 8% gewijzigd door hackerhater op 24-10-2026 23:47 ]

[RayNbow]

hackerhater schreef op zaterdag 24 oktober 2026 @ 23:46:
Nope, want een taal als PHP moet geheugen direct kunnen manipuleren.
Om objecten aan te maken en weer te kunnen verwijderen.
En foutafhandeling te doen.

Waarom zou de bijbehorende compiler of interpreter niet kunnen worden geschreven in een memorysafe taal?

Het idee van memorysafe is net als dat van een typechecker: het verwerpen van programmateksten die niet veilig geacht worden.

[hackerhater]

RayNbow schreef op zondag 25 oktober 2026 @ 07:30:
[...]

Waarom zou de bijbehorende compiler of interpreter niet kunnen worden geschreven in een memorysafe taal?

Het idee van memorysafe is net als dat van een typechecker: het verwerpen van programmateksten die niet veilig geacht worden.

Omdat het memory-safe deel van een taal als bijvoorbeeld Rust direct geheugen manipulatie blokkeerd ;)
Dat is het hele punt erachter. Wat werkt heel goed voor de meeste programma's behalve in generiek deze 3 categorieen:

1) Drivers die low-level toegang nodig hebben
2) De HAL van operating systems
3) De compilers/interpreters van talen.............

[mrdemc]

hackerhater schreef op zondag 25 oktober 2026 @ 08:07:
[...]

Omdat het memory-safe deel van een taal als bijvoorbeeld Rust direct geheugen manipulatie blokkeerd ;)
Dat is het hele punt erachter. Wat werkt heel goed voor de meeste programma's behalve in generiek deze 3 categorieen:

1) Drivers die low-level toegang nodig hebben
2) De HAL van operating systems
3) De compilers/interpreters van talen.............

Deze man doet wel z’n best: https://phprust.com/

[hackerhater]

mrdemc schreef op zondag 25 oktober 2026 @ 09:52:
[...]

Deze man doet wel z’n best: https://phprust.com/

Well deels kan je het doen, maar bepaalde stukken zullen alsnog in "unsafe" sections moeten.
Oa het stuk waar deze bug zat.

[.oisyn]

hackerhater schreef op zondag 25 oktober 2026 @ 08:07:
[...]

Omdat het memory-safe deel van een taal als bijvoorbeeld Rust direct geheugen manipulatie blokkeerd ;)
Dat is het hele punt erachter. Wat werkt heel goed voor de meeste programma's behalve in generiek deze 3 categorieen:

1) Drivers die low-level toegang nodig hebben
2) De HAL van operating systems
3) De compilers/interpreters van talen.............

Sorry maar dit is echt onzin. Er is geen enkele reden waarom je een compiler of interpreter niet in Rust kan schrijven, noch dat Rust geen directe geheugenmanipulatie kan doen.

[mrdemc]

hackerhater schreef op zondag 25 oktober 2026 @ 10:45:
[...]

Well deels kan je het doen, maar bepaalde stukken zullen alsnog in "unsafe" sections moeten.
Oa het stuk waar deze bug zat.

Maar dan kan het dus wel net zei je dat het blokkeerde

[.oisyn]

hackerhater schreef op zondag 25 oktober 2026 @ 10:45:
[...]

Well deels kan je het doen, maar bepaalde stukken zullen alsnog in "unsafe" sections moeten.
Oa het stuk waar deze bug zat.

De bug zat in het niet opruimen van een entry in een hashtable. Safe code had dat kunnen voorkomen.

[ Voor 12% gewijzigd door .oisyn op 25-10-2026 13:15 ]

[eheijnen]

Misschien helpen meer donaties....
https://www.reuters.com/technology/php-foundation-under-funded-with-one-full-time-staff-member-director-says-2026-10-23/

[RobertMe]

.oisyn schreef op zondag 25 oktober 2026 @ 13:14:
[...]

De bug zat in het niet opruimen van een entry in een hashtable. Safe code had dat kunnen voorkomen.

Ze hebben ~5.000 regels productie code herschreven (en de totale patch incl tests is 10.000 regels). Dat lijkt me toch iets meer dan alleen het niet opruimen van een entry in een hash table?

[hackerhater]

RobertMe schreef op zondag 25 oktober 2026 @ 13:28:
[...]

Ze hebben ~5.000 regels productie code herschreven (en de totale patch incl tests is 10.000 regels). Dat lijkt me toch iets meer dan alleen het niet opruimen van een entry in een hash table?

Ja zover ik weet zat de bug oa in het opruimen en afhandelen wanneer het programma door een OOM afgeschoten werd.

[.oisyn]

RobertMe schreef op zondag 25 oktober 2026 @ 13:28:
[...]

Ze hebben ~5.000 regels productie code herschreven (en de totale patch incl tests is 10.000 regels). Dat lijkt me toch iets meer dan alleen het niet opruimen van een entry in een hash table?

Ik heb alleen high level overviews gelezen tot nu toe, dus dit is puur theorycrafting, maar als je er in eerste instantie niet nadenkt over ownership van de data, dan kan het best dat je jezelf dan in een hoekje hebt geverfd omdat het opruimen ervan niet meer kan zonder het design van je systeem grondig te refactoren.

[Webgnome]

en zijn er anderen ook druk bezig met node2shell? Gelukkig was het bij ons een stuk simpeler. Via nvm nodejs upgraden en alles herstarten en we waren klaar. Cloudflare ruleset overrulen en alles deed weer wat het moest doen

[RobertMe]

Webgnome schreef op maandag 26 oktober 2026 @ 13:10:
en zijn er anderen ook druk bezig met node2shell? Gelukkig was het bij ons een stuk simpeler. Via nvm nodejs upgraden en alles herstarten en we waren klaar. Cloudflare ruleset overrulen en alles deed weer wat het moest doen

Node2shell, uh, ik bedoel Python2shell, uh, ik bedoel http2shell, ownee, brocolli2shell.

In alke gevallen gaat het immers om een RCE in de C library (van Google) voor Brotli compressie. Waarmee dus elke webserver/... die hier gebruik van maakt getroffen is.

Overigens zelf niet getroffen. Ik werk in PHP

[wackmaniac]

Webgnome schreef op maandag 26 oktober 2026 @ 13:10:
en zijn er anderen ook druk bezig met node2shell? Gelukkig was het bij ons een stuk simpeler. Via nvm nodejs upgraden en alles herstarten en we waren klaar. Cloudflare ruleset overrulen en alles deed weer wat het moest doen

Nou, daar waren wij al op voorbereid, omdat een contactpersoon ons op de hoogte had gebracht van een security release. Dat stond allemaal klaar en was een kwestie van een paar knoppen indrukken, gelukkig.

[Webgnome]

Hier was het uiteindeljik ook meer werk om mijn reactie te typen dan om daadwerkelijk iets te doen

nvm update..

pm2 reload

klaar..

(verkorte versie)

[mrdemc]

RobertMe schreef op maandag 26 oktober 2026 @ 13:18:
[...]

Node2shell, uh, ik bedoel Python2shell, uh, ik bedoel http2shell, ownee, brocolli2shell.

In alke gevallen gaat het immers om een RCE in de C library (van Google) voor Brotli compressie. Waarmee dus elke webserver/... die hier gebruik van maakt getroffen is.

Overigens zelf niet getroffen. Ik werk in PHP

PHP heeft ook een update voor de brotli lib

In ieder geval onder Windows. Linux weet ik zo even niet.

The PHP team announces the immediate availability of updated Windows
builds:

- PHP 8.2.35-1
- PHP 8.3.36-1
- PHP 8.4.27-1
- PHP 8.5.12-1

These builds include Brotli 1.2.1, which fixes CVE-2026-111497, an
out-of-bounds write vulnerability in Brotli decompression.

On Windows, PHP's cURL extension can invoke the affected decoder when
automatic HTTP response decompression is enabled. This is disabled by
default in cURL, but applications and HTTP client libraries may enable
it.

PHP Windows users are advised to update to these builds.

The -1 suffix marks a Windows package rebuild with updated dependencies.
The PHP source and runtime versions have not changed.

[Lethalis]

SPee schreef op vrijdag 23 oktober 2026 @ 18:55:
[...]

Maar ook Rust is niet (100%) veilig.

[YouTube: Rust Had a Memory Safety Bug for 11 Years #rust #programming #security]


Maar: waarom PHP herschrijven in Rust? Wil je niet eerder de programma's/websites die met PHP zijn gemaakt herschrijven? (naar React )

Niets is 100% veilig, maar de borrow checker van Rust voorkomt wel een hoop foutjes die je misschien in een andere programmeertaal wel maakt.

Voor de rest heeft PHP gewoon bestaansrecht als een taal waarin mensen snel iets kunnen bouwen en daarnaast zijn er heel veel systemen al mee gebouwd. Dus het is makkelijker om PHP zelf aan te pakken dan om al die software aan te pakken.

[Lethalis]

RobertMe schreef op vrijdag 23 oktober 2026 @ 17:15:
[...]

Zijn andere talen dan ook herschreven? Volgens mij is .NET op een gegeven moment wel in .NET geschreven (incl compiler en al)? Maar geldt dat bv ook voor Java? Python? ...

.NET heeft inderdaad het Roslyn compiler platform, maar een ander bekend en recent voorbeeld is TypeScript. De TS compiler is herschreven van JavaScript naar Go. Met name voor de performance in dat geval. De Go compiler is meer dan 10x zo snel

[ Voor 10% gewijzigd door Lethalis op 26-10-2026 16:57 ]

[Cartman!]

Webgnome schreef op maandag 26 oktober 2026 @ 13:10:
en zijn er anderen ook druk bezig met node2shell? Gelukkig was het bij ons een stuk simpeler. Via nvm nodejs upgraden en alles herstarten en we waren klaar. Cloudflare ruleset overrulen en alles deed weer wat het moest doen

AWS Lambda update automatisch dus geen werk aan gehad

[Lethalis]

hackerhater schreef op zondag 25 oktober 2026 @ 08:07:
[...]

Omdat het memory-safe deel van een taal als bijvoorbeeld Rust direct geheugen manipulatie blokkeerd ;)
Dat is het hele punt erachter. Wat werkt heel goed voor de meeste programma's behalve in generiek deze 3 categorieen:

1) Drivers die low-level toegang nodig hebben
2) De HAL van operating systems
3) De compilers/interpreters van talen.............

Je kunt met Rust echt alles zelf bepalen en dus ook alles bouwen. Inclusief de nucleaire optie:

Rust:

unsafe { }

[RobertMe]

mrdemc schreef op maandag 26 oktober 2026 @ 16:21:
[...]

PHP heeft ook een update voor de brotli lib

In ieder geval onder Windows. Linux weet ik zo even niet.


[...]

Lijkt me bij PHP wel een stuk minder "relevant" / "kwetsbaar". Dan moet je vanuit de PHP code dus al iets met Brotli doen (zoals dus de aangehaalde cURL request) met een malafide file of request naar een malafide server. Bij die andere talen zit het in de ingebakken webserver. Waardoor dus iedereen een malafide HTTP request, "met Brotli encoding" kan doen om deze RCE te misbruiken.

Uiteraard ben je bij PHP wel mogelijk vatbaar als Apache / Nginx / Lightspeed / FrankenPHP / ... Brotli ingeschakeld hebben en dezelfde vatbare library gebruiken. Waarbij ik het idee heb dat Go een eigen implementatie heeft, waardoor Caddy, en daarmee FrankenPHP, naar ik aanneem niet vatbaar zijn. En hetzelfde geldt dan voor Traefik als reverse proxy die mogelijk al decompressed voor die het naar de upstream server stuurt.

[RobertMe]

Lethalis schreef op maandag 26 oktober 2026 @ 16:56:
De TS compiler is herschreven van JavaScript naar Go.

Maar die was dus niet geschreven in een unsafe taal. En dus irrelevant in de discussie. En TS is natuurlijk geen volledige taal met runtime en al. Het is een taal die transpiled. En ook daarom irrelevant v.w.b. "kun je een taal in een 'safe' taal schrijven".

* RobertMe vraagt zich nu af of er een "safe" JS implementatie is. Servo is wel in Rust geschreven, maar is alleen HTML / DOM, CSS, rendering etc meen ik. Dus zonder JS parser, runtime, ....

[hackerhater]

Lethalis schreef op maandag 26 oktober 2026 @ 17:02:
[...]

Je kunt met Rust echt alles zelf bepalen en dus ook alles bouwen. Inclusief de nucleaire optie:

Rust:

unsafe { }

Jup en dan val je dus uit memory-safe mode.

[RayNbow]

hackerhater schreef op maandag 26 oktober 2026 @ 22:56:
[...]

Jup en dan val je dus uit memory-safe mode.

Dat is hetzelfde als in een taal een cast uitvoeren. Daarmee zeg je "Sorry typechecker, ik weet het beter". Unsafe is net zoiets: je geeft aan dat de memorysafetychecker een in jouw ogen een geldig programma zou verwerpen, dus zet je de check uit. Het is alleen wel zo dat als je de checkers omzeilt, de bewijslast bij jou als programmeur ligt en het aan jou is om de geschreven code te verantwoorden.

[.oisyn]

hackerhater schreef op maandag 26 oktober 2026 @ 22:56:
[...]

Jup en dan val je dus uit memory-safe mode.

...en? Een klein blokje unsafe is zoveel beter om over te redeneren dan een gehele applicatie. Kijk bijvoorbeeld naar Rust's dynamische array class, Vec<T>. Intern moet die unsafe gebruiken; er is immers een gealloceerde buffer met ongeinitialiseerd geheugen die gevuld kan gaan worden. De unsafe blokken zijn geisoleerd en je kunt beredeneren dat de code klopt. De externe API is vervolgens volledig safe te gebruiken. Je kunt bijvoorbeeld niet een referentie naar een element opvragen en onthouden en vervolgens de Vec aanpassen, want dan gaat de borrow checker klagen.

Natuurlijk kun je ook gewoon overal pointers gebruiken en unsafe blokken om die te dereferencen, maar dat is heel ver verwijderd van idiomatisch Rust, en dat is geen argument om Rust af te schrijven.

[ Voor 9% gewijzigd door .oisyn op 27-10-2026 11:21 ]

[DevWouter]

Ugh... Ik ben zo klaar met een bepaalde groep software ontwikkelaars. Het lijkt wel alsof ze steeds dommer worden, tot het punt dat ik denk dat ze een grap maken om vervolgens ze toch vragen of ze wel heel zeker zijn van hun zaak. Maar helaas, met ze in discussie gaan is zinloos, zelfs een Jehova getuigen met een coke verslaving is makkelijker te overtuigen dan deze groep software ontwikkelaars.

En als ze wel bereid zijn om te luisteren moet ik eerst wachten tot ze hun firehose of bullshit leeg hebben gespoten om vervolgens stapsgewijs elke argument te ontmantelen.

Nog heel even en ik wil verplichten dat software ontwikkelaars hun werk zonder computers doen en de eerste die zo dom is om te zeggen dat het onmogelijk is mag van mij een twintig pagina opstel schrijven over waarom het wel kan. Ik raak inmiddels overtuigd dat daardoor het werk sneller zal gaan en met minder bugs.

[RobertMe]

DevWouter schreef op dinsdag 27 oktober 2026 @ 15:08:
Nog heel even en ik wil verplichten dat software ontwikkelaars hun werk zonder computers doen en de eerste die zo dom is om te zeggen dat het onmogelijk is mag van mij een twintig pagina opstel schrijven over waarom het wel kan.

Ponskaarten?

* RobertMe heeft tentamens op het HBO nog op papier gedaan, waarbij IIRC dus ook daadwerkelijk stukjes code geschreven moesten worden. Waarbij het dan nog knap is dat ze mijn hanenpoten konden ontleden. "Is het nu een (, {, [ of |" ,

[Webgnome]

DevWouter schreef op dinsdag 27 oktober 2026 @ 15:08:
Ugh... Ik ben zo klaar met een bepaalde groep software ontwikkelaars. Het lijkt wel alsof ze steeds dommer worden, tot het punt dat ik denk dat ze een grap maken om vervolgens ze toch vragen of ze wel heel zeker zijn van hun zaak. Maar helaas, met ze in discussie gaan is zinloos, zelfs een Jehova getuigen met een coke verslaving is makkelijker te overtuigen dan deze groep software ontwikkelaars.

En als ze wel bereid zijn om te luisteren moet ik eerst wachten tot ze hun firehose of bullshit leeg hebben gespoten om vervolgens stapsgewijs elke argument te ontmantelen.

Nog heel even en ik wil verplichten dat software ontwikkelaars hun werk zonder computers doen en de eerste die zo dom is om te zeggen dat het onmogelijk is mag van mij een twintig pagina opstel schrijven over waarom het wel kan. Ik raak inmiddels overtuigd dat daardoor het werk sneller zal gaan en met minder bugs.

en waar komt deze frustratie vandaan?

* Webgnome heeft ook nog een tentame of 2 op papier moeten doen. Zakte de eerste keer omdat ik een ; vergeten was en ja dan compiled het niet he..

[ Voor 7% gewijzigd door Webgnome op 27-10-2026 15:24 ]

[Merethil]

RobertMe schreef op dinsdag 27 oktober 2026 @ 15:21:
[...]

Ponskaarten?

* RobertMe heeft tentamens op het HBO nog op papier gedaan, waarbij IIRC dus ook daadwerkelijk stukjes code geschreven moesten worden. Waarbij het dan nog knap is dat ze mijn hanenpoten konden ontleden. "Is het nu een (, {, [ of |" ,

In 2020 bij de Open Universiteit nog wel gedaan, en ook hele state machines uitgetekend op die manier. Wat ruk als je dan ergens iets vergeten was ja...

Ik denk dat je het voordeel van de twijfel kreeg bij dit soort zaken; de docent gaat je code echt niet uittypen om te testen of het werkt want met de snelheid waarop mijn docenten typten had ik dan nu nog steeds sommige cijfers niet gehad...

[DevWouter]

RobertMe schreef op dinsdag 27 oktober 2026 @ 15:21:
[...]

Ponskaarten?

Oh please, dan nog liever handmatig weerstandjes vervangen

Webgnome schreef op dinsdag 27 oktober 2026 @ 15:23:
[...]

en waar komt deze frustratie vandaan?

Voornamelijk gebrek aan liefde van mijn kant, maar het is de zoveelste persoon (van een bepaalde categorie) die zijn verhaal goed probeert te lullen terwijl het zo krom is als een triangel.

[DevWouter]

RobertMe schreef op dinsdag 27 oktober 2026 @ 15:21:
* RobertMe heeft tentamens op het HBO nog op papier gedaan, waarbij IIRC dus ook daadwerkelijk stukjes code geschreven moesten worden. Waarbij het dan nog knap is dat ze mijn hanenpoten konden ontleden. "Is het nu een (, {, [ of |" ,

Ik maakte er tijdens mijn opleiding er juist een sport van om mijn huiswerk (code op een stick) zonder ook maar één keer te compilen in te leveren. Dat is volgens mij maar één keer fout gegaan maar toen heeft de docent me toch het volledige cijfer gegeven omdat die overtuigd was dat hij het per ongeluk aangepast had.

Was wel humor als de halve klas te horen krijgen dat ze hun code moeten compilen voordat ze het inleveren waarna de docent regelmatig mij code pakt als voorbeeld.

[hackerhater]

.oisyn schreef op dinsdag 27 oktober 2026 @ 11:18:
[...]


...en? Een klein blokje unsafe is zoveel beter om over te redeneren dan een gehele applicatie. Kijk bijvoorbeeld naar Rust's dynamische array class, Vec<T>. Intern moet die unsafe gebruiken; er is immers een gealloceerde buffer met ongeinitialiseerd geheugen die gevuld kan gaan worden. De unsafe blokken zijn geisoleerd en je kunt beredeneren dat de code klopt. De externe API is vervolgens volledig safe te gebruiken. Je kunt bijvoorbeeld niet een referentie naar een element opvragen en onthouden en vervolgens de Vec aanpassen, want dan gaat de borrow checker klagen.

Natuurlijk kun je ook gewoon overal pointers gebruiken en unsafe blokken om die te dereferencen, maar dat is heel ver verwijderd van idiomatisch Rust, en dat is geen argument om Rust af te schrijven.

Het gros van een taal-runtime is geheugen reserveringen en manipulatie.
Het gedraagt zich NIET als een gewoon programma.
Als ik moet schatten zou ruim 50% in unsafe staan.

Buiten dat het herschrijven van iets als PHP in een andere taal gewoon vragen om bugs is.

[ Voor 4% gewijzigd door hackerhater op 28-10-2026 08:07 ]

[Eärendil]

hackerhater schreef op woensdag 28 oktober 2026 @ 08:05:
[...]
Buiten dat het herschrijven van iets als PHP in een andere taal gewoon vragen om bugs is.

Die zitten er nu ook al in

[.oisyn]

hackerhater schreef op woensdag 28 oktober 2026 @ 08:05:
[...]

Het gros van een taal-runtime is geheugen reserveringen en manipulatie.

Élk programma is voornamelijk geheugen-manipulatie.

Het gedraagt zich NIET als een gewoon programma.
Als ik moet schatten zou ruim 50% in unsafe staan.

Je schatting is compleet kul. Er is geen enkele reden waarom een PHP in Rust geen normale references kan gebruiken.

[DevWouter]

Eärendil schreef op woensdag 28 oktober 2026 @ 09:23:
[...]


Die zitten er nu ook al in

Niet zoveel als je het compleet zou herschrijven. Tijd (lees: middelen) en aandacht is wat noodzakelijk is.

[Mugwump]

Waar ik dan weer moe van word, is dat ik steeds meer tijd kwijt ben aan mensen overtuigen van het feit dat hun AI Agent totale onzin produceert, hetzij code, dan wel verklaringen voor iets. Ze begrijpen zelf de materie maar zeer matig en dat leidt er ook weer toe dat ze niet in staat zijn om een AI agent de juiste instructies te geven. En die diepgaande kennis doen ze ook niet op door gelijk weer naar een AI agent te rennen.
Dus vaak ben ik dan weer van alles aan het uittekenen en uitleggen, maar dan krijg ik constant 'ja maar mijn AI agent komt met...'. Moet me aardig inhouden om ze niet recht in hun gezicht te melden dat de AI Agent hun incompetentie slechts versterkt.

[wackmaniac]

Sommige collega's verworden inderdaad in meat proxies. Zie ook https://dontbeameatproxy.com/

Waarbij het me weer niets zou verbazen als die website met AI is gebouwd 😂

[Merethil]

wackmaniac schreef op woensdag 28 oktober 2026 @ 11:36:
Sommige collega's verworden inderdaad in meat proxies. Zie ook https://dontbeameatproxy.com/

Waarbij het me weer niets zou verbazen als die website met AI is gebouwd 😂

Maar de persoon die het heeft laten bouwen door AI heeft de 400 regels HTML vast wel gelezen voor deployment. Toch? TOCH?!?!

[NullVoid]

Alsof het niveau voor de AI-hype wel hoog lag? Helaas meer slechte dan goede codebases gezien in de afgelopen jaren. AI gaat helaas niet helpen om het niveau omhoog te krijgen. Het wordt nu alleen maar makkelijker om bagger te produceren.

Vooral bij bedrijven die denken dat softskills belangrijker zijn dan hardskills wordt er veel gebeunhaast.

[OMX2000]

NullVoid schreef op woensdag 28 oktober 2026 @ 15:50:
Alsof het niveau voor de AI-hype wel hoog lag? Helaas meer slechte dan goede codebases gezien in de afgelopen jaren. AI gaat helaas niet helpen om het niveau omhoog te krijgen. Het wordt nu alleen maar makkelijker om bagger te produceren.

Vooral bij bedrijven die denken dat softskills belangrijker zijn dan hardskills wordt er veel gebeunhaast.

Waarom zouden hardskills belangrijker zijn of andersom?

[NullVoid]

OMX2000 schreef op woensdag 28 oktober 2026 @ 17:54:
[...]

Waarom zouden hardskills belangrijker zijn of andersom?

Hoe wil je software schrijven zonder goede fundamentele kennis? Hard skills zijn toch wel de basis van een goede engineer imho.

[ThomasG]

OMX2000 schreef op woensdag 28 oktober 2026 @ 17:54:
[...]

Waarom zouden hardskills belangrijker zijn of andersom?

Nu alles steeds meer AI wordt, zijn goede hard-skills echt wel een must. Vooral heel goed zijn in debuggen is iets wat steeds meer ontbreekt bij collega's, terwijl dat nu net iets is wat je een baangarantie gaat geven. En dat is echt meer dan alleen een breakpoint plaatsen, of wat code in AI stoppen en vragen waar het probleem zit.

[Koenvh]

ThomasG schreef op woensdag 28 oktober 2026 @ 18:48:
[...]

Nu alles steeds meer AI wordt, zijn goede hard-skills echt wel een must. Vooral heel goed zijn in debuggen is iets wat steeds meer ontbreekt bij collega's, terwijl dat nu net iets is wat je een baangarantie gaat geven. En dat is echt meer dan alleen een breakpoint plaatsen, of wat code in AI stoppen en vragen waar het probleem zit.

Ik wacht nog tot de AI antwoordt met "Het probleem bevindt zich tussen de stoel en het toetsenbord"

[ThomasG]

Koenvh schreef op woensdag 28 oktober 2026 @ 21:10:
[...]

Ik wacht nog tot de AI antwoordt met "Het probleem bevindt zich tussen de stoel en het toetsenbord"

Dan zijn we er over 10 jaar niet meer

[Webgnome]

NullVoid schreef op woensdag 28 oktober 2026 @ 18:06:
[...]


Hoe wil je software schrijven zonder goede fundamentele kennis? Hard skills zijn toch wel de basis van een goede engineer imho.

Je hebt goede software en software met mooie code. Die laatste interesseert de meeste klanten helemaal niks. Daar komt softskills om de hoek. Hoe verkoop je dat je langer bezig bent etc. En natuurlijk het snappen en begrijpen van klantvraag stukken. In kleine teams zijn beide heel belangrijk. Daar kun je niet simpelweg de code koning uit hangen.

[NullVoid]

Ook voor goede software heb je hard skills nodig. Over software kwaliteit kun je hele boeken schrijven, maar het belangrijkste voor mij is dat het makkelijk is om aanpassingen te maken. Uiteindelijk wil je zo goed mogelijk de business ondersteunen. Dan moet je niet gaan over-engineren met micro-services en kubernetes als dat niet nodig is. Tegelijkertijd is het gebrek aan goede abstracties en functies van 200 regels lang ook niet ideaal. Simpele oplossingen voor complexen problemen, niet andersom.

De klant is alleen maar goed geholpen als je als team makkelijk functionaliteit kunt aanpassen zonder dingen te breken en daar helpt een goed opgezette codebase enorm bij.

Verder zorgen voor goede processen om te zorgen dat de klantvraag helder is. Je kunt gewoon afspraken maken met stakeholders om op vaste momenten samen te zitten om de requirements duidelijk te krijgen. Korte lijntjes tussen developers en PO/stakeholders helpt ook enorm.

[ElkeBxl]

Hier ben ik weer met mijn jaarlijkse plug voor de Advent of Code met bijhorend topic: Advent of Code 2026