111–120 of 129 posts
Earlier quoted context omitted.
If you want PRs, I suggest you set up Semantic Linefeeds* sooner, rather than later. Each sentence gets its own line, and it really helps avoid merge conflicts. * https://rhodesmill.org/brandon/2012/one-sentence-per-line/
TIL. It's too late for this book, but I'll try it in the next one.
Author here. I wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig. I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it how…
I almost feel tempted to use your book to both learn about OS and improve my shitty Japanese. :)
Author here. I wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig. I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it how…
Hi OP, this looks super cool. I remember hearing about this ( https://www.linuxfromscratch.org/ ) many years ago but have never done it. Curious, what are the prerequisites for this? Do I have to know about how kernels work? How memory management, protection rings or processes are queued? Some I'd like to definitely learn about.
Also, because the implementation in this book is very naive, it would stimulate your curiosity.
Author here. I wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig. I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it how…
How does your book compare with the classic "Operating systems design and implementation" by Andrew S. Tanenbaum and Albert S. Woodhull implementing MINIX?
MINIX book describes more practical designs, with a more feature-rich implementation. However, UNIX features such fork, brk, and tty are not intuitive for beginners. By writing a toy OS first, readers can compare the toy OS with MINIX, and understand that UNIX-like is just one of many possible designs. That's an important perspective IMO.
Also, readers can actually implement better algorithms described in the MINIX book. It makes the MINIX book more interesting to read.
Earlier quoted context omitted.
Fair point. I was slightly more getting at it being not a natural fit for a Unix-like OS but I accept your point. AFAIK, sadly, Intel BiiN is lost to history now. A Register reader wrote in to me to tell me that he was one of the developers.
That's cool that you heard from one. What I really wanted from a developer was the i960. Specifically, the version with the object protections. That might be worth buying today for secure, embedded work. If I found the right person, I'd ask them to open-source, or at least dual-license, the i960. For embedded systems, leave it as a RISC-V alternative or port it to RISC-V.
It was. (If you ever see this, thank you again, Mr Buchanan.)
> What I really wanted from a developer was the i960.
Interesting choice!
Given that Intel has a number of distinctive architectures in its historical portfolio, and is in trouble these days due to the competition from Arm and perhaps even RISC-V, I would love to see it do either experimental revivals of some of its architectures, or open up the specs for other ones.
(Someone there must bitterly regret selling off its Arm architecture license cheaply to Marvell; now, Marvell is worth more than Intel itself.)
How about modern die-shrinks of i860 and i960, or even just FPGA versions?
After the DEC/Compaq/HP implosion, Intel also ended owning the Alpha. I would not be at all averse to a resurrected Alpha chip, even if a very low-end chip on some old cheaper process tech.
Earlier quoted context omitted.
That's cool that you heard from one. What I really wanted from a developer was the i960. Specifically, the version with the object protections. That might be worth buying today for secure, embedded work. If I found the right person, I'd ask them to open-source, or at least dual-license, the i960. For embedded systems, leave it as a RISC-V alternative or port it to RISC-V.
> That's cool that you heard from one. It was. (If you ever see this, thank you again, Mr Buchanan.) > What I really wanted from a developer was the i960. Interesting choice! Given that Intel has a number of distinctive architectures in its historical portfolio, and is in trouble these days due to the competition from Arm and perhaps even RISC-V, I would love to see it do either experimental revivals of some of its a…
Yes, even shrinks to nodes like 180-350nm would be helpful. The older nodes are still more reliable than modern ones due to the physics involved in deep-sub micron. While not power-efficient, both i960 and Alpha would be fast and reliable.
On FPGA’s, that’s a likely use. Crash-safe.org used Alpha ISA in their early prototype. It’s also just easy for experimentation. In security and accelerators, we’re seeing many companies just throw a fat FPGA. Then layer the improvements on it to avoid the NRE cost.
Btw, Alpha had something worth continuing to talk about in new designs: PALcode. From what Alpha people told me, it is in between microcode and kernel code in nature. They can switch to PAL mode to run a series of instructions as an atomic block with more access to internal parts of the CPU. Projects could essentially extend the CPU to make things like secure, context switching or concurrent GC’s easier. They don’t have to open their internals up as much as custom microcode either.
On that note, what I’d really prefer is custom microcode on an open ISA. There were HLL to microcode compilers, at least in academia, that let you synthesize the microcode from HLL algorithms. That would be super-helpful since one could eliminate problematic instructions or add better ones with no hardware changes. Intel could still differentiate on that, too.
This looks nice! I would love to have an ebook version to read on my ereader. I wonder how much effort it would take to use the markdown files in the GH repo and convert those. [0] https://github.com/nuta/operating-system-in-1000-lines
You can clone the repo and install pandoc. Then run "pandoc index.md *.md -o operating-system-in-1000-lines.epub" in "website/en/" folder and you will have a fully working ebook.
* an issue, "make an ebook": https://github.com/nuta/operating-system-in-1000-lines/issue...
* an epub: https://github.com/pronoiac/operating-system-in-1000-lines/r... The epub is mostly ok but a bit broken.
For any rust enthusiasts, phil-opp's guide is such a fun exercise to try out. It was actually the first thing I tried in Rust (very silly idea) and ended up only understanding ~5% of what I had just typed out. I tried it again 2-3 years later and took the time to go over each subject. I even planned in advance to make sure I was going to finish it.
Author here. I wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig. I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it how…
"Designing an OS is like creating your own world" Making video game is also like creating your own world! And it's order of magnitude less hard than making an OS... Bonus point, you have a chance to make a living from it!
Earlier quoted context omitted.
"Designing an OS is like creating your own world" Making video game is also like creating your own world! And it's order of magnitude less hard than making an OS... Bonus point, you have a chance to make a living from it!
actually making a video game would be 100x more complicated. Plus kernel developer jobs are more lucrative than most game dev jobs.
Also I'm not speaking about making a game engine along with the game.
Having a kernel dev job is different than making your own kernel, speaking on a "world builder" perspective.