41–50 of 79 posts
Earlier quoted context omitted.
> microkernels aren't necessarily better than hybrid, they're slower, harder to debug and process management can be complicated I was basically on board, but how are they harder to debug? I'd think being able to run components in userspace would make debugging way easier.
You are now debugging a distributed system.
Earlier quoted context omitted.
>why in the heck is he going for POSIX compatibility Because existing desktop applications can be ported to ToaruOS >why not a safer microkernel, keeping everything in userspace? This is a design choice, microkernels aren't necessarily better than hybrid, they're slower, harder to debug and process management can be complicated
Isn't QNX a microkernel? I remember it being known for being quite fast?
Full disclosure: I maintain QNX toolchain.
Under features, the first bullet point is "Dynamically linked userspace." Can someone say what this means? How is this different than a userspace made up of dynamically linked utilities and shell?
Earlier quoted context omitted.
Just curious how hard it would be to forego POSIX entirely if you were building an OS. I know TempleOS is entirely from scratch. I'd like to implement a small LISP like SectorLISP [1] (see yesterday's posts too on HN). I don't know much about building my own OS, so I'd like to start with something like MenuetOS (my first PL was asm), SerenityOS, TempleOS, or this one. I'd like it to be completely an 'island', i.e. PO…
Someone who would make a new OS, should define a completely new system call interface, as it is likely that now it is possible to conceive a better interface than 50 years ago and anyway if it would not be different there would be no reason to make a new OS, instead of modifying an existing one. Nevertheless, the first thing after defining a new OS interface must be writing a POSIX API translation layer, to be able t…
> So there must exist some translation layer also for device drivers, maybe by running them in a virtual machine.
> ... but rewriting all the device drivers that could be needed would take years, so it is important to implement a way to reuse the existing device drivers.
I'd think most people making a hobby OS specifically want to do these things.
I also think most don't care about wide hardware compatibility.
Earlier quoted context omitted.
You need POSIX to compile nearly any program
True, and as another commenter hinted at, you're free to do your own hobby project however you please, there's not a wrong way to do so if you find it fulfilling. But at the same time, it does make me sad that most hobby OSes end up seeking POSIX compatibility, because that means being destined to essentially either be another unix-variant or develop a unix-variant inside some subsystem of your OS. Yes, being unix-li…
Earlier quoted context omitted.
>why in the heck is he going for POSIX compatibility Because existing desktop applications can be ported to ToaruOS >why not a safer microkernel, keeping everything in userspace? This is a design choice, microkernels aren't necessarily better than hybrid, they're slower, harder to debug and process management can be complicated
Just curious how hard it would be to forego POSIX entirely if you were building an OS. I know TempleOS is entirely from scratch. I'd like to implement a small LISP like SectorLISP [1] (see yesterday's posts too on HN). I don't know much about building my own OS, so I'd like to start with something like MenuetOS (my first PL was asm), SerenityOS, TempleOS, or this one. I'd like it to be completely an 'island', i.e. PO…
it looks pretty cool, although the url thing seems yet to prove its utility. they seem to be playing around a bit with using the protocol component (net, disk, etc), but it's unclear what this adds over just using paths. although maybe if they used the protocol to describe the encoding of the data, it would add something?
Earlier quoted context omitted.
Isn't QNX a microkernel? I remember it being known for being quite fast?
As a real-time OS it is known for deterministic response times. If it were exceptionally fast (and licenses cheap enough), you'd see hosts in the TOP500 using it.
Earlier quoted context omitted.
Someone who would make a new OS, should define a completely new system call interface, as it is likely that now it is possible to conceive a better interface than 50 years ago and anyway if it would not be different there would be no reason to make a new OS, instead of modifying an existing one. Nevertheless, the first thing after defining a new OS interface must be writing a POSIX API translation layer, to be able t…
> Writing a new OS is enough work, nobody would have time to also write file systems, compilers, a shell, a text editor, an Internet browser and so on. > So there must exist some translation layer also for device drivers, maybe by running them in a virtual machine. > ... but rewriting all the device drivers that could be needed would take years, so it is important to implement a way to reuse the existing device drive…
The volume of work for rewriting all these is many times larger than writing from scratch all the core of a new OS.
Rewriting them requires studying a huge amount of documentation and making experiments for the cases that are not clear. Most of this work is unlikely to present much interest for someone who wants to create an original OS, so avoiding most of it is the more likely way leading to a usable OS.
Earlier quoted context omitted.
>why in the heck is he going for POSIX compatibility Because existing desktop applications can be ported to ToaruOS >why not a safer microkernel, keeping everything in userspace? This is a design choice, microkernels aren't necessarily better than hybrid, they're slower, harder to debug and process management can be complicated
I'm very confused by this comment. There are a ton of other things you need to implement if you want to have desktop applications. POSIX does not specify any APIs for graphical applications. You might be thinking of something else. If you want to support the lion's share of desktop applications, it would actually be better to implement the Win32 API...
Earlier quoted context omitted.
I'm very confused by this comment. There are a ton of other things you need to implement if you want to have desktop applications. POSIX does not specify any APIs for graphical applications. You might be thinking of something else. If you want to support the lion's share of desktop applications, it would actually be better to implement the Win32 API...
Sorry, I meant software in general but wrote "desktop applications" instead. Anyway the sentence is still valid, even if you'll have to implement other things such as the graphical interface, the POSIX compliant code won't need modification