Show HN: Very basic Unix-like operating system built when I was younger | Hacker News Reader

Show HN: Very basic Unix-like operating system built when I was younger

github.com

150 pointsSamyPesse63 comments

"This code was written several years ago as one of my first projects when I was in High School so it's normal if some parts of the code looks like "crap"."

In other words: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)..."

Please don't insult yourself by writing 'not great' on things that you wrote. You know it's not great, I know it's not great, but you made an effort and have a basic workable system. Don't kid yourself, and don't put yourself down. Not everyone can be a 'great programmer'. If there are maybe 20 great programmers in the world that you look up to, there are 200,000 programmers who are average at best. So don't compare your code to the top 0.01% - no way any of us can be that good.

You are completely right. It is the same with giving discounts on products or services, you devaluate what you are providing.

I wouldn't even know where to get started on building an OS, so I think this is pretty awesome.

Some 'for dummies' step by steps on getting this to run would be great :).

I wouldn't even know where to get started on building an OS

http://pdos.csail.mit.edu/6.828/2012/xv6.html

http://pdos.csail.mit.edu/6.828/2012/xv6/book-rev7.pdf

At least provide the link to the full course where people can work through the labs!

http://pdos.csail.mit.edu/6.828/2012/

I took Dan Tzafrir's version of this course at Technion last semester. Best. Course. Ever!

Thanks guys.

Please, please say that you also wrote a simple flight simulator for your OS but you're kind of ashamed at the quality of it ...[1]

[1] http://www.metafilter.com/119424/An-Operating-System-for-Son.... .... "bro i think you can be proud of the flight simulator you wrote for the operating system you also wrote"

Agreed, unfortunately posting this with just "check out this basic OS I wrote" would yield a ton of flamey comments like "WTF, why would I use this instead of Ubuntu?! Lame."

I attempted the very same in my first year of college (in the UK, so about the same age). I only got as far as a memory manager, FAT16 filesystem driver and basic bootloader though so congratulations for making it so far!

Here's some great resources for OS dev, if you wanted to take this further (or if anyone else in this thread fancies a shot):

- http://wiki.osdev.org/Main_Page

- http://forum.osdev.org/

- http://en.wikipedia.org/wiki/Master_boot_record (MBR layout)

- http://en.wikipedia.org/wiki/File_Allocation_Table

- http://www.ctyme.com/rbrown.htm (full BIOS interrupts list)

- http://www.emu8086.com/interrupts.html (much friendlier BIOS interrupts)

What an amazing achievement. If only I hadn't wasted all those years at high school when I actually had a lot of time to spare....

Ironically the institutions and society thought I was wasting my time, being from school when I was making my own LinuxFromScratch at home. Even going so far as to threaten to expel me from the school, for not being there at classes.

I came back about 4,5 years later to that school, then as a teacher of their newly founded IT classes. Chuckle.

To get back on post, this guy making his own OS is a wizard.

I think OS designers have too small a vision. The basic principle separating 'OS' from any other support is: sharing. Device, process, hardware, access, network, anything.

There are so many things to share that are usually exclusive, they should be pushed back into the 'OS'. So many lame devices surface a serial streams - the OS doesn't allow sharing those. Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.

Even the model of 'process, thread, priority' is inadequate today. I'd much rather schedule latency than priority. And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero). I'd like to schedule network traffic across purposes/apps.

I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.

I guess my point is, there's so much more to what an OS should be, than page table/scheduler/disk drivers.

This. So much.

> Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.

Does the multiplexed access need to be at the kernel level? It could be done with a user space server.

> And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero).

There have been efforts to eliminate copies, and to allow direct access to network devices from userspace.

> I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.

I'm in agreement that the filesystem tree is problematic. It's inefficient to traverse a directory tree when it's structured as a persistent linked list, and it's brittle. The tree is intuitive, but you could create a tree interface even if there isn't a literal metadata tree on disk.

You might be surprised by all of the zany things that have been proposed and tried in the OS community. The abstractions that have stuck around are oldies but goodies that are simple but work. A lot of things don't need to be done at OS level, like cosmetic changes to the interface of some resource. You can usually do that in userspace. Linux is pretty remarkably flexible with filesystems, too. FUSE is about as flexible as you can get.

The best argument to change the kernel is when something simply can't be done efficiently in userspace. If there's a way to implement something useful in userspace on top of existing kernel functionality, that's the way to go.

The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

I'd say its universities that are letting us down, by continuing to teach the obsolete ideas current in the 1980s.

> The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

Do you mean like a SQLite file? You have to consider how much there is to gain from embedding this stuff deeper.

> In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

This doesn't necessarily need to be in the OS. Look at it as a technical problem to solve. Is there a way to meet this need without changing the OS? There's usually a creative solution.

Ever try playing with plan9? It persuaded me that, yes, the modern tree filesystem sucks, but not because organizing persistent data into heirarchies is bad, but because you don't always want the physical translation presented to you. Plan9 was pervasively virtual, with an applications filesystem view being radically different than anothers, and with everything accessable through file read / writes (including OS system calls besides open, read, write, and close).

I've never tried Plan9. Doing searches over deep source code hierarchies has been my most recent experience with the inefficiency of the directory tree (nevermind the inefficiency of overly-complex source code). Really, there's no fundamental reason why `find /usr -name foo` has to take all day. While installing software, also, I was struck by how long it took, while it was apparently updating all the filesystem metadata. For the problem of long installs, I had a brainstorm: what if userspace could hand the filesystem an entire archive in a single transaction, and let the filesystem handle materializing it into a directory tree at its leisure? Just give the filesystem a tarball, rather than the application having to piece together the subtree step by tiny step? It would certainly make it more ACID, and it's not like tarfiles are bleeding-edge technology. Maybe that's a good project for someone who wants to hack filesystems.

This is the reason I learned Assembly in high school. I wanted to write my own OS and well it seemed at the time (around 2000) that I would need to know ASM to a bunch of the low level stuff. I didn't really have anyone to tell me I could write a whole OS in C or C++.

I got a floppy to boot into my os and print hello world and I learned a ton about how to program a processor. It was fun. Oh the crazy things you do as a teenager...

I can barely do the most basic tasks in programming and you wrote an OS in high school? Bravo.

And thus begins the successor to Linux.

Bravo indeed! I only started programming in my senior year of high school. I wanted to write an operating system for my senior project, but I thought that was WAY too ambitious. Kudos!

I forget where I read it but I remember a quote the basically boiled down to "The only people willing to attempt writing an OS are those too naive to know how much work it really is." Part of that probably explains why you can learn so much when just starting out...you just don't realize, yet, how much of you're life it will consume.

Look at Linus... he's gotten further than most, but there's no end in sight. He pretty much stopped resisting.

I realized over the years that it's those high school and college years where you can really expand your skill sets where as once the real world starts throwing things at you you start to stagnate. Makes me regret a lot of the time I wasted in those years.

The OP (SamyPesse), is my co-cofounder and we're currently building our own Startup together (https://friendco.de).

I thought you might be interested in seeing what he's (and I are) working on now. (We've got some cool open source components here: https://github.com/FriendCode/, that you might want to check out).

Just a heads-up: the 'Try it' button on the home page does nothing for me apart from reloading.

It is working for me.

Chrome Version 29.0.1547.65 Ubuntu 12.04.3 LTS

Check out: (CS194-24) Advanced Operating Systems Structures and Implementation

http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S13/

Its pretty cool. Unfortunately the Linux VM used for development does not exist any more. But Still cool.

I'm having trouble compiling this.

    freefull@freefull-hp ~/c/o/devos> make all
    Building Kernel
    make -C ./kernel
    make[1]: Entering directory `/home/freefull/code/other/devos/kernel'
    makefile:9: runtime/Makefile: No such file or directory
    makefile:10: core/Makefile: No such file or directory
    makefile:11: modules/Makefile: No such file or directory
    makefile:12: arch/x86/Makefile: No such file or directory
    make[1]: *** No rule to make target `arch/x86/Makefile'.  Stop.
    make[1]: Leaving directory `/home/freefull/code/other/devos/kernel'
    make: *** [all] Error 2

I haven't tried myself but it looks like a casing issue. All the makefiles have a lower case m. I'd suspect correcting that would do that trick.

make looks for both Makefile and makefile, but those directories don't have any makefiles at all.

Is there a configure script or cmake or something? It looks like you might have to do something before `make all`

Nope, just a top level makefile and a readme that says to compile you only need to

    make all

make looks for [Mm]akefile if you run it with no arguments, but here it's being run recursively (or included). On OSX, filenames are case-insensitive, which could be a possible reason why it works for some people. On Linux, filenames are case sensitive.

That seems to be the case, since running file on one of the existing .o files says that they are Mach-O i386 objects. The readme doesn't mention OS X though, only Ubuntu

Well, on my system (Ubuntu) at least this is not the case and renaming the files gets past the errors and on to actual build errors:

  runtime/cxx.cc:74:41: error: ‘operator new’ takes type ‘size_t’ (‘unsigned int’) as first parameter [-fpermissive]
  runtime/cxx.cc:84:43: error: ‘operator new’ takes type ‘size_t’ (‘unsigned int’) as first parameter [-fpermissive]
  make[1]: *** [runtime/cxx.o] Error 1

After renaming the Makefiles to fix the case, running make clean and then make all, I get the same error.

Thinking about this, this is a casing issue after all. The makefiles include Makefile rather than makefile

The compile/build works fine now (check out my commits).

However what does not yet work is booting the image with Qemu.

Thanks for fixing the compile

I too wrote unix like kernel when I was student (around 8-9 years ago). My kernel was also in C++ and and little bit of asm (nasm)

It was very fun experience. Probably that was my most enjoyable time in programming. I learned a lot about many things: OS internals, compilers, device drives, software engineering etc. Also spent good amount of time in exploring C++ object mode. Much later I wrote an online (short) article on C++ object model and how C code is translated into assembly (http://www.avabodh.com/cxxin/cxx.html, http://www.avabodh.com/cin/cin.html)

This just makes me feel inadequate...you wrote this in highschool? How old where you back then if I may ask and what made you take the challenge?

Also, how does one even start to write their own OS, I mean after you say "I'm going to write an OS form scratch", what's the first step, what's the first line of code and how do you figure out which components you need to implement and how? This is what really boggles me as a 30 year old crud guy, how do you design these sort of systems from scratch (OS's, emulators, compilers, etc)? It just makes me feel...completely useless compared to guys like you, you are so far ahead of the curve its not even funny, I could never reach your level.

Congratulations.

I thought this was pretty cool. It would be fun to do something like this and I'm sure I'd learn a lot. I found a lot of helpful information, books, and websites on this Stack Overflow question: http://stackoverflow.com/questions/1224617/how-can-i-build-a...

Nice! And I wouldn't call it "very basic". It's inspiring to see how far you've gone, even at such a young age.

I took a shot at os development and it took me almost a month of reading to get something that boots and handles interrupts (https://github.com/raaapha/sos), and I'm in college. Now _that_ is "very basic"!

Suddenly, everything I've done thus far seems rather inadequate. However, kudos for doing this! I hope you haven't stopped working on it.

Looks like you've worked on the expected base functionality.

https://github.com/SamyPesse/devos/blob/master/kernel/arch/x...

Never too late. The only problem with writing an OS is that you are exposed to the x86 architecture - which is HORRIFIC, but even something as small as booting to "hello world" gives you a wealth of knowledge about the underlying layers that we take foregranted.

'Foregranted' should be a word, I like it.

Targeting ARM and using qemu is a good way to stay out of x86 land.

I'm not really qualified to say, but isn't modern ARM also quite horrific from osdev point of view. At least x86 has some sort of standards imposed by intel, but with ARM every manufacturer is doing it's own thing with the peripheral functions. Wasn't that what Linus was complaining some time back that Linux ARM support files are blowing up because there is too little code shared between platforms?

That's only an issue if you're building a general purpose OS that tries to target every ARM board out there. If you're just making a hobby OS on a simple device, then you don't really need to worry about it. In the x86 world it would be analogous to saying that you don't need to worry about writing an ACPI engine into your hobby OS.

The main issue I've encountered is actually finding documentation for these various architecture-specific oddities.

I looked at the teaching kernels xv6 from MIT, and Pintos from Stanford. They are both x86, and I've heard the same sentiment that you express, which makes me a bit hesitant to dive in.

Does anyone know of something similar for x64? Or maybe ARM? Online course materials would be nice.

http://www.stanford.edu/class/cs140/projects/pintos/pintos.h...

http://pdos.csail.mit.edu/6.828/2012/xv6.html

I doubt x64 would be less horrific. As for ARM, there is Cambridge's Baking Pi course http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/, which has you develop an "Operating System" for the Raspberry Pi. Although, from looking at it, it seems more like an embedded systems course than an OS course. It talks about controlling hardware like LEDs, monitor, and keyboard, but it doesn't talk about stuff that full-fledged operating systems have, like scheduling of userspace processes, memory mapping, filesystems, etc.

My own effort from late in high school:

http://glider-kernel.sourceforge.net/

Unfortunately, I'm not allowed to put my 236376 Operating Systems Engineering course project online, due to the licensing issues with JOS-based project code.

I'm adding support for Vagrant.

So you can boot the whole thing with Vagrant. Check out the latest commits.

How long did this take? What would you estimate your C++ proficiency was when you wrote it?

It took me like a year to really understand how everything works and come to this version (it was 4 years ago). I really learned C/C++ (and some assembly) with doing this, so I wasn't really good at C++ before (and if you take a look at the code, you'll see that it's not really pretty).

(Sorry for my english, I'm french)

Don't worry - you write like a native English speaker!

Better than most in the states, for that matter :p

Don't apologise for your English. You speak, at least, French and English, most English speakers can't even manage to speak English very well.

Hey! I wrote a kernel in Highschool too, after being inspired by Linus' "Just For Fun". Amazing experience, although mine was in C and nowhere near as complete as yours. Well done!

Why did you decide to do it in C++ and not C?

Reply on news.ycombinator.com