> It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.
And he meant it too, as later in the thread when someone says they don't believe him about the non-portability:
> Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386. As already mentioned, it uses a MMU, for both paging (not to disk yet) and segmentation. It's the segmentation that makes it REALLY 386 dependent (every task has a 64Mb segment for code & data - max 64 tasks in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
This is a historical curiosity of course. The Linux kernel supports more architectures than anything else.
Mostly because of the slow adoption which allowed a lot of flexibility. It's much easier to move around when you don't have the baggage of millions of users and applications to consider.
Even Windows ran on plenty of non-x86 architectures usually because they got in on the ground floor before there was baggage to migrate. And even now you can run it on ARM but without much traction because people hate losing functionality.
And it was ported to Alpha early on to be ported to a very 'not 386' style architecture. Before that it was very x86 specific.
Linux never had a significant footprint in any long existing segment at the time they migrated from one architecture to another, especially not in a consumer one. Take Apple and their move from 68K to PPC to x86 to ARM.