TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rust in Linux Revisited

162 点作者 Munksgaard9 个月前

21 条评论

alphazard9 个月前
I don&#x27;t see why it&#x27;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).<p>The language isn&#x27;t the problem, it&#x27;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.<p>In Drew&#x27;s own Helios microkernel, the architecture is right, and it&#x27;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.<p>It&#x27;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&#x27;t ruin the kernel). Instead of having another Linux written in a different language, with all the same design flaws.
评论 #41406177 未加载
评论 #41408486 未加载
评论 #41406208 未加载
评论 #41407075 未加载
评论 #41405938 未加载
评论 #41405916 未加载
评论 #41410435 未加载
cryptonector9 个月前
&gt; 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.<p>The BSDs, Solaris&#x2F;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&#x27;ve all failed. And all future attempts will fail too for the same reason:<p><pre><code> The Linux kernel ABI is not specified anywhere, and it&#x27;s insanely large (and growing). </code></pre> Besides the system calls (easy), many ioctls (hmmm), proc(4) (oof), and many ioctl-like ABIs within ABIs, there&#x27;s loads of driver-specific ABIs and things like security modules and what not that add their own ABIs and which you&#x27;ll invariably end up having to support. The last effort in Illumos land foundered on proc(4), IIRC.<p>To top it all off that undefined (but stable) ABI is a moving target: it&#x27;s always evolving &#x2F; getting extended.<p>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&#x27;ll be chasing a never ending and ever growing ill-defined ABI.<p>Good luck with that!
评论 #41406107 未加载
评论 #41407528 未加载
yshui9 个月前
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.<p>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&#x27;t at that position yet.
评论 #41405882 未加载
评论 #41406455 未加载
capitainenemo9 个月前
Duplicate of <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41400493">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41400493</a>
tredre39 个月前
&gt; 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.<p>Rust is many things, but devoid of political drama it is not.
评论 #41405470 未加载
评论 #41407057 未加载
评论 #41406091 未加载
评论 #41405379 未加载
PoignardAzur9 个月前
Someone in a sub-thread accused Drew of being incurious, and reading the article, I kind of agree.<p>It&#x27;s a very polite, high-effort, superficially humble piece of writing, that nevertheless boils down to &quot;You guys should probably leave us alone and work on stuff we don&#x27;t need to worry about&quot;.<p>Now, working on a Linux fork as a &quot;proof of value&quot; thing could be interesting, but it also means that this hypothetical Linust project would be stuck forever chasing Linux&#x27;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).<p>I can&#x27;t help but notice that Drew&#x27;s plan doesn&#x27;t include any exit strategy, any point where the projects merge or Linux starts taking components from Linust or something.<p>Maybe Drew thinks that forever being stuck between shadowing a concurrent project&#x27;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&#x27;d find that patronizing.
评论 #41407290 未加载
评论 #41405870 未加载
评论 #41407081 未加载
raggi9 个月前
There&#x27;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 &quot;assuming you have an army of people with specifications, this won&#x27;t be a problem&quot;, but that assumption is crazy. Fuchsia is a real OS effort funded by Google (at varying levels of funding through it&#x27;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&#x27;t provide docs or assistance, even for serious efforts, they demand money first - they&#x27;re literally holding the software world hostage with this activity.<p>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 &#x2F; people &amp; companies having different attitudes than they do. I&#x27;d love to see something like Redox prove me wrong, but real world experience suggests that&#x27;s extremely unlikely. RISCv is the one thing in flight that might &quot;change the shape of the world&quot; enough to alter this, but RISCv comes with it&#x27;s own stack of long challenges to overcome to meet the originally stated goal of broadly and practically usable.<p>Writing a core kernel and usable userspace isn&#x27;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.
评论 #41409877 未加载
评论 #41466309 未加载
评论 #41405537 未加载
keybored9 个月前
&gt; 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.<p>Now this compassionate revisit offers the same conclusion: don’t do Rust in Linux.<p>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]<p>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.<p>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.<p>The penultimate paragraph then declares that the Rust-for-Linux project itself is “burned out” (“and that’s awful”).<p>Who needs enemies with compassionate friends like this.<p>[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?
评论 #41407170 未加载
评论 #41466317 未加载
e-dant9 个月前
I must be missing something obvious. I’m not aware of any too-frequent toxicity in the rust lkml.<p>Just seems like a lot of groundwork is still being laid, without much even having been started.<p>The article makes it seem like things are actually being rewritten in rust.<p>Are they?
评论 #41405616 未加载
评论 #41406391 未加载
anonnon9 个月前
The reddit threads on this subject were interesting, with hundreds of comments in r&#x2F;programming and r&#x2F;linux all bemoaning the lack of Rust adoption in the kernel and the supposed mistreatment of the Rust maintainers.<p>Are these people just users with a strong opinion about what language their kernel uses? If they&#x27;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?
评论 #41466370 未加载
a-dub9 个月前
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?
评论 #41405632 未加载
评论 #41405482 未加载
评论 #41406964 未加载
评论 #41406746 未加载
评论 #41409624 未加载
nurettin9 个月前
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.
评论 #41406906 未加载
h_tbob9 个月前
Could not agree more.<p>I think there’s a parable in the Bible about this one:<p>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.<p>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.<p>That’s why apples m1 was so successful. They took the time to rebuild just for apple. But it was 100% worth it.
JackSlateur9 个月前
The counter has started. I am looking forward that drop-in kernel, that could replace Linux on all my production systems &quot;has-is&quot;.<p>This sounds very easy. Very.
tptacek9 个月前
This is an interesting take. Has DeVault done a lot of Linux kernel development?
评论 #41406974 未加载
troad9 个月前
TLDR: In response to the recent resignation of Rust-for-Linux&#x27;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).<p>It&#x27;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 <i>and</i> the Rust evangelism brigades happy (by keeping them apart). And it&#x27;s a great proving ground for Rust&#x27;s claims - assuming licence compatibility, successful rewrites of individual components could be lifted by Linux down the line.<p>[0] <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;987635&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;987635&#x2F;</a>
评论 #41403688 未加载
fijiaarone8 个月前
I expect the result of Filho&#x27;s tantrum will be the ouster of Ted Tso from the Linux kernel.
daghamm9 个月前
I think he is wrong on two accounts:<p>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<p>2. These &quot;hugely talanted&quot; Rust devs are competing with ten times more talented Linux devs on their home turf.<p>My point is, stop creating drama. This task requires hard work and compromises.
评论 #41407749 未加载
评论 #41410417 未加载
goatmanbah9 个月前
These arguments are pointless because in a few years you can have your AI of choice translate Linux to your language of choice.<p>The real question is will you even bother to do it? Will it matter at that point?
fizlebit9 个月前
<a href="https:&#x2F;&#x2F;youtu.be&#x2F;kQcIV5389Ps?si=9Lixq3OUYxaei7s4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;kQcIV5389Ps?si=9Lixq3OUYxaei7s4</a>
评论 #41410240 未加载
andrewchambers9 个月前
It&#x27;s more or less working for ladybird browser, could work for a kernel.
评论 #41406365 未加载
评论 #41405775 未加载