Jonah Thomas wrote:
> I could imagine it working, if you can do the work. There's a story
> about Mitch Bradley that I probably have details wrong on, so I'll try
> to skip the details. He was an engineer working for Sun, and they were
> building a new component, a graphics processor or something. After hours
> he went to the guys who were doing that and he built a Forth system to
> interact with it, to help debug the hardware. There was a team that was
> supposed to do that in C but they were behind schedule. His stuff
> worked. The C guys fell more and more behind schedule, and when the
> product shipped they shipped it with the drivers in Forth because the C
> drivers weren't ready.
Probably not quite correct story, but the origin of Open Firmware was like
this: New SPARC boards arrived (first SPARC generation), and Forth ran ways
before any other stuff, so Forth bootstrapped the Unix. So: Open Firmware
was born.
> So if you did somehow get a Linux clone working, and you tracked what
> they wanted to put into the next version and you got it working before
> anybody else did, they might possibly go with your version. You could
> get the whole Linux community to switch to your kernel. Does it seem
> plausible? No. Not the least bit. Even if your kernel is obviously
> better in every way, would Linus agree to switch from what he's been
> wrapping his mind around for years to something completely new? Not
> plausible. And yet, it's the most likely approach I can imagine to
> getting your hard work into many people's hands.
Linux is not just Linus. The Linux kernel is controlled by Linus and similar
people, and they certainly have some NIH problems. But if you wrote a
kernel that's compatible with Linux and works better, Debian and other GNU
system distributions can switch over.
When I think about this problem (Unix-like operating system), however I
doubt that it really makes sense to write a Linux clone in the sense as
drop-in replacement. A lot of things are IMHO "wrong" in Linux or Unix in
general. Wrong as in "not simple enough", "not quite right for our
high-speed networked world", "too much legacy baggage", and such.
When you implement quite radical changes, you still can add a POSIX layer on
top (sufficient similar semantics of the underlying OS implied), but it's
not going to be optimal. E.g. one of the points I think are wrong in Linux
is the synchronous system call. I'd use active messages to call the kernel,
i.e. you write some token-threaded code into a buffer (token threaded for
security reasons), and let the kernel execute it. Then you can make
hundrets or thousands of function calls and execute them with two context
switches instead of having two context switches per single call.
However, when you emulate POSIX, you get the trouble that most POSIX calls
have synchronous return values. POSIX hasn't been designed for message
passing. The other problem of radical changes are social problems. One
reason of the success of Linux is a social one: Many Unix hackers
immediately were at home with kernel programming - at least in the early
days. What if I wrote my suggested message passing microkernel in Forth? I
alienate most people. Those who write in C because I use Forth. Those who
know Unix and Linux, because I solve the problems radically different.
When I'm not interested in legacy baggage, I'll probably not implement the
POSIX layer in a way that makes porting trivial. Actually, I'll probably
only proof that you can implement POSIX if you liked to (and the rest is
left as exercise to the reader ;-).
E.g. take the file system. What I see as basic factors of a file system is a
lightweight database for metadata, and a (hopefully efficient) block
storage for the actual data. Forth-way to do it: Expose the database. You
want to add ACLs? Add an ACL record to the database, query it when you open
a file (you can add NTFS-style ACLs or POSIX-style ACLs within the same
filesystem). You want xattrs? Add an xattr record to the database. You want
something completely different? Go ahead, just do it.
