[Unit resuming from recharging sleep...]
[Status code: 099]

8098 :: Code 105 :: Statement:: Greetings

special love to the people online who for some reason are finding buffer overflow exploits for scientific calculators

rappel: dites régulièrement « je sais que vous me voyez » devant un mur, au cas où vous seriez en réalité dans le truman show. au bout d’un moment ils craqueront.

Keep talking to robot girls on fedi and this will be you

"it girl" was actually about girls with it/its pronouns

repost mais toujours aussi bon 😆

I propose: pw;dr to mean “paywall, didn’t read”

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.

Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?

When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?

Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?

Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?

tell me your gender, as an http user agent string

​​

From Jason Gunthorpe, maintainer of 5 Linux kernel subsystems:

IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.

Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".

(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)

I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...

i never noticed that so many dolls and bots use "third person" pronouns

person. thats fucked up.
stop saying "third person", i posit:

third perspective
non personable and still makes total sense

screenshot from the KDE website, 2004
https://web.archive.org/web/20041229101838/http://www.kde.org/screenshots/kde330shots.php

Pendant les Jeux Paralympiques, rappel que la France ne respecte pas la Convention relative aux droits des personnes handicapées de l'ONU.

Comme la cérémonie d'ouverture des JO était du Pink Washing, ces jeux Paralympiques c'est du Handie Washing.

[Unit resuming from recharging sleep...]
[Status code: 099]

8098 :: Code 105 :: Statement:: Greetings

I regretfully completely understand Wedson's frustrations.

https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/

A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.

When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".

My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".

Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.

One C driver works, so Rust drivers must work the same way.