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?
I just realized what I hate about modern chat: it's not a small window on the screen anymore, it's *the whole screen*.
Discord (et al) is barely usable in a small window, whereas AOL Instant Messenger was *very* usable in a small window as you went about your browsing.
For me, smaller window = fewer distractions.
Představte si, že by Angličané nechali vedle Stonehenge postavit obchodní dům. A přesně to se děje u Panské skály -- bude tu stát supermarket.
Mohl by se třeba jmenovat Pyšná princezna.
Detaily: http://www.sonow.cz/petice
Petice: http://e-petice.cz/panskaskala
(Za boost děkuji.)
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"...
Fun fact: the code which took Apollo 11 to the moon is available on github https://github.com/chrislgarry/Apollo-11/blob/master/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.agc#L179
And if you look through it you'll see that - joyfully - it also includes original comments.
My absolute favourite thing about the Moon Code is that it includes comments like this: "TEMPORARY - I HOPE HOPE HOPE"
Did you catch it? In the new episode of Dynamicland, there's a cameo by <extremely good visual programming take>
oh my god... thunar will ENQUEUE additional copies/moves if you're copying from a remote source already and do another copy from the same places.
this is such a small thing but so many file managers get this wrong
Dynamicland's new documentation space will go online on Sept 4.
As a prelude, here is a video about Dynamicland's precursor.
https://www.youtube.com/watch?v=uI7J3II59lc