Agreed; the criticism here is way too harsh. In particular, I think it's somewhat amusing that people are giving him grief for wanting to "jump to C as soon as possible." Any rational kernel developer wants to jump to C as soon as possible -- and wants as much of the system to be in C as possible. (Indeed, this is the ethos that drove Unix -- and separated it from the horrifically unportable systems that predated it.[1])
Further, there are some good ideas here -- in particular, jumping directly to long mode allows one to avoid much of the replaying of the history of the PC that one is historically required to do to boot an x86. Most civilians (and I dare say, most of the negative commenters here) have NFI how ugly this process is and how much of a drag it is on future development. With the decline of the PC, it's reasonable to believe that a future is coming in which x86 becomes primarily a server-side microprocessor -- and begins to shed much of the baggage from the misadventures of the 1980s and 1990s.
All that said: there is a certain arrogance of youth here, and one hopes that when reality has sandblasted it away, the resulting humility will find its way to a formal computer science education and ultimately into professional software engineering; our discipline needs more people who have dared to write an OS from scratch, not fewer.
Very well said, particularly our discipline needs more people who have dared to write an OS from scratch, not fewer. Truth is that I've thought about doing what the OP is talking about, but quailed at the complexity of it.
That said, I'd be interested in making an OS that gets to JavaScript as fast as possible. Yes the system would be a dog, but sure would be fun to build.
At least when it comes to systems programming, but probably across our whole field, most seeming impossibility has more to do with fear than real difficulty. I've spent a lot of time clumsily trying to paint a target on exactly what that fear is, but I've learned by having a lot of crazy stuff shoved into my face as a security researcher that if you can just get yourself to focus on a task and start coding, a lot of contraptions that seem so hard to build as to be implausible are actually the work of just a day or two; at least, the kernel of those contraptions (emulators, hypervisors, compilers, debuggers, drivers, interpreters, routing protocols, static analyzers).
If you have a basic aptitude for coding, not knowing how hard a task is isn't a liability; it's a powerful asset. If you haven't actually done real work on an OS, you wish you thought it was as easy as this guy does.
When asked, "How could you possibly have done the first interactive graphics program, the first non-procedural programming language, the first object oriented software system, all in one year?" Ivan replied: "Well, I didn't know it was hard."
I have, however, balked at the enormity going from the kernel of something to the whole completed thing suitable for commercial release.
There's two kinds of fear; fear of the unknown - where you may learn to wade in anyway - and the more awkward fear of the known. The latter, if you believe the project's basis to be questionable, can destroy motivation. It made me quit my last job.
I don't know a lot about math (I still don't) but I always wanted to write a 3D render engine. I also was afraid of the complexity. But then I figured I didn't know anything about it's complexity because I never tried.
So I started with Processing and wrote an photo-realistic ligh-tracer. Very slow but very very fun. Then I wrote a multi-core version which was a little faster. Then an path-tracer which was faster. Then an exporter for Blender. Then I ported the project to Java.
Is it as good as current render engines? No! But I don't care because I learned a lot and had a lot of fun.
Then I liked to have a CNC router. But I could not afford one. So I just built one and it worked!
Moral of the story: just do it. You will fail sometimes but who cares? You will always learn a lot.
Cool. Well I did do something recently that was a lot of fun, and not a little useful: I was annoyed with D3's opaque API and wondered if I could do better. So I wrote a particle system in mostly raw JavaScript - and actually, the code looked (and looks) a lot better to me. I even did some quirky things that ended up being useful like storing velocity vectors in normalized polar coordinates. It only took a few hours, and was quite fun to do. Not quite an operating system, but still. :)
Smalltalk used to be an OS, and there have been some things resembling ports of the Smalltalk image to JavaScript. Also, JIT compilation is good enough, that such an OS need not be a dog, provided a clean architecture. BeOS showed that to be the case on machines orders of magnitude slower than today's.
BeOS was written in C++ and compiled with gcc 2. For all intends and purposes the whole operating system was native code, certainly not running over a VM.
Yes, but it could achieve feats of multitasking and multimedia display mainstream OS could only achieve on machines with much more power. It showed that a 10X increase in efficiency is possible though architecture.
That is an odd statement when you considered that CoffeeScript is transformed to JavaScript before it runs. It sounds like saying "Let's drop the cows and just get the milk straight from the store instead"
The BIOS on the original IBM PC totally made it easy to code a homebrew bare metal OS which could access all the peripherals. These BIOS calls exists today in i7 based motherboards allowing OS's coded in the 80's to still (mostly) function on a modern Motherboard, its biggest fault was being 16 bit which meant all newer OS's needed to write there own once they switched to 32/64 bit mode.
The BIOS layer made the PC easier. I find it frustrating that almost every new SOC I get, even from the same manufacturer requires me to re-code all my IO routines.
If a common BIOS existed across the ARM/x86 which emulated the simpleness of the original BIOS concept and not the API hell you usually get now, there would be a lot more adventurers in homebrew OS's
Note to iRobot: it looks like your comment 165 days ago about "Melissa[sic] Gates" got your account killed.
Totally agreed here. This is one of the reasons I really like the "build your own OS" course for the Raspberry Pi as the ARM ecosystem doesn't suffer from this legacy of system design. That said, the current SoC's sort of assume you are building a phone, but perhaps that will change.
Further, there are some good ideas here -- in particular, jumping directly to long mode allows one to avoid much of the replaying of the history of the PC that one is historically required to do to boot an x86. Most civilians (and I dare say, most of the negative commenters here) have NFI how ugly this process is and how much of a drag it is on future development. With the decline of the PC, it's reasonable to believe that a future is coming in which x86 becomes primarily a server-side microprocessor -- and begins to shed much of the baggage from the misadventures of the 1980s and 1990s.
All that said: there is a certain arrogance of youth here, and one hopes that when reality has sandblasted it away, the resulting humility will find its way to a formal computer science education and ultimately into professional software engineering; our discipline needs more people who have dared to write an OS from scratch, not fewer.
[1] http://cm.bell-labs.com/who/dmr/cacm.html