Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

251–260 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#251
post #54

Earlier quoted context omitted.

Can you expound in this some? I am not fully grasping your point. Are you saying "building safe by default" is a bad thing or assuming "safe forever" is a bad thing. Or are you saying something entirely different?

I expect it's likely more of "memory safety in a language doesn't make it _safe_, it makes it less vulnerable". It removes _some_ issues, in the same way that a language with static types removes some ways a program can be wrong, it doesn't make it correct.

The problem is the word "safe," which is inherently ambiguous. Safe from what? A better term would be "correct," because at least that implies there is some spec to which the developer expects the program to conform (assuming the spec itself is "correct" and devoid of design flaws).

Re: Maestro: A Linux-compatible kernel in Rust

#252

Earlier quoted context omitted.

I am not quite sure this discussion applies to this project: "Linux-compatible" and "Unix-like" seems to mean "a POSIX-like kernel" rather than being a direct rewrite of the Linux kernel. The Rust rewrite of coreutils is more problematic because it advertises itself as a drop-in replacement and they are going for complete binary compatibility. I don't think Maestro is actually going for kernel compatibility with Linu…

If I understand this project correctly it's going for syscall compatibility, and can run some subset of Linux binaries already. Which is cool, but... In any case, I wish the author luck, and it'd be cool if it went somewhere, but I am disappointed by the choice of license. But that's up to them, in the end.

While I disagree with you about licenses (I prefer permissive licenses as they grant more freedom), I at least give you kudos for having the good grace to not shit on the author for using a license model other than what you prefer. So many people in this thread are displaying a truly remarkable level of rudeness about the license when it is (as you said) the author's right to decide what he wants to use.

Re: Maestro: A Linux-compatible kernel in Rust

#253
post #249

Earlier quoted context omitted.

Or Redox OS, which is still there: https://www.redox-os.org/ . It has a micro kernel design. But it is a bit more mature probably. And also MIT licensed so, there probably is some opportunity for code sharing.

Seems that the project is dead. The repository does not receive any commit for two years.

No its not. See: https://gitlab.redox-os.org/redox-os/redox/

https://www.redox-os.org/news/development-priorities-2023-09...

Re: Maestro: A Linux-compatible kernel in Rust

#254

Earlier quoted context omitted.

Drivers are the tough part and the lack of a stable interface in Linux makes them hard to reuse.

People who want stable interfaces should not touch anything Linux with a ten-foot pole.

That's only in terms of the driver interface, right? My understanding is that the userspace interface is extremely stable.

Re: Maestro: A Linux-compatible kernel in Rust

#255
post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

[deleted]

Re: Maestro: A Linux-compatible kernel in Rust

#256
post #82

Some words of encouragement in the sea of pessimism on HN which brought down the previous attempt at this [0]. Keep going, ignore the FUD and continue where others have left off. We need alternative and safer kernels, and attempts like this should be encouraged. Rust is suitable for that guarantee. Keep going. [0] https://news.ycombinator.com/item?id=28986377

[deleted]

Re: Maestro: A Linux-compatible kernel in Rust

#257
post #122

Earlier quoted context omitted.

People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", bec…

I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.

> "If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN."

It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.

Re: Maestro: A Linux-compatible kernel in Rust

#258

What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. However, my guess is that the ones that are missing are the more complicated ones. The TTY layer, for example, looks rather basic at the moment. Getting this right will probably be a lot of work. So don't hold your breath for Maestro running your Linux applications in the next 3 years or so…

>It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. It's a great project, but I don't find this ratio surprising at all. Any mature platform builds up logic to enable scenarios such that most things don't need most of the system. As the saying goes, no one uses more than 10% of Excel, but it's a different 10% for everyone. You could implement 30% of Excel functions and…

> You could implement 30% of Excel functions and probably have an engine which opens 99% of spreadsheets out there.....though if you wanted full doc compatibility you would still have a long journey ahead of you.

Isn't this what effectively googles docs did? For a ton of use-cases google sheets is enough, I've heard of companies that basically were extra stringent about excel licenses (as a cost cutting measure no doubt), instead heavily pushing users toward using google sheets instead.

Re: Maestro: A Linux-compatible kernel in Rust

#259

Earlier quoted context omitted.

I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.

> " If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN. " It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, t…

Again, this is wrong, actually a lie in regards of what I have been saying on this thrtead. I have been giving my opinion and explaining all along in all parts of this threads my views and opinions.

This is so bluntly disregading everything, I think you may very probably be a AI bot with a very small context window.

Re: Maestro: A Linux-compatible kernel in Rust

#260

So many thank to all of you for your support! This project has represented a lot of efforts for me and it means a lot! Right now the website seems to be pretty slow/down. There is a lot of traffic, which was not expected. I also suspect there might be a DoS attack going on. I will try to make it work better when I get home! (I am currently at work so I cannot give much attention to it right now) Sorry for the inconve…

Please test your website on mobile. The navbar takes like 33% screen state and can't be removed. I never understand why people want to make them sticky and steal valuable reading screen space. You can, if you want, always scroll to the top in like 300 ms.

75% zoom alleviated most of the ux issues I had
Post reply on HN