À ce stade, on peut imaginer que personne chez Microsoft n'a jamais fait autant pour que les gens restent sous Windows, que ne le font les gens qui maintienent la glibc …

C'est marrant j'ai lu les slides de présentation de pledge dont il parle juste avant, et j'ai tiqué sur exactement la même slide qui parle de seccomp.

Via: https://firmwaresecurity.com/2015/11/12/kees-on-linux-seccomp-and-openbsd-pledge/

Quelle UX de merde …

C'est intéressant, même si ce que je retiens personnellement c'est que ce n'est pas seccomp qui fout la merde, c'est d'avoir une libc linkée dynamiquement, ce qui fait que le développeur ne peut pas savoir à l'avance quel syscalls seront utilisés.

De ce point de vue là je trouve que la position GNU/Linux est un peu bâtarde: soit on fait façon Windows, MacOS, OpenBSD à avoir une libc fournie par l'OS et obligatoire, en interdisant les syscalls custom soit chaque programme vient avec son propre lot de syscalls en utilisant une libc compilée statiquement, mais le modèle hybride c'est le merdier.

rename -v 's/image//' *.png

L'“executor” pour le code Rust asynchrone dans le noyau Linux. Ça tient en moins de 1000 lignes de code, et ça permet d'utiliser async-await dans le noyaux.

Le modèle de Rust pour async/await n'est pas sans poser de problèmes (le fait d'avoir plusieurs executeurs qui existent en parallèle avec chacun leur propre écosystème), mais ça marche vraiment bien pour ce pour quoi c'était pensé, à savoir permettre d'utiliser async/await même à très bas niveau. Et ça c'est vraiment très très fort.