I (accidentally) removed two symbols from a curl header that have been deprecated and without functionality for over 17 years.

Result: of course there is still code out there using those that now reports build failures...

Keeping absolute backwards compatibility is real work.

@corbet Despite maybe a different viewpoint I say my views with the hopes that Rust integration, spread and reach will all improve 🙂 Personally Ive found existing kernel documentation, yes, messy but also full of details that I actually need. Ive used Rust in userland professionally since early 2022 so not exactly a ”denialist”. I do get its benefits especially in the uapi layer.

@corbet it is also a money question. We must enforce big companies like Microsoft to use a portion of their Rust budget to make it happen if they are unwilling otherwise. It is also in the long run best for Linux Rust governance. Ie great and well documented features.

@corbet It could be improved by being more integral part of the review process. NCC Groups article series ”Rustproofing” provides a good example of how to explain Rust kernel internals. I see it just as a process improvement, not something that I would expect to be fixed in fast phase. Starting from simple example there is rustdoc/kdoc and rst/md. I could not find any guidance which convention should be used for documenting an exported symbol.

At the gates of hell - The Lake of Hell national park

i got so angry after reading this paper on LLMs and African American English that i literally had to stand up and go walk around the block to cool off https://www.nature.com/articles/s41586-024-07856-5 it's a very compelling paper, with a super clever methodology, and (i'm paraphrasing/extrapolating) shows that "alignment" strategies like RLHF only work to ensure that it never seems like a white person is saying something overtly racist, rather than addressing the actual prejudice baked into the model

@lina gcc rust compatibility is a non-opianated constraint against taking Rust code to anything in any arch defconfig.

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"...

@drewdevault Rust landed 2 years ago to mainline. It is not uncommon timeline for a large feature patch set. Can take longer too. And we are talking like a completely new programming language. When the announcement came (was it 6.1), I was like "very cool, this will probably realize into something within 10 year timeline".

One persons rejection is other persons governance.

Speaking of recent events at LKML concerning #Rust and #kernel, and also what I've said in some threads, the key element for reaching tolerance is #documentation.

This does not mean that bad behavior is acceptable but great documentation is best means to be preventive of such events ever occurring. Right now Rust kernel documentation almost does not exist.

What is an appropriate granularity for documentation? It is the level where an experienced kernel maintainer who has *never* used Rust can still understand your kernel patch.

That is the ideal. Obviously not always reached but underlines how bad state Rust documentation is ATM. I blame for most of this #Google and #Microsoft, not the developers. They are two private companies who spend vasta amounts of money for Rust kernel work. And they should know what I said already.

This is a screenshot of the most beautiful karma post of 2024.

After having abused his ownership of X for two years, Brazil becomes the first country to simply shut down X.

The legally elected social democratic government of Brazil experienced a January 6 style coup attempt by anti-democratic, hard-right nationalist Bolsonaro in January 2023.

They have since fought a long legal battle to get Musk to shut down X accounts related to this coup.

Musk refused.

So they shut him down.

@lkundrak @ljs @vbabka Hell is nice and relaxing place to be in: https://www.nationalparks.fi/helvetinjarvinp

@ljs @vbabka There's a nice cafeteria near the national park, so that will keep me going ;-)

@vbabka @ljs Should start gym routine again, holidays mixed it up. Today, I'm going to kick off my exercise routine and do some hiking at Helvetinjärvi of which literal English translation is "The Lake of Hell" ;-) It's a national park nearby.

I have accountant for my company now. Had a meeting yesterday. I decided to go to a traditional accountant office and pay for personal accountant. I think this spending will come back!

I.e. not using one of those fancy Internet platforms. IMHO, great accountant is the same for a company as a great doctor is for a person.

@ljs is that a weight lifting term :D https://thegainzbox.com/

it is crazy how acid you can get with u-he bazille without even getting even into using filters yet. phase distortion and fractalize rock

@anotherwalther The expectations on timeline might also be too optimistic. Rust support has been in the mainline like couple of years or something. It's not a long time and not much progress is expected on overall acceptance during that period. Some patience can go a long way.

Even outside Rust circles some people give up on kernel development because a major feature patch set can take about the same time to upstream going to through various forms and sizes, as Rust has been available.

@anotherwalther In addition to documentation, for Linux it is not sustainable to have defconfig's, which don't compile with GCC. So other way to make Rust more feasible for Linux is to contribute to GCC-Rust backend. Up until it is as usable tool for Rust based kernel development, the whole language is cool demo but cannot be scaled handling any of the kernel internals. It is a huge capping element here and I don't think all Rust folks necessarily understand the importance of GCC compilation.

@anotherwalther It could be also that checking the details would require reverse engineering huge chunks of Rust code base, which is simply not possible to commit into. Some people might use Rust if the barrier is not too high, but not all people are particularly excited about it, which is a fair position.

It could be also just my own beliefs but I got impression from some Rust posts sometimes that some people think that there would be some kind of large-scale plan to reimplement Linux with Rust. It might be something that Microsoft and Google would like to happen but otherwise such plan does not exist.

There is neither a plan to not do it. The point is that we look at best for Linux maybe few weeks ahead and the overall result is distributed consensus.

That leads to the conclusion that only way to increase Rust adaptation is to make it lower hanging fruit than it is today. Documentation is a great starting point.