Earlier quoted context omitted.
this comment reads... a lot like chatgpt
I always use an LLM to recraft my comments to ensure they are clear (English isn't my first language). Is that not allowed here?
[deleted]
Operating System in 1,000 Lines – Intro
61–70 of 129 posts
Re: Operating System in 1,000 Lines – Intro
#62For 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.
Hey, any chance you could link it please?
Re: Operating System in 1,000 Lines – Intro
#63For 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.
Hey, any chance you could link it please?
Re: Operating System in 1,000 Lines – Intro
#64> The tricky part of creating your own OS is debugging.
The older I get, the more I think I can figure out most problems that don't require some really gnarly domain expertise if I have a good way to iterate on them: code something, try it, see the results, see how they compare with what I wanted. It's when pieces of that are difficult or impossible, or very slow, things get more difficult.
Re: Operating System in 1,000 Lines – Intro
#65Author 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.
Re: Operating System in 1,000 Lines – Intro
#66I started a toy OS years ago based on the book Operating System Design by Douglas Comer. Personally I just couldn't get excited about anything that didn't run on real hardware, so I made mine for Raspberry Pi. Is there any real hardware that this could run on? Looking through this seems to use a lot of assembly. In the above the amount of assembly is kept to a minimum. Pretty much just bootstrapping and context switc…
Comer was also my introduction to OS design and I still like the approach used in his Xinu books. I had a quick glance at the OS in the linked article. This seems to be based on a 32-bit RISC-V with MMU. However, AFAIK, all available RISC-V SoCs with MMU are 64-bit. The 32-bit cores are only used for embedded controllers (unless you want to start designing an FPGA-based system). The 32 and 64 bit versions of RISC-V a…
That's encouraging, thanks for sharing.
Re: Operating System in 1,000 Lines – Intro
#67Author 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 Or like building your temple so you can talk to God directly
TempleOS: https://en.m.wikipedia.org/wiki/TempleOS
Re: Operating System in 1,000 Lines – Intro
#68A noble idea, but Github is literally littered with hobbyist home-grown Unix-like kernels in C. As an industry are we not supposed to be trying to move away from hoary old unsafe C? Could we not have a hobbyist educational OSes in more of the C replacements? Drew DeVault wrote Bunnix in Hare, in one month. There's the proof of concept. How about tiny toy Unix-likes in Zig, Nim, Crystal, Odin, D, Rust, Circle, Carbon,…
Dijkstra famously said that programmers who started with BASIC are "mentally mutilated". But I think this applies a lot more to C and UNIX. Most of them don't seem to understand how anything substantially different could exist in the world of computing - every other language and operating system is seen as either an inferior copy, or as another layer of abstraction building on top of C and UNIX.
Exactly my own sentiments!
Re: Operating System in 1,000 Lines – Intro
#69A noble idea, but Github is literally littered with hobbyist home-grown Unix-like kernels in C. As an industry are we not supposed to be trying to move away from hoary old unsafe C? Could we not have a hobbyist educational OSes in more of the C replacements? Drew DeVault wrote Bunnix in Hare, in one month. There's the proof of concept. How about tiny toy Unix-likes in Zig, Nim, Crystal, Odin, D, Rust, Circle, Carbon,…
> Yes I know Ada is not a good fit Why? > https://en.wikipedia.org/wiki/TUNIS Interesting; do you know whether the source code is available somewhere?
No, sadly, I don't know of any.
You might ask co-developer Prof James Cordy: https://en.wikipedia.org/wiki/James_Cordy
Or approach the University of Toronto: https://www.utoronto.ca/
Re: Operating System in 1,000 Lines – Intro
#70Very delightful article. Based on my experience in "hobby" OS programming, I would add setting up GDB debugging as early as possible. It was a great help in my projects and an improvement over debugging with the QEMU monitor only. QEMU contains a built-in GDB server, you'll need a GDB client built for the target architecture (riscv in this case) and connecting to the QEMU GDB server over the network. https://qemu-pro…
Agree, and I'll add 3 other really useful QEMU features for osdev:
1) Record & Replay: Record an execution and replay it back. You can even attach GDB while replaying, and go back in time while debugging with "reverse-next" and "reverse-continue": https://qemu-project.gitlab.io/qemu/system/replay.html
2) The QEMU monitor, especially the "gva2gpa" and "xp" commands which are very useful to debug stuff with virtual memory
3) "-d mmu,cpu_reset,guest_errors,unimp": Basically causes QEMU to log when your code does something wrong. Also check "trace:help", there's a bunch of useful stuff to debug drivers