Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for Filesystems

lwn.net

Post reply on HN
Print view View original

71–80 of 206 posts

Re: Rust for Filesystems

#71

Post by [deleted] »

another2another wrote: post #30
vollbrecht wrote: post #8

Earlier quoted context omitted.

One can argue that any additional code is introducing complexity, not only writing Rust. Does that mean we should just stop innovating and go into an indefinite state of maintenance, since we are already so vast? A tax in one place may not be a net negative, if it's used like in the real world to offset other problems. And just saying it will not offset any problems because of a single discussion, that does not have…

>Does that mean we should just stop innovating and go into an indefinite state of maintenance If you mean that not using Rust (or maybe some other languages e.g. Zig or Ada?) means that there can be no innovation in the Linux kernel, I would have to disagree since there's been plenty of progress in plain old c (see for instance io_uring), not to mention the fact that the c language itself could change to make develop…

[deleted]

Re: Rust for Filesystems

#72

Post by [deleted] »

olivermuty wrote: post #20
eru wrote: post #14

Earlier quoted context omitted.

Alas, that link just gets you a rant about politics, if you click on it directly. Copy-and-pasting works.

"Rant about politics", haha. Or as other people like to call it: "A real concern described in an apt manner". I have observed these inflammatory sub-graphs of comments myself and have thought to myself that this must be a huge growing grounds for unmoderated and unwanted behaviour because it more or less becomes invisible once flagged enough.

[deleted]

Re: Rust for Filesystems

#73

Post by pornel »

I don't get how can each file system have a custom lifecycle for inodes, but still use the same functions for inode lifecycle management, but apparently with different semantics? That sounds like the opposite of an abstraction layer, if the same function must be used in different ways depending on implementation details.

If the lifecycle of inodes is filesystem-specific, it should be managed via filesystem-specific functions.

Re: Rust for Filesystems

#74

Post by pessimizer »

pjc50 wrote: post #39
erdii wrote: post #37

Earlier quoted context omitted.

In this specific case complaining about "politics" gets the sour by-taste of enabling (or at least not condoning) harrasment to the point of single folks taking their own lifes over it. Why?! Even if you're not sure what to think about the queer movement; even if you have already made up your mind about the queer movement and oppose their ideas or some of them; I refuse to believe that any single person would not wan…

> I refuse to believe that any single person would not want to stop someone from bullying someone else into their own suicide! There are plenty of people who do want the freedom to say exactly what they choose, including a lengthy period of directed harassment, and shrug their shoulders if someone commits suicide over it. There's not much that can be done other than ban them from civilized spaces.

"Bullying" is a judgement. Intrinsic to the word is a judgement that what is being done is bad, and the person doing it would not describe it that way.

And by that I don't mean that it's not bad to bully people (it's rather tautological), I mean that talk of bullying often begs the question, and is intentionally done in order to elide past the actual events that occurred. Lèse majesté laws against talking about the King, elected officials, or even cops or bureaucrats now get justified as anti-bullying.

I missed any rant about politics in the blog however. But this thread has a smell of "my politics aren't political because they are true, and your politics are political because they are lies."

Re: Rust for Filesystems

#75

Post by hu3 »

Some of the comments below the lwn.net page are rather disrespectful.

Imagine getting this comment about the open source project you contribute to:

"Science advances one funeral at a time"

Re: Rust for Filesystems

#76

Post by mjburgess »

pjc50 wrote: post #51
mjburgess wrote: post #42

Earlier quoted context omitted.

> That cannot scale. lol... you're talking about the linux kernel, written in C . The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc. The scale of the success of C is unparalleled.

The scale of C adoption is certainly unparalleled over the past 40 or so years, but so are the safety issues in the cyberwarfare era. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... If, somehow, we'd got to an era where (a) operating systems were widely deployed in a different language, and (b) the Morris Worm of 1988 had happened due to buffer overflow issues, then C in its current form would never h…

C is just convenient assembly. In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative.

C's choices were for performance on hardware-limited systems. I don't really see what other ones made sense historically.

Re: Rust for Filesystems

#77

Post by _flux »

tucnak wrote: post #50
rcxdude wrote: post #41

Earlier quoted context omitted.

The other person behind the proposal, is however a seasoned kernel developer, with >14 years of experience working in the FS subsystem of linux.

This is case-in-point; bcachefs maintainer is merely _entertaining_ the ideas proposed by the Rust evangelist, with the express intent of exploring alternatives... and suddenly it's enough for "the movement" to co-opt him into the "proposal" [to include Rust in the FS subsystem], it seeems. Are Rust supporters really as desperate so-as to co-opt ANY interest in the subject?? This toxicity is not helping anybody.

I'm not sure what you are saying. Maybe the first proposal isn't the best one, so some exploration is warranted.

Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered?

From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.

Re: Rust for Filesystems

#78

Post by gwbas1c »

Maybe they are asking the wrong questions?

Does Rust need to change to make it easier to call C?

I've done a bit of Rust, and (as a hobbyist,) it's still not clear (to me) how to interoperate with C. (I'm sure someone reading this has done it.) In contrast, in C++ and Objective C, all you need to do is include the right header and call the function. Swift lets you include Objective C files, and you can call C from them.

Maybe Rust as a language needs to bend a little in this case, instead of expecting the kernel developers to bend to the language?

Re: Rust for Filesystems

#79

Post by amiga386 »

aniviacat wrote: post #63
eru wrote: post #14

Earlier quoted context omitted.

Alas, that link just gets you a rant about politics, if you click on it directly. Copy-and-pasting works.

I can't find a rant in the link. Was the link changed or did I overlook something?

If you click the link - any link to asahilinux.org from HN - it should start "Hi! It looks like you might have come from Hacker News.", followed Hector Martin ranting that he isn't in charge of the moderation policy of HN.

The response given in Arkell v. Pressdram is appropriate.

Re: Rust for Filesystems

#80

Post by phkahler »

pornel wrote: post #73

I don't get how can each file system have a custom lifecycle for inodes, but still use the same functions for inode lifecycle management, but apparently with different semantics? That sounds like the opposite of an abstraction layer, if the same function must be used in different ways depending on implementation details. If the lifecycle of inodes is filesystem-specific, it should be managed via filesystem-specific f…

>> I don't get how can each file system have a custom lifecycle for inodes, but still use the same functions for inode lifecycle management, but apparently with different semantics?

I had the same question. They're trying to understand (or even document) all the C APIs in order to do the rust work. It sounds like collecting all that information might lead to some [WTFs and] refactoring so questions like this don't come up in the first place, and that would be a good thing.

Post reply on HN