Please don't! Build something original. It really is possible!
Once you've built a UNIX clone, you have polluted your mind as an OS designer. I did so (as a standard college homework assignment) and it took me years to shake the crud out of my head.
As for the tutorial, it is very well written, but x86-32-centric and therefore worthless. There are nontrivial differences between x86-32 and x86-64 from the standpoint of an OS author who wants to make full use of the latter's capabilities.
It very well could not be, but what's important here isn't what's built, but how it's built. The concepts are important, not the end result. Compared to the vast majority of intro to OS tutorials out there, this is great.
As I said, you can't expect someone to create something original unless they understand the mistakes of the past. I started off implementing toy kernels with no structure, moved on to Unix-like kernels, and eventually ended up in a realm entirely different. Just because someone starts out copying Unix doesn't mean they're going to be blind to other competing designs or completely unique ones.
Expecting someone to build something new without any basis is just foolish.
I want to become a musician. If I listen to existing music, my creativity will be limited by what I've learned. Does that mean that listening to music is a bad thing if you want to become a musician?
Music is a poor example: a field with unusually rigid cultural norms, where true originality is punished far more often than it is rewarded. So, taming one's creativity by exposure to current norms is exactly how you become a successful (permissibly mildly creative) musician.
If you don't understand the mistakes of the past, you're bound to repeat them. This is especially true if you haven't implemented a real-esque kernel already. Pushing someone away from a tutorial that does a great job of teaching the concepts while telling them to do something original is just ludicrous.
OS development is already difficult enough, why make it harder? For every ten people that read and follow this and decide to make the Next Big OS (TM) following Unix concepts, you might get one that sees something bigger.
If you're serious about getting into OS development and doing something different, you have to study everything available. Plan 9 (and the closely related Inferno), L4 (my personal favorite microkernel), NT, BeOS, Singularity, etc. If you're going to build something unique, you have to sample everything.
This is terrifyingly bad advice, all the more so because no one here seems to understand why or even thinks there is anything to understand.
Learning has a direct cost in creativity. Once you have mired your brain in cached thoughts (http://lesswrong.com/lw/k5/cached_thoughts/) of Unix brokenness, it is very difficult to dislodge them. They won't feel like cached thoughts, or like anything special for that matter - just "the way you write operating systems."
Not one of the systems you mentioned deviates in any fundamental way from the mistakes of the original Unix. Not one. One of the reasons for this is that each was designed by people who have been steeped in Unix internals.
Yes, learning has an impact (negative and positive) on creativity, but not learning has an impact on your ability to design and implement in general.
In addition, what Unix mistakes do you see in Singularity, for instance? It's drastically different from Unix-like kernels in effectively every way.
What OSes would you recommend that budding OS developers study, if not these? Amoeba is one of the few I can think of off the top of my head that might fit what you're looking for.
Building a demo and building a full kernel are two very, very different things. In addition, it really says nothing about the design, but the implementation (again, we come back to implementation). There's no reason you couldn't implement orthogonal persistence in a Unix-like system, even if it's not optimal.
Honestly, I'm sort of baffled we're still arguing about this. I can't stand Unix-like kernels, I just believe that this particular tutorial is excellent at teaching the basic concepts required to put together any OS. If you find a tutorial of this sort of quality for any other design, submit it and I'll be certain to upvote it.
The world needs more OS designers, and tutorials of this sort lower the barrier to entry.
Edit: Also, if you're on Freenode by any chance, shoot me a PM (my nick is my username here). I always enjoy talking with someone who's as passionate about OS technology as I am.
As to your previous point, the tutorial series is aimed to be one thing and one thing only: A set of tutorials to help bridge the gap between the practical and the theoretical as far as OS implementation is concerned.
There are plenty of tutorials on ASM coding, and plenty on low-level C coding. There are plenty of books about OS internals. The books and articles I've found before tend to stay firmly in the theoretical, in the abstract. The aim of this series is to show how the theory can be implemented. Then, the reader has the knowledge to (possibly) implement their own algorithms and know how they link to the CPU's internals.
As to your second point - do you think that the memory manager in this OS is optimal? Do you think that the linked-lists everywhere are optimal? Of course not. Everything was chosen for its simplicity - I failed in some areas I know, and I'm rewriting them as I speak (they're stalled at the moment due to a lack of time); the heap for example is a mess in that series. The new one is much easier to understand.
The series does not create an optimal OS for IA32. So your point about transitioning to amd64 to "make full use of the latter's capabilities" is moot - you have to do more research to optimise for IA32 anyway, let alone amd64!
(And let's not forget that all amd64 CPUs are backwards compatible with IA32).
Once you've built a UNIX clone, you have polluted your mind as an OS designer. I did so (as a standard college homework assignment) and it took me years to shake the crud out of my head.
As for the tutorial, it is very well written, but x86-32-centric and therefore worthless. There are nontrivial differences between x86-32 and x86-64 from the standpoint of an OS author who wants to make full use of the latter's capabilities.