I find LFS a better guide http://www.linuxfromscratch.org/lfs/
Operating System Development Series (2008)
11–20 of 38 posts
Re: Operating System Development Series (2008)
#12I find LFS a better guide http://www.linuxfromscratch.org/lfs/
Isn't this different since you're actually writing everything including the bootloader?
Re: Operating System Development Series (2008)
#13It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX.
There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the actual OS research? Where's the service-oriented OS built on capabilities with a typed object store for a filesystem?
Re: Operating System Development Series (2008)
#14It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX. There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the…
I expect it is because people who want to provide something like your service-oriented OS will do it as an application layer over existing operating systems.
This also gives them the flexibility to factor the problem into smaller bits. Cap'n Proto is a service-oriented something-or-other, built on capabilities and even typed objects. But it does not give a flying -ck about storage.
Re: Operating System Development Series (2008)
#15It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX. There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the…
I expect it is because people who want to provide something like your service-oriented OS will do it as an application layer over existing operating systems. This also gives them the flexibility to factor the problem into smaller bits. Cap'n Proto is a service-oriented something-or-other, built on capabilities and even typed objects. But it does not give a flying -ck about storage.
To be fair, Cap'n Proto is a sub-project of Sandstorm.io which is basically an operating system and cares deeply about storage. But Cap'n Proto can be used independently...
Re: Operating System Development Series (2008)
#16It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX. There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the…
I expect it is because people who want to provide something like your service-oriented OS will do it as an application layer over existing operating systems. This also gives them the flexibility to factor the problem into smaller bits. Cap'n Proto is a service-oriented something-or-other, built on capabilities and even typed objects. But it does not give a flying -ck about storage.
The issue is that all these bits and pieces are wonderful for developers, and to a lesser extent sysadmins, but not so wonderful for users, who still get to interact with their systems using much the same paradigm as when the first desktop operating systems came out.
The closest I can find would be Sandstorm, which ends up being a frankenstein mashup of Linux and a capability system.
Re: Operating System Development Series (2008)
#17Would it be possible to move more parts of the operating system into hardware to realize an improvement in speed? So for example say Microsoft announced Windows 10 was the perfect operating system and needed no new features/bug fixes would it make sense and would it be possible to realize the OS software in hardware?
In chapter 2 of the tutorial, he mentions Commodore DOS as being an OS which resides in ROM (read only memory), which means it's definitely possible. I'm just a laymen but I'd wager that there are some cases where this is still done.
But that's still just software stored in a ROM chip. I think what he meant was implementing the actual logic in silicon. Something like a hardwired CPU.
I'm not aware of such a machine.
Re: Operating System Development Series (2008)
#18Earlier quoted context omitted.
In chapter 2 of the tutorial, he mentions Commodore DOS as being an OS which resides in ROM (read only memory), which means it's definitely possible. I'm just a laymen but I'd wager that there are some cases where this is still done.
But that's still just software stored in a ROM chip. I think what he meant was implementing the actual logic in silicon. Something like a hardwired CPU. I'm not aware of such a machine.
Intel i432 had some of that (capabilities, garbage collection, multitasking, etc) but was crippled by a variety of problems—perhaps most of all that it was quite slow and expensive. It was originally intended to run a Smalltalk-like language, the name of which escapes me at the moment, but got retrofitted to run Ada. Unfortunately the Ada compiler for the i432 was awful, in addition to the slow hardware.
It was a pretty fascinating idea though.
Re: Operating System Development Series (2008)
#19It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX. There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the…
If you want something different, research SPIN OS with Modula-3, Oberon with Oberon [1].
The work done by Xerox with Interlisp-D, Smalltalk and Mesa/Cedar [2]
Or before Multics and UNIX were even born, the work done in Burroughs B5000. [3]
There are plenty more examples, one just needs to dive into the history of computing.
[0] - http://www-spin.cs.washington.edu/ [1] - http://www.projectoberon.com/ [2] - https://archive.org/details/bitsavers_xerox [3] - http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
Re: Operating System Development Series (2008)
#20Fun to see this popping up on the day I'm hacking on my own litte OS, intermezzOS.
There's lots of great stuff in this series, but it also exemplifies an issue with the hobby OSdev scene: it's almost all for protected mode, with some real mode stuff, and very little long mode stuff. This one does have great real mode stuff, though.
Protected mode is a bit simpler, which is nice. Hopefully over the next few years, the long mode stuff will come along. Most of the hobby OSes in Rust are in long mode.