6 ms·

Operating systems aren't that big, and if you know your stuff, I'm sure it's not too hard to pull off. Here's an example I borrowed from StackExchange: Accordi

Operating systems aren't that big, and if you know your stuff, I'm sure it's not too hard to pull off. Here's an example I borrowed from StackExchange: According to cloc run against 3.13, Linux is about 12 million lines of code. 7 million LOC in drivers/, 2 million LOC in arch/, and only 139 thousand LOC in kernel/. (http://unix.stackexchange.com/a/223753 http://unix.stackexchange.com/a/223753) Edit: Would be nice to have the numbers for the latest Minix release for comparison. Does anybody know how big their core team is? (The kernel is something like 15k LOC IIRC.)

Manishearth 11y ago
Btw, if anyone is interested in learning how to write an OS, and interested in Rust, check out https://intermezzos.github.io/ https://intermezzos.github.io/. It's a "learning OS" in Rust, with a companion book. Incomplete, but a good start.
- caipre 11y ago
  This looks outstanding, thanks for the link.
  - steveklabnik 11y ago
    Project lead here. I haven't had time in the last few weeks to work on this, so the book is pretty far behind the kernel itself at the moment. Playing the long game. I was hoping to do some more today, in fact...
    - BinaryIdiot 11y ago
      It looks really interesting! I'm going to be looking at it probably next weekend :)
      - steveklabnik 11y ago
        Awesome. Please open issues if anything is confusing!
    - caipre 11y ago
      I'm reading through now, and would love to contribute. I've been trying to break into this space (systems programming, especially OS and compilers) for a long time and the biggest hurdle for me has been to actually do it. I really appreciate that this project is focused on explaining just enough to jump in, complemented with nods to further resources that can add on to whatever knowledge the reader brings. Steve, thanks for all your work on this and with Rust. Your attitude toward teaching and your writing ability go a long way in encouraging people to learn and in having the lesson be worthwhile.
      - steveklabnik 11y ago
        Thanks so much. We had a few contributors at the start, but once I lost time, so did they. Would be very happy to have you involved :)
    - qz_ 11y ago
      This is great and so much clearer than osdev wiki. I've wanted to learn os development for quite some time and I think this is where I'll start.
      - steveklabnik 11y ago
        That is exactly my goal. Thanks :)
    - Animats 11y ago
      The "everything is a URL" concept is interesting. QNX uses pathnames in a somewhat similar way; programs with the privilege to do so can register to own some portion of the pathname space, and requests with such pathnames go to that program. The kernel has no idea what pathnames mean. This gets file systems out of the kernel. It looks like Redox is doing something similar, but not enough of the documentation is written yet for me to tell quickly.
      - steveklabnik 11y ago
        To be clear, lead on intermezzOS, not Redox. I do some small editing to their docs but don't regularly contribute.
    - deleted 11y ago
      [deleted]
- olalonde 11y ago
  http://littleosbook.github.io/ http://littleosbook.github.io/ is another good resource though it uses C.
iagooar 11y ago
Warning: I have no idea about systems programming. I understand that the amount of lines of driver code comes from the variety of devices. But still, it looks completely unbalanced, when compared to the kernel code itself. So I have some questions here: 1) Shouldn't there be common interfaces / abstractions for most of the devices? 2) If they exist, could they be improved somehow? 3) A bit unrelated, but how fun / interesting is it to develop driver code?
- bluecmd 11y ago
  There are. USB, SATA, SCSI and such share a lot of code between the drivers - but drivers are huge.
  - k__ 11y ago
    I would guess, that most of the size comes from history. Like, once it seemed a good idea to have it like that and later people found out there are a bunch of things missing. Now many of them have to be implemented on the driver side over and over again.
    - mrob 11y ago
      Have you read the USB specs recently? They're publicly available here: http://www.usb.org/developers/docs/ http://www.usb.org/developers/docs/ Just making a standards compliant implementation takes a huge quantity of code. And with a standard this complex people inevitably get it wrong, so you'll need workarounds for all the broken devices too.
      - tracker1 11y ago
        Not just with hardware interfaces, but even in pure software... I wrote an LMS that the core of which was used by a fortune 100 company, and a few airlines for nearly a decade... I literally left out about 1/3 of the SCORM spec, and implemented one piece badly... it wasn't until about 8 years in that the missing piece was even an issue, and the part I got wrong never became an issue. In the end, you understand as much as you can, implement what you have to, and do your best to get through it... and even then, someone will mess things up on some end or another... to this day, I'm surprised that SCORM was synchronous... hell, it feels like they're half the reason XHR has a sync option. I feel the same way when looking at terminal emulators... sigh, so many things to implement to get something useful, even if you're only looking to get a small subset working.
pmlnr 11y ago
Actually, they can be really small... http://kolibrios.org/ http://kolibrios.org/
zongitsrinzler 11y ago
Are you the guy that says stuff like "How hard can it be?" and "It shouldn't take that long" in meetings?
carussell 11y ago
> Does anybody know how big their core team is? Right now it's about 2.
jotux 11y ago
I worked at a company that made POS terminals on the OS development team. We had a proprietary OS based loosely on UNIX that was ~100KLOC (kernel). It was largely designed by 3-4 core developers and maintained by ~12 embedded software engineers (in addition to drivers, apps, UI, etc).

Manishearth 11y ago

Btw, if anyone is interested in learning how to write an OS, and interested in Rust, check out https://intermezzos.github.io/ https://intermezzos.github.io/. It's a "learning OS" in Rust, with a companion book. Incomplete, but a good start.

caipre 11y ago
This looks outstanding, thanks for the link.
- steveklabnik 11y ago
  Project lead here. I haven't had time in the last few weeks to work on this, so the book is pretty far behind the kernel itself at the moment. Playing the long game. I was hoping to do some more today, in fact...
  - BinaryIdiot 11y ago
    It looks really interesting! I'm going to be looking at it probably next weekend :)
    - steveklabnik 11y ago
      Awesome. Please open issues if anything is confusing!
  - caipre 11y ago
    I'm reading through now, and would love to contribute. I've been trying to break into this space (systems programming, especially OS and compilers) for a long time and the biggest hurdle for me has been to actually do it. I really appreciate that this project is focused on explaining just enough to jump in, complemented with nods to further resources that can add on to whatever knowledge the reader brings. Steve, thanks for all your work on this and with Rust. Your attitude toward teaching and your writing ability go a long way in encouraging people to learn and in having the lesson be worthwhile.
    - steveklabnik 11y ago
      Thanks so much. We had a few contributors at the start, but once I lost time, so did they. Would be very happy to have you involved :)
  - qz_ 11y ago
    This is great and so much clearer than osdev wiki. I've wanted to learn os development for quite some time and I think this is where I'll start.
    - steveklabnik 11y ago
      That is exactly my goal. Thanks :)
  - Animats 11y ago
    The "everything is a URL" concept is interesting. QNX uses pathnames in a somewhat similar way; programs with the privilege to do so can register to own some portion of the pathname space, and requests with such pathnames go to that program. The kernel has no idea what pathnames mean. This gets file systems out of the kernel. It looks like Redox is doing something similar, but not enough of the documentation is written yet for me to tell quickly.
    - steveklabnik 11y ago
      To be clear, lead on intermezzOS, not Redox. I do some small editing to their docs but don't regularly contribute.
  - deleted 11y ago
    [deleted]
olalonde 11y ago
http://littleosbook.github.io/ http://littleosbook.github.io/ is another good resource though it uses C.

iagooar 11y ago

Warning: I have no idea about systems programming. I understand that the amount of lines of driver code comes from the variety of devices. But still, it looks completely unbalanced, when compared to the kernel code itself. So I have some questions here: 1) Shouldn't there be common interfaces / abstractions for most of the devices? 2) If they exist, could they be improved somehow? 3) A bit unrelated, but how fun / interesting is it to develop driver code?

bluecmd 11y ago
There are. USB, SATA, SCSI and such share a lot of code between the drivers - but drivers are huge.
- k__ 11y ago
  I would guess, that most of the size comes from history. Like, once it seemed a good idea to have it like that and later people found out there are a bunch of things missing. Now many of them have to be implemented on the driver side over and over again.
  - mrob 11y ago
    Have you read the USB specs recently? They're publicly available here: http://www.usb.org/developers/docs/ http://www.usb.org/developers/docs/ Just making a standards compliant implementation takes a huge quantity of code. And with a standard this complex people inevitably get it wrong, so you'll need workarounds for all the broken devices too.
    - tracker1 11y ago
      Not just with hardware interfaces, but even in pure software... I wrote an LMS that the core of which was used by a fortune 100 company, and a few airlines for nearly a decade... I literally left out about 1/3 of the SCORM spec, and implemented one piece badly... it wasn't until about 8 years in that the missing piece was even an issue, and the part I got wrong never became an issue. In the end, you understand as much as you can, implement what you have to, and do your best to get through it... and even then, someone will mess things up on some end or another... to this day, I'm surprised that SCORM was synchronous... hell, it feels like they're half the reason XHR has a sync option. I feel the same way when looking at terminal emulators... sigh, so many things to implement to get something useful, even if you're only looking to get a small subset working.

pmlnr 11y ago

Actually, they can be really small... http://kolibrios.org/ http://kolibrios.org/

zongitsrinzler 11y ago

Are you the guy that says stuff like "How hard can it be?" and "It shouldn't take that long" in meetings?

carussell 11y ago

> Does anybody know how big their core team is? Right now it's about 2.

jotux 11y ago

I worked at a company that made POS terminals on the OS development team. We had a proprietary OS based loosely on UNIX that was ~100KLOC (kernel). It was largely designed by 3-4 core developers and maintained by ~12 embedded software engineers (in addition to drivers, apps, UI, etc).