-
Retiring from the Rust for Linux project 4 lore.kernel.org
On Rust, Linux, developers, maintainers airlied.blogspot.com via
gioele
5 months ago
A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible vt.social via
WeetHet
5 months ago
How Rust solves the problem of incomplete Kernel Linux API docs vt.social via
abhinav
5 months ago
I watched the video linked in the email and there’s definitely a degree of completely unwarranted hostility that would’ve prompted me to make a similar decision. I can imagine this wasn’t remotely close to the first time someone from the RustForLinux project has had to field aggressive questions arising from made up ideas about what bringing Rust into the kernel entails.
Edit: Here’s a summary of the discussion that was happening in the linked video: https://lwn.net/Articles/978738/
I wrote large chunks of RFD 26, the document describing our thought process and our choice at Oxide to go with illumos rather than, say, Linux, for our host operating system. I recall wringing my hands for months on the subject of how likely it would be that we could work towards use of Rust in the core upstream repository of the OS, for both kernel and user mode components. Basically everybody is familiar with the stereotypes about what it’s like to work in the Linux kernel community and participate in their project spaces, and with widely shouted (if not shared!) opinions about whether it’s good to have debugging tools and safer languages. In the end I tried to give credit or at least open mindedness to the idea that perhaps the Linux folks were coming around in 2020 and 2021 and that they would have seen the light by now.
In hindsight it increasingly seems to have been a waste of good hand wringing.
Not just hostility but an incredible degree of ignorance. Saying something like “we’ve learned from Java that methods are bad” (barely paraphrasing) is such a hilarious misunderstanding of so many concepts in programming.
I don’t usually get angry with people on the internet. But this level of hostility and assumption of bad intent is next level. (Also, wow, looks like my corner of the internet is more friendly than I thought).
There was absolutely zero reason for the hostility of that audience member and the conference organisers should have stepped in.
Yeah that part shocked me as well, at the very least someone should have offered to continue the discussion offline/sidebar to allow others a chance ask questions before time. Anytime emotions start to become visible it’s passed time to step in. The speakers held their composure quite well, and I can’t imagine what kind of stress that adds on top of an already stressful event for most people (public speaking about controversial topics).
I would consider this to be tyrannical organizational behavior. If this actually happened I would absolutely have supported counter-organizers stepping in in order to allow Ted Ts’o to continue talking, and if that failed organizing and promoting a completely different conference run by different people in order to allow Ted Tso’ to continue making this point.
The result of such approach is that arguments are won by those who shout the loudest and have the most power, not on the merits of their arguments. We have a prime example how an organisation loses contributors by defending asshole behavior. Assholes tolerate assholes, but others don’t.
I’m an experienced Rust developer with expertise in C<>Rust interoperability, and in position where I could have been working on it professionally. There’s no way I’m going to contribute to Linux when it’s run this way.
Considering working on Redox?
I don’t contribute to any OS at the moment, but I’m considering seeing how I can help out Redox purely out of protest to this kind of circumstance. I don’t think Linux should have it’s place in the market anymore.
It’s a complex situation, and the people who say Rust is a religion probably wouldn’t reflect on themselves even if Redox eclipsed their work.
I suspect it’s more constructive to just focus on Rust’s own ecosystem and tooling (in userspace).
I started looking into contributing a week or two ago and I’ve started working on a Nix-based build system for Redox, see here: https://gitlab.redox-os.org/redox-os/redox/-/issues/1552
Seems like a small but friendly group so far.
I agree the other replies, but I think this hasn’t been said clearly enough: the issue is not what Ted is saying, but how. The question is valid, though it has been rehashed a lot, but the tone and aggressiveness is not a valid way to ask a question in any context. That’s toxic behavior, plain and simple, so yes it falls within an organizer’s duty to rein in.
Is the question valid? It was addressed by the speakers but he kept going. And I believe this has come up before.
I meant in general it’s a valid question, I agree it sucks to bring it up then again, and shows Ted was more in it to rant than ask a good question.
The “though it has been rehashed a lot” was meant to hint at that, but it wasn’t really the point of my comment.
Have you ever been to any sort of professional conference? Talks are organised into thematic sessions, sessions have chairs, chairs keep the Q&A on track and stop things devolving like they did here, or at least encourage people not to shout over each other, like Ts’o was doing. It’s not tyranical in the least and it’s not CeNSoRsHIp!!1 either.
Who are the organizers that they would have enough political capital to shut down Ted Ts’o?
Shutting down flagrant nonsense and defending community members from abuse is one way to develop capital!
Accusations of abuse are often a form of abuse, precisely because they offer an excuse for an organization to shut down something they claim is flagrant nonsense. I wouldn’t want to work with anyone who thinks that Ted Ts’o should’ve been prevented by some outside power from communicating the way he did here.
What in the actual… what kind of conferences do people here go to!? Like, for me, it’s been years, and the ones I’ve attended were primarily academic conferences, but the religion comment + shouting would’ve been more than enough to make the session chair step in. Abuse or not, that kind of thing just derails the whole presentation.
I wouldn’t want to work with you either, so I think we’re all happy.
The chair of a track has the full right to the room at any descent conference.
To be more clear, I don’t question whether a conference organizer could kick out a high Linux maintainer if the organizer so chose but rather whether the organizers would find it worthwhile to begin a conflict with someone who presumably has influence in the Linux dev community with which to make continued participation in that community unpleasant for the organizers (assuming the organizers are, and want to continue to be, participants in that community).
Asahi Linux’s developer also recounts a similar experience. https://vt.social/@lina/113045455229442533
Please tell me that wasn’t actually Ted T’so being that aggressive, as LWN suggests. I expect better from such a senior Linux contributor.
You shouldn’t! This is the norm, and although some things are no longer as publicly inflammatory the attitude has been this way for literal decades.
I don’t like to wear it as a badge of honor, but “I stood next to a lieutenant while Linus yelled at them during kernel summit” is definitely the closest I’ve ever been to the kernel development process, and it was standard practice back then whenever something new was coming to Linux. At that time, it was Kernel Mode-Setting (KMS) for GPUs.
It’s interesting that he mentions if this breaks the function of a bunch of critical file systems that users depend on, it’s not his problem.
I’m pretty sure that would be considered breaking userspace?
What’s the first rule of Linux kernel development?
And then his suggestion “Lets just see what happens if we don’t give a crap about the semantic interfaces in a year.”
Like he doesn’t know that it’s just going to be a total disaster and blow the fuck up; and claim that is evidence of the unworkability of the solution, rather than evidence of the unwillingness to even make minor changes for compatibility sake.
Also the comparison to Java… They are certainly suffering a lot with people just fundamentally misunderstanding what Rust is.
The semantic definitions I would imagine would be useful even to C programmers using C interfaces in the Linux Kernel.
This is a truly unfortunate development. I really hope the Rust ecosystem in the Linux Kernel continues to grow.
As a long time Linux kernel module developer, and current Rust developer, I’ve been following this project closely.
It’s not breaking user space, it’s breaking kernel space. He didn’t say that he would break file systems that end-users depend on, but rather break APIs which in-kernel users depend on.
This would mean breaking file systems among other things, but those breakages would be fixed before the kernel with that change is released; because Linux does not break userspace. The question is who’s responsible for fixing that, the person who made the breaking change in the API or the users of the API.
The presenters were pretty clear that they do not expect maintainers to learn rust and that they will maintain the rust API. So that is not the question.
The presentation was about describing the state of their patch and clarifying how the C API actually is meant to be used. My impression was that the maintainers do not really know either:-)
The Asahi graphics driver dev said pretty much the same thing about the DRM layer they need to interface with… the only crashes she sees are in that layer – due to unclear and undocumented lifetime issues.
IMHO it would be nice to have rust wrappers for those layers: Lifetimes are clearly documented there.
Oh I agree completely, tho Ted did problematise the “we can’t fix your Rust code when we break APIs” thing even though it was in bad faith. However I was mainly trying to delineate between “driver developer breaks their users, namely the end user, user has to adapt” and “core infrastructure breaks their users, namely drivers, driver developers have to adapt”. The former is breaking userspace, the latter is not,
Good Lord yes, what a troubled audience member. I felt like we were about three seconds away from him shouting about a ‘goddamn WOKE AGENDA’. It must be exhausting to deal with such deep confusion combined with fearful hostility.
That seems to be Ted Ts’o, the maintainer of ext4.
https://en.wikipedia.org/wiki/Theodore_Ts'o
That’s an interesting piece of history. Kerberos remains one of the worst technologies I am forced to use on regular basis especially on non-Windows hosts.
Sorry I laughed. I used to work with MIT Kerberos and the GSSAPI and don’t have any fondness.
I am not sure where you’re getting the “woke agenda” thing … that seems to be inflaming an already inflamed situation without reason. It’s a non-sequitir
I watched the video, and I can definitely sympathize with the author, and why an interaction like that it would prompt him to leave the project.
At the same time, I think the technical disagreement is fairly clear, and the social / project management disagreement is fairly clear:
And he actually offers a path forward – keep doing what you’re doing, but know that we’re going to break you, and it’s up to YOU to fix that, not US.
He also says we will find out OVER TIME if this idea is good or not. He is not REJECTING the idea, but merely saying he refuses to do any work (and maybe even learning) to accommodate an idea that he views as experimental (or maybe even unpromising).
Now I have no idea if this is the right thing, because I am not involved in the kernel, and I also don’t write Rust.
But to me if the maintainer of a piece of code is saying this, it is actually crystal clear what the disagreement is.
He wants to put the burden on you to do the work, because he doesn’t see the benefit right now.
The Rust for Linux is making what seems like a reasonable request for more information on the semantics, so that they can encode it statically in the type system.
I am not sure, but I suspect the answer is “you have to figure that out yourself because there’s 30 years of history there” … or “that is a misguided way of looking at the problem – the solution does not match reality” [1]
I have been involved in such migrations professionally, and this is a very typical disagreement between the “old team” and a “new team”.
A new team assumes they are going rewrite everything and make the world better.
The old team has been down in the trenches for years. They have intimate knowledge of the code and the painful debugging necessary to get the system into its current state (a very successful state in this case, as Linux file systems store approximately ALL the data in the cloud, when it comes down to it)
The old team feels disrepected by the oversimplifications in the new way of thinking. (The perceived disrespect is probably why you’re getting this aggressive tone.)
A new team is genuinely optimistic and wants to improve things
The results are usually a mix, which is unsurprising. It’s never what the old team thinks it was, or a new team thinks it will be. It is a very typical conflict.
(And note it’s also possible that there are multiple new teams, and that one or more new teams is abandoned. But that doesn’t mean it’s not worth trying.)
It has nothing to do with any “woke agenda”. Do you agree? If so, I suggest retracting this comment, because it’s unhelpful and inaccurate
To me, the issue with what he said has nothing to do with the technical content and everything to do with the hostility. It sounded like he was seething with hatred toward the language and the Linux Rust project. Hell, he even described the speaker as pushing a religion!
It was not a comment from someone trying to productively discuss technical challenges.
The discussion was about power, really, disguised as technical one. It’s about establishing who is subservient to whom: the Rust interfaces to C ones, or vice versa.
Yes, in the context of the Linux project. The people who have power are the ones who have made things work for users, and Linux has a track record of making things work.
Are there Rust devs interested in contributing to GNU Hurd, and converting it to Rust? (honest question)
If Rust devs make the kernel better, and I hope they do, then they will naturally have more power. But so far it looks like it’s still the early days.
Rust developers can fork Linux and do whatever they want with it – that is the beauty of open source. There can be parallel development among people who disagree.
Users can vote with their feet
I actually suspect that is the best solution here – as I would personally like a memory safe kernel, but I’m not sure if Rust is on the path to it. It would let both projects move faster.
Ted Tso is a long time maintainer and he’s basically saying he refuses to merge stuff which is going to make his job harder later.
That’s not what I heard. Ted said that he isn’t interested in learning anything about Rust, even if it makes his job easier later. It’s about anti-intellectualism and machismo, not about maintenance burdens.
He has not yet been sold on the values of Rust in projects of the scope of the Linux kernel.
At such a time as he is convinced, he will probably change his mind on what he wishes to learn.
This isn’t anti-intellectualism. This is pragmatism.
Ted clearly isn’t listening to what the presenter is saying. Ted says “I don’t want to fix Rust code when it breaks because we change the C API” and the presenter says “that’s fine, I’ll fix the Rust code, but please tell me what the current semantics of the C API are”, to which Ted says “I don’t want to learn Rust!”.
Pragmatism would be delegating the work to someone else. This isn’t pragmatism, it’s childishness.
Right, and learning Rust deeply enough only to be able to make such a decision might feel like putting the cart before the horse to him.
Not really. I’ve answered a few questions like this on the Phoronix Forums, but basically:
Linux is a very special case because it’s used everywhere, it’s the standard OS of the world, even MS has given up on Windows and is just letting everyone use Linux now (through WSL or Azure Linux). There are a lot of reasons to use Rust, but the primary benefits are a more secure kernel and it will bring in new developers, as there are a lot less new C developers than there used to be.
I’ve considered the implications of making a separate fork of Linux just for Rust, but I don’t think it’s feasible. I can’t see a bunch of people just going over to some random fork that has no funding, and the split would be detrimental for both projects, but especially the fork as they’ll slowly lose the ability to merge patches as they fundamentally change how Linux is architected.
[Comment removed by author]
They have. The Asahi Linux GPU drivers are all in Rust in their own fork.
It’s a side-note but I wish people would stop using “memory safe” in reference to programs to mean “written in a memory-safe language” and not “free of memory errors”, which is what it is (or at least was) actually supposed to mean (of course the first implies the second, but the reverse is not true). The use of
unsafeas an actual keyword in Rust hasn’t helped the situation; “unsafe Rust” can mean so many things depending on the context (an unsafe languagesubsetsuperset, or a piece of code that is only valid in that subset, or a piece of code written in that subset that also has a memory safety issue, or code within anunsafeblock regardless of whether it uses unsafe language constructs) and it causes so much confusion in discussions about memory safety.I think what you are saying is that you like the idea of a kernel written in a memory-safe language, not just that you want a kernel free of memory safety errors, which should really be a given.
I want a kernel that’s free of memory safety errors [1], not necessarily one that’s written in Rust or any other particular language
Rust is one promising solution, but not the only possible solution
[1] and one that’s free of logical errors like missing/incorrect access checks, local root exploits, etc.
I think this might be where the ‘religion’ word came from. I don’t see other languages aggressively pushing rewrites for everything. Video said “Rust has ADTs” which weren’t invented in Rust, nor exclusive to Rust, nor popularized by Rust. Same applies to memory safety, and other arguments used in the ‘why Rust’—but also in the Venn diagram of the languages that are suitable for systems programming is Rust not alone or particularly remarkable.
Other languages with Rust’s features aren’t suitable for integration into the Linux codebase.
Rust is the first successful attempt to write a language that solves the same problems as C and also has the sort of nice features that application programmers have had for twenty years. Of course people would be excited about it.
Zig is not memory safe language.
Go is not memory safe in the presence of multiple threads.
None of these are memory safe, nor will they ever be.
Yep. Started a Go job recently after five years of rust. My heart sank the first time I saw “make sure not to call this without holding a mutex!” in some function’s comments.
Thats not traditionally what memory safety means. Traditionally memory safety means something more like free from memory errors that would lead to control of the instruction pointer which removes a massive class of never ending security vulns. Go achieves this.
Crashing from threads racing to overwrite a variable could definitely be considered a safety issue in some domains of course.But, If you redefine memory safety this way, doesn’t that exclude all languages but rust?
Go does not achieve this.
In Go, stores to slice-type variables are not atomic. You can create three goroutines that all have access to a struct that has a slice as one of its fields:
Goroutine one stores a small slice to the field, in a loop.
Goroutine two stores a large slice to the field, in a loop.
Goroutine three reads the field until it gets the base of the small slice and the length of the last one. From there, you can build type confusion, use-after-free, and all other categories of memory safety bugs. You can overwrite a function pointer (or interface type) with a value that you control and cause control flow to transition to n arbitrary point.
No, this is something that doesn’t happen in any memory-safe language. Nothing in the JVM or CLR has this problem, neither do Haskell, ML, Lisp, JavaScript, Erlang, and so on.
Memory safe means that every memory access must be via a valid pointer that is derived from a pointer to a valid object (global, heap, or stack allocation), is within the bounds of that object, and is within the lifetime of that object. Any access that does not follow these rules must either trap at run time or be disallowed at compile time. It is a subset of type safety, which additionally imposes rules on the operations within an object.
Super interesting. Would it break backwards compatibility to fix this?
No, it would be an ABI change and Go doesn’t guarantee a stable ABI. It would be a perf hit though. Almost no CPUs can do atomic three-word stores, so you’d need to either hold a lock while updating slices or do what .NET did and make slices heap-allocated things. This places more strain on the GC.
I realize this is possible: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html
But, I still argue that Go is considered a memory-safe language by normal definitions. I have never seen a single real-world Go bug of this nature that could be used as a security vuln which brings it out of the class of languages like C/C++ for which large code bases seem to have a never ending problem of bugs and security vulns from being memory-unsafe.
I think at the very least it would also exclude BEAM languages, where nothing is shared?
OCaml has a moderate runtime. I wouldn’t call it ‘large’. The MirageOS unikernel is written in OCaml and Mirage programs are very small and start up in a handful of milliseconds. Also I wouldn’t say it needs ‘a lot of tooling’ for basic C interop, it supports C FFI out of the box. Finally, OCaml is widely recognized as generating quite predictable Assembly.
I think all your points do hold for Haskell, though.
One point on OCaml, aren’t they looking to deprecate 32 bit support? Probably wouldn’t be suitable for Linux.
They have removed 32-bit support from OCaml 5 onwards, but the latest 4.14.x series is still supported. And Linux might remove 32-bit support in the near-to-mid future: https://www.reddit.com/r/linux/comments/152yeqx/there_are_plans_to_drop_32bit_support_from_the/
One random maintainer opining that they should remove 32 bit support is not indicative of much.
Will it be supported 20 years from now? We are talking about integration into the Linux kernel, after all.
Will Linux support 32-bit 20 years from now?
At most the syscall ABI. Maybe redirected binfmt style to 2030’s kernel running in a special VM (points at WSL).
Yes, because the cheapest processor nodes are not getting any smaller, so the silicon cost savings of 32 bit over 64 bit will continue to make sense forever. Linux will only lose 32 bit support if people decide to just stop using Linux for small systems.
If the cost savings are substantial enough then I’m sure someone will step up and pay to maintain OCaml 32-bit support. It shouldn’t be that difficult since the support already exists in the 4.14.x series, the last series before 5.x (multicore) 🤷♂️
“First successful” implies other attempts didn’t reach that goal & they have, but community uptake & such are a fickle bit that can get a “aren’t mature enough yet” aren’t despite having sound fundamentals, but even some are quite old/mature/stable, just not a lot of users even if they, say, have a more robust type system than Rust’s affine types which has limitations (such as linear types). One other difference is unless exposing externs for C binding, Rust’s ABI isn’t stable or particularly usable/portable outside of Rust which continues to fuel the rewrite it all in Rust with Rust libs situation as opposed to the C libs that back so many projects regardless of language. If Rust was as easy to use/link from every language as C, then I would be more enthusiastic about it as a step in the right direction even with type system limitations, but as the post above me mentioned, it is not the only language that could be a solution to this problem.
Which non-Rust language do you think should be used for writing memory-safe code in the Linux kernel?
I think you’re mixing up a couple issues.
The C ABI is widely used because any language with the concepts of function calls and memory access can use it. It’s common ground for any language that compiles to native code, but that also means it’s not idiomatic in any of the languages that are using it for FFI. Even in C++, which has the smoothest possible upgrade path from C, you’ll need an
extern "C"layer of plain functions wrapping your classes and templates.Whether or not Rust has a stable ABI for its own semantics doesn’t matter for cross-language use cases. The reason to want a stable ABI is better support for pre-compiled object code archives, which is pretty niche in the use cases that Rust is focused on.
The push to rewrite existing code in a memory-safe language is because people are tired of having their programs and computers crash, or get taken over by botnets, or get all their tax documents encrypted.
It’s not about Rust. Rust is probably the least-popular memory-safe language in common use today. All the Rust code in the world is a fraction of a percent of the C#, Swift, Java, and JavaScript code out there – and that code has almost entirely displaced C/C++ for the development of applications.
The reason people object to Rust isn’t because of anything about Rust, it’s because because they want to use C forever, and they hate the idea of seeing the last remnants of the PDP-11 era get scoured away down the drain.
Rust is as easy to use/link from every language as C – easier in some ways, because you don’t have to worry about dynamic symbol compatibility in libc. The
rustcoutput is a regular object file that can be passed into the regular build toolchain, and a shared library written in Rust can be a drop-in replacement for one in C.If it were gun to my head (meaning developer ecosystem/community isn’t there even if it is an old language), I would pick ATS as a ‘C generator’ for supporting linear types for tracking resources over Rust’s affine types–along with having refinement + dependent types & a proof system you could actually start asserting things in the type system beyond Rust’s type system & language features capabilities (including tail call optimization as jumps) while having all the low-level resource allocations + tracking (memory alloc, shared memory, locks, pointers, etc.). The type system asserts + zero-cost abstractions can eliminate most run time checking, and being from the ML family tree (which technically Rust came from OCaml explaining many of its features), you have a syntax, if unfamiliar to the C programmer, that is more ergonomic for doing ADTs/pattern matching & recursion. The compiler is built around abstracting over & even outputting C code to be linked via C code so it doesn’t disrupt those still wanting to use C or where C is easier.
But this would likely never happen & be even less popular of an option even if I think it is neat & crosses all the boxes.
You may be interested in the proposed crABI ABI, which has as a goal the ability to interop with other languages in a richer way than simply exposing C types.
There are languages in development that could do the job of Rust here, none of which I think have been mentioned in this thread, but they’re all way less mature than Rust. All languages in existence that may be mature enough are simply inadequate.
All popular languages with a young and enthusiastic user base ask for projects to be rewritten in their language of choice.
The C++ crowd famously nagged Linus to use C++ in the kernel till he told them very explicitly he does not want to. And evenntoday youbget people arguing for C++ in the kernel in addition to or instead of rust. The kernel got by pretty well as there are not too many languages that fit its niche, applications get this a lot more.
I was going to say that the user base was the only truly exceptional bit, but being non-technical & might be just zeitgeist (we will see) I left it out :)
I want a memory-safe kernel, which definitionally means a kernel written primarily in a memory-safe language.
There do exist kernels written in memory-unsafe languages that, when compiled to a binary artifact with a specific toolchain, can be proven to contain no memory safety errors. But those kernels have extremely high development overhead due to all the extra manual verification. Consequently they do not, and likely never will, have the breadth of hardware and software support needed to supplant Windows / macOS / Linux as the foundation layer of all general-purpose computing.
I think you’ve got this wrong – “unsafe Rust” has a single definition[0]. When discussing code that contains memory safety errors, Rust programmers use terms such as “unsound” (or “incorrect”, “buggy”, “fucking broken bullshit”, etc depending on mood) to describe code that contains memory safety errors.
Being unsafe doesn’t mean that the code contains memory safety errors, it means that the code can’t be proven memory-safe by the compiler.
[0] To the extent that any programming language name does. It’s true that programming language names are usually used for both the language itself and code written in that language (e.g. “a new version of Java was released” and “I don’t want to read ten thousand lines of Java”), but that’s not Rust-specific.
It doesn’t though, that was the whole point I was making.
It might have a single formal definition (where?), but it is “casually” used in all the ways I pointed out.
Yes, that’s the problem. They can’t call it “unsafe”, which is what would’ve been said prior to the existence of Rust, because it has become ambiguous.
I spoke of programs, not of smaller pieces of code, for which I don’t think there’s necessarily any prevalent definition of “unsafe”. But for programs, being unsafe definitely does or at least did mean that the program (code) contains a memory safety error. It’s only since the emergence of Rust (and its growing popularity) that this definition has become muddied.
You’re unintentionally reinforcing my point - that the use of “unsafe” as a keyword in Rust has led to confusion about what a “memory-unsafe program” actually is.
I disagree with both assertions. The term “unsafe” in programming has always described code that may contain errors, because if the code is known to contain an error then it’s simply incorrect.
I know from personal experience that the use of “unsafe” to describe programming languages without memory-safety guarantees dates to at least the mid ‘90s (when it featured prominently in arguments about Sun’s Java applets vs Microsoft’s ActiveX vs Macromedia’s Flash), and would not be surprised if more experienced devs could cite examples from the Usenet era.
Rust introduced the concept of memory safety to a generation of systems programmers who grew up after C had conclusively trounced all of its competitors, but that doesn’t mean Rust originated the idea.
Here’s a 2009 paper discussing memory safety as a property of a C program: safe if it contains no memory errors, unsafe otherwise:
https://link.springer.com/chapter/10.1007/978-3-642-04694-0_10
Here it’s talking about specific executions being safe or unsafe, and here:
It’s talking about proving the memory safety of a program (though it’s not written in a memory-safe language).
This spells it out very clearly:
So, it’s certainly not true that:
At least this one paper is an exception to that claim. I’m sure there are plenty of others, if you are willing to search.
Here’s a 2014 blog post by Michael Hicks, a professor of Computer Science at the University of Maryland:
http://www.pl-enthusiast.net/2014/07/21/memory-safety/
That’s a pretty clear definition, in line with what I’ve stated and not equivalent to your own definition. A memory-safe language can only be used to write memory-safe programs, but that doesn’t mean that all memory-safe programs are written in memory-safe languages.
The use of “safe” or “unsafe” to describe programming languages isn’t at question.
I agree with both davmac and jmillikin.
Everyone agrees that for languages, the natural definition of being “memory safe” is that no program has memory errors. (In practice we use a more complex, less natural definition, closer to “a language that pushes you towards writing programs mostly with this property and with clear social contracts about the exceptions”) Same with programs, a program is “memory safe” if no run of the program has a memory error. This is consistent with Mike Hicks’ terminology, which is fairly clear.
Obviously “not safe” is the negation of “safe”, so a language is “not memory-safe” if some of its programs have memory errors, and a program is “not memory-safe” if some of its runs/executions have memory errors.
We probably want “unsafe” to mean the same thing as “not safe” because doing something different would be confusing. (But not unheard of.) So we want to define an “unsafe” program as a program that has some runs that have memory errors, which is consistent with what davmac claims but appears contradictory to what jmillikin’s claim.
But note that jmillikin is talking about what “unsafe” means in Rust, and
unsafeis first a qualifier of program fragments, not whole programs. A natural definition of “memory safe” for a program fragment is something like: for any usage of this fragment in a program that “has no other source of unsafety”, the program is memory safe. (This is a bit tricky and not obvious to define formally, but programming language researchers are good at this.) Say a function, for example (but it also works for language constructs, etc.), is memory-safe in this sense if there isn’t a way to get a memory error by calling it.I believe that this notion of safety of a program fragment is consistent with the established use of “memory safe” in industry and academia. It is compatible with the claims of jmillikin, and also with the formal statements of Mike Hicks cited by davmac. In OCaml, we have a function
Array.unsafe_get : 'a array -> int -> 'a, which is not memory-safe as it does not perform bound-checking on the array access; this is “unsafe” precisely in this sense – and has been around well before Rust was introduced.Now one thing that is a bit confusing is that there are several reasonable but incompatible definitions of what it means for a program to be “unsafe”. The academic citations from davmac write that a program is unsafe if some of its executions contain memory errors. Another usage that exists in the wild (I believe well before Rust, but maybe Rust popularized it) is to say that a program is “unsafe” if it contains “unsafe” fragments. I believe that the first definition makes more sense if we think of the program extensionally, as an abstract object that runs, and that the second definition makes sense if we think of the program intentionally, mostly as source code (that can be executed).
I appreciate that you’re trying to engage in this discussion in good faith. I do need to point out though:
That is exactly the issue I was raising right off the bat - the terminology introduced by Rust has muddied the more general, previously-existing terminology about memory-safe programs. jmilkin rejected that assertion, though; so, if their ongoing argument was actually about a different “unsafe” that is specific to Rust, then that would accord with my point, that the terminology has become confused.
And also:
Indeed, but the only reason that I only cited academic sources because those were the ones that I could find that could easily be dated to a pre-Rust-prevalance period. There are plenty of non-academic uses of “memory safe” entailing the exact same definition. I won’t point them out because I’m not a personal assistant and people should be able to do their own Google searches. After pointing out the academic cases, jmilkin shifted the goalposts by dismissing them as being only relevant to an “academic bubble”. Their response was so arrogant and condescending that I posted a snarky reply (that I partially regret, but which frankly was deserved) designed to close off the conversation. The fact is that uses of those definitions can easily be found, today, outside of any “academic bubble”, but it’s not my job to provide counterexamples to every bad argument that is made against something I’ve said. People can believe what they want, even if it’s wrong, or do a tiny bit of groundwork and find out for themselves.
The way I understood it was clear enough, and the quotes I did provide illustrate some nice concise definitions which matched that understanding. While indeed these don’t prove that other definitions weren’t used, they do clearly disprove jmilkin’s sweeping statement:
I think, if there’s going to be any argument about what definitions were around and when, they need to be based on more than just bold assertions that are clearly contradicted by available evidence. Your observation about Array.unsafe_get is at least a starting point in that regard (although it doesn’t prove anything by itself, of course).
It’s possible that some areas of academia use non-standard terminology, in the same way that astrophysics describes all elements heavier than helium as “metallic”. I don’t think that matters to anyone outside that specific academic bubble.
It’s also possible that terminology originates in some area of academia, and is used somewhat consistently outside of that area until some popular phenomenon - say, the emergence of a new programming language - leads to it entering the lexicon of a broader population, and beginning to be misused by a segment of that population who don’t realise that they are overloading the term by using it a slightly different context, for example.
I don’t know if that’s how it actually happened, but it’s certainly possible, and since we’re just apparently throwing possibilities out there now, may as well throw that one out too right?
That you don’t think it matters to anyone isn’t of any concern to me or anyone else that it does matter to, sorry.
I feel like your definition of
unsafein Rust is a bit nebulous. I have a better one: Rust guarantees that it will have no undefined behavior (there’s one or two places it doesn’t, but those are known bugs.) Rust also has a few built-in APIs to perform actions which can lead to undefined behavior (operations outside of the purview of the compiler), these APIs are manually marked asunsafeso that they can only be used in otherunsafe(allows UB) scopes.This is what people mean when they say Rust is safer than C because C is basically Rust in an entire
unsafecontext, because C itself allows UB, whereas Rust doesn’t. It’s a matter of UB.The question being discussed in this thread isn’t the exact types of behavior that are forbidden outside of
unsafe { ... }blocks, it’s the definition of “unsafe” itself.davmac wants “unsafe” to refer to a property of the program as a whole. In this definition if a program can reach a state that permits it to execute instructions that violate the safety guarantees of the language, then the program is “unsafe”. In this model it doesn’t make sense to describe a function (or module, or library) as safe or unsafe – safety can only be verified given a full execution graph. And if someone says a program is unsafe, they’re not saying it might contain an error, they’re claiming that it does contain an error.
Furthermore, he wants to define “memory-safe language” to mean a language that can only express memory-safe programs. In other words, if it’s possible to write a program that can violate memory-safety guarantees, then he would say that the language that program is written in is not memory-safe.
Thus he claims that Rust is not a memory-safe language – and presumably none of Java, C#, Haskell, Python, Ada, or JavaScript are either. I’m honestly not sure whether there are any languages he would consider memory-safe. It strikes me as the conversational equivalent of setting off a fart bomb in a theater.
I’m sorry, but you’re confused. It’s not that I want “unsafe” to mean anything in particular, it’s that I believe it does mean something in particular. But not what you are claiming here; in the previously established meaning, “unsafe” has meaning outside of languages that don’t provide any safety guarantees.
What? I didn’t claim that. (Unless perhaps… if you mean “Rust including unsafe Rust” then … well, if you want to argue that “Rust including unsafe Rust is a memory safe language”, go at it, I won’t try to stop you).
I don’t see how, though that seems like almost an appropriate response to the ridiculous claims you’re making here now.
Using the definition “memory-safe language” as a language for which all valid programs obey the language’s memory safety guarantees, then a language cannot be memory safe if it (1) has some concept of memory mutability or visibility, (2) supports Linux as an execution platform, and (3) is able to perform file I/O on arbitrary paths.
Rust distinguishes mutable and immutable memory regions, supports Linux as a target platform, and is able to perform file I/O. Therefore, it’s possible to define a program entirely in safe Rust that modifies its own memory via
/proc/self/mem, and therefore the program is unsafe, and (per the claimed definition) safe Rust is unsafe.I don’t see the value in such a definition, since all of the languages of interest to industry would be excluded from the “safe” category, so I follow the standard definition of memory-safety as applied to both source code (not programs) and programming languages.
That wasn’t the definition, read it again. It’s not about violating or not violating the “language’s memory safety guarantees” (if it was, it would be meaningless for languages which don’t provide such guarantees).
And for that matter, I wish that people would stop calling any old language which bolts memory-safe constructs onto conventional pointer arithmetic but leaves the latter exposed to unskilled programmers “memory safe”.
There’s no reason in principle why those should be mutually-exclusive.
Interestingly, to me it sounded like a disagreement between experience and inexperience. I have conflated experience with hostility and/or authority many times in the past.
EDIT: @andyc said it way better than I could!
The “you’re pushing a religion” part invalidates that interpretation in my opinion.
I am inclined to agree on this point, though I lack full context and cannot be 100% sure.
?? The Rust guy kept saying over and over that no one is going to force any C dev to fix Rust interfaces. They already offered that path forward! The audience member was strawmanning hard.
What you’re saying here is equivalent to saying that it’s impossible for new C code to use the interface correctly because no one actually knows how it’s supposed to work. Asahi Lina actually pointed out something similar about the DRM subsystem here:
Fediverse version of that link which (unlike xitter) can be viewed in full without logging in: https://vt.social/@lina/113045455229442533
Thank you!
But that lays bare a horrible implication: no-one knows how to safely write file-systems against this API then. Regardless of whether it is when writing a Rust wrapper for the API or someone writing a new or maintaining an existing file-system in C.
Yeah, I was somewhat surprised to find that no one even knows how the ext4 filesystem works. The most authoritative document was basically some guy reverse engineering it with lots of “from what I can tell…” and “I think it does this…”, and after digging through the code I have to say he did a much better job understanding it than I’m capable of doing. It’s still wild to me that something as foundational as a filesystem isn’t specified such that people can write tools to operate on them without having to FFI to the Linux source code.
Yes, this is how most C and C++ APIs work. People who are horrified, I envy you because it seems like this isn’t something you have to deal with on a daily basis.
It’s also why Rust (and, to a lesser degree, modern C++) is such a breath of fresh air to so many of us who are used to dealing with giant old C and C++ code bases. Just the fact that Rust encodes lifetime information in the type system eliminates so many questions. When I write against someone else’s C APIs, my biggest question is usually “what are the lifetime requirements of this object? Should I free it? If so, when?”. That question is very rarely answered by documentation, so it’s left up to intuition, reading the implementation, and address sanitizer telling me when I’m leaning something or double-freeing something or use-after-freeing something.
There are many things about the Rust language that I’m not a huge fan of, and I personally prefer writing C++, but I don’t feel like I can ignore it.
Worse: many codebases don’t have a rule for that, either. I’m guilty of that, too, I think I’ve written at least one long piece of spaghetti code where, halfway through the implementation, I realised that accommodating a particular quirk of some underlying protocol or filesystem required something to be freed based on slightly different conventions than the rest of the code followed.
Sure, you document that visibly, comment your code, whatever, but wetware sidechannels just aren’t very good for that.
If you get a pointer from a function call, then you should free it, no?
Wouldn’t that be after you’re done using it?
No, and there are even examples in the standard library. For example, you are not supposed to free the
char *returned bygetenv.I wish those rules were universal, but they’re not.
Is that surprising?
I wonder in how many C projects the size and age of Linux people really know how the APIs work.
you have a dangling reference here
Good job checking that for them
[1] Regarding “whether encoding file system semantics statically in the Rust type system is a good idea”
Take this with a grain of salt, since I haven’t looked at the specific problem, nor do I have any real expertise in it
But I think there is the general problem where some people think “Of course that’s a good idea, why wouldn’t you do that?”
And then there is the reality that there are inherently dynamic aspects to software interfaces.
I ran into this difference in thinking while working on a garbage collector. Some people want there to always be a static way of doing things, but in this case it’s mathematically impossible (due to Rice’s theorem, etc.).
https://lobste.rs/s/8dqbty/my_experience_crafting_interpreter_with#c_a6kmdz
GC and rooting are inherently dynamic.
I suspect there is a big bridge to gap between Linux kernel dev and Rust for a similar reason
It’s a dynamic vs. static way of thinking, and again the answer is going to be somewhere in between.
The fallacy of the dynamic side is perhaps a status quo fallacy.
The fallacy of the static side is that everything important can be encoded statically. The failure mode is when you only encode the trivial properties, and the cost isn’t worth the benefit. The dynamic techniques for correctness still end up bearing most of the weight, and then you have a static “bureaucracy” off to the side.
I suspect @matklad might have some thoughts/opinions on this, e.g. since after using Rust, he’s using Zig and writing more about dynamic properties of software:
https://tigerbeetle.com/blog/2023-12-27-it-takes-two-to-contract
https://lobste.rs/s/blszfs/it_takes_two_contract
https://matklad.github.io/2024/07/05/properly-testing-concurrent-data-structures.html
My guess is that the Linux kernel is more like Tiger Beetle … are you going to try to encode the invariants of a transactional database in a type system?
Or are you doing to do it with dynamic assertions and the like? (Of course it’s not either-or, but I think there is a contrast philosophically, which is similar to the one between Rust and Zig)
I also noticed from the recent thread that the prototype of Tiger Beetle was done in node.js (https://lobste.rs/s/tr8ozm/why_is_spawning_new_process_node_so_slow)
To me that suggests that one of the most important properties of the system – performance, and the algorithms you use to get there – don’t benefit that much from static encodings
Of course the answer is different for each system, and that’s what makes it hard.
(“advice = limited life experience + generalization”)
This is somewhat of a non sequitur. Type systems encode dynamic aspects of programs all the time, especially so in Rust which has sum types. The example API in the talk was doing exactly this.
The simplest example is, I feel,
Arc, which statically describes a set of rules for entirely dynamically managing the life cycle of an object. You don’t know which thread is going to end up freeing it, but it’s still safe because the rules lay out why that doesn’t matter.By “inherently dynamic” I mean “expressing it statically is like solving the halting problem” – i.e. mathematically impossible
I didn’t say dynamic – I said inherently dynamic, and gave an example of what I mean
For people who don’t understand what I mean, I suggest writing a garbage collector in Rust. It will give you a good perspective on the nature of – and the limitations of – the abstraction you’re using.
I also believe there is a pretty strong analogy with the conventions used in say kernels or transactional databases
I also recommend reading this article
https://kevinlynagh.com/rust-zig/
https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_firmware
for an example of why hardware may not match what your type system can express, which is very relevant to kernel development.
Basically, you can be spending a lot of effort solving the wrong problems.
The Linux kernel has tons of problems I’m sure, so I’m glad this experiment is being done – but it does still appear to be an experiment.
Your example doesn’t demonstrate what you claim it does. Every property captured by a static type system is already dancing with the halting problem. There is no “inherently dynamic” boundary to cross here.
The business of a (sound) type system is to find an approximation of the dynamic property we are interested in, such that it can rule out all the violations without ruling out too many interesting dynamically-valid programs. All Rice’s theorem means is that this will always strictly be an approximation, not that it can’t be good enough for general purpose use.
GC rooting is absolutely no exception to this, and the borrow checker is actually uniquely suited to capture this kind of thing- an un-rooted reference is very much like a borrow, during which the collector must wait for a safepoint when the reference is again rooted or discarded. There are several designs for encoding this property in the Rust type system: https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/
Again, while these encodings are approximations, all this really means is that you can’t go crazy passing around un-rooted references in ways that are too complicated for the type system to understand. But this is essentially never something you want to do anyway! These encodings are plenty flexible enough to capture all the typical ways that the mutator holds onto un-rooted references, which are very localized.
You can encode SOME rooting policy, but what about the most efficient (minimal) rooting policy?
Do you agree that this is a possible failure mode?
Or is it inconceivable? Is it always better to use the static approach, and there is no tradeoff to make?
I haven’t said anything about which side of the tradeoff is better. I only specifically disagreed with your claim about the “reality” that some things were “inherently” dynamic.
But with that out of the way, I think it should also be obvious that nobody is claiming that the static approach is always better. Rust itself uses the dynamic approach for things like bounds checks and integer overflow checks!
But even then, your argument is somewhat of a non sequitur: the thing Linux is doing is neither dynamic nor static. It is just an un-checked free-for-all where the human programmer has to manually learn and follow the rules of the API, and when they fail it just corrupts the abstraction.
Right, so if I have a Rust program with an integer
i, then it is an inherently dynamic property of that program whether the integer overflows.It’s not a property you can statically encode in the type system. It’s mathematically impossible to do so (in general)
Do you agree?
Likewise, I claim that software interfaces and especially hardware interfaces have inherently dynamic properties. (I’m not sure if the keyboard firmware example is one, but it appears to be a case where the type system is creating bureaucracy that doesn’t help correctness. It is sort of beating around the bush, and not really helping with the core problem.)
You can approximate them with a static property, but it may not be the algorithm or policy you actually want.
For example, it might run too slowly, which is why I brought up the GC rooting example.
Just because there is no encoding of the file system API in a static type system doesn’t mean that not well-specified, prima facie
It could be well specified, but impossible to express in Rust’s type system. Or you can express some part of it in Rust type’s system, but not in a way that actually helps you ship 50 working file systems.
It can certainly be be a big mess too – Linux code is messy with many hands in it.
Let me additionally quote Tso
Do you believe that this question makes any sense?
Is the idea of encoding semantics in the static type system prima facie a good idea?
My feeling from this thread is that many Rust users believe that what he’s saying can’t possibly be an argument, which is what I alluded to in the comment that you replied to.
I believe there is a fundamental difference in thinking – and it is more or less accurate to call it dynamic vs. static.
On the one side, you have the dynamic “reality”, backed by shipping 50 file systems over a few decades (which implies debugging them), and on the other side you have “we think in static type signatures; the program can’t be correct and can’t be reasoned about unless it passes the type checker”.
Tso is not saying it won’t work – he is treating it as an empirical question. But I believe many Rust users do not believe it’s an empirical question.
Is it an empirical question?
Is it possible for a static type system to model a problem poorly, and get in the way of a correct program? Or are the static types reality itself?
Absolutely not, for the reasons I already gave. You can use ranged integer types, and reject operations where the ranges of the inputs mean there may be overflow. This is a classic example of encoding a property in the type system.
The GC rooting example does not suggest anything like this. As I already said, the rooting behavior of existing GC languages is already easily local enough that it would not have to change at all to be encoded in a type system.
I repeat: nobody is claiming that the static approach is always better. The reason Rust uses dynamic checking for overflow is not that it would be impossible to encode in the type system, but that they judged it to be more practical to check that particular property at runtime.
You are trying to counter an argument that you completely made up, not anything the Rust language or the Rust-for-Linux project is actually saying. And worse, you are trying to pull me into that argument, which I am entirely uninterested in.
This issue came up again and I responded here - https://lobste.rs/s/yx57uf/is_linux_collapsing_under_its_own_weight#c_gvj8fk
(won’t reply again on this thread due to length)
(For context: I use and like Rust, but I have ~no opinion on whether it’s a good fit for Linux.)
This feels to me like a false dilemma posed in such as way as to make people either agree with you or appear to agree with an absurd proposition (that static types are “reality itself” and no use of them ever models a problem poorly). Maybe something more concrete can be more constructive….
I get an impression that you use (or previously used) that keyboard firmware post to suggest that Rust is bad for interfacing with hardware, but I still don’t think that keyboard firmware post is relevant.
I think a better example of some Rust code being bad at interfacing with hardware is David Chisnall’s MMIO anecdote (see, e.g., here or here). The details weren’t clearly stated, but it sounded like what was happening in that case was that some Rust code was reading the value of a “device register” as a richly typed value, which is not okay. The solution would be to read the register value as just an integer and then map that to a more richly typed value with plain, safe Rust code like
Rust code can use structs and enums and lifetime-equipped references within itself, but, at an interface with hardware like that, Rust code must treat values it gets from the hardware as just bytes, or just integers, not structs or enums or lifetime-equipped references. The device registers’ world is a wild, untyped one whose values mustn’t be eaten raw in Rust’s typed world.
I think the many remarks you’ve made here about “dynamic vs. static” could be more understandable if more concrete examples were given. Does this MMIO example sound relevant to what you’re trying to say about “inherently dynamic properties”?
Yeah I could have omitted the last line, but it made me chuckle … I don’t believe the general point is a strawman, because I see a very strong consensus in this thread and elsewhere that if an interface is not expressible in Rust’s static type system, it can’t be a good interface, and should be changed so that it is.
I disagree with that.
Also, I ended up skimming a mailing list thread, and it is very clear to me that it is a clash between the dynamic mindset of kernel devs and static mindset of Rust devs:
https://lwn.net/ml/linux-fsdevel/ZZWhQGkl0xPiBD5%[email protected]/
For the record, I would like the future of kernels to use more static analysis, and static types. I think it would make kernel programming a lot more accessible to me personally, and to everyone, and thus widen the pool of contributors, and make kernels better.
I just think the types need to be appropriate to the problem. And what I am hearing from Tso is that this might be possible, but it’s a question that should be answered empirically.
My suspicion is basically the same as what chisnall and matklad said elsewhere in the thread:
https://lobste.rs/s/46pt2l/retiring_from_rust_for_linux_project#c_eqlhxb
There is a “Rust view of the world”, and Rust has a very specific aliasing model. I would even say that Rust is domain-specific language – because all languages are.
And type safety is a global property of a program.
This makes it harder to migrate an existing codebase like Linux, with its own specific model. The models clash.
I believe what they are saying is not substantially different from Tso’s suspicion – it’s just expressed with less shouting
But like I said, it’s an empirical question that will (eventually) be answered …
The MMIO issue with unsafe does seem relevant and important, though not exactly what I was thinking of
There were 2 related claims
As for examples:
It “feels” like RCU is “inherently dynamic”, with respect to the Rust type system, though I have no expertise in this area:
https://en.wikipedia.org/wiki/Read-copy-update#Sample_RCU_interface
https://lwn.net/Articles/653326/#Other%20RCU%20Flavors
Can the Rust type system say anything about this? Can it statically eliminate errors in obeying these protocols?
I could certainly be underestimating what it can express
My suspicion is if that it were shown that Rust could statically check all usages of RCU protocols, kernels developers would be JUMPING to learn and use Rust
But I think Rust doesn’t help there. The Rust way would be to introduce some other mechanism that’s probably not as finely tuned.
I read over this story and thread again - https://lobste.rs/s/eppfav/why_i_rewrote_my_rust_keyboard_firmware
As an aside, the top comment seems to be from a pretty experienced Rust programmer, who expresses an opinion that Rust penalizes RUNTIME behavior in favor of its “model” (async/await in this case):
That is basically what I mean by models vs dynamic reality.
The keyboard post also expresses something like this:
That is what has to happen in reality. And the author is very neutral and agnostic about which tool will be used to get there – it is very problem-focused rather than tool-focused.
Does it have some examples of where Rust’s type systems misrepresents reality?
Reading over it, I think it’s closer to “the type system made my life hard”, and when I used Zig, with a weaker type system, was a breath of fresh air.
Though there is some good humility at the end – it is possible that tradeoff can change over time, as the program evolves and is maintained by more people
Nonetheless I think this is similar to the issues that I suspect will result in continued clashes on the Rust for Linux project.
I haven’t seen that at all here, actually.
Hm I just noticed this sentence in the Wikipedia page:
“Observing the time sequence” certainly sounds “inherently dynamic” to me!
You are describing an implicit state machine, and the question is whether you can encode the valid state transitions in the type a way that is useful in Rust’s type system. In many cases like this you can.
This may still result in dynamic checks - but in those cases, the type will guide you to insert those checks, and the code will not compile without them.
There is a field called choreographic programming which goes much deeper into encoding this kind of stuff in types than what you can do in Rust, too, if you are interested in that kind of thing.
This issue came up again and I responded here - https://lobste.rs/s/yx57uf/is_linux_collapsing_under_its_own_weight#c_gvj8fk
(won’t reply again on this thread due to length)
You’re not alone as I understood it the same way as you. It almost felt to as the kind of discussion I’d hear in the corporate world.
New member of the dev team: “We could rewrite this like that and it would be so much better!”
Veteran of the dev team: “Yeah it could be better long term but you do understand that we have to keep releasing the product at a steady rate and while the old stuff is not perfect, it does work and it is what everyone here knows.”
You may not know this, but Rust for Linux is an experiment to see whether Rust would be a good fit for the kernel, and Linus Torvalds is quite supportive of it. Some senior maintainers who dislike Rust are not content to let the experiment simply run its course, they are obstructing it.
But the actual situation is that Rust is proposed to be used in new drivers, not rewriting tons of stuff. And the veterans are not being respectful and thoughtful about how they respond, they are being caustic shitheads.
Wouldn’t that be part of the experiment though? In grade school we might say: “my hypothesis is that not everyone will love rust and welcome it with open arms”.
How are they supposed to test if it will work well if some maintainers simply block all work? Linus said that writing an fs module in Rust would be a great test for Rust in Linux. When Rust people ask for stuff from the fs people, stuff that they’d need even if they were writing C, like “what is the correct way to use this interface?”, the maintainers get caustic and go on rants about how the Rust people are pushing a religion.
It’s completely fucking unhinged.
It’s the same rhetoric, the same vibe. Instead of screaming ‘they are shoving GENDER IDEOLOGY down our throat’ they are screaming ‘they are shoving the religion of SUBSTRUCTURAL TYPE SYSTEMS down our throat’.
I watched video attached in the email and even for me it was really painful to watch. It seems that part of the audience judged the presented solutions before they even had a chance to hear what the presenter had to say and wanted to undermine the presenter’s competence.
Rust is great but promoting it in such way to this crowd is not a smart strategy. Rust is not really new anymore, it’s almost 10 years old (since 1.0). Linux maintainers have been aware of it for a while and have their own opinions and concerns. I think the engineer’s reaction is a buildup from past interactions.
Regardless what the discussion is about, it’s very natural to oppose change. If you beat the drum too hard, people will refuse whatever you’re offering. A better approach to make them adopt your ideas would be to manifest them in an independent project and show them how nice it’s.
The presenter is asking of the existing maintainers “I want to know what the semantics of this API are, so that we can properly model them, we will maintain the bindings” and the response is “you can’t make me care about Rust, if I break the API semantics, you need to adapt”, which was a side-comment that was already preempted in the question itself.
I wonder whether a root problem here is that the exact semantics of the decades-old mass of C are not known to the C maintainers either, so they can’t tell the Rust people what the semantics are nor know whether a change in the C code will change them. I wonder whether the C maintainers understand this tacitly and only tacitly, such that what seems to the Rust proponents like a reasonable request (tell us the semantics) seems to the C maintainers like an absurd imposition but neither side quite realizes why the request so agitates the C side.
Crass thought, but maybe the C maintainers know that they have no idea how the code actually works, but don’t want to admit it? They’d rather just continue to play whack-a-mole when bugs crop up.
That’s needlessly inflamatory. We who use and advocate for Rust need to do all we can to de-escalate, including assuming the best in others.
I am physically incapable of assuming the best in someone who behaves like in that video. Though I should say that I am not assuming the thing I posted above, it’s just a terrible possibility that popped into my head. I can think of other explanations for their behavior, though none of them are good. For example, maybe Ted Ts’o really really really hates Rust, and is being obstructionist and caustic to intentionally stall the Rust for Linux effort enough to kill it.
How do you assume the best in people who are demonstrating their worst? That’s going to get you nowhere but burning everyone out who tries to improve things somewhat (insert “improve society somewhat” comic meme here for a moment of levity)
I do think that (or rather a less hyperbolic version of it¹) also plausible, though I chose not to say it in my previous comment.
¹ the maintainers literally having no idea how the code works seems unlikely
While the guy in the video definitely needs to work on his communication skills, I think he’s raising an important issue. The Linux kernel is known for internal API churn and churn to the C code will require churn to the Rust code that wraps it. What will the policy be going forward?
I think the only sane policy is the first policy and I think most would agree. The only “problem” is that it contradicts what is being said, I.e. you won’t be forced to write Rust.
While I love the idea of a Rust based kernel, I think slowly transitioning the Linux project to Rust is not really a workable idea. There’s just so much momentum in the project and doing the transition in the right way requires direct focus on the transition from all areas of the kernel, which is a significant commitment of effort. Doing it as this side thing without team-wide buy in doesn’t seem like it’s going to work long term.
IMO it would be better to fork Linux and start aggressively rewriting internals with a community and project charter that embraces knowing both C and Rust. Or start a new Rust kernel project.
IMHO that’s kind of a non-issue in the context of the Linux kernel. There are several abstraction layers in the kernel, Rust’s is only one of them. Churn on one API leads to churn on another, or in any case, to churn in code that uses it. Hell I think I paid off half my mortgage off of the device tree API alone. For the last 30 years or so, the rule has been pretty much that you can break C code and it’s not considered critical, and parts that bitrot get removed.
The problem with Rust abstractions over Linux FS code IIRC revolved around some lifetime management problems, where different filesystems manage the lifetime of different objects slightly differently, so things that in Rust you would (ideally) statically encode at the type level are deferred to local conventions and enforced at runtime. There was a LWN article about it a while back, I think. It’s a legit technical issue, but not one that looks intractable, as long as Rust adoption is a goal both in the FS subsystem and in the Rust for Linux project.
The logical conclusion of what you’re saying is either:
The RFL team is saying #2 will never happen, therefore Rust code will likely bitrot. This is not an ideal situation.
Be aware that Rust code bitrotting will on average happen faster than C code bitrotting because most kernel developers arent familiar with rust.
Sorry, but I don’t understand what the problem is here. It goes without saying that critical code should not be written in a language that only a handful of people in the community know, that’s software engineering 101. Critical modules that most people working on a codebase can’t even read are a recipe for disaster.
Yes, that would mean it’s going to bitrot faster and, obviously, that compatibility with that language is going to be a secondary consideration, at least until enough people know it that critical code does start getting written in it. That issue is compounded by the fact that Rust code can enforce a lot of things at the type level which C code can’t, so breaking compatibility is going to be particularly easy. Is it even feasible to even keep up with that level of API churn? Heaven knows, hopefully the folks trying to get Rust into the kernel have thought of that beforehand.
If they haven’t and it turns out it’s not, that sucks, but at the risk of being that guy with the unproductive I told you so, this sort of project would have been extremely difficult even in a homogenous team of kind people who aren’t prone to tech flamewars and are used to constructive engineering criticism. The Linux community is not that kind of community. As with everything other engineering project, there are both technical and social limits to what a team can achieve.
Would it be better for this particular project if everyone in the Linux community learned Rust? Sure, but might I point out the project is called Rust for Linux, not Linux for Rust :-). Would it be better for the Linux kernel if everyone did that? Possibly, I mean I think so but I come from an embedded background so I’m easily convinced, I would’ve also said “yes” to Ada, but not everyone’s concerned about the same things as me. Would that ever even work if it happened by decree? Maybe in a commercial setting, but in the FOSS community, haha, no.
I think the issue is with the claim that kernel devs won’t need to know Rust. It seems clear enough that the eventual plan is for critical code to be written in Rust and this means eventually the core language will switch from Rust to C. So there is a contradiction between what is publicly being stated and implicit plans. I think most devs were okay enough to allow non-critical Rust modules into the kernel but not necessarily with the implicit understanding that this will lead to the entire kernel eventually shifting to Rust.
I see this implicit understanding as the major point of conflict. An affirmative explicit statement here by someone authoritative on kernel direction (either Linus or someone else if Linus is checking out) could really help out.
What implicit plan, and who’s making them, exactly? When I say “at least until enough people know it”, I don’t mean that to be some inevitable outcome. It’s entirely up to the Linux community if that’s some specific moment in time or on the same timeframe as “at least until pigs achieve aerial locomotion capabilities”. If people in the Linux community don’t want critical code to be written in Rust, it simply won’t get written in Rust, no matter what “implicit plans” someone might have.
Fair enough but I don’t think that’s clear to a lot of people. I don’t think people really understand how decisions are being made.
Calling someone a religious cultist over programming language preference automatically makes anything he says invalid garbage that should be ignored.
Sometimes you have the luxury of ignoring the signal coming from those who you personally dislike, sometimes you don’t!
Could you link me to the timestamp where he says that? I don’t doubt he did, I’m just curious.
26:10 for the actual words, but the link in the mailing list post links to the context immediately before it which should probably be watched for completeness.
Are you sure that’s the timestamp? He doesn’t call him a cultist in that particular clip, is it another video? I’m using https://www.youtube.com/watch?v=WiPp9YEBV0Q
The exact quote is “I suspect part of the problem here is you’re trying to convince everyone to switch over to the religion as promulgated by Rust.”
If “religious cultist” doesn’t sit right, then maybe “religious fanatic” or “religious zealot” would work better?
The meaning of the heckler’s statement is clearly that they believe the documentation of expected function semantics in the filesystem layer is being advocated for out of a sense of pro-Rust radicalism, which is a difficult claim to defend.
Yeah I heard that. That’s a bit of a stretch from directly calling someone a religious cultist. I somewhat doubt that that is the quote to which OP is referring because their reaction seemed to be very strong. There is the tiniest of semblance of restraint and diplomacy in what you quoted but name calling someone directly: that’s crossing a line and definitively ends all remnants of civility in the conversation.
No, no it really doesn’t. While I’m not convinced either way on the specific issue of Rust vs. C in question, in general, it’s totally possible for someone to simultaneously be an asshole and be right.
That doesn’t make it good, mind you. It’s actually to this guy’s detriment that he’s communicating this way, because it causes people like you to knee-jerk away from his opinions regardless of their potential merits.
I’m strongly in favor of using Rust in the Linux kernel. That being said, I don’t actually believe:
and I think the C partisans in the Linux kernel team don’t really believe it either and this explains their hostility to the project. Getting Rust in the door in the Linux kernel is in fact the first step down a path that leads to huge amounts of kernel code being in Rust, and everyone who works on the Linux kernel needing to know Rust in order to be effective.
I personally think this is a good thing, and it is a good thing precisely because C is a bad and outdated programming language that Rust improves upon in meaningful ways. Everyone contributing to the Linux kernel should in fact learn Rust, and should be excited about the improved tools Rust gives you for avoiding bugs.
And as a meta-point, Linux kernel contributors should avoid hanging their identity upon being skilled C developers, precisely because clinging to C makes it more psychologically difficult for a developer to give it up in favor of a better programming tool (and Rust developers should also take this same advice - Rust is not the perfect apex of programming languages, and in particular we should expect that in the future programming languages will be developed that can do better static analysis than Rust can, and that people will want to replace substantial portions of large Rust projects with code in some new language in order to reduce correctness bugs, and it’s better if people using Rust envision this possible future now so this eventual transition is as smooth as possible).
I think it’s better to argue this honestly and straightforwardly in the face of C developers who are reluctant to switch to Rust, than to pretend that it isn’t the future Rust partisans want (again, I say this as a Rust partisan).
Rust in the Linux Kernel is still very much in the exploratory phase so I do think that statement is probably true. Just because Rust is a good language and has many nice properties does not automatically mean it will take over a large multi-decade old codebase overnight. Nor does it mean that it should.
There are a lot of both cultural and technical reasons why Rust in the kernel might take decades to get fully adopted. I don’t have a problem with the project being honest about that. What I heard in the snippet of the talk was a team trying to communicate what value they see so far and very vocal members of the audience refusing to even engage with that topic and instead rejecting the entire premise of the effort very loudly because they don’t want to see the exploration at all regardless of where it might lead.
I think it’s still an open question whether a mixture of C and Rust is going to be more secure and maintainable than C. At this point, I’m more interested in what Redox OS does.
Redox is much, much more mature, but, given your other interests, you might like to be aware also of Robigalia, which is much more capability-oriented (object-capability, particularly).
Redox is an interesting project, and it’s possible that it would be better if Redox simply replaced the Linux kernel in all the places the Linux kernel is currently used. There is a lot of embodied knowledge contained in the Linux kernel that would be a shame to throw away in the process of switching to a new project, and the fact that Redox is MIT licensed as opposed to the Linux kernel’s GPL 2.0 might lead to worse incentives from a promotion-of-free-software perspective (this is a complex topic that I don’t have a well-defined opinion about). On the other hand, Redox has other innovations in addition to being written in Rust (e.g. it’s a microkernel), and it might also be easier to bring those to mainstream adaptation by swapping out the commonly-used free software kernel rather than trying to retrofit them into the Linux kernel.
The fact it’s a microkernel rather than another ‘80s design clone is one of the things I like. A bunch if microkernels have followed the Xen model of using Linux to fill in gaps in driver support. The LKL project makes it easy to port Linux to run in a foreign userspace and then pick up drivers, which is a nice migration path.
That’s fine, provided that the driver API is properly documented and reasonably stable.
Reading the comments on Phoronix, it’s painfully obvious that the decision taken by Wedson is the only sensible one. It’s sad to see so much hate towards everything Rust
It reads like sportsball fans arguing over rule changes.
I made myself a promise to never read Phoronix comments again but my drama-seeking brain clicked by itself and… it’s pretty much what I expected to see.
The point of “we will find out whether or not [Rust] is a good thing or a bad thing” was almost 10 years ago.
It seems to me like the Linux kernel is run by a bunch of old people not wanting to change and not wanting to accept that times have changed. IMO not seeing the value in a strong type system and being able to model your invariants is just plain ignorance at this point.
Strong type systems ** are highly desirable, and that’s particularly the case with systems/embedded programming.
But at the same time Rust can be deeply scary for those experienced in that area, since it moves away from the ALGOL model where visibility is determined entirely by scope.
There’s too much entrenched on both sides of the argument. On the one side we’ve got “we need C’s transparency and flexibility”, on the other we’ve got “we can benefit enormously from having a strong type system designed into the fundamental language”. What we really don’t need is a third front: “let’s rewrite everything in Python because of its expressivity, and because we trust its implementers to do their job properly”.
** Bottom line: strong type systems come from Pascal.
This bit resonated:
This is not unique to the driver layers. This was my experience with every bit of the Linux kernel I touched. Functions take and return pointers all over the place and do not document who is responsible for cleaning things up or how. You just have to grep the kernel for the function you’re using and figure out what other callers do. It amazed me that it worked at all.
This is not really to do with Rust, it’s to do with anyone being able to work on Linux if they’re not actively mentored by an expert in the subsystem that they’re working on. The Rust people are not really different from people wanting to improve documentation.
This is a pretty big advert for Rust: you can’t commit code like this in Rust because it simply won’t compile (well, unless you make every function
unsafeand use bare pointers, but no one would ever merge code that did that).Yup, I am also thinking about DDeVault comment here:
It seems spot-on: Rust is exceptional for structuring large tightly-coupled things where A calls directly into B. Lifetimes+traits+crates lend themselves really well to describing rich and complicated interfaces.
That is to say, while a micro kernel is probably the right way to go about building a kernel, it’s the monoliths where Rust benefits are outsized.
Unfortunately, I suspect that it’s less good for incrementally adopting in an existing monolithic kernel. Protection aside, the big difference between monolithic kernels and microkernels is the degree of tight coupling that’s possible between subsystems. In a monolithic kernel, any subsystem can directly manipulate the data structures of any other subsystem. If you design a monolithic kernel in Rust, the type system will enforce an ownership model that works with Rust and make you think about the kinds of sharing that you may have. If you design a kernel in another language and then try to adapt it to Rust, you’ll find a lot of things that just don’t line up with the Rust view of the world.
C++ may be somewhat better here. Once you can figure out what the current model is, you can wrap it in some types that enforce that model and incrementally move the code from using bare pointers in C to using C++ types that eliminate categories of bugs. The end point probably won’t be as good as for Rust, but the intermediate improvements are easier.
Improving things like FUSE and CUSE and moving things out of the kernel is probably a better long-term path.
Precisely! This is the main hurdle towards adopting Rust-style memory safety for existing C/C++ codebases (via Rust or via a safe C++ successor language with Rust lifetimes).
Rust has a very specific aliasing model, rules for who can point at what. This model is global property, but it is enforced by inter-locking local checks between each function call and the corresponding signature.
But if your existing app’s aliasing model doesn’t conform to Rust rules, you can’t fix it “locally”, you’d have to fix everything everywhere at once. Which means that, practically, you are mostly restricted to chipping away at subsystems which are already quasi-independent.
That’s why I am exited about the recent buzz about safer C++: you can’t roll out a safe “C++, but Rust” onto existing code bases. But saf_er_ “C++, but Zig -OReleaseSafe” seems achievable.
I actually think that the Rust for Linux effort has proven quite well that you can in fact add Rust. The kernel has tons of reference counting (works well with Rust) and most of the more convoluted lifetimes involve so many bugs that you’d want to simplify them anyway even if you aren’t adding Rust.
The problem is that Linux doesn’t have any kind of aliasing or lifetime model. The Rust folks want to know what the rules are, to figure out how the solution should look, but no one actually knows what the rules are. You can’t fix that with “safer C++” either.
@matklad said:
Most of the places it’s been used in Linux are device drivers that are at the edge of the kernel, with little coupling to the rest. Most Linux GPU drivers, for example, run in the FreeBSD kernel with a small(ish) shim layer (‘LinuxKPI’). The efforts to implement filesystems, for example, which need to interact with the VFS, buffer cache, and a bunch of other subsystems, have had problems.
Agreed. Step one would be to add consistent memory management and document lifetimes. The question is whether the archeology to figure out what Linux is doing and then to fix all of the places where it’s doing it wrong is more or less work than writing a modern kernel in Rust. My strong suspicion is that ReduxOS will get decent Linux-equivalent (or better) performance long before Linux gets a coherent ownership and aliasing model.
There’s a difference: Safer C++ is designed for building wrappers around existing (not necessarily well-designed) ownership models and allows these to be different for different data structures. Rust is opinionated about what well-designed lifetime models look like.
I think it’s hard to untangle (without reading literally all the relevant LKML history) how many of the issues are unavoidable and how many have been caused by the FS maintainers refusing to help.
In any case, I think drivers for hardware is exactly where Rust offers the most value to Linux, so even if Rust can only be adopted for relatively self-contained stuff, it still seems very worthwhile to me. Something like 90% of crashes I’ve experienced on Linux were due to bugs in the amdgpu driver.
This is entirely true, but even with more flexibility around what kind of ownership model you can have, you still need to do that archeology to figure out what Linux is doing, even if there’s less fixing needed. Some Linux maintainers seem quite resistant to the “figuring out” stage.
That seems plausible. And with their plans to run Linux VMs to use Linux drivers, there’s a migration path that doesn’t involve suddenly not being able to use all that hardware that Linux has drivers for.
This is just incredible, isn’t it?
Some people around social media have speculated that maybe her fix was rejected due to it breaking drivers or something, but she explained what her fix did in a reddit comment, it sounds quite reasonable:
I always thought it was bonkers that only one person was porting Linux to M1 despite the popularity behind it. Now I’m starting to realize potentially why that is. I wonder if there’s even going to be anyone left to develop for Linux in a few years at this rate.
It’s not one person, not sure where you got that idea from. Here are the most important contributors: https://asahilinux.org/about/#who-is-working-on-asahi-linux
I’m not a Mac user and I don’t follow Asahi Linux, but I would see it mentioned. For a long while, I was under the impression that it was (at least mainly) a single-person project by Asahi Lina, who I assumed had named it after herself. I’m pretty sure I got that idea from their names being almost entirely the same. :-)
You had it backwards, Asahi Linux came first. After that someone assumed the identity of Asahi Lina (a v-tuber) and began contributing to it.
people are employed to make Linux support various hardware. for Linux to go away it needs to be replaced by something. the community being unpleasant to work with is not going to make it go away absent an alternative
I would like to see the maintainer’s feedback on it (I couldn’t find a link to the email thread).
I think it’s https://lore.kernel.org/asahi/[email protected]/, subthread
[PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn downThe maintainer’s argument is that the scheduler shouldn’t be torn down if it still contains queued work, and that code that tries to do so is incorrect:
Having spent all of ten seconds thinking about it, it does seem like the Rust type system could be used to good effect here, but the proposed patch feels backwards. If I were the maintainer, I would probably request a more detailed explanation of why the chosen Rust API requires the scheduler to be destroyed at any time.
edit: I might be misreading (again, ten-second thought budget) but it seems like an additional source of disagreement is that the patch is trying to change the original code so that the new Rust driver can be merged with an idiomatic API, and the reviewers don’t particularly care about that as a motivation. There were several mentions in the thread about how if the existing code isn’t fixed then some or all of the DRM scheduler’s Rust bindings must be be marked
unsafedue to manually-verified semantics, which seems to have been met with shrugs all around.Would they have had the same reaction if the new driver was written in C? It’s difficult to imagine that being the case.
It’s not the Rust API that requires it, it’s the overall design of the driver and GPU, which use a separate scheduler per queue (basically per application). So when the application is closed, the scheduler must be destroyed. As Lina explains in the linked to thread, all the lifetimes are already tracked, and tracking them to tear everything down before destroying the scheduler would just duplicate all the tracking.
And while the problem is more pronounced with the M1 driver due to the per-queue schedulers, all drivers must actually be able to cope with this, since eGPUs people plug in and out are a thing. So pretty much all GPU drivers in Linux actually have this exact bug! It has nothing at all to do with Rust. The making of a Rust interface simply exposed a long standing issue.
You can find more context in this (currently ongoing) thread.
More context from Lina no less.
I almost didn’t click this expecting it to be random redditors weighing in.
And way down the thread, Christian says
Which doesn’t look like a “developer determined to make the lives of the rust maintainers as difficult as possible”. TBH this basically looks like every v1 for a complex feature: a lot of discussion hashing out the objections (and the response to objections etc.). And the series was marked RFC anyway.
This seems to be running in the scheduler kthread, so it seems it can’t easily just reference the scheduler from the jobs, since it might deadlock on the reference, when you try to stop the kthread you’re executing from. It’s mentioned that a job queue would solve it, but I agree with lina kinda; it’s simpler if we allow for the surrounding kernel to finish cleanup as long as the scheduler promises that it’s cleaned up as much as it can before it exits.
edit: Lina also tries to explain things a bit:
This sounds pretty similar to the experience designers have when trying to contribute to open source projects.
This pains me. I have been to the Lund Linux Conference last year for some discussions about Rust in Linux. And while I found some things odd (*), by and large, my conversations were open, friendly, between peers and strong. There’s a lot of legitimate concerns around Rust, particularly deep in the kernel, and I had a lot of fun either defusing them when there was a misunderstanding about Rust or - just as often - strengthen them in voicing their legitimate concerns.
(*) there was someone on stage attributing Rust success to an astro-turfing-activity of major multinationals that founded grass-roots-movements - which I wish were true, but also found a bit insulting to my free time work
TBH, I don’t understand how Lennart Poettering does it. The push back that he receives are the same as RustForLinux if not more, but duplicated over ~10 projects (systemd, pulseaudio, avahi, …). I would have given up years ago…
I understand that people want to be careful, and not chase the latest trend. But sometimes people need to let it go. It reminds me of the (now deleted) Drew Devault’s rant about the resistance to Wayland. He was basically saying “I’m not maintaining this unmaintainable pile of garbage called Xorg.”
I’m myself also guilty of resisting change (even though I love systemd and wayland :P), but I think try to be considerate of people maintaining the software. Especially the maintainers doing it for fun on their free time.
The answer is actually rather depressing. He (and, for that matter, much of the systemd community) does it exactly like the angry person in the video: by belittling anyone who points out legitimate cases that their solution doesn’t address well, claiming to be in possession of the map that shows the right way, and deflecting virtually every bug report onto every possible third party and only addressing the ones that simply don’t stick anywhere else. Not that this justifies all the abuse they got in any way, but they were exactly as immature as the entitled nerds raging about init system freedom.
There are legitimate problems that Rust for Linux hasn’t found solutions to (yet). However, a lot (or at least the most visible reactions it got) from the kernel community were basically angry shouting over non-issues. Same with systemd (muh unix philosophy!!), but systemd has two things that, so far, Rust for Linux doesn’t: an equally abbrasive development team and strong commercial backing from someone who really needs its features.
Oh man this hits close to home. At a previous job it was decided to switch from CentOS to CoreOS/Flatcar which meant using systemd for everything and becoming fairly well versed in it.
When using systemd-networkd we ran into situations where it assumes behavior on network interfaces that was just flat out wrong and if you dared report them to the systemd issue tracker, you better come with a mountain of evidence because you’ll need the cushion to soften the attack that lands you on your butt hurting. I lost count of the number of bugs where a systemd-networkd developer would argue with the Linux maintainer of the subsystem that networkd was incorrectly using. They’d argue systemd-networkd was correct and the kernel was wrong.
I still actually like systemd, even networkd, but the developers of it for a long time had been attacked so much that they became actively hostile towards people actually seeking to improve the product and could not fathom someone might actually be offering legit feedback.
Or… you run the issues(systemd only, not networkd) up through RHEL support contracts and they’ll be more likely to take you serious…
That whole thing went both ways. Early on, both with systemd and with, uh, other projects from the same maintainer, every bug report that wasn’t an outright crash or something got closed with the equivalent of “it works on my machine”. Anyone who pointed out that they’re running on a different machine and therefore have either a slightly different configuration or slightly different requirements was quickly told their configuration is incorrect and their requirements don’t make sense, and if the discussion didn’t stop there, they just got the bird.
So in time there were only two types of people who went through this:
There is no excuse for the behaviour of people under #2 but there’s no excuse for the behaviour that drew them there, either. People like you and me just got caught in the middle.
That reminds me of what happened when large numbers of people reported that OS/2 wouldn’t run on their hardware (eventually determined to be deficient cache implementations). And we all know what happened to OS/2…
“muh” interface consistency
By completely ignoring feedback and (constructive) criticism, calling people dumb, from the middle ages and anti-innovation, not differentiating between flamers and others. A general “everyone who isn’t a hardcore fan is dumb” attitude.
He is actually on the opposite side where he previously hijacked a person doing a talk presenting gentle, productive feedback, not even allowing them to finish their talk, but taking the microphone in the middle of the talk.
I really don’t think that a comparison with Poettering is fair to Wedson Almeida Filho.
To be fair, I don’t know, maybe that’s the way to go. Maybe one has to disregard both flamers and well-meaning people to succeed, keep some inner peace and so on.
I mean given what we saw in the video maybe that’s the correct attitude.
This is just so sad. I really really wish there would be less hostility in the community, be it Rust-For-Linux, systemd, or wayland.
I have been at a conference (CCC) where Lennart was the annoying interrupting person in the audience. It was really quite something.
I saw the video, that was indeed a cringe-worthy presentation…
The organizers should not have given the stage to such an ill-informed presenter: Projects need to invest a lot of effort to debunk BS said on a stage for month if not years. Ok, granted, nobody would have bothered to watch this particular presentation if Lennart had not interrupted it and “Do you hate handicaped people?” is at the same level as “rust religion”… but then you had the presenter claim that accessibility features are bloat.
Maybe the presentation was not good, but Lennarts attitude was awful. I was in the room and that was by far the strangest atmosphere I ever saw during a Talk.
Reading this thread makes me seriously question my plans for attending conferences. What the fuck. Is there not a mandatory “is a grownup” check at these things?
Like, I’ve seen academics, the posterchildren of entitlement and lack of social skills, handling these things better. You think presenter is full of shit? Great, wait until the QA session, ask for the mic, and say:
$project, I wanted to offer a counterpoint to this presentation.I swear to God that kind of behaviour is exactly why so many people treat professionals in our field like children. I thought it was the exception but it’s not? Is this what I’ve been missing on? Should I just continue to attend, like, street food festivals and the like instead?
Who does it for fun?
Everybody doing it is getting something out of it (even if it’s just learning or recognition or klout). If they’re not, they shouldn’t be doing it.
“fun” is something.
Linus. He wrote a book about it. It is called “Just for fun”
“shouldn’t”!? Why?
I don’t want to post this here, since it will just be buried by the tons of other stuff, but it’d just get merged anyway, so here goes: https://vt.social/@lina/113053001575612250
This is making me feel things that have left me unable to express myself in any way that would be reasonable on in a public forum, so I won’t offer my own comments on this.
This line struck a chord. This is why I’m way more hopeful for Redox than Linux. And not because Linux isn’t adopting Rust - it is - but because the maintainers and community around Linux are so hostile that I really want nothing to do with them. We are beyond Linux having any technical merit, it’s purely a bog of politics now, and any interested party is simply scared away from it. Don’t get mad at me for saying that, just look at the OP.
Ironically, I specifically talked about this point in a thread from Oxide computer about using illumos instead of Linux, which a maintainer posted about in here as well.
Linux kernel development is legendarily hostile.
Having a kernel that is stripped down for just modern systems, with a decent maintenance community, would be a good thing.
yikes
I would merge this into: https://lobste.rs/s/46pt2l/retiring_from_rust_for_linux_project
I wouldn’t because it’s a different story and would just be lost in the sea of comments already there
[Comment removed by author]
Depressing and unsurprising.
Is that comment considered hostile? I watched only that clip but is sounds like a person who takes the longevity of their product seriously and is impressing upon the presenter that stability and maintenance are vital considerations. It sounds like a person who has seen fads come and go and doesn’t want the product to fall into a trap.
When you start off by accusing the person of being in a cult, it’s not going to be a friendly conversation.
Somehow I think that if they’d just said that, this whole thread wouldn’t exist :-).
Edit: pre-emptively addressing the “but muh tone policing” crowd, this has nothing to do with politeness (although having to point out that that’s a thing, too, is kind of embarrassing, but anyway). This is a matter of engineering communication.
If someone has concerns about stability, they can bring them up. Especially if they’re someone with decades of experience, who have seen fads come and go. If they think the (obviously less experienced) person speaking isn’t addressing them, it’s particularly important to bring them up, because that person may literally not understand them, or appreciate their importance, since they have less experience.
Thing is you have to articulate them. Explain what the technical concern is. Otherwise that’s just basic ranting with zero engineering value.
Just to pick one topic at random to illustrate it.
Good: lots of people in our community don’t know Rust, this is a problem. We can’t write critical code in a language with so little traction, but we also have critical code that we need to keep refactoring. We don’t want to be restricted in what we can refactor by a non-critical component. Can you make that happen? What information do you need from us to make it happen?
Bad: “part of the problem here is you’re trying to convince everyone to switch over to the religion as promulgated (?) by Rus, and the reality is that’s not gonna happen because we have 50+ filesystems in Linux, they will not all be instantaneously converted to Rust. Before that happens, we will continue to refactor C code, because we want to make the C code better. If it breaks the Rust bindings, the Rust bindings are a second class citizen, and those filesystems that depend on those Rust bindings will break, and that is the Rust bindings’ problem and not the filesystem community’s problem”. Etc., I’m not going to quote the whole rant here, that’s what whoever’s speaking in that video is saying (I really want to think it’s not Theodore Ts’o, hell, there are only so many idols I can add to my “never meet” list…).
See how the former is something you can make software better with?
See how the latter isn’t, and is actually just cheap thrash talk with zero technical value – like, yes, everyone can count how many filesystem drivers there are and coming up with flexible Rust bindings is literally what the talk is about.
The commentators were poorly engaging with presenter’s answers about the APIs (that he only needs the docs, and will handle Rust breakage for them).
They mostly expressed vague skepticism and suspicion, and seemed to just feel threatened by Rust. The condescending Java comments showed they don’t actually know Rust, and it’s an ingropup vs outgroup people problem, not a technical problem with Rust or their product.
It’s in the delivery. The speaker is the one in a vulnerable position. The questioner’s tone might have been acceptable during a conversation in the bar afterwards, but in the environment they were in, it places the speaker in a position where they are forced to listen to the whole thing (valid or not) try and be diplomatic as they’re the one on stage. We don’t really know who the questioner was, but we do know who was on the stage.
The power balance is terribly lopsided. So while I saw the video and thought “seems harsh but Linux-normal, won’t be a way to win friends” , when you place it into context it’s actually pretty bad. When the questioner then goes “you can’t make us all learn Rust, sorry!” it’s clear that things have gone completely off the rails. If I was the person on stage who had been subjected to that without defense, I would be pretty upset too.
When I gave talks I emotionally felt that way, but in terms of power dynamics the speaker has the power.
If I’m charismatic enough I can make a big group of people do things. Even if I’m half way decent, I can change how a lot of people behave.
Tough questions from listeners is a good and time honored check.
That wasn’t tough questions, that was an angry rant. The speaker attempted to answer a few times and the ranter just steamrolled him.
I’m not well versed in the Linux Kernel or Rust, so I’m going to find the whole video. This whole thing has been a nice nerd fight and all but I’m genuinely curious about the personality struggle here.
It’s possible I’m too far on the wrong side of thirty because I didn’t used to be the person who supports the heckler in the crowd, but I do have a natural instinct to push back on something that adds risk to something (like an OS) that I don’t want to spend time fixing on the way to something else.
The whole video is the one linked, it’s just linked at a timestamp.
Thank you! I’m so used to our clickbait culture that I assumed it was a short excerpt with out all the context.
OK so the bottom line appears to be that it’s not “The API is being presented to us in Rust since that allows it to be checked robustly”, but “The API is being redefined and understanding it requires proficiency in Rust”.
Actually it feels like the speaker is basically begging people to explain what the API, which exists implicitly at all times, actually is so that it can then be described in Rust. Proficiency in Rust does not appear to be a requirement, just a sound understanding of what the code that exists (and which can apparently change at any moment!) actually does and the ability to communicate that to other C programmers. Which one would hope is already a robust part of existing software engineering work in the kernel!
I worked with a former employee years ago who did this to an obviously lessor extent. He “owned” a particular API and any time he was requested to document or explain it, he would instead “just go fix the calling code” himself to whatever the new implicit semantics were. I am a firm believer it was a leadership failure allowing him to do that instead of taking the time to actually define the semantics and keep those definitions up to date instead of playing fast and loose.
Rust doesn’t want to redefine the API. Rust wants to offer equivalent of what C does, but the maintainers are refusing to answer clarifying questions about what the API guarantees/requires and what it doesn’t.
The maintainers say they don’t mind updating 50 filesystems using the API to new semantics if they needed to, but act as if it was impossible to also inform a single person what the changes they make. They’re just refusing to cooperate.
Mastodon tip: Click the 👁 icon on the top of the page to expand all posts.
I feel Airlie is very much mischaracterizing the events in his article. The problem here really isn’t that the “wayfinders” are frustrated that progresses are slow…
I have a weird feeling that this isn’t him trying to ignore the problem or anything, it’s more like how things work has changed so much, he is missing something that would allow him to perceive the problem to begin with.
There’s no flag for editorialised title, and there’s no obvious title for this, which maybe suggests it’s not a story so much as a tweet.
I would ordinarily mention that, but in the “Retiring from Rust for Linux” thread, people have brought this exact post up several times and started discussions on it, so I assume WeetHet figured it was worth cementing as a proper thread. It certainly makes it easier to find, since a few people were asking how they could find it.
When the kernel let Rust in, it also let in the associated drama it carries with it.
Now we can see, in hindsight, that it was not the best decision. Complicating a kernel with preexisting millions of LoCs by mixing in a relatively new programming language that hasn’t even proved itself in systems development… was never a good idea.
Rust developers were never prevented from writing their own kernel and OS, and should have been told to do just that i.e. told off.
In life, there are those who are too accommodating or otherwise have difficulties saying no. This tends to create problems in the long run, be it through mere misunderstandings or malice. These events resemble just that.
e.g. Linux isn’t going to suddenly change its culture and freeze and document internal APIs for drivers and the like just to make this minority of developers that prefer rust comfortable. It is a waste of time and good will all around.
But the Rust devs in this case have been calm and cordial. This is C drama, not Rust drama.
The decision Linus Torvalds made was to allow an experiment to see if Rust would be a good fit. So far, every driver written in Rust has been hugely successful on the metrics Linus hoped to achieve, i.e. safer and fewer bugs.
Since the boss of all Linux, Linus Torvalds, wanted this experiment done, maybe it’s the anti-Rust fanatics who should go make their own kernel.
Literally no one asked for that.
If you can’t document how your complex interfaces are supposed to work, no one else can write functioning code either. This is NOT a Rust specific issue. Every single DRM driver has tons of bugs because no one knows how anything is actually supposed to work. If you don’t understand the requirements of your own code enough to be able to document how it should be used, you shouldn’t be writing any C code ever.
[Comment removed by moderator pushcx: Don't pick fights.]
[Comment removed by moderator pushcx: No, let's pass on that fight. ]
[Comment removed by moderator pushcx: Pruning some bickering that's wscalating.]
[Comment removed by moderator pushcx: Pruning some bickering that's wscalating.]
So the root cause is that Linus is just unable to say “No” to anything?
That has nkt been my impression so far, but of course it might be Big Oxide holding him to the grill here…
[Comment removed by author]
[Comment removed by author]