13 ms·

Rust in Linux Revisited

162 points by Munksgaard 2y ago

fijiaarone 2y ago
I expect the result of Filho's tantrum will be the ouster of Ted Tso from the Linux kernel.
troad 2y ago
TLDR: In response to the recent resignation of Rust-for-Linux's Wedson Almeida Filho [0] and consequent debate over the politics of Rust in the kernel, Drew DeVault suggests that the Rust for Linux crowd build their own ABI-compatible Linux clone, reasoning that a clone is easier than a greenfield research OS (like the existing Redux). It's not a bad idea, imho. Rust folks love rewriting things, and are often quite good at it. It would keep both the curmudgeonly kernel Never-Rusters and the Rust evangelism brigades happy (by keeping them apart). And it's a great proving ground for Rust's claims - assuming licence compatibility, successful rewrites of individual components could be lifted by Linux down the line. [0] https://lwn.net/Articles/987635/ https://lwn.net/Articles/987635/
- mustache_kimono 2y ago
  [flagged]
  - drewdevault 2y ago
    Why would you even say something like that?
    - mustache_kimono 2y ago
      >> I am a Drew Devault hater, so buckle https://drewdevault.com/2021/09/27/Let-distros-do-their-job.htmlup https://drewdevault.com/2021/09/27/Let-distros-do-their-job..... > Why would you even say something like that? Well -- never let it be said I wouldn't say it directly to you, and I hope after reading this you will at least understand why I feel the way I do. I said what I said above, because I find your writing deeply incurious, and what is probably worse, directed towards others who are similar incurious, in much the same way say Fox News or MSNBC is in my country. When I read your writing, I never have the sense you've ever thought critically about your opinions at all. There also seems to be only good things and bad things in your cosmology. I hope you know this isn't to denigrate you as an engineer, or you as a person. You may be a wonderful person, and you have certainly built artifacts which are useful to your users. You do also seem to be very principled and sincere in your beliefs. And it's certainly not to say I always live up to my/these aspirations! On the other hand, I think, when a software engineer expounds more broadly on software (which seems to be your only beat), they owe their readers a duty to be self-critical. For instance, as you, yourself, note: You're known for your Rust hot takes[0]. If you (or the comment readers) want me to get more particular see "Does Rust belong in the Linux kernel?"[1]. There you skip talking about memory safety to spend more than a few graphs on the "Trendiness" of Rust. An argument AFAIK that was never made by those seeking to integrate Rust into the Linux kernel. And this is where I usually get off the Devault train, because it is another shallow strawman based on vibes. Not once do you ask, as someone who is intellectually curious might: "Maybe Rust is trendy because it provides lots of interesting and useful features. Perhaps I/Drew should try this new language, then I'd have some basis for the many graphs I wrote about 'Trendiness'." Unfortunately for the reader, that never happens. Each blog post is one string of unschooled, untested assumptions tied inexorably to another string of assumptions, on and on, ad infinitum. I'll admit I've compared you to Tucker Carlson more than once because that is exactly what reading a Drew Devault blog post feels like, because yours is actually a deeply conservative breed of tech demagoguery, saying to your readers, again and again: "We already know what's right. Someone just needs to say it now and then..." Similarly, re: your latest article[0], yes, you do, in a footnote, express that you thought Ted T'so's behavior was bad. But your solutions have nothing to do with remedying the bad behavior. Your solution is -- I was right all along, it was never going to work out, this couple needs a divorce. At every turn I keep expecting you to say: "Was I right? I think so because..." but, as a regular reader, I should know better. We are on the Epistemic Closure Express. Drew's writing only knows one destination. TBC this beef doesn't just extend to your writing on Rust. Your writing on Linux packaging was what first bothered me[2]. Never once do you ask yourself questions like: Is there something wrong with the Linux model of 12 different package managers? What if a dev wants users to actually use his or her software, what should they do instead of wait? Do I really imagine distro maintainers are scouring the land looking for new software to land in their distros? Is there a software solution, perhaps a declarative language/system, which would make this easier? Your answer here is like your answer to bad behavior within Linux -- your problem isn't a problem. Because I can't tell my reader Linux has any problems? Because that would be too grey for my black/white world? [0]: https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... [1]: https://drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux.html https://drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux... [2]: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
      - iknowstuff 2y ago
        slay
      - jmercan 2y ago
        No matter the situation, no good can come from hatred. The RfL situation has already come from anger and bad, derailed arguments. Instead of having beef with a stranger online and comparing him to an alt-right figure (which is very much not okay) I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best. Focus your hatred to the injustice of the world instead. edit: pronoun fix
        mustache_kimono 2y ago
        > No matter the situation, no good can come from hatred. Appreciate this POV, probably ascribe to it. Suppose my "hate" for Drew is mostly re: his public persona. I "hate" Drew like I hate teams that play in the same division as my team, which is to say it that hate is lightly held. So, yes, "hate" is probably too strong a term. > Instead of having beef with a stranger online and comparing them to an alt-right figure (which is very much not okay) I would disagree with this notion. In many ways, Drew is a demagogue and a populist and a (tech) conservative. I am (tech) conservative in some/many ways too. But this disagreement isn't about our politics. > I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best Agreed. But the problem I have with Drew don't extend to his good faith opinions. What bothers me is the incurious way in which he chooses to express himself, not what he believes. Which I suppose it would be fine if he had a smaller audience, but he seems to want a broader relevance. I really do believe that 100 more and then 100 more people who express themselves in a similar way would be bad for any community.
        deleted 2y ago
        [deleted]
        anonfordays 2y ago
        >and comparing him to an alt-right figure (which is very much not okay) When I read your reaction to being compared to one of the most influential conservative political commentators, I had an inkling that you were missing the forest for the trees. Twas such an egregious transgression that you were compelled to virtue signal about how "very much not okay" that is, then attempt to gaslight people with scary terms like "alt-right" (nowhere in his Wikipedia is he listed as alt-right). This is a common pattern I see from a certain segment of the population with a high propensity to have pronouns in their profile. As an experiment I click on your profile, and, well...
  - stonogo 2y ago
    > First, there is no reason why we have to choose between Rust in the Linux kernel and a new Rust kernel. First, we may have to choose between those things because Rust in the Linux kernel is not gaining traction and major contributors are dropping out rather than seeing it through. It's valid to speculate about alternatives. Second, software development is not a zero-sum game and such a rewrite can exist in concert with Rust-for-Linux (and even benefit from it). Drew is not handing out orders here anyway. > Second, this would perpetuate toxic LKML behavior. I'd suggest maybe this bad behavior should be dealt with. You've used the passive voice here, and the probable reason for that is that there is nobody who is or will ever be responsible for dealing with LKML's shitty "culture." It's a cesspool at every level and will continue to be so until everyone currently in a leadership position is gone. In addition, the problem here is not technical. Rust is a solution to some technical problems, but technical decisions in a mature group effort are secondary to what Filho referred to as "nontechnical nonsense." That nonsense is the single most important aspect of the project, and too many of the Rust-for-Linux proponents don't seem to understand that. Without developer buy-in, none of your advanced futuristic solutions are even going to make it in the door. The fact that many of the developers whose buy-in you need are assholes is not grounds to reject the work. It simply makes the work less pleasant. Linux moves forward because the people who build it are moving in the same direction. If you want that direction to change, you have to convince a majority of the actors. You're not going to do that by telling them the tools they've used for decades are bad and wrong and the answer is this other shit you happen to be good at. People keep making this assumption that Rust-for-Linux is hindered by technology considerations, but that was never the case. It is and always has been a sales pitch, and the Rust-for-Linux people have completely fumbled the ball at almost every stage. There is a great example in Filho's linked video where he's showing get_or_create_inode and the C devs (poorly and abrasively) try to explain that this design means to implement special cases you have to go fucking around in the type system instead of just branching differently in the call site where the other logic is. Filho gets frustrated because he can't seem to understand that using types this way is not intuitive for many people, and the C people get frustrated because Filho's answers don't account for their objections at all. There's another great example in this very thread where you declare that "the Rust devs showed an better/easier way." They, arguably, did not, if you're not a Rust dev. To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do. Nobody at any point is trying to demonstrate why the Rust approach is superior -- a position I happen to agree with, for the record -- and instead just bemoan these stupid C toddlers who don't take the same things for granted that Rust adults do. It's pointlessly demeaning, combative, and in this case self-defeating, and it's the primary reason I think projects which use Rust ab initio succeed more than these piecemeal approaches.
  - mcdow 2y ago
    I think both things can be true. The worst of the LKML are crybabies. The worst of Rustaceans are zealots. The worst of any community are usually a vocal minority. Rust for Linux can continue on their mission, and that’s noble. But conflict is to be expected between the babies and zealots, naturally. RFL is not mutually exclusive with a Rust Linux clone. Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
    - mustache_kimono 2y ago
      > But conflict is to be expected between the babies and zealots, naturally. Let's note: that's not what happened here. A baby didn't meet a zealot. Here, a baby just lost it. > Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project. I agree a Linux compatible Rust OS is perfectly reasonable. I'm not sure it's a reasonable alternative. One contributor leaves because of technical nontechnical nonsense, so let's call the whole thing off? Rust was being included for a technical reason. Is this technical reason less true? Can Linux do without memory safety?
      - snvzz 2y ago
        Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety". Rust is merely a tool; a language that makes memory safety easier. It is not required for memory safety, nor does it, by itself, guarantee memory safety. This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
        mustache_kimono 2y ago
        > Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety". I'm glad you were able to reason through it. > Rust is merely a tool; a language that makes memory safety easier. I suppose, if I overstated the effect Rust might have on memory safety, you risk understating it here. > It is not required for memory safety, nor does it, by itself, guarantee memory safety. No, but it does an incredible job? This reminds me of a post, on this site, I saw which said something to the effect of "ZFS is only great because it is the only filesystem in its domain" which is ridiculous on it's face, but I think even more ridiculous as you dig a little deeper. When someone who keeps shooting themselves in the foot says, "That safety doesn't prevent all the ways you can kill yourself". Sometimes you want to scream to that fool who manages to continue to avoid using the safety: "What more do you want?" > This is particularly true in supervisor mode, with hardware other than the CPU itself within reach. Of course, I'd agree to some extent, but I think your framing is again perhaps overly narrow. Rust is a really good tool. It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
  - Rochus 2y ago
    > I am a Drew Devault hater, so buckle up. With this sentence you have completely disqualified yourself, regardless of what else - if anything at all - you might have to say.
    - mustache_kimono 2y ago
      Perhaps you should see why below: https://news.ycombinator.com/item?id=41404644 https://news.ycombinator.com/item?id=41404644
      - Rochus 2y ago
        There is no excuse for such statements by an adult person.
capitainenemo 2y ago
Duplicate of https://news.ycombinator.com/item?id=41400493 https://news.ycombinator.com/item?id=41400493
tredre3 2y ago
> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. Rust is many things, but devoid of political drama it is not.
- timeon 2y ago
  Does your comment contains anything more than drama?
- brezelgoring 2y ago
  I also disagree with his take that the Kernel could be replicated in Rust by 6 motivated volunteers in 4 or 5 years. That could be said of many projects, you could probably reproduce AAA entertainment software with such a team in such a span of time, but the trick is getting these people to stay on track, fed, and satisfied for that time. Who's going to pay for their rent/mortgages? Are they just not going to work for the duration? It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.
  - bangaladore 2y ago
    You are misrepresenting the original article. Drew did not say six volunteers or 4 or 5 years. Those are your numbers, so feel free to agree to disagree with yourself. A Linux kernel clone is the epitome of a large Rust community project (for many reasons, some noble, some not so noble). It would likely pull in hundreds if not thousands of developers in an arms race assuming the end goal is well defined. Nobody claims it's a small task, but I believe it can probably be accomplished. Particularily in the scope of the original claim "applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years."
    - stroupwaffle 2y ago
      [flagged]
    - brezelgoring 2y ago
yshui 2y ago
I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and starting a project out of grudge, is always the last resort, IMO. OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.
- snvzz 2y ago
  Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers. >but I will always wish people can just stop fighting, and work together. Two separate ideas are conflated here. It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
  - steveklabnik 2y ago
    > including those most prominent, The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.
    - snvzz 2y ago
      >The most prominent one is supportive of Rust It is the premise. Without his acceptance of Rust, we wouldn't be at this point. But he can't realistically do the relevant rust-accommodation work all by himself. Not does he seem supportive of Rust enough as to replace the top maintainers he trusts and has worked with for a very long time with those that will extend the red carpet for Rust developers. Perhaps Linus was trying to be kind. But sometimes, just saying "No." is most kind. He didn't have the luxury of hindsight. He tried to be accommodating. Now, we are in a situation that is not pleasant for anybody involved.
      - nequo 2y ago
        The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore. So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.
a-dub 2y ago
with respect to linux kernel rust projects: is there anything new that is complete and ready to use or anything that existed in c that has been rewritten that is stable and has reached feature parity with the existing implementations yet?
- dmm 2y ago
  The gpu driver for apple m1 silicon is written is Rust.
  - Narishma 2y ago
    I think the new Nvidia driver is also being written in Rust, though it's not ready yet.
    - Rochus 2y ago
      Didn't they announce hat they use Ada and SPARK for such things some years ago?
      - mixedCase 2y ago
        I believe this poster meant the new Linux driver for Nvidia cards called Nova (announcement: https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/ https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopei...), not the driver maintained by Nvidia.
  - a-dub 2y ago
    this is also very cool! some pretty nice blog posts from the asahi folks about this and the code looks nice...
  - MBCook 2y ago
    And have never had a single crash from their code. And wrote a fully compliant Open GL stack for it in rust. Shipped by Fedora. Used on all Apple Silicon Macs running Linux. The value exists and has been proven. The community can say no to it, but dismissing the work of Lina and the Asahi team members who have worked on Rust stuff as a “toy project” is just being rude.
raggi 2y ago
There's an attempt at heading off the driver commentary with a note at the bottom. The note makes some hand-wavy thing which is essentially "assuming you have an army of people with specifications, this won't be a problem", but that assumption is crazy. Fuchsia is a real OS effort funded by Google (at varying levels of funding through it's lifecycle, which is still ongoing AIUI) - I worked on Fuchsia for a number of years, from approximately the time the kernel had become usable, through to launching on nest hubs where it replaced the existing OS from bootloader to GUI. Drivers remain a huge problem for Fuchsia despite funding. SOC vendors don't provide docs or assistance, even for serious efforts, they demand money first - they're literally holding the software world hostage with this activity. After leaving Fuchsia and reflecting on the whole thing, I really believe that despite the many problems Linux may have over the long term, the only viable strategies for a broadly and practically usable safer OSS system are either: someone donates at least $2bn to get it done in a PBC well managed and focused over a decade, or you slowly mutate Linux into that thing. Anything drastically different is, for now, dependent on the world being a different shape / people & companies having different attitudes than they do. I'd love to see something like Redox prove me wrong, but real world experience suggests that's extremely unlikely. RISCv is the one thing in flight that might "change the shape of the world" enough to alter this, but RISCv comes with it's own stack of long challenges to overcome to meet the originally stated goal of broadly and practically usable. Writing a core kernel and usable userspace isn't something to be trivialized, but by cost and work volume, getting a broad set of drivers is far far more effort by an astronomical margin. The OSDev community has thousands of OSes to explore, and barely any drivers that do things a user actually cares about.
- IshKebab 2y ago
  > RISCv is the one thing in flight that might "change the shape of the world" enough to alter this I don't think RISC-V will have any effect on the availability of drivers.
- andrewchambers 2y ago
  If its compatible with linux then the linux drivers would work right?
andrewchambers 2y ago
It's more or less working for ladybird browser, could work for a kernel.
- bla3 2y ago
  Ladybird isn't using rust.
  - simjnd 2y ago
    The point is not the specific language, but the approach.
- ndiddy 2y ago
  Ladybird is getting migrated to Swift, not Rust. Andreas Kling goes over why he chose Swift here: https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031 and his views on Rust here: https://x.com/awesomekling/status/1822241531501162806 https://x.com/awesomekling/status/1822241531501162806
  - LeFantome 2y ago
    It is intended to be migrated. Nothing has been done in Swift yet. Ladybird is all C++ though a somewhat unique dialect of it. Servo is a browser engine written in Rust.
  - simjnd 2y ago
    The point is not the specific language, but the approach. The split from Serenity OS (and its "C++ only, no external dependencies" approach) made Ladybird a lot more attractive for both funding and potential contributors.
  - andrewchambers 2y ago
    I am well aware, the point is that ladybird is a new project following some standards and they are free to use a memory safe language now.
PoignardAzur 2y ago
Someone in a sub-thread accused Drew of being incurious, and reading the article, I kind of agree. It's a very polite, high-effort, superficially humble piece of writing, that nevertheless boils down to "You guys should probably leave us alone and work on stuff we don't need to worry about". Now, working on a Linux fork as a "proof of value" thing could be interesting, but it also means that this hypothetical Linust project would be stuck forever chasing Linux's API decisions without any power to influence them (and, if recent history is any indication, quite a lot of hostility from OG Linux maintainers). I can't help but notice that Drew's plan doesn't include any exit strategy, any point where the projects merge or Linux starts taking components from Linust or something. Maybe Drew thinks that forever being stuck between shadowing a concurrent project's API and trying to convince its billion users to switch to yours instead is an attractive prospect. If I was a Rust-on-Linux developer, I'd find that patronizing.
- unclad5968 2y ago
  Just seems pragmatic to me. The people contributing rust to Linux are having a bad time so the advice is to do something else. It sucks I guess but it's no different than any other open source project. "Fine I'll do it myself" is a story basically as old as time. - Walt Disney - Ferruccio Lamborghini - King Henry VIII - Juan Pujol Garcia I doubt Drew has the power to serious change the culture among Linux kernal contributors and maintainers, so he's just offering advice.
  - snvzz 2y ago
    The elephant in the room, which is Linux's untenable complexity and lack of internal APIs (even for drivers), is not addressed. Doing anything on Linux is many times as hard as doing it on systems that put a strong emphasis on structure. This is true not just for microkernel, multiserver systems, but for other unices/unix-like such as the BSDs (which put far more emphasis on structure relative to Linux) as well. Thus, I agree entirely with Drew, with extra reasons, that we (developers in general, not specific to rust) should try and put some effort elsewhere than Linux. It doesn't have to be Linux. It isn't the end-all in operating systems. It's just what happens to be most popular -right now-.
JackSlateur 2y ago
The counter has started. I am looking forward that drop-in kernel, that could replace Linux on all my production systems "has-is". This sounds very easy. Very.
e-dant 2y ago
I must be missing something obvious. I’m not aware of any too-frequent toxicity in the rust lkml. Just seems like a lot of groundwork is still being laid, without much even having been started. The article makes it seem like things are actually being rewritten in rust. Are they?
- e-dant 2y ago
  Oh, I started searching for some hot topics in the rust lkml, ouch, there’s some bad stuff in there. Linus seems reasonable in comparison…
- MBCook 2y ago
  I’m not sure it’s rewritten so much as new code. But it sounds like it’s been taking a very long time (year+) to merge even smaller things like structure definitions Rust developers need, let alone “real” code.
alphazard 2y ago
I don't see why it's so important to rewrite parts of the kernel in rust, or why Drew is so sympathetic to the cause. The linux project uses static analysis tools which provide some of what rust guarantees (outside of unsafe). The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness. In Drew's own Helios microkernel, the architecture is right, and it's ready to have folks start piling on drivers in user-space. Those drivers can be written in pretty much any low level language that can produce ELF binaries. It's surely a better path forward to slap a Linux syscall API on top of Helios + some new drivers than to clone the whole linux system architecture in another programming language. At least then, we would have gained something tangible (drivers can't ruin the kernel). Instead of having another Linux written in a different language, with all the same design flaws.
- kvemkon 2y ago
  Do we get also realtime (10ths us latency) out-of-the-box, where badly written drivers cannot negatively interfere good ones?
  - snvzz 2y ago
    To get to that point (mixed criticality, some processes and drivers can be critical and others not be), you need to be able to reason about time. That's exclusively seL4 right now, and the very state of the art. (incidentally, we really should be putting our weight behind seL4, it really is good)
- iknowstuff 2y ago
  gtm strategy trumps nerdy perfectionism. Linux is successful because of its timing and probably accidental social engineering - regularly breaking out-of-tree drivers incentivized upstreaming hardware support. Doesn't matter how good an alternative would be on technical merits, there's too much momentum behind Linux. Except maybe a fork where oxidation proceeds much faster, sponsored by a large corporation with bespoke hardware they can develop for and interest in security. Cloud OS-es or Android maybe.
h_tbob 2y ago
Could not agree more. I think there’s a parable in the Bible about this one: No one puts new wine into old wineskins; or else the new wine will burst the wineskins and be spilled, and the wineskins will be ruined. But new wine must be put into new wineskins, and both are preserved. He was specifically talking about bringing new paradigms to an old system. Sometimes, it’s just easier to start over. It has been my experience in programming that starting over almost always yields better results, but it does take time. That’s why apples m1 was so successful. They took the time to rebuild just for apple. But it was 100% worth it.
cryptonector 2y ago
> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. The BSDs, Solaris/Illumos, and Windows all have tried, some more than once even. I think there have been at least 4 Linux kernel ABI compatibility layers for those OSes. They've all failed. And all future attempts will fail too for the same reason: The Linux kernel ABI is not specified anywhere, and it's insanely large (and growing). Besides the system calls (easy), many ioctls (hmmm), proc(4) (oof), and many ioctl-like ABIs within ABIs, there's loads of driver-specific ABIs and things like security modules and what not that add their own ABIs and which you'll invariably end up having to support. The last effort in Illumos land foundered on proc(4), IIRC. To top it all off that undefined (but stable) ABI is a moving target: it's always evolving / getting extended. The only thing you have to help you is that whatever the ABI, Linux [mostly] commits to maintaining backwards compatibility with it. If your compatibility ever gets good enough, that will help you, but in the meantime you'll be chasing a never ending and ever growing ill-defined ABI. Good luck with that!
- HaroldCindy 2y ago
  There's at least one more to add to the pile, Google's Fuchsia is primarily written in Rust and aims to support the Linux ABI through "starnix". See https://fuchsia.dev/fuchsia-src/concepts/components/v2/starnix https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn... and https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/starnix/ https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
  - plus 2y ago
    Fuchsia is written in C++, not Rust.
    - surajrmal 2y ago
      It's half-half. The kernel is c++, but it is small relative to the overall OS which is predominantly use space. Growth in rust far outpaces c++ so in a few years c++ will likely be a much smaller fraction. Also, notably, starnix is entirely written in rust.
goatmanbah 2y ago
These arguments are pointless because in a few years you can have your AI of choice translate Linux to your language of choice. The real question is will you even bother to do it? Will it matter at that point?
lolnowtf 2y ago
[flagged]
fizlebit 2y ago
https://youtu.be/kQcIV5389Ps?si=9Lixq3OUYxaei7s4 https://youtu.be/kQcIV5389Ps?si=9Lixq3OUYxaei7s4
- fizlebit 2y ago
  From the Linux conference video I watched I think they have the wrong approach. They’re trying to improve a bad api by adding types do describe it’s awkward behavior. The C programmers who love the Linux style want to be able to change semantics or api without modifying rust code. The solution is straight forward, build an adapter later in C that has well describable and clean semantics. Since it is C and in the kernel and has clear semantics the C programmers can maintain it without having to look at Rust. Perhaps the general lack of encapsulation and layers in the kernel will defeat them as they will need a lot of adapter layers. But for file systems it might be achievable.
nurettin 2y ago
Cygwin is a compatibility layer between linux syscalls and windows. And that is all userspace. So if you somehow implement everything in there plus the raw kernel functions, maybe there is a chance I think.
- lmz 2y ago
  Cygwin requires recompiling.
  - _nalply 2y ago
    Care to explain a little bit more? In which cases recompiling is required? Do you agree that Cygwin is a moderately successful reimplementation of a part of Linux? If you agree then I wonder how recompiling affects that Cygwin is a (partial) reimplementation?
    - drewdevault 2y ago
      Cygwin is a POSIX implementation, not a Linux implementation. Linux is mostly POSIX compatible and so Cygwin is source-compatible, but not binary-compatible, with many programs that work on Linux.
      - deleted 2y ago
        [deleted]
    - lmz 2y ago
      What the other guy said. Cygwin is a set of libraries to compile and run GNU programs on Windows. It does not run existing Linux binaries and definitely does not translate Linux syscalls into Windows (that would be WSL v1). If recompiling is OK, I suggest starting with one of the BSDs, at least they have a fork() that works.
  - nurettin 2y ago
    What I meant is that it can be used as a checklist of what to do, since so many linux programs can be built against it and it has been around for more than two decades.
tptacek 2y ago
This is an interesting take. Has DeVault done a lot of Linux kernel development?
- criticalfault 2y ago
  No. He himself said it here. https://fosstodon.org/@drewdevault/113052127771211132 https://fosstodon.org/@drewdevault/113052127771211132 What he did though, he developed a Unix clone using hare in roughly 30 days. https://fosstodon.org/@drewdevault/112319697309218275 https://fosstodon.org/@drewdevault/112319697309218275
  - daghamm 2y ago
    Probably a significant number of HN readers have done something like this at one point. IIRC there is a MIT course where you do a modern Unix clone in one semester. There is an ocean between that and being an expert in Linux internals. Oh, and the original UNIX was done in one week by one guy.
    - drewdevault 2y ago
      I have not contributed much to Linux -- my claim to fame is submitting a one-line patch which generated 50+ emails of arguments from LKML before Linus merged it -- but I have read a ton of the Linux source code and familiarized myself with many of its internals many times, as well as doing extensive low-level systems work in userspace against the Linux API/ABI. I often use it as a reference in my own osdev work, or working on Hare, etc. Have read a lot of the syscall API surface, DRM internals in depth, dcache and several filesystem implementations, io_uring, etc. Not ignorant to what would be involved in making a Linux-compatible kernel.
    - criticalfault 2y ago
      Nobody said he is an expert in Linux internals. What this brings to light is the ability to compare Helios (microkernel) and Unix clone development, or how it was said in the post: reimplementing already existing design vs designing something new. Because of this, I think his statements carry some weight.
keybored 2y ago
> Two years ago, seeing the Rust-for-Linux project starting to get the ball rolling, I wrote “Does Rust belong in the Linux kernel?”, penning a conclusion consistent with Betteridge’s law of headlines. Two years on we have a lot of experience to draw on to see how Rust-for-Linux is actually playing out, and I’d like to renew my thoughts with some hindsight – and more compassion. If you’re one of the Rust-for-Linux participants burned out or burning out on this project, I want to help. Burnout sucks – I’ve been there. Now this compassionate revisit offers the same conclusion: don’t do Rust in Linux. This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1] The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here. The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. But what if you cared about working on the Linux Kernel specifically? What if you cared about the code in the Linux Kernel itself, its long term health… hush, hush now. You are burned out and don’t know what you are saying. The penultimate paragraph then declares that the Rust-for-Linux project itself is “burned out” (“and that’s awful”). Who needs enemies with compassionate friends like this. [1] How often do we read about maintainers suffering burnout? Every day? Do we then declare that the project is a failure, even when there are other maintainers left on the project?
- IshKebab 2y ago
  > resigning because of burnout It wasn't even because of burnout.
- drewdevault 2y ago
  >This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1] There are several Rust-for-Linux folks who have complained about the same things and been at various levels of burned out over the course of the project. Ignoring them because it raises uncomfortable questions regarding the viability of the project doesn't make it go away, it just erases their experiences. >The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here. >The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. This article is in response to someone who already decided to abandon the project, and to suggest what's next. I didn't impose the conclusion to abandon it on anyone, and in fact I explicitly supported it if burnout victims choose to return to the fold. Yes, I stand by the conclusion that Rust-for-Linux is probably not a great idea, and I'm allowed to say that without being anyone's "enemy". I also believe people when they say they're burned out and quitting the project and take their needs seriously, something I think is missing from your comment. All of this is compatible with compassion. I'm not and have never been your enemy: I can say that I think it's not a good idea and wish you well in your efforts nevertheless, and I have.
daghamm 2y ago
I think he is wrong on two accounts: 1. While the Linux guy mentioned here is not a great politician and his rant was pathetic, his technical argument was sane. You can put months into creating the perfect data model for your Rust implementation but Linux have a habit of completely changing things every year or so. That would make Rust the bottleneck of Linux development 2. These "hugely talanted" Rust devs are competing with ten times more talented Linux devs on their home turf. My point is, stop creating drama. This task requires hard work and compromises.
- Klonoar 2y ago
  Stop contributing to the drama with the “ten times more talented” comment. You have no way of measuring such a thing and are just fanning the flames.
- surajrmal 2y ago
  Linux devs and rust devs aren't two opposing groups. There exists major pockets within Linux community who embrace rust. That doesn't mean they turned in their Linux dev cards.
_zagj 2y ago
The reddit threads on this subject were interesting, with hundreds of comments in r/programming and r/linux all bemoaning the lack of Rust adoption in the kernel and the supposed mistreatment of the Rust maintainers. Are these people just users with a strong opinion about what language their kernel uses? If they're Rust devs and reflective of how popular Rust is in general, where are all of the killer apps written in Rust? Why do Rust programmers seem to mostly just produce partial, feature-incomplete rewrites of Unix utilities?
- IshKebab 2y ago
  > where are all of the killer apps written in Rust What like Ripgrep, uv, Rustdesk, Deno, Tauri, Zed, Meillisearch, Typst, Nushell...?
  - steveklabnik 2y ago
    Your parent is also ignoring the tens of millions of lines of Rust that powers products from many massive tech companies, like Amazon, Meta, Cloudflare, and many many more.
kranuck 2y ago
[flagged]

162 points by Munksgaard 2y ago

I expect the result of Filho's tantrum will be the ouster of Ted Tso from the Linux kernel.

TLDR: In response to the recent resignation of Rust-for-Linux's Wedson Almeida Filho [0] and consequent debate over the politics of Rust in the kernel, Drew DeVault suggests that the Rust for Linux crowd build their own ABI-compatible Linux clone, reasoning that a clone is easier than a greenfield research OS (like the existing Redux). It's not a bad idea, imho. Rust folks love rewriting things, and are often quite good at it. It would keep both the curmudgeonly kernel Never-Rusters and the Rust evangelism brigades happy (by keeping them apart). And it's a great proving ground for Rust's claims - assuming licence compatibility, successful rewrites of individual components could be lifted by Linux down the line. [0] https://lwn.net/Articles/987635/ https://lwn.net/Articles/987635/

mustache_kimono 2y ago
[flagged]
- drewdevault 2y ago
  Why would you even say something like that?
  - mustache_kimono 2y ago
    >> I am a Drew Devault hater, so buckle https://drewdevault.com/2021/09/27/Let-distros-do-their-job.htmlup https://drewdevault.com/2021/09/27/Let-distros-do-their-job..... > Why would you even say something like that? Well -- never let it be said I wouldn't say it directly to you, and I hope after reading this you will at least understand why I feel the way I do. I said what I said above, because I find your writing deeply incurious, and what is probably worse, directed towards others who are similar incurious, in much the same way say Fox News or MSNBC is in my country. When I read your writing, I never have the sense you've ever thought critically about your opinions at all. There also seems to be only good things and bad things in your cosmology. I hope you know this isn't to denigrate you as an engineer, or you as a person. You may be a wonderful person, and you have certainly built artifacts which are useful to your users. You do also seem to be very principled and sincere in your beliefs. And it's certainly not to say I always live up to my/these aspirations! On the other hand, I think, when a software engineer expounds more broadly on software (which seems to be your only beat), they owe their readers a duty to be self-critical. For instance, as you, yourself, note: You're known for your Rust hot takes[0]. If you (or the comment readers) want me to get more particular see "Does Rust belong in the Linux kernel?"[1]. There you skip talking about memory safety to spend more than a few graphs on the "Trendiness" of Rust. An argument AFAIK that was never made by those seeking to integrate Rust into the Linux kernel. And this is where I usually get off the Devault train, because it is another shallow strawman based on vibes. Not once do you ask, as someone who is intellectually curious might: "Maybe Rust is trendy because it provides lots of interesting and useful features. Perhaps I/Drew should try this new language, then I'd have some basis for the many graphs I wrote about 'Trendiness'." Unfortunately for the reader, that never happens. Each blog post is one string of unschooled, untested assumptions tied inexorably to another string of assumptions, on and on, ad infinitum. I'll admit I've compared you to Tucker Carlson more than once because that is exactly what reading a Drew Devault blog post feels like, because yours is actually a deeply conservative breed of tech demagoguery, saying to your readers, again and again: "We already know what's right. Someone just needs to say it now and then..." Similarly, re: your latest article[0], yes, you do, in a footnote, express that you thought Ted T'so's behavior was bad. But your solutions have nothing to do with remedying the bad behavior. Your solution is -- I was right all along, it was never going to work out, this couple needs a divorce. At every turn I keep expecting you to say: "Was I right? I think so because..." but, as a regular reader, I should know better. We are on the Epistemic Closure Express. Drew's writing only knows one destination. TBC this beef doesn't just extend to your writing on Rust. Your writing on Linux packaging was what first bothered me[2]. Never once do you ask yourself questions like: Is there something wrong with the Linux model of 12 different package managers? What if a dev wants users to actually use his or her software, what should they do instead of wait? Do I really imagine distro maintainers are scouring the land looking for new software to land in their distros? Is there a software solution, perhaps a declarative language/system, which would make this easier? Your answer here is like your answer to bad behavior within Linux -- your problem isn't a problem. Because I can't tell my reader Linux has any problems? Because that would be too grey for my black/white world? [0]: https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... [1]: https://drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux.html https://drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux... [2]: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
    - iknowstuff 2y ago
      slay
    - jmercan 2y ago
      No matter the situation, no good can come from hatred. The RfL situation has already come from anger and bad, derailed arguments. Instead of having beef with a stranger online and comparing him to an alt-right figure (which is very much not okay) I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best. Focus your hatred to the injustice of the world instead. edit: pronoun fix
      - mustache_kimono 2y ago
        > No matter the situation, no good can come from hatred. Appreciate this POV, probably ascribe to it. Suppose my "hate" for Drew is mostly re: his public persona. I "hate" Drew like I hate teams that play in the same division as my team, which is to say it that hate is lightly held. So, yes, "hate" is probably too strong a term. > Instead of having beef with a stranger online and comparing them to an alt-right figure (which is very much not okay) I would disagree with this notion. In many ways, Drew is a demagogue and a populist and a (tech) conservative. I am (tech) conservative in some/many ways too. But this disagreement isn't about our politics. > I think having a good faith reply to a good faith personal opinion will at worst do nothing and maybe result in something at best Agreed. But the problem I have with Drew don't extend to his good faith opinions. What bothers me is the incurious way in which he chooses to express himself, not what he believes. Which I suppose it would be fine if he had a smaller audience, but he seems to want a broader relevance. I really do believe that 100 more and then 100 more people who express themselves in a similar way would be bad for any community.
      - deleted 2y ago
        [deleted]
      - anonfordays 2y ago
        >and comparing him to an alt-right figure (which is very much not okay) When I read your reaction to being compared to one of the most influential conservative political commentators, I had an inkling that you were missing the forest for the trees. Twas such an egregious transgression that you were compelled to virtue signal about how "very much not okay" that is, then attempt to gaslight people with scary terms like "alt-right" (nowhere in his Wikipedia is he listed as alt-right). This is a common pattern I see from a certain segment of the population with a high propensity to have pronouns in their profile. As an experiment I click on your profile, and, well...
- stonogo 2y ago
  > First, there is no reason why we have to choose between Rust in the Linux kernel and a new Rust kernel. First, we may have to choose between those things because Rust in the Linux kernel is not gaining traction and major contributors are dropping out rather than seeing it through. It's valid to speculate about alternatives. Second, software development is not a zero-sum game and such a rewrite can exist in concert with Rust-for-Linux (and even benefit from it). Drew is not handing out orders here anyway. > Second, this would perpetuate toxic LKML behavior. I'd suggest maybe this bad behavior should be dealt with. You've used the passive voice here, and the probable reason for that is that there is nobody who is or will ever be responsible for dealing with LKML's shitty "culture." It's a cesspool at every level and will continue to be so until everyone currently in a leadership position is gone. In addition, the problem here is not technical. Rust is a solution to some technical problems, but technical decisions in a mature group effort are secondary to what Filho referred to as "nontechnical nonsense." That nonsense is the single most important aspect of the project, and too many of the Rust-for-Linux proponents don't seem to understand that. Without developer buy-in, none of your advanced futuristic solutions are even going to make it in the door. The fact that many of the developers whose buy-in you need are assholes is not grounds to reject the work. It simply makes the work less pleasant. Linux moves forward because the people who build it are moving in the same direction. If you want that direction to change, you have to convince a majority of the actors. You're not going to do that by telling them the tools they've used for decades are bad and wrong and the answer is this other shit you happen to be good at. People keep making this assumption that Rust-for-Linux is hindered by technology considerations, but that was never the case. It is and always has been a sales pitch, and the Rust-for-Linux people have completely fumbled the ball at almost every stage. There is a great example in Filho's linked video where he's showing get_or_create_inode and the C devs (poorly and abrasively) try to explain that this design means to implement special cases you have to go fucking around in the type system instead of just branching differently in the call site where the other logic is. Filho gets frustrated because he can't seem to understand that using types this way is not intuitive for many people, and the C people get frustrated because Filho's answers don't account for their objections at all. There's another great example in this very thread where you declare that "the Rust devs showed an better/easier way." They, arguably, did not, if you're not a Rust dev. To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do. Nobody at any point is trying to demonstrate why the Rust approach is superior -- a position I happen to agree with, for the record -- and instead just bemoan these stupid C toddlers who don't take the same things for granted that Rust adults do. It's pointlessly demeaning, combative, and in this case self-defeating, and it's the primary reason I think projects which use Rust ab initio succeed more than these piecemeal approaches.
- mcdow 2y ago
  I think both things can be true. The worst of the LKML are crybabies. The worst of Rustaceans are zealots. The worst of any community are usually a vocal minority. Rust for Linux can continue on their mission, and that’s noble. But conflict is to be expected between the babies and zealots, naturally. RFL is not mutually exclusive with a Rust Linux clone. Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project.
  - mustache_kimono 2y ago
    > But conflict is to be expected between the babies and zealots, naturally. Let's note: that's not what happened here. A baby didn't meet a zealot. Here, a baby just lost it. > Drew’s proposal seems like a perfectly reasonable parallel project to the RFL project. I agree a Linux compatible Rust OS is perfectly reasonable. I'm not sure it's a reasonable alternative. One contributor leaves because of technical nontechnical nonsense, so let's call the whole thing off? Rust was being included for a technical reason. Is this technical reason less true? Can Linux do without memory safety?
    - snvzz 2y ago
      Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety". Rust is merely a tool; a language that makes memory safety easier. It is not required for memory safety, nor does it, by itself, guarantee memory safety. This is particularly true in supervisor mode, with hardware other than the CPU itself within reach.
      - mustache_kimono 2y ago
        > Throughout your posts, I notice a recurrent theme of false equivalence between "rust" and "memory safety". I'm glad you were able to reason through it. > Rust is merely a tool; a language that makes memory safety easier. I suppose, if I overstated the effect Rust might have on memory safety, you risk understating it here. > It is not required for memory safety, nor does it, by itself, guarantee memory safety. No, but it does an incredible job? This reminds me of a post, on this site, I saw which said something to the effect of "ZFS is only great because it is the only filesystem in its domain" which is ridiculous on it's face, but I think even more ridiculous as you dig a little deeper. When someone who keeps shooting themselves in the foot says, "That safety doesn't prevent all the ways you can kill yourself". Sometimes you want to scream to that fool who manages to continue to avoid using the safety: "What more do you want?" > This is particularly true in supervisor mode, with hardware other than the CPU itself within reach. Of course, I'd agree to some extent, but I think your framing is again perhaps overly narrow. Rust is a really good tool. It's such a good tool I hear they are trying to write drivers with it in the Linux kernel.
- Rochus 2y ago
  > I am a Drew Devault hater, so buckle up. With this sentence you have completely disqualified yourself, regardless of what else - if anything at all - you might have to say.
  - mustache_kimono 2y ago
    Perhaps you should see why below: https://news.ycombinator.com/item?id=41404644 https://news.ycombinator.com/item?id=41404644
    - Rochus 2y ago
      There is no excuse for such statements by an adult person.

capitainenemo 2y ago

Duplicate of https://news.ycombinator.com/item?id=41400493 https://news.ycombinator.com/item?id=41400493

tredre3 2y ago

> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. Rust is many things, but devoid of political drama it is not.

timeon 2y ago
Does your comment contains anything more than drama?
brezelgoring 2y ago
I also disagree with his take that the Kernel could be replicated in Rust by 6 motivated volunteers in 4 or 5 years. That could be said of many projects, you could probably reproduce AAA entertainment software with such a team in such a span of time, but the trick is getting these people to stay on track, fed, and satisfied for that time. Who's going to pay for their rent/mortgages? Are they just not going to work for the duration? It's naive grandstanding in the best of cases, and malicious proselytizing in the worst.
- bangaladore 2y ago
  You are misrepresenting the original article. Drew did not say six volunteers or 4 or 5 years. Those are your numbers, so feel free to agree to disagree with yourself. A Linux kernel clone is the epitome of a large Rust community project (for many reasons, some noble, some not so noble). It would likely pull in hundreds if not thousands of developers in an arms race assuming the end goal is well defined. Nobody claims it's a small task, but I believe it can probably be accomplished. Particularily in the scope of the original claim "applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years."
  - stroupwaffle 2y ago
    [flagged]
  - brezelgoring 2y ago

yshui 2y ago

I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and starting a project out of grudge, is always the last resort, IMO. OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.

snvzz 2y ago
Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers. >but I will always wish people can just stop fighting, and work together. Two separate ideas are conflated here. It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
- steveklabnik 2y ago
  > including those most prominent, The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.
  - snvzz 2y ago
    >The most prominent one is supportive of Rust It is the premise. Without his acceptance of Rust, we wouldn't be at this point. But he can't realistically do the relevant rust-accommodation work all by himself. Not does he seem supportive of Rust enough as to replace the top maintainers he trusts and has worked with for a very long time with those that will extend the red carpet for Rust developers. Perhaps Linus was trying to be kind. But sometimes, just saying "No." is most kind. He didn't have the luxury of hindsight. He tried to be accommodating. Now, we are in a situation that is not pleasant for anybody involved.
    - nequo 2y ago
      The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore. So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.

a-dub 2y ago

with respect to linux kernel rust projects: is there anything new that is complete and ready to use or anything that existed in c that has been rewritten that is stable and has reached feature parity with the existing implementations yet?

dmm 2y ago
The gpu driver for apple m1 silicon is written is Rust.
- Narishma 2y ago
  I think the new Nvidia driver is also being written in Rust, though it's not ready yet.
  - Rochus 2y ago
    Didn't they announce hat they use Ada and SPARK for such things some years ago?
    - mixedCase 2y ago
      I believe this poster meant the new Linux driver for Nvidia cards called Nova (announcement: https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/ https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopei...), not the driver maintained by Nvidia.
- a-dub 2y ago
  this is also very cool! some pretty nice blog posts from the asahi folks about this and the code looks nice...
- MBCook 2y ago
  And have never had a single crash from their code. And wrote a fully compliant Open GL stack for it in rust. Shipped by Fedora. Used on all Apple Silicon Macs running Linux. The value exists and has been proven. The community can say no to it, but dismissing the work of Lina and the Asahi team members who have worked on Rust stuff as a “toy project” is just being rude.

raggi 2y ago

There's an attempt at heading off the driver commentary with a note at the bottom. The note makes some hand-wavy thing which is essentially "assuming you have an army of people with specifications, this won't be a problem", but that assumption is crazy. Fuchsia is a real OS effort funded by Google (at varying levels of funding through it's lifecycle, which is still ongoing AIUI) - I worked on Fuchsia for a number of years, from approximately the time the kernel had become usable, through to launching on nest hubs where it replaced the existing OS from bootloader to GUI. Drivers remain a huge problem for Fuchsia despite funding. SOC vendors don't provide docs or assistance, even for serious efforts, they demand money first - they're literally holding the software world hostage with this activity. After leaving Fuchsia and reflecting on the whole thing, I really believe that despite the many problems Linux may have over the long term, the only viable strategies for a broadly and practically usable safer OSS system are either: someone donates at least $2bn to get it done in a PBC well managed and focused over a decade, or you slowly mutate Linux into that thing. Anything drastically different is, for now, dependent on the world being a different shape / people & companies having different attitudes than they do. I'd love to see something like Redox prove me wrong, but real world experience suggests that's extremely unlikely. RISCv is the one thing in flight that might "change the shape of the world" enough to alter this, but RISCv comes with it's own stack of long challenges to overcome to meet the originally stated goal of broadly and practically usable. Writing a core kernel and usable userspace isn't something to be trivialized, but by cost and work volume, getting a broad set of drivers is far far more effort by an astronomical margin. The OSDev community has thousands of OSes to explore, and barely any drivers that do things a user actually cares about.

IshKebab 2y ago
> RISCv is the one thing in flight that might "change the shape of the world" enough to alter this I don't think RISC-V will have any effect on the availability of drivers.
andrewchambers 2y ago
If its compatible with linux then the linux drivers would work right?

andrewchambers 2y ago

It's more or less working for ladybird browser, could work for a kernel.

bla3 2y ago
Ladybird isn't using rust.
- simjnd 2y ago
  The point is not the specific language, but the approach.
ndiddy 2y ago
Ladybird is getting migrated to Swift, not Rust. Andreas Kling goes over why he chose Swift here: https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031 and his views on Rust here: https://x.com/awesomekling/status/1822241531501162806 https://x.com/awesomekling/status/1822241531501162806
- LeFantome 2y ago
  It is intended to be migrated. Nothing has been done in Swift yet. Ladybird is all C++ though a somewhat unique dialect of it. Servo is a browser engine written in Rust.
- simjnd 2y ago
  The point is not the specific language, but the approach. The split from Serenity OS (and its "C++ only, no external dependencies" approach) made Ladybird a lot more attractive for both funding and potential contributors.
- andrewchambers 2y ago
  I am well aware, the point is that ladybird is a new project following some standards and they are free to use a memory safe language now.

PoignardAzur 2y ago

Someone in a sub-thread accused Drew of being incurious, and reading the article, I kind of agree. It's a very polite, high-effort, superficially humble piece of writing, that nevertheless boils down to "You guys should probably leave us alone and work on stuff we don't need to worry about". Now, working on a Linux fork as a "proof of value" thing could be interesting, but it also means that this hypothetical Linust project would be stuck forever chasing Linux's API decisions without any power to influence them (and, if recent history is any indication, quite a lot of hostility from OG Linux maintainers). I can't help but notice that Drew's plan doesn't include any exit strategy, any point where the projects merge or Linux starts taking components from Linust or something. Maybe Drew thinks that forever being stuck between shadowing a concurrent project's API and trying to convince its billion users to switch to yours instead is an attractive prospect. If I was a Rust-on-Linux developer, I'd find that patronizing.

unclad5968 2y ago
Just seems pragmatic to me. The people contributing rust to Linux are having a bad time so the advice is to do something else. It sucks I guess but it's no different than any other open source project. "Fine I'll do it myself" is a story basically as old as time. - Walt Disney - Ferruccio Lamborghini - King Henry VIII - Juan Pujol Garcia I doubt Drew has the power to serious change the culture among Linux kernal contributors and maintainers, so he's just offering advice.
- snvzz 2y ago
  The elephant in the room, which is Linux's untenable complexity and lack of internal APIs (even for drivers), is not addressed. Doing anything on Linux is many times as hard as doing it on systems that put a strong emphasis on structure. This is true not just for microkernel, multiserver systems, but for other unices/unix-like such as the BSDs (which put far more emphasis on structure relative to Linux) as well. Thus, I agree entirely with Drew, with extra reasons, that we (developers in general, not specific to rust) should try and put some effort elsewhere than Linux. It doesn't have to be Linux. It isn't the end-all in operating systems. It's just what happens to be most popular -right now-.

JackSlateur 2y ago

The counter has started. I am looking forward that drop-in kernel, that could replace Linux on all my production systems "has-is". This sounds very easy. Very.

e-dant 2y ago

I must be missing something obvious. I’m not aware of any too-frequent toxicity in the rust lkml. Just seems like a lot of groundwork is still being laid, without much even having been started. The article makes it seem like things are actually being rewritten in rust. Are they?

e-dant 2y ago
Oh, I started searching for some hot topics in the rust lkml, ouch, there’s some bad stuff in there. Linus seems reasonable in comparison…
MBCook 2y ago
I’m not sure it’s rewritten so much as new code. But it sounds like it’s been taking a very long time (year+) to merge even smaller things like structure definitions Rust developers need, let alone “real” code.

alphazard 2y ago

I don't see why it's so important to rewrite parts of the kernel in rust, or why Drew is so sympathetic to the cause. The linux project uses static analysis tools which provide some of what rust guarantees (outside of unsafe). The language isn't the problem, it's the architecture. In Linux, all of the drivers run with the rest of the kernel. A bad driver can take down the whole thing, or perform arbitrary badness. In Drew's own Helios microkernel, the architecture is right, and it's ready to have folks start piling on drivers in user-space. Those drivers can be written in pretty much any low level language that can produce ELF binaries. It's surely a better path forward to slap a Linux syscall API on top of Helios + some new drivers than to clone the whole linux system architecture in another programming language. At least then, we would have gained something tangible (drivers can't ruin the kernel). Instead of having another Linux written in a different language, with all the same design flaws.

kvemkon 2y ago
Do we get also realtime (10ths us latency) out-of-the-box, where badly written drivers cannot negatively interfere good ones?
- snvzz 2y ago
  To get to that point (mixed criticality, some processes and drivers can be critical and others not be), you need to be able to reason about time. That's exclusively seL4 right now, and the very state of the art. (incidentally, we really should be putting our weight behind seL4, it really is good)
iknowstuff 2y ago
gtm strategy trumps nerdy perfectionism. Linux is successful because of its timing and probably accidental social engineering - regularly breaking out-of-tree drivers incentivized upstreaming hardware support. Doesn't matter how good an alternative would be on technical merits, there's too much momentum behind Linux. Except maybe a fork where oxidation proceeds much faster, sponsored by a large corporation with bespoke hardware they can develop for and interest in security. Cloud OS-es or Android maybe.

h_tbob 2y ago

Could not agree more. I think there’s a parable in the Bible about this one: No one puts new wine into old wineskins; or else the new wine will burst the wineskins and be spilled, and the wineskins will be ruined. But new wine must be put into new wineskins, and both are preserved. He was specifically talking about bringing new paradigms to an old system. Sometimes, it’s just easier to start over. It has been my experience in programming that starting over almost always yields better results, but it does take time. That’s why apples m1 was so successful. They took the time to rebuild just for apple. But it was 100% worth it.

cryptonector 2y ago

> Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. The BSDs, Solaris/Illumos, and Windows all have tried, some more than once even. I think there have been at least 4 Linux kernel ABI compatibility layers for those OSes. They've all failed. And all future attempts will fail too for the same reason: The Linux kernel ABI is not specified anywhere, and it's insanely large (and growing). Besides the system calls (easy), many ioctls (hmmm), proc(4) (oof), and many ioctl-like ABIs within ABIs, there's loads of driver-specific ABIs and things like security modules and what not that add their own ABIs and which you'll invariably end up having to support. The last effort in Illumos land foundered on proc(4), IIRC. To top it all off that undefined (but stable) ABI is a moving target: it's always evolving / getting extended. The only thing you have to help you is that whatever the ABI, Linux [mostly] commits to maintaining backwards compatibility with it. If your compatibility ever gets good enough, that will help you, but in the meantime you'll be chasing a never ending and ever growing ill-defined ABI. Good luck with that!

HaroldCindy 2y ago
There's at least one more to add to the pile, Google's Fuchsia is primarily written in Rust and aims to support the Linux ABI through "starnix". See https://fuchsia.dev/fuchsia-src/concepts/components/v2/starnix https://fuchsia.dev/fuchsia-src/concepts/components/v2/starn... and https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/starnix/ https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
- plus 2y ago
  Fuchsia is written in C++, not Rust.
  - surajrmal 2y ago
    It's half-half. The kernel is c++, but it is small relative to the overall OS which is predominantly use space. Growth in rust far outpaces c++ so in a few years c++ will likely be a much smaller fraction. Also, notably, starnix is entirely written in rust.

goatmanbah 2y ago

These arguments are pointless because in a few years you can have your AI of choice translate Linux to your language of choice. The real question is will you even bother to do it? Will it matter at that point?

lolnowtf 2y ago

[flagged]

fizlebit 2y ago

https://youtu.be/kQcIV5389Ps?si=9Lixq3OUYxaei7s4 https://youtu.be/kQcIV5389Ps?si=9Lixq3OUYxaei7s4

fizlebit 2y ago
From the Linux conference video I watched I think they have the wrong approach. They’re trying to improve a bad api by adding types do describe it’s awkward behavior. The C programmers who love the Linux style want to be able to change semantics or api without modifying rust code. The solution is straight forward, build an adapter later in C that has well describable and clean semantics. Since it is C and in the kernel and has clear semantics the C programmers can maintain it without having to look at Rust. Perhaps the general lack of encapsulation and layers in the kernel will defeat them as they will need a lot of adapter layers. But for file systems it might be achievable.

nurettin 2y ago

Cygwin is a compatibility layer between linux syscalls and windows. And that is all userspace. So if you somehow implement everything in there plus the raw kernel functions, maybe there is a chance I think.

lmz 2y ago
Cygwin requires recompiling.
- _nalply 2y ago
  Care to explain a little bit more? In which cases recompiling is required? Do you agree that Cygwin is a moderately successful reimplementation of a part of Linux? If you agree then I wonder how recompiling affects that Cygwin is a (partial) reimplementation?
  - drewdevault 2y ago
    Cygwin is a POSIX implementation, not a Linux implementation. Linux is mostly POSIX compatible and so Cygwin is source-compatible, but not binary-compatible, with many programs that work on Linux.
    - deleted 2y ago
      [deleted]
  - lmz 2y ago
    What the other guy said. Cygwin is a set of libraries to compile and run GNU programs on Windows. It does not run existing Linux binaries and definitely does not translate Linux syscalls into Windows (that would be WSL v1). If recompiling is OK, I suggest starting with one of the BSDs, at least they have a fork() that works.
- nurettin 2y ago
  What I meant is that it can be used as a checklist of what to do, since so many linux programs can be built against it and it has been around for more than two decades.

tptacek 2y ago

This is an interesting take. Has DeVault done a lot of Linux kernel development?

criticalfault 2y ago
No. He himself said it here. https://fosstodon.org/@drewdevault/113052127771211132 https://fosstodon.org/@drewdevault/113052127771211132 What he did though, he developed a Unix clone using hare in roughly 30 days. https://fosstodon.org/@drewdevault/112319697309218275 https://fosstodon.org/@drewdevault/112319697309218275
- daghamm 2y ago
  Probably a significant number of HN readers have done something like this at one point. IIRC there is a MIT course where you do a modern Unix clone in one semester. There is an ocean between that and being an expert in Linux internals. Oh, and the original UNIX was done in one week by one guy.
  - drewdevault 2y ago
    I have not contributed much to Linux -- my claim to fame is submitting a one-line patch which generated 50+ emails of arguments from LKML before Linus merged it -- but I have read a ton of the Linux source code and familiarized myself with many of its internals many times, as well as doing extensive low-level systems work in userspace against the Linux API/ABI. I often use it as a reference in my own osdev work, or working on Hare, etc. Have read a lot of the syscall API surface, DRM internals in depth, dcache and several filesystem implementations, io_uring, etc. Not ignorant to what would be involved in making a Linux-compatible kernel.
  - criticalfault 2y ago
    Nobody said he is an expert in Linux internals. What this brings to light is the ability to compare Helios (microkernel) and Unix clone development, or how it was said in the post: reimplementing already existing design vs designing something new. Because of this, I think his statements carry some weight.

keybored 2y ago

> Two years ago, seeing the Rust-for-Linux project starting to get the ball rolling, I wrote “Does Rust belong in the Linux kernel?”, penning a conclusion consistent with Betteridge’s law of headlines. Two years on we have a lot of experience to draw on to see how Rust-for-Linux is actually playing out, and I’d like to renew my thoughts with some hindsight – and more compassion. If you’re one of the Rust-for-Linux participants burned out or burning out on this project, I want to help. Burnout sucks – I’ve been there. Now this compassionate revisit offers the same conclusion: don’t do Rust in Linux. This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1] The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here. The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. But what if you cared about working on the Linux Kernel specifically? What if you cared about the code in the Linux Kernel itself, its long term health… hush, hush now. You are burned out and don’t know what you are saying. The penultimate paragraph then declares that the Rust-for-Linux project itself is “burned out” (“and that’s awful”). Who needs enemies with compassionate friends like this. [1] How often do we read about maintainers suffering burnout? Every day? Do we then declare that the project is a failure, even when there are other maintainers left on the project?

IshKebab 2y ago
> resigning because of burnout It wasn't even because of burnout.
drewdevault 2y ago
>This person read that email about one Rust Kernel developer resigning because of burnout. Now he goes into how the Linux project is a “burnout machine” and how his heart goes out to the “developers who have been burned” (how did we get to plural?).[1] There are several Rust-for-Linux folks who have complained about the same things and been at various levels of burned out over the course of the project. Ignoring them because it raises uncomfortable questions regarding the viability of the project doesn't make it go away, it just erases their experiences. >The “so where do we go now?” almost gets ahead of itself before it says in the next paragraph that “the path is theirs to choose”. Well yeah because the only person who implied there was a crossroads is the author here. >The predictable conclusion is to abandon the project and do something adjacent to the Linux Kernel. This article is in response to someone who already decided to abandon the project, and to suggest what's next. I didn't impose the conclusion to abandon it on anyone, and in fact I explicitly supported it if burnout victims choose to return to the fold. Yes, I stand by the conclusion that Rust-for-Linux is probably not a great idea, and I'm allowed to say that without being anyone's "enemy". I also believe people when they say they're burned out and quitting the project and take their needs seriously, something I think is missing from your comment. All of this is compatible with compassion. I'm not and have never been your enemy: I can say that I think it's not a good idea and wish you well in your efforts nevertheless, and I have.

daghamm 2y ago

I think he is wrong on two accounts: 1. While the Linux guy mentioned here is not a great politician and his rant was pathetic, his technical argument was sane. You can put months into creating the perfect data model for your Rust implementation but Linux have a habit of completely changing things every year or so. That would make Rust the bottleneck of Linux development 2. These "hugely talanted" Rust devs are competing with ten times more talented Linux devs on their home turf. My point is, stop creating drama. This task requires hard work and compromises.

Klonoar 2y ago
Stop contributing to the drama with the “ten times more talented” comment. You have no way of measuring such a thing and are just fanning the flames.
surajrmal 2y ago
Linux devs and rust devs aren't two opposing groups. There exists major pockets within Linux community who embrace rust. That doesn't mean they turned in their Linux dev cards.

_zagj 2y ago

The reddit threads on this subject were interesting, with hundreds of comments in r/programming and r/linux all bemoaning the lack of Rust adoption in the kernel and the supposed mistreatment of the Rust maintainers. Are these people just users with a strong opinion about what language their kernel uses? If they're Rust devs and reflective of how popular Rust is in general, where are all of the killer apps written in Rust? Why do Rust programmers seem to mostly just produce partial, feature-incomplete rewrites of Unix utilities?

IshKebab 2y ago
> where are all of the killer apps written in Rust What like Ripgrep, uv, Rustdesk, Deno, Tauri, Zed, Meillisearch, Typst, Nushell...?
- steveklabnik 2y ago
  Your parent is also ignoring the tens of millions of lines of Rust that powers products from many massive tech companies, like Amazon, Meta, Cloudflare, and many many more.

kranuck 2y ago

[flagged]