> I get the impression lots of folks would really like it if the actual C code making up linux stayed in place forever. Like it would be a good thing if humans exploring the cosmos in the year 3025 were still logging in using pam, written in C. And not just C, but the current lines of code we have right now.
What does that even mean? The kernel codebase isn't append-only. Things are constantly getting refactored and improved.
> lets never try and iterate and improve?
Isn't that what the linked project, Fil-C is doing? Iterating and delivering an (extremely overdue) improvement to the language infrastructure—one of the most fundamental parts of the systems we use?
> C is the best at things[…] C is fast and efficient. Oh, never mind fast and efficient - lets compile it with Fil-C even though it makes it really slow
It sounds like you would be fine with people who go off and rewrite a system in C# or Smalltalk or whatever, even if it's at the expense of the system being slow. But if someone does the same thing with Fil-C, you're no longer for it.
> I think gnu/linux could be way better than it is now, in lots of ways. I get the impression that we - as a species - have barely scratched the surface of the design space for operating systems. The UNIX model is a really early design attempt. Is it the best design that will ever exist? Of course not.[…]¶ I want proper capabilities. I want a microkernel. I want faster syscalls. I want storage that's relational, not just file based. I want[…]¶ But the idea of just making a bug for bug compatible, drop in replacement of a single tool like sudo is met with so much hostility and distrust from the community.
In what way is the latter (a bug-for-bug compatible sudo reimplementation written in a different language) moving the needle on the former (the UNIX problem)?
You also act as if work on alternatives don't exist. They exist. You're allowed to like them and even run them. Lucent went so far as to relicense from the LPL to the GPL to MIT, so you're even allowed to build on them with virtually no restrictions.
What does that even mean? The kernel codebase isn't append-only. Things are constantly getting refactored and improved.
> lets never try and iterate and improve?
Isn't that what the linked project, Fil-C is doing? Iterating and delivering an (extremely overdue) improvement to the language infrastructure—one of the most fundamental parts of the systems we use?
> C is the best at things[…] C is fast and efficient. Oh, never mind fast and efficient - lets compile it with Fil-C even though it makes it really slow
It sounds like you would be fine with people who go off and rewrite a system in C# or Smalltalk or whatever, even if it's at the expense of the system being slow. But if someone does the same thing with Fil-C, you're no longer for it.
> I think gnu/linux could be way better than it is now, in lots of ways. I get the impression that we - as a species - have barely scratched the surface of the design space for operating systems. The UNIX model is a really early design attempt. Is it the best design that will ever exist? Of course not.[…]¶ I want proper capabilities. I want a microkernel. I want faster syscalls. I want storage that's relational, not just file based. I want[…]¶ But the idea of just making a bug for bug compatible, drop in replacement of a single tool like sudo is met with so much hostility and distrust from the community.
In what way is the latter (a bug-for-bug compatible sudo reimplementation written in a different language) moving the needle on the former (the UNIX problem)?
You also act as if work on alternatives don't exist. They exist. You're allowed to like them and even run them. Lucent went so far as to relicense from the LPL to the GPL to MIT, so you're even allowed to build on them with virtually no restrictions.