Comment by starspangled

I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS.

If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.

"In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd

I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.

Market failures of the other Unices aren't necessarily related to the technical advantages or disadvantages or symbiosis with C or being implemented in C. However, making C programmers' life easier was crucial.

Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.

C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.

OSX would like to disagree with you.

Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all.

As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.

The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.

Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.

[0]: https://lwn.net/Articles/978738/

Or may be Zig might be more acceptable to the Kernal team, once it becomes mature enough?

> there is no way to have a "half-secure" kernel.

There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.

In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).

Rust is used to make kernel drivers secure by providing a safe interface for them to use.

Of perfectly moderate Rust users get annoyed with C zealots?

I don't understand how this is related to what I said.

>. I don't know why, but either zealots choose rust or rust induces zealotry.

That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.

However that doesn't happen with Ada. So that cant be the full explanation.

To be fair, anything that does not support BWX is really painful to deal with.

Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:

        bic     a0, #3, t1
        and     a0, #3, t4
        ldl     t2, (t1)
        insbl   a1, t4, t3
        mskbl   t2, t4, t2
        bis     t2, t3, t2
        stl     t2, (t1)
        ret     zero, (ra)

But with BWX, it becomes:

        stb     a1, 0(a0)
        ret     zero, (ra)

I guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66).

I'm not sure if Alphas are even being made anymore, even 15-20 years ago.

M68k has the advantage that it has a fairly typical memory model.

Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)

And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.

Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.