I've recently been pretty interested in operating systems. I was wondering if it were possible (and feasible) to develop a Linux distribution through Rust.
Most Linux distributions are curated collections of software written by others. So when you say "develop a Linux distribution", is that what you're talking about, or do you mean develop a new POSIX-like OS from scratch?
For the former, I don't think rust has all that much to add since most of developing such a curated collection doesn't involve software development per se, and more things like packaging, writing and maintaining documentation, hosting infrastructure etc.
For the 2nd category, have a look at RedoxOS.
2 Likes
If you mean changing GNU/Linux to Rust/Linux, see GitHub - uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils
3 Likes
I take this to mean a Linux kernel bundled with whatever user space programs, libraries, etc to make it a useful operating system of some kind. Perhaps with a package manager or some system building tool to construct it.
Linux is of course written in C so that dictates one needs a C compiler, linker and other tools included. That straight away gets one into a largely C/C++ based distribution.
Thanks kornel for the heads up on the Rust core utils. Very interesting. So with that we likely get to a minimal command line driven operating system using components written in Rust.
Of course Rust depends on LLVM, which is written in C++ so we have even more C/C++ creeping into our Rust Linux distro.
I imagine we are far away from having a graphical environment in Rust on top of Linux.
We could remove the requirement that our distro can build itself. Just put a compiled kernel and whatever programs we need on a boot image and use that. As we do when building embedded Linux systems.In that case I suspect we stand a good chance of everything being Rust except the kernel itself. Which I would find interesting for many applications.
There's no C++ in Linux per se, so you don't need to touch a C++ compiler if you don't want to.
There is no C++ involved here, either. Unless you are trying to build the Rust compiler from source, the pre-built distribution doesn't require you to compile (let alone write) any C++. The amount of "C" you inevitably need to interact with is restricted to whatever set of system APIs Rust needs to be productive (likely just POSIX libc on Linux). And even that is more of an interface question, since that happens to be how OSes specify their APIs for hystorical reasons. Rustc doesn't care whether libc was written in C or assembler or C++ or FORTRAN.
Given these circumstances, and the fact that just about any non-C systems programming language needs to understand APIs and ABIs in terms of C, I think it would be quite unfair to state that this is "C creep". It's not like it could be avoided unless you are willing to convince Mr. Torvalds and the entire POSIX standards committee to switch to Rust or specify POSIX/Linux APIs in terms of a Better, Universal, Pure, Abstract Language. And unless you are actually writing/using bindings to C libraries, you won't need to write a line of C yourself.
I agree, if the distribution you want to create is provided as precompiled binaries and libraries then one will not need a C++ (or even C perhaps) compiler in the distribution.
Although I would hope a distribution provides for a Rust compiler so that I can use the distribution itself to create Rust programs.
On the other hand if ones aim is to create a distribution that can build itself, reproduce itself, like say Debian, then one will need to include a C/C++ compiler to do so.
I'm not clear on what the aim of our OP is exactly.
The kernel is primarily C, but contains many languages, and Rust is looking to make a little progress there.
For an entire distro:
C, yes.
C++ is a relatively minor component by comparison.
There's also perl, python, lots of shell scripting, awk, bison and others.
For a functional linux distro (console only, no X11) roughly 80-100 distinct packages are needed, varying somewhat based on need and personal preferences. Of these maybe half a dozen use C++.
Representing Rust, there is the afforementioned coreutils project and impressively it has reached a point where you can run a Debian system using it. But that is just one package. Although there are Rust based bootloaders, vi replacements, shells, X Window Managers, and Xterm replacements, there are many components that do not have a Rust substitute.
A rough guess is that you might be able to substitute 10% to 15% of the packages with Rust replacements. But some of the remaining ones are doozies, like cryptsetup, binutils, gcc, and bash (you can replace the shell for normal usage, but many packages will likely only build properly with bash scripting).
No, I haven't looked at this in any detail. LOL
Perhaps C++ is a relatively minor component. My point was though that as soon as you require a "self hosting" distribution, one that can rebuild itself, you need a C++ compiler to rebuild GCC and/or Clang/LLVM and all their source codes. It's huge.
On the other hand a very minimalist distribution, provided as collection of pre-compiled binaries can be very small and would not require those compilers.
Anyone remember Tom's Boot Root system? A Linux bistro on only two floppy disks that could be used for recovery operations and such.
In the extreme one could imagine a Linux distro that only contained a boot loader, a kernel and a single application that gets started at boot.
There are a lot of people that will never take "can't" for an answer. Eventually, I don't know how long, those ironclad parts of the toolchain will rust.
That sounds heavenly. I always have this feeling that a "proper" programming language should have a compiler written in itself. No other languages as crutches.
I don't mean to pour cold water on you, but if it does so, we will all be old people at the very least before it comes to pass I think.
That is to say, of course people will be working on it, but there are 10s (maybe 100s) of millions of lines of C/C++ spread out over most current packages.
The main exception I can think of is if we actually manage to get to AGI and by means of that manage to automate programming. But if that actually comes to pass, will we be needing any rust tooling by then? 
This is a common sentiment amongst compiler writers 
But unfortunately there is no such thing as a free lunch. By the time all of those projects are fully oxidized (just LLVM alone is 6+MSLOC), there's a fair chance Rust's successor will have popped up¹, which just iterates one step w.r.t. the current situation.
Of course that one iteration will still have made an absolutely massive difference to people everywhere.
¹ Almost definitionally, this means it will be able to do things Rust not only can't do, but is unable to grow due to technical limitations or design decisions, and yet are deemed so valuable that it's worth trying to replace Rust for some set of use cases. Examples like fully dependent types comes to mind, or if we collectively decide that we're ready to rock and roll with explicitly encoded Monads (or something that lowers to Monads) by then except in a language with a borrow checker.
1 Like
Something like this?
Rust code will be included in the Linux kernel beginning from v6.1 so yes. 
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.