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

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

321–330 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#321

Post by peoplefromibiza »

surajrmal wrote: post #248
ahmedfromtunis wrote: post #233

Earlier quoted context omitted.

From what I understood, I think the big difference here is the human factor: Windows and Android are maintained by employees, who have no choice but to work on things even if they don't like doing it. Linux on the other hand is a collective effort of people doing what they want to do on their free time.

That's a myth. Most Linux contributions come from paid employees from various companies not unpaid volunteers.

Half true, but getting stuff upstream it's not the same thing as your boss saying "the higher ups said so". Linux development still is a public forum.

Of course Redhat can put what they want into their distro, but there are a lot of choices beyond that.

Re: Maestro: A Linux-compatible kernel in Rust

#322

Post by PrimeMcFly »

thfuran wrote: post #188
baq wrote: post #153

Earlier quoted context omitted.

the file is inconsequential. it could be any other universal abstraction, e.g. HTTP POST. it's just something that every program running on a computer knows how to do, so why bother with special APIs you have to link against if you can just write to a file? (note you can still develop those layers if you wish, but you can also write a device driver in sh if you wish, because why not?)

>the file is inconsequential. it could be any other universal abstraction Bad abstractions are notoriously problematic, and no abstraction is fit for every purpose.

What are some ways the file abstraction has been problematic for Unix?

Re: Maestro: A Linux-compatible kernel in Rust

#323

Post by dean2432 »

PrimeMcFly wrote: post #303
sillywalk wrote: post #283

Earlier quoted context omitted.

For those who are wondering WTF is a Slashdot, and how does it effect websites. https://tech.slashdot.org/story/24/01/03/0017242/25-years-si... https://en.wikipedia.org/wiki/Slashdot_effect

Weird to think there are now people so young in these types of discussions that wouldn't know about Slashdot.

i used to browse slashdot on my amiga back in the late 90s with iBrowse. what glorious days!

Re: Maestro: A Linux-compatible kernel in Rust

#324

Post by sylware »

fl0ki wrote: post #285
sylware wrote: post #208

Earlier quoted context omitted.

This is where you are wrong: it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. Short term-ists won't understand as this is going for the long run, and that requires perspective of what happened in software in the last decades.

> it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. This is a bit of a stretch. Not one ISA has lived longer than C without making any changes whatsoevever, but I admit that this could at least be possible for some kinds of devices. What is utterly…

I do severely disagree. Something is different with RISC-V as this is a modern ISA and is not locked by some absurd PI in many places in the world like x86_64 and arm, not to mention it is seems the RISC-V guys are actually "doing it". Ofc, RISC-V can still fail as it needs extremely performant implementations all over the board (mobile/server/workstation/"embedded"), and will have to survive the mistakes of its big CPU vendors (usually accute micro-arch bugs).

About what you call "evolution" of computer languages, well after decades of coding, that "evolution" is to me mostly tantrums from developers and a scam: "planned obsolescence" and "developer locking" for the benefits of few vendors, that to justify permanent income. I now believe the people doing that are brain-washed, or actually really toxic people (a liability for humanity as a whole). Not to mention, those issues are exponentially boosted by language syntax complexity, with the worst being c++ and now rust. Of course, I did shape this opinion after decades of coding, this is will be alien to short term-ists or inexperienced people.

From this global perspective, I think the real way forward would not be to code a kernel in rust, but to code one in RISC-V, and I was voicing my disagrement here, on HN, even though the pro-rust/AI bots are performing accute karma slash only because I have different views on the matter and voicing it...

But some people made me think more about the issue of the computer language extremists a bit more, and now I am thinking RISC-V... as a computer language, namely with its "compiler" generating code for other ISA (not a JIT). I may have a look at that in the near future as RISC-V as a computer language should be much more resilient to syntax "planned obsolescence" and "vendor/developer lock-in for permanent income via compiler/syntax grotesque complexity". Hopefully, I did open the eyes of some non AI bots here, while providing some different paths of moving forward.

Re: Maestro: A Linux-compatible kernel in Rust

#325

Post by Anonbrit »

staunton wrote: post #278
kelvie wrote: post #258

Earlier quoted context omitted.

> 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 do…

No. Excel/Docs is user-facing. Most of the way is enough, people will figure out the edge cases or just give up on them. To be viable as an OS, you have to support applications. An application running on your OS won't go "well, I guess this syscall doesn't work. I'll try to go around it somehow"...

If you're writing your own libc, then you absolutely can work around a whole bunch of missing syscalls by emulating them in userspace

Re: Maestro: A Linux-compatible kernel in Rust

#326

Post by Anonbrit »

steveklabnik wrote: post #274
jvanderbot wrote: post #189

Earlier quoted context omitted.

It's not possible for me to say. Clearly you can only do worse in Rust than you'd have with perfect C. But what's that? The question is: what is the expected loss (time, bugs, exploits that lead to crashes or injury or death or financial catastrophe) with Rust vs other languages. Unfortunately that's not the conversation we have. We instead have absolutism re managed memory, which does account for about half of known…

> Clearly you can only do worse in Rust than you'd have with perfect C. Is this clear? Why would the best Rust be worse than the best C?

Rust has a few small but unavoidable runtime overheads compared to the best C (maybe they can be avoided with the right unsafe usage but that removed most of the benefits of rust). They are difficult to see the affect of without micro-benchmarking in my very limited experience, but C can avoid them

Re: Maestro: A Linux-compatible kernel in Rust

#327

Post by sylware »

MobiusHorizons wrote: post #229
sylware wrote: post #149

Earlier quoted context omitted.

RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.

I agree that rv64 is easier to write than x86_64. My point was more that earlier ISAs were designed with human authors as a target audience, and that results in differences that are arguably (subjective) easier to hand write. Modern load store architectures are cleaner, but also quite verbose. 6502 is probably more representative of my point than 32bit x86, and most things in the 64 bit era are more compiler focused.

Yep. And from a hard real coding perspective, you are right about verbosity of load and store ISA. Hence the importance of having multi-instruction per line assemblers. Because, without that, coders may be too much tempted to abuse the preprocessor. In RISC-V, some hardware instructions are kind of meant to be used as a group (hardware instruction fusion here we come!), then instead of creating a macro, you would cut and past that group of instructions, properly "isolated" on its line.

I say that, because currently I am coding some x86_64, with a intel syntax dialect I can assemble with several assemblers which are fasmg, gas, nasm/yasm. Some of them are not multi-instruction per line, and I am kind of glad this is only CISC x86_64 and not RISC-V :)

But the feeling of freedom I get with assembly coding, because being independent of those abominations (I am sorry, but the word is fair...) of compilers (gcc|clang/llvm) is a breath of fresh air. I still code very simple and plain C from time to time, avoiding IS O C tantrum and gcc extension though (and using tinycc, cproc/qbe, simple-cc/qbe C compilers).

BTW, thinking out of the box of using a compiler for classic high level and complex syntax languages made me thing about using RISC-V as a language with... its compiler. It "should" be much more resilient to all those pesky long term issues classic complex computer languages suffer from.

Maybe, this is actually the sane way forward.

Re: Maestro: A Linux-compatible kernel in Rust

#328

Post by sylware »

BatmanAoD wrote: post #311
sylware wrote: post #216

Earlier quoted context omitted.

The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the li…

So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?

This would not happen overnight!

It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software.

RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extremely performant implementations (micro-arch and silicium process), all over the board (server/mobile/workstation/"embedded") it will probably fail.

And I do believe we could get a very good middle ground with very high level language interpreters (python/lua/etc) directly coded in RISC-V assembly.

And I am thinking about RISC-V... as a computer language with some compilerS (not JIT). I may investigate how much out-of-the-box-thinking and disruptive this is, hopefully soon enough.

Re: Maestro: A Linux-compatible kernel in Rust

#329

Post by sylware »

fl0ki wrote: post #286
sylware wrote: post #145

Earlier quoted context omitted.

"Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in t…

> the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end) This is not the reason why. Indeed x86_64 has a much broader instruction & register baseline than i386 did, so the impact of per-CPU tuning is less than it used to be. But even a generic compiled Linux selects CPU instruction sets at runtime for things like hardware-accel…

This is not complete: I clearly stated in some scenarios we would still install specific code paths at runtime.

Nice try, but we do agree here ;)

Re: Maestro: A Linux-compatible kernel in Rust

#330

Post by peoplefromibiza »

peoplefromibiza wrote: post #319
bigstrat2003 wrote: post #291

Earlier quoted context omitted.

I genuinely have no idea what your point is.

If I am contributing to a community project, made by the people for the people, GPL protects my work from being stolen by corporations that pack it up and sell it for a price. GPL means you work on something and in return you get something from someone else that improved on your work, you can't keep any published change private. GPL also means that if someone forks the original source code and makes substantial chang…

EDIT:

BSD was 12 years old when Linus started Linux.

Post reply on HN