4 ms·

Really? Why can't the C bits be replaced with e.g. Rust?

ganfortran 10y ago
Good Luck with your precious Rust to be compatible with your client's millions of lines of code. For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.
- bluejekyll 10y ago
  Writing Rust off as flashy is demeaning to the excellent work that has been going on in the Rust ecosystem to specifically address the area you mention with a safe language alternative.
  - ganfortran 10y ago
    That doesn't make the OP's claim of rewriting 100 million of lines of code with Rust and that would solve the whole problem, sounds less stupider.
jacquesm 10y ago
They could be. But you'd need a reason in order to be able to fund it (or maybe you just want to scratch an itch). But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements: - it really needs to be better in terms of bugs - it needs to be about as fast or faster - it would have to come with similar start-up times for the runtime - you'd need to find funding somewhere or convince people the need is so high they should volunteer their time For a single individual this is likely not a viable project, even doing just the basics (coreutils) would take you a couple of years at a minimum. What might be a better way is to reboot unix entirely starting from the kernel and working your way up into userland. There is plenty there that could use a more modern look at things, after all UNIX really is showing its age and LINUX is a re-implementation of something that was already old when it was started.
- peterwwillis 10y ago
  The Linux ecosystem was created with the userland already having being rewritten from scratch, by the GNU Project. Then a Finnish student came along and wrote a kernel. So you can probably start anywhere, but maybe starting with a working kernel would be better. Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years.
  - jacquesm 10y ago
    > Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years. Hm. I'm not sure I see the similarities there. plan9: small, elegant, really an improvement on Unix in many respects but unfortunately somewhat theoretical rather than practically oriented. Linux: bloated, blunt, practically oriented, gets the job done but it never feels like it's the shortest path.
pjmlp 10y ago
No because UNIX requires C semantics, so even if someone writes a UNIX like OS in Rust, Ada whatever language it might be, for compatibility with UNIX software it would require a POSIX API to be available. POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures. Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code. This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes. As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.
- mjw1007 10y ago
  There used to be POSIX standards for both Ada and Fortran as well a C (POSIX.5 and POSIX.12). Though I don't think they can be described as successful. If I remember right, the Fortran one was defined in terms of the C one, but the Ada one was written as if it was an independent specification. I suppose this was only possible because POSIX misses out a lot of the fiddlier bits of Unix anyway (and the Ada one specified a spawn to use instead of fork+exec).
  - pjmlp 10y ago
    Yes I remember those, but you still have the safety problem. Let's say how does one make memcpy() safe in Ada? The very first step of converting the pointers + length into an access type must trust the caller did the right thing.
- viraptor 10y ago
  I wouldn't say the OS requires unsafe POSIX compatibility. The whole system can be mostly unaware of POSIX if you can use the available APIs to create shims. Basically a wine equivalent - Linux didn't implement any windows APIs after all. So all the unsafe bits can exist only in the process which is based on them.

Good Luck with your precious Rust to be compatible with your client's millions of lines of code. For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.

bluejekyll 10y ago
Writing Rust off as flashy is demeaning to the excellent work that has been going on in the Rust ecosystem to specifically address the area you mention with a safe language alternative.
- ganfortran 10y ago
  That doesn't make the OP's claim of rewriting 100 million of lines of code with Rust and that would solve the whole problem, sounds less stupider.

jacquesm 10y ago

They could be. But you'd need a reason in order to be able to fund it (or maybe you just want to scratch an itch). But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements: - it really needs to be better in terms of bugs - it needs to be about as fast or faster - it would have to come with similar start-up times for the runtime - you'd need to find funding somewhere or convince people the need is so high they should volunteer their time For a single individual this is likely not a viable project, even doing just the basics (coreutils) would take you a couple of years at a minimum. What might be a better way is to reboot unix entirely starting from the kernel and working your way up into userland. There is plenty there that could use a more modern look at things, after all UNIX really is showing its age and LINUX is a re-implementation of something that was already old when it was started.

peterwwillis 10y ago
The Linux ecosystem was created with the userland already having being rewritten from scratch, by the GNU Project. Then a Finnish student came along and wrote a kernel. So you can probably start anywhere, but maybe starting with a working kernel would be better. Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years.
- jacquesm 10y ago
  > Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years. Hm. I'm not sure I see the similarities there. plan9: small, elegant, really an improvement on Unix in many respects but unfortunately somewhat theoretical rather than practically oriented. Linux: bloated, blunt, practically oriented, gets the job done but it never feels like it's the shortest path.

pjmlp 10y ago

No because UNIX requires C semantics, so even if someone writes a UNIX like OS in Rust, Ada whatever language it might be, for compatibility with UNIX software it would require a POSIX API to be available. POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures. Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code. This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes. As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.

mjw1007 10y ago
There used to be POSIX standards for both Ada and Fortran as well a C (POSIX.5 and POSIX.12). Though I don't think they can be described as successful. If I remember right, the Fortran one was defined in terms of the C one, but the Ada one was written as if it was an independent specification. I suppose this was only possible because POSIX misses out a lot of the fiddlier bits of Unix anyway (and the Ada one specified a spawn to use instead of fork+exec).
- pjmlp 10y ago
  Yes I remember those, but you still have the safety problem. Let's say how does one make memcpy() safe in Ada? The very first step of converting the pointers + length into an access type must trust the caller did the right thing.
viraptor 10y ago
I wouldn't say the OS requires unsafe POSIX compatibility. The whole system can be mostly unaware of POSIX if you can use the available APIs to create shims. Basically a wine equivalent - Linux didn't implement any windows APIs after all. So all the unsafe bits can exist only in the process which is based on them.