I will never not find this kind of project incredibly impressive. It’s interesting to think that Linux, after all, is really just the kernel — and yet getting that work done paved the way to getting an open source version of Unix installed on billions of machines. Great stuff!
It's even more funny and amusing when you remember that in the initial release mail for Linux, Torvals said "just a hobby, won't be big and professional like gnu".
https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
Transcribed here for posterity:
> Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
> I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)
> Linus (torv...@kruuna.helsinki.fi)
> PS. Yes - it's free of any minix code, and it has a multi-threaded fs. 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 :-(.
He's also referred to Linux as "the GNU Emacs of all terminal emulators".
> It's now the GNU Emacs of all terminal emulators.
> (Linus Torvalds, regarding the fact that Linux started off as a terminal emulator.)
http://neil.franklin.ch/Jokes_and_Fun/Linux_Quotes.html
That's the best reference I can find, but even if it's totally legit it doesn't make any sense to me.
Perhaps it's a reference to how Emacs does "everything" and some has also joked that Emacs is an OS with a text editor
Back then Emacs was considered what we call in modern software 'bloatware': resource hungry, big and full of feature creep.
BTW, in early versions of Slackware emacs was bundled in its own software category due to its huge size when selecting which packages to install on first boot.
Probably even had its own floppies too. Remember that install method?
> I will never not find this kind of project incredibly impressive
I wouldn’t call it incredibly impressive. The path on how to write a minimal multi-tasking kernel has been beaten decades ago.
Writing a kernel that can boot and do a few things is ‘just’ a matter of being somewhat smart and have some perseverance. Doing it for RISC-V complicates things a bit compared to x86, but there, too, the information about initialising the hardware often is easily obtained (for example: https://wiki.osdev.org/RISC-V_Meaty_Skeleton_with_QEMU_virt_... I wouldn’t know whether this project used that)
I think the author agrees, given (FTA) that they wrote “This is a redo of an exercise I did for my undergraduate course in operating systems”
It’s work, may be nice work, but I think everybody with a degree in software engineering could do this. Yes, the OS likely will have bugs, certainly will have rough edges, but getting something that can multi-process, with processes shielded from each other by a MMU isn’t hard anymore.
To you maybe. The subset of population that is even interested, smart, persevering to do this is extremely tiny.
I am 99.99% sure that less than 20% of Australian graduates could do this, and honestly I wouldn't be surprised to hear that the actual answer is <1%.
I was studying at Monash, which is considered a solid university here, and holy moly are the standards low. I had classmates in the second year of my machine learning postgrad asking me things like "What is machine learning?", and they all graduated and found jobs anyway.
Hmmm here at least in my uni in Argentina, we have an obligatory computer architecture class and we implement a protected-mode x86 (32 bits) kernel with interrupts, paging, etc. We obviously get some guidance but it's not that hard if you read the docs, nowadays you don't even need to go deep into the Intel manuals probably since osdev wiki has a lot of content.
Besides it's much easier nowadays, if something's wrong you can feed ChatGPT your GDT definition for example and find out if you misplaced a value, which used to be a PITA to debug.
As the parent comment says, I think the path to a booting usermode kernel has long been beaten, it's not trivial but it's not that hard either, I believe the impressive stuff is once you get out of "tutorial land" and implement a network stack, or a UI stack, etc.
I'd agree with this. I did a double degree in Comp Sci/Comp Sys Eng at RMIT (1998-2002) and even from that era I would say that's largely true. Out of the people who did my course (and those I knew from other degrees like Comp Sys Eng/Business) very few are still doing deep technical programming for a career and/or hobby programming on the side on deep technical non-web things. The rest are mostly working for places like consulting companies, banks, big data, Telstra, etc in management roles like project manager, scrum master, solutions architect, change management. A lot of folks I think were just not that interested in stuff like writing an OS, how does virtual memory work, how does the hardware work, etc so they gravitated out of those software development roles into management roles. Nothing wrong with that, but I just think not everyone is interested in or capable of writing an OS!
What did they find jobs in? Australia has like one tech company.
Which is odd since their universities have built two of the most interesting CS projects I can think of (Mercury and L4). And WWWJDIC I suppose.
Folks end up at all sorts of places. Like I mentioned above, the banks hoover up a lot of graduates. There are a lot of smaller local companies doing web stuff. The consulting companies all have a presence here (KPMG, Accenture, Fujitsu Consulting, etc).
Google and Amazon both have offices in Australia, and a bunch of banks / media companies / startups / SMEs employ machine learning specialists.
Atlassian Stripe, Zendesk,
> I think everybody with a degree in software engineering could do this
Ideally this would be true, but it hasn't been my experience at all. At least with American graduates, I can't speak to other countries.
My CS undergrad in the UK had us write an ARM kernel with scheduling and IPC, though didn’t require we use the MMU.
Is there a book one can read to learn how to create one?
I'd suggest https://os.phil-opp.com/ instead of a book from long ago. There is no reason to drag yourself through C anymore.
And if you do want the more historical content, https://www.projectoberon.net/
https://en.wikipedia.org/wiki/Operating_Systems:_Design_and_...
That is an excellent recommendation. For Operating Systems anything Andy Tanenbaum did is world class.
This made me look up what he has been up to, there is a 2023 edition of "Modern Operating Systems" which covers cloud virtualization and Android along with everything that came before, hm, tempting.
We really need a Tech Writer Hall of Fame. W. Richard Stevens, Andrew Tanenbaum, P.J. Plauger. Others?
Kernighan!
And how can we leave out the OG of tech writers: Donald Knuth. He got a bit distracted by developing TeX but he got a well deserved Turing award for the series.
It is equally valid to say that Stallman's starting to write a C compiler and Unix utilities (in 1984 whereas the Linux project started in late 1991) paved the way to getting an open source version of Unix installed on billions of machines.
I agree - there's a number of kernels that were "open source" and released at a similar time enough time to linux (e.g. 386BSD in '92) that I could see any of those winning the "community battle" and taking that space instead, but no real credible "development toolchain" equivalent until decades later.
Though I'm unsure how differing licenses might have affected this - I suspect that really early in it's development the "copyleft" nature of the GPL Linux didn't make as much of a difference, as from what I remember most commercial uses of Linux didn't come until it had already gained significant momentum.
The copyleft nature was essential to good driver support. It set it up such that for corporations making drivers the easiest path was to get the driver upstreamed. There was a bunch of hoops they could have gone through to avoid that (as many did, like Nvidia) but that became a sorta-default.
Copyleft encourages a collaborative relationship between entities because it makes trying to play it close to the chest with IP involve more legal effort (if it's possible at all).
Yes, I can see that stalling development as (at best) it turns into a pile of private forks rather than a cohesive project, but from what I remember that was already after Linux had "won" the "Open Source Kernel" race.
Commercial support for Linux was... Sparse... before the early 2000s.
> [Stallman/GNU] getting an open source version of Unix installed on billions of machines.
Agreed, funnily enough GNU tools/compilers also ended up getting installed on a lot of proprietary UNIXes because proprietary UNIX was mostly shit (in user space!). At least most of the ones I had the misfortune to have to work on.
I first came across GNU tools on NeXTSTEP, which wasn't too bad.
If Stallman had started with a kernel, there would be very few people who had the legal right to run any utilities or apps on the new kernel whereas GNU's utilities and apps (e.g., Emacs) were immediately useful (i.e., without breaking any copyright law or violating any software license) to a large population, namely, anyone with an account on a proprietary Unix system, which explains why Stallman chose to start with the userland.
That's true in isolation, but is missing vital context. In the 1980s a user of proprietary Unix usually had no way to make the ls utility or a C compiler or a text editor run on an new Unix-like kernel. And even if he had the technical means to do it, he probably did not have the legal right, i.e., it would have been a violation of copyright law.
In the Unix world, there was no tradition of binary compatibility: you couldn't just take a binary compiled for NeXTSTEP and run it on Solaris or on Linux: you needed to recompile, which means you needed a C compiler and the source code for the program you want to run, and most users of Unix in the 1980s didn't have a practical way to get the source code (and if he did have access to the source code, using to to port the program to a new kernel was probably a copyright violation). Stallman could have tried to start a tradition of binary compatibility in the Unix world. That is one of the strategies he could have chosen for the GNU project: i.e., he could have picked a proprietary Unix, Solaris, say, and make sure the kernel of his GNU system could run all (or most) binaries that run on Solaris. But that strategy ran the risk that the owner of Solaris might have sued to stop this and the courts might have sided with owner, requiring the GNU project to shut down, pay the owner (Sun) a lot of money or start over with some other strategy.
(Replying to myself because it is too late to edit.)
I found a shorter reply to your comment, which I will now write:
>when it comes to the GNU project and the whole Free Software movement is the ability to run _any_ program, be it non-free software or free software.
Just because the GNU project allowed non-free software to run on GNU doesn't mean there existed in the 1980s a userland that would run on GNU if GNU had consisted of just a kernel (or just a kernel and a C library and a C compiler).
[dead]