Live data from Hacker News

Operating System in 1,000 Lines – Intro

operating-system-in-1000-lines.vercel.app

91–100 of 129 posts

Re: Operating System in 1,000 Lines – Intro

#91
post #36

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…

Nice project, short and concise enough for an undergrad to learn basic os concept and implementation.

Re: Operating System in 1,000 Lines – Intro

#92
post #36

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!

Re: Operating System in 1,000 Lines – Intro

#93
post #34

Very 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…

> you'll need a GDB client built for the target architecture

Thankfully, GDB has a multiarch build these days which should work for all well-behaved targets in a single build.

(the place it is known to fail is for badly-behaved (embedded?) targets where there are configuration differences but no way to identify them)

Re: Operating System in 1,000 Lines – Intro

#94

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.

Thank you for the tip!

Re: Operating System in 1,000 Lines – Intro

#95
post #51

This is on my to do list of things to learn but I also don't know yet the purpose other than it being your own. Maybe security since most of what I work with is on top of the OS eg. programming languages. Maybe for RTOS applications at any rate this and OS Dev good resources.

I find this kind of thing most useful for microcontrollers and real-time embedded systems that don't require full networking. I've used many of these concepts but maybe not all at once on what many would call "bare metal" systems with no OS. Audio gizmos like cheap synths, LED nodes, things you want booting really fast with well-bounded functionality. An OS can get in the way with this kind of system if all you really need is some timers and simple I/O. You may still want a primitive scheduler, sane interrupt dispatching, and filesystems.

Re: Operating System in 1,000 Lines – Intro

#96
post #60
post #36

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 Or like building your temple so you can talk to God directly

We won't know until we try.

Re: Operating System in 1,000 Lines – Intro

#97
post #36

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…

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/

Re: Operating System in 1,000 Lines – Intro

#98
post #36

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. :)

Re: Operating System in 1,000 Lines – Intro

#99
post #34

Very 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 mem…

Record & replay sounds really nice, but the actual reverse-debugging is broken, see https://gitlab.com/qemu-project/qemu/-/issues/2634

Re: Operating System in 1,000 Lines – Intro

#100
post #78

Earlier quoted context omitted.

> Dijkstra famously said that programmers who started with BASIC are "mentally mutilated" He knew how to make friends.

To be fair, he was talking about classic BASIC which didn't even have user defined procedures but just goto and gosub similar to jumps and calls in assembly language. I remember when I started learning Pascal after BASIC on the Apple II and there was so much to unlearn about programming because how you wrote BASIC was so different from any other high level programming language.

No point trying to justify what he said, history has proved him wrong.

This industry was built on foundations laid down by people who started by with basic on 8 bit systems.

Post reply on HN