ARM gets to completely redesign their ISA to be more superscalar friendly.. like what Power and MIPS had for years. They get to do this because they now have huge mind-share from the low-end. It will be interesting if they can really compete at all in the high end. Eventually they will have to compete with things that other vendors have tuned for years, such as cache size and smart cache-prefetching. MIPS and Power really dropped the ball on the low end and are hurting for it. For MIPS I think the issue is that their ISA is not as powerful as ARM for simple single-issue CPUs. In particular, not auto-increment. Power does have this (with the pre-add offset to index register), but somehow they never made in the mobile world. Maybe Freescale and AMCC didn't try hard enough.

Binary drivers suck: it means you need the vendor to recompile them for each kernel version. This leads to extreme difficulties with commercial use of Linux: you have pressure to use a particular version of the kernel for one reason, but you can't because the binary driver was built for a different version. You may have to try to get the vendor to recompile their driver for you, but then there is a schedule dependency. Why have the vendor in your release loop? GPL APIs also suck: Frequently custom hardware comes with proprietary non-GPL drivers, but which do come with source (usually terms are "free to use and re-distribute but only with my custom hardware"). I've seen where a kernel API changed from free-access to GPL restricted.. but now what? You are free to change the custom driver sure, but you can not use it because you are not free to change the vendor's license. Ugh. IMHO, both the binary drivers and the GPL APIs need to go.

Besides the open-source, how is this project any different from what Tilera already has? http://www.tilera.com/

CP/M's filesystem seems very much a rip-off of the IBM's DOS/360 (allocation and "extent" information were all in directory or "VTOC"). Today this certainly would have created a patent issue. "And QDOS didn't have CP/M's file system - it used FAT, not the somewhat inefficient CP/M system which, IIRC, required scanning the entire directory to determine where the free sectors were."

Relocation, or lack of it, were certainly big issues in the 60s and 60s. There were systems (RSX-11 without mapping and DOS/360) where a big operator task was to link the entire system: and I mean both applications and OS. You needed to carefully plan where your applications were to be loaded and how much memory to devote to each area. In DOS/360 you could have background and foreground tasks. But you had to have your application pre-linked for a different load address if you wanted to use it as a background task.

MS-DOS is actually a big improvement compared to previous microprocessor operating systems. It uses the relocation capability provided by the x86 segment registers to keep the OS separate from the application. In CP/M, the load address for the application is right above the operating system so there is actually no way to make large changes to the core OS.