"If a programmer writes software for a living, he should better be specialized in one or two problem domains outside of software if he does not want his job taken by domain experts who learn programming in their spare time."
Seems a bizarre sentiment, but after reading this sentence, I feel like I really wanna donate some money to the guy. If he gives a way I will surely do.
I think what he's explaining is that for most (maybe all? no empirical evidence to back this up) programming and computer software in general is a means to solving a problem.
Operating Systems solve the problem of needing a foundation in which to develop higher-level tools that enable computing. Whether the higher-level problems are complex astrophysics calculations or hailing a ride, as you travel down the stack, each piece of software is solving some problem domain.
Point of this sentence is to say, as you move forward in your career, you (usually?) develop knowledge of an industry, a customer base, a constituency or some other problem domain in which you combine your skill in engineering with your knowledge of the domain.
If you don't do this, and you say "I can do anything but I have no special knowledge of any problem" then it's more likely a person with both problem-specific knowledge and engineering knowledge will be given the job.
However, there are so many problem domains in the world of computing, it's very easy to pick one or two that interest you personally.
Those best suited to compete in that scenario are going to have deep experience in some area where programming is an applied skill, not an end unto itself.
About the sentence, sadly, but it is the trend.
I would also like to recommend another free resource that might be a good complement(theory vs implementation) to this:
"Operating Systems: Three Easy Pieces"
available online at:
Good luck!
The book not only teaches x86, but how to use the official resources from the hardware manufacturer to write the OS. In sum, a reader when reaching part 3 for writing the OS, he will need to use the official document, in this case, the "System Programming Guide" manual from Intel to write C code that complies with the documents. Once he learned how to do so, learning other platforms will be much easier given how complex x86 is.
You still have to open the A20 gate in the bootloader if you want to access a memory adress that has bit 20 (counting from 0) be set to 1 (you probably want) - even if you switch to protected mode. The only exception is if you boot from UEFI instead of BIOS - in this case the A20 gate is already set. But the book uses BIOS as far as I see it.
From the title, I had mistakenly assumed it was about the first OS ever.
The first OS was OS/360 at IBM in 1964.
The problem is that the guide is out of date in terms of toolchain, and you need to figure out many things by yourself, especially if you want to develop on Linux. My book helps you to understand how to learn and write x86 with Intel manuals (this is really important!), understand how to craft a custom ELF binary that is debuggable on bare metal, which in turn requires you to understand a bit of how debugger works.
Once you get gdb working, it is much easier to learn how to write an operating system.
It does not focus on the concrete implementation of an OS though.
No, he (Robert Szeleney, http://www.skyos.org/?q=node/411) doesn't. He (together with Heiko Hufnagl) founded a studio for creating software and games for mobile devices:
Surely: Field Programmable Gate Array (FPGA) ?
From just skimming through a few chapters I can completely understand what the author is saying but the grammar is jarring and pulls me out of the book.
Hopefully the author uploads the LaTeX source files to the repo soon. Grammar fixes are pretty trivial.
