Hacker News Reader

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.

[1] http://cm.bell-labs.com/who/dmr/cacm.html

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.

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.

And amazingly fun to hack on.

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.

I did this once: http://github.com/charliesome/jsos

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."

http://en.wikipedia.org/wiki/Ivan_Sutherland

Worth noting that the person that asked him this was Alan Kay.

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.

Javascript seems like throwing in the towel, lets go for coffeescript! Or markdown!

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"

I think that was the point. The markdown comment is what gives me that idea.

Yet it is an odd statement to get to C as fast as possible, because that is transformed to assembly before it runs.

i like your sarcasm.

Just start what you like to do.

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. :)

Dead comment from iRobot:

iRobot 10 hours ago | link [dead]

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.

Give him a break? Why? That guy is awesome. Look at him go! "What does the IDT look like? Do I have to fake it up before I switch to protected mode? And are interrupt handlers just C callbacks?"

Here's the thing about all this: those are questions with answers that are straightforward to find, and he is probably going to find them, because he seems totally fearless.

I could never in a million years write a blog post that so forthrightly laid out the stuff I don't know and sort of plaintively said "I'm going to try to figure this stuff out, and in the meantime, I'm putting system configuration under /system/configuration and not /etc". I think I envy him intensely.

Note to people babbling about what a herculean task building an OS is: I started coding as a teenager in the early '90s and multiple friends of mine wrote plausible protected mode operating systems. A basic operating system is not that hard. Going head-to-head with OS X as a one-person project is insanely ambitious, but who cares? By the time that becomes totally apparent to him, he may well be an unstoppable systems programming juggernaut.

My way of seeing it is... the system is everything, so the system is /.

Everything is part of the system, so the system configuration should be either /configuration or /config. But then, you already have /etc... why bother?

Anyway I doubt he's aiming to be POSIX compliant so... he's free to do what he pleases. The journey is going to make him a much better programmer.

Seconded.

As one of those fools that wrote their own OS (A QnX clone, which I'm now wondering if I should port it to the raspberry pi in my non-existent spare time) I can completely sympathize.

The good news is that the way clueless newbies learn is by doing, and there is nothing more helpful here than healthy self over-estimation. It stops you from being discouraged when you probably should be and great things can come of that. Worst case he will learn, and probably a lot more than from building yet-another-to-do-list-in-insert-fashionable-language-here.

And if you haven't written your own OS just yet, trust me it is easier than it seems and harder than it seems at the same time. It's easier to get started and to get something working (especially with VMs nowadays, in my time we had to reboot the hardware 50 times per day (cue 'hah!, you had hardware' comment including chisels and stone tablets)) and harder because it is just simply hard to get it perfect.

Oh, and Tanenbaum was right.

Seems fitting: the birth of QNX itself was Dan Dodge and Gord Bell collaborating on writing the operating system for the computers that they had respectively homebrewed. (I don't know if this is still true, but for years dtdodge had the computer he had built in his office -- it was an amazing piece of engineering, with the hand-made modem in particular inducing a kind of slack-jawed awe.) Motivated by Unix (and implementing it originally in B, if I recall correctly), they called their OS "Quick Unix" or "Qunix" -- which (after a brief infestation of AT&T lawyers) became QNX. Point is: great things spring from motivated amateurs.

Oh, and agreed that Tanenbaum was right. ;)

Tanenbaum was right about what? The infamous microkernel debate? Did the experience from writing your own OS solidify that belief?

I think Linus' argument was basically that microkernels require distributed algorithms, and distributed algorithms are more complex.

But maybe in a multicore world that argument is weakened. I like this paper: "Your computer is a distributed system already, why isn't your OS?"

http://scholar.google.com/scholar?cluster=945420933600220038...

> The infamous microkernel debate?

Yes.

> Did the experience from writing your own OS solidify that belief?

Absolutely. Micro-kernels have many advantages other than a slight overhead due to message passing (and a large chunk o that overhead can be overcome by using the paging mechanism in a clever way). They're easier to secure, much easier to stabilize, support such luxuries as on the fly upgrades without powering down with grace and allow you to develop drivers in userland greatly simplifying debugging and testing as well as allowing you to do hard real-time (and by extension soft real time) much easier than you could ever do it using a macro kernel.

I've built some pretty large systems using QnX in the 80's and 90's that I would have a real problem with re-implementing even today on todays hardware without the benefits brought by a micro kernel with network transparent message passing. If you haven't used a setup like that then it is probably hard to see the advantages, it goes way beyond some theoretical debate.

In practice two systems side-by-side, one running QnX, one running Linux will have the QnX system come out way ahead in terms of responsiveness for interactive tasks and things like latency and real world throughput.

We'll never know what the world would have looked like if Linus hadn't been as pig headed during that whole debate. Likely we wouldn't be stuck with a re-write of a 30 year old kernel.

The bit where Linux got it right and Tanenbaum got it wrong was that GPL'ing an OS was a much better move than to do a deal with Prentice Hall (who published the minix source). And minix wasn't the most elegant micro kernel either, which may have skewed Linus' perception of what it was that Tanenbaum was getting at.

My guess is if he would have used QnX instead of having looked at minix that he would have readily agreed with Tanenbaum, but we'll never know about that and Linux is here to stay for a long time.

If you haven't used QnX give it a shot and see how it works for you, you might be pleasantly surprised.

Thanks for the pointers. I have heard of QnX through a book about message-based programming with SIMPL. SIMPL I think borrows the QnX APIs for making modular and networked systems.

I prefer open source so I've been taking a look at Minix 3. It seems really cool. And it's only 6 or so years old -- at the time of the argument Minix wasn't meant to be a production system, but now it is.

I feel like it must be easier to trace application performance with Minix since you have natural points to insert hooks. With monolithic kernels it's hard to understand what is really going on.

I see a lot of potential advantages of a microkernel in distributed systems. For example, Amazon EC2 has well known I/O sharing issues. With a microkernel, you could fairly easily reimplement the file server with your own custom disk scheduling logic based on identities (not Unix users) and priorities.

In Linux I know there is some work with containers, but I don't think it is as customizable as you would like.

I agree. There's nothing wrong with what the guy's doing. He'll learn a lot from it, and I wish him well. It's also good to be writing about the things you do, successful or not.

It's not even remotely newsworthy, though.

Agreed it isn't newsworthy, but it can be inspirational to a reader who hasn't had the 'guts' to take this leap. I'm sure a lot of people reading HN think about writing a new OS it's one of the archetypes [1]. So seeing someone take the plunge can be liberating. Seeing him get slammed on the site can be de-motivating so I was hoping to counter some of that. Back when I was doing a Java based OS I spent a lot of time reading the basic kernel in eCos which had a very nice packaging an build system. I would not have invested that time if I hadn't been aspiring to other things.

[1] Programmers seem to come in 3 archetypes; the systems guy who dreams of building a new OS, the language guy who dreams of building a new programming language, and the networking guy who dreams of building a new protocol. Some folks are parts of all three, I once thought if you wrote an RPG where the characters were coders these three areas would be where you would add skill points.

Also, text editor.

most other content on HN isn't newsworthy either

"Not newsworthy" is a valid critique of a submission from a news site, but you should avoid making it of blogs like this. The author didn't submit their own post. I know you're implicitly criticizing the submitter (and the voters), but that's a subtle and annoying distinction.

the leaping into the unknown and figuring it out is one of the essential qualities of a good hacker.

a massively minimal os is not that hard.

He might also want to take a look at Pure64 [1] to handle the bootup stuff in a super lightweight manner (and also see how it's done).

[1] http://www.returninfinity.com/pure64.html

As someone who once implemented a prototype distributed OS (about 10% of an inch-thick spec) that the designers said was a total impossibility given the 6 month time constraint, I say he's biting off a big chunk, but more power to him for trying.

Some of my favorite work has come from me saying "How hard can it be? Screw it… I'm building this myself." Even from the failures I learned a thing or two, and I had a ton of fun at the same time.

I for one love being in way over my head. Keeps things interesting!

I so agree with you. I love daring people who set out to make the impossible despite the odds and prevalent "common sense". They do not ponder in doubts and expectations - they live their dream.

When Musk decided to build his own rocket, people thought he's a nut. Now he's an icon of innovation. A qualitative leap in any area requires a bold outlook, which is bound to be unpopular with the establishment. As PG once noted, if you experience a lot of opposition, it may be a sign that you're on the right track :)

I think the guy could use our support. HN is not very different from him in spirit.

I was looking at the version of your first listed book, and noticed what appears to be a more recent revision, 2004 versus 2011:

http://www.amazon.com/Operating-System-Concepts-Abraham-Silb...

Do you still recommend the Seventh Edition over the newer release?

Hmm, reading the description on Amazon it seems like they have added more 'implementation' examples. For me at least I found better sources of implementation examples (the Bach book on UNIX for example) so I suspect, but can't confirm, that the newest one is probably not a whole lot better, and if you can find the 7th edition at a discount (or the 6th or 5th) you might be able to add it to your library less expensively.