17 ms·

I'm very excited about this! Minoca is an interesting system, and I applaud any attempt to make driver-writing less inherently horrible. Minoca OS has been aro

I'm very excited about this! Minoca is an interesting system, and I applaud any attempt to make driver-writing less inherently horrible. Minoca OS has been around for a while, but the news is that they're GPLv3. I think that's a great thing! The MIT license is good for software that wants to permeate through everything, but for building a community, the GPL is a good idea. It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. I wonder when we will leave that behind? Or if we ever will? I'm glad POSIX is just a layer in Minoca, and not the base of the system, because these days it really should just be treated like a big wad of glue. PS: I love the object manager. I don't see any particularly ground-breaking networking stack, though. A plan9-inspired networked file system approach would have been amazing, but it seems this project is content with today's more typical approach. Perhaps it is just trying to be less opinionated about network structure than plan9 was? PPS: I'm terrible at organizing a comment. Maybe I need a blog.

barbs 10y ago
> It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. Curious - what are your main objections with POSIX? Is there another system you prefer?
- JasonSage 10y ago
  I mean, it sounds like his objection is that an operating system that doesn't have POSIX compatibility is dismissed out of hand. If we think of POSIX compatibility as something which is required in order for an operating system to be viable at any level, it means that there's a lot of energy in pioneering a new OS devoted to building up this compatibility simply so it can get some exposure. If we really want to encourage a fresh approach and disseminate new ideas, we need to move away from criterion like this and look more specifically at the principles and work being put forth and whether or not those are objectively successful or have merit. That's a much better way to move forward.
  - caf 10y ago
    I think if you were building an OS an an academic research exercise and publishing papers based on it, no-one would object to your results on the basis of a lack of POSIX compatibility. The criteria is different if you're writing an OS for practical use with wide adoption, though. There, backward-compatibility is rightly considered a positive attribute - there is much existing software in the world, and the entire point of a practical OS is after all to run the software that people use. Exactly the same situation exists with CPUs. If you come up with a new micro-architecture that you actually want to sell to customers, you'd better come to the party with a C compiler and a ported OS or three.
- gumby 10y ago
  The best thing about POSIX at this point is back compatibility, nothing to be sneered at! But it carries a lot of (in retrospect) bad habits and decisions from the 60s and 70s as well as a tendency to redundancy due to some competing standards that were unified and need for some back compatibility. Now not everyone agrees on what is good and what is bad, so some experimentation in this area is good for everyone. Examples of what bother me include the ludicrousness of ioctl(), messed up / redundant semaphore semantics, ditto for IPC, primitive memory mgmt semantics, fork() -- a great hack for its time but since it's 99.9999% of the time followed by exec() should be split into separate address space and thread management), outdated and simultaneously simplistic and baroque security model(s), and various IO issues to many to go into in a HN comment. But my loathed feature is undoubtably someone else's sacred cow. As I said, letting more flowers bloom is in everybody's interest.
  - CalChris 10y ago
    Well, I'm not going to disagree except to say that there are posix_spawn and vfork. I don't think anyone thinks the IPC solutions on offer are great but perhaps we should lower our expectations on that.
  - dom0 10y ago
    I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are ridiculously non-portable and painful to the point where you're better off just using "mkdir" - POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. This makes it painful and hard to implement proper text handling in many instances. This also leads to a lot of bad behaviours. - Memory management is IMHO lacking from a user space perspective. For example, it's practically impossible to implement a cooperative memory cache on this. To the best of my knowledge no OS has the necessary interfaces, though. - ioctl as you mentioned - SysV/POSIX IPC is so bad that no one ever bothered actually using it for anything - Personally I think it's a misleading API (conceptually, see above, the text example for example) almost to the point of deceptiveness. It's very easy to write correct looking programs that behave far from intended, especially in edge cases. IMHO code using it is practically unreviewable in everything but the most trivial cases. Non-portability is practically guaranteed, you have to test every platform. Portable code usually turns out to be quite ugly due to platform deficiencies and minor API incompatibilities.
rogerhoward 10y ago
Seems to me like POSIX compatibility is actually a cheap pass that gives you access to a huge software environment. Right on the homepage they mention already having packages for Python, Ruby, Git, Lua, and Node... would that, and thousands of other packages, be feasible without a workable POSIX layer?
- jprzybyl 10y ago
  > would that, and thousands of other packages, be feasible without a workable POSIX layer? I think my problem is the core concept. POSIX stands for Portable Operating System Interface (and X stands for Xtreme?). In an age where we spin up entire operating systems to start a single application, why are we defining portability at the operating system level when network portability works so much better? Keep in mind, this is also an age where systems like Qubes OS can make separate VMs cooperate with each other. The only sell for POSIX I can think of is performance, and I don't know if I buy it anymore. Why do programs have to be cross-compatible when the concept of an operating system no longer means owning the hardware?
  - dom0 10y ago
    > and X stands for Xtreme? The X in POSIX is for unIX. Kinda like a pun on all the *nix things that were floating around back then (Xenix, Minix, AIX, Sinix, Ultrix, IRIX, ...)
    - atsaloli 10y ago
      See "The origin of the name POSIX" https://stallman.org/articles/posix.html https://stallman.org/articles/posix.html
  - kevin_thibedeau 10y ago
    > why are we defining portability at the operating system level when network portability works so much better A lightweight POSIX-capable system has real value today. Operating systems need to be in more places than just the data center. IoT devices don't have the resources to run a VM or any other fancy containerized environment. POSIX was designed to be used on systems with comparable resources to what many embedded processors now have. It makes sense to leverage the existing codebase where possible.
tssva 10y ago
Microsoft has produced several successful operating systems without POSIX compatibility.
- bluejekyll 10y ago
  Not quite accurate: https://technet.microsoft.com/en-us/library/cc754351(v=ws.11).aspx https://technet.microsoft.com/en-us/library/cc754351(v=ws.11...
  - wamatt 10y ago
    Interix which later became, SFU (Windows Services for UNIX) and then finally SUA (Subsystem for Unix-based Applications) was initially developed in the 90's by Softway Systems, as an optional addon subsystem to the Windows family of OS's. For the record, it did not ship built-in or as part of the kernel. Even within Microsoft, it seemed the project was in perpetual life-support-mode. Still, I do feel a small pang of sadness. There was once a time in the early 2000's, where I would have loved to see this chimeral oddity succeed. [1] https://en.wikipedia.org/wiki/Interix https://en.wikipedia.org/wiki/Interix
    - mathw 10y ago
      And we now have the Windows Subsystem for Linux, which I believe is supposed to be entirely new, but carries on the strange saga of Windows and POSIX userspace coming together.
qznc 10y ago
You can use the Plan9 file system on Linux afaik. Still nobody cares. Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.
- i336_ 10y ago
  > You can use the Plan9 file system on Linux afaik. Still nobody cares. Actually, start QEMU with some special arguments and a directory path, and the Linux guest inside will be able to see the given directory as a read-write 9P filesystem, mountable with a single command. (New files get QEMU's UID unless QEMU is run as root.) > Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address. An incredibly good point, and why Plan 9 has zero adoption. :(

barbs 10y ago

> It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. Curious - what are your main objections with POSIX? Is there another system you prefer?

JasonSage 10y ago
I mean, it sounds like his objection is that an operating system that doesn't have POSIX compatibility is dismissed out of hand. If we think of POSIX compatibility as something which is required in order for an operating system to be viable at any level, it means that there's a lot of energy in pioneering a new OS devoted to building up this compatibility simply so it can get some exposure. If we really want to encourage a fresh approach and disseminate new ideas, we need to move away from criterion like this and look more specifically at the principles and work being put forth and whether or not those are objectively successful or have merit. That's a much better way to move forward.
- caf 10y ago
  I think if you were building an OS an an academic research exercise and publishing papers based on it, no-one would object to your results on the basis of a lack of POSIX compatibility. The criteria is different if you're writing an OS for practical use with wide adoption, though. There, backward-compatibility is rightly considered a positive attribute - there is much existing software in the world, and the entire point of a practical OS is after all to run the software that people use. Exactly the same situation exists with CPUs. If you come up with a new micro-architecture that you actually want to sell to customers, you'd better come to the party with a C compiler and a ported OS or three.
gumby 10y ago
The best thing about POSIX at this point is back compatibility, nothing to be sneered at! But it carries a lot of (in retrospect) bad habits and decisions from the 60s and 70s as well as a tendency to redundancy due to some competing standards that were unified and need for some back compatibility. Now not everyone agrees on what is good and what is bad, so some experimentation in this area is good for everyone. Examples of what bother me include the ludicrousness of ioctl(), messed up / redundant semaphore semantics, ditto for IPC, primitive memory mgmt semantics, fork() -- a great hack for its time but since it's 99.9999% of the time followed by exec() should be split into separate address space and thread management), outdated and simultaneously simplistic and baroque security model(s), and various IO issues to many to go into in a HN comment. But my loathed feature is undoubtably someone else's sacred cow. As I said, letting more flowers bloom is in everybody's interest.
- CalChris 10y ago
  Well, I'm not going to disagree except to say that there are posix_spawn and vfork. I don't think anyone thinks the IPC solutions on offer are great but perhaps we should lower our expectations on that.
- dom0 10y ago
  I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are ridiculously non-portable and painful to the point where you're better off just using "mkdir" - POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. This makes it painful and hard to implement proper text handling in many instances. This also leads to a lot of bad behaviours. - Memory management is IMHO lacking from a user space perspective. For example, it's practically impossible to implement a cooperative memory cache on this. To the best of my knowledge no OS has the necessary interfaces, though. - ioctl as you mentioned - SysV/POSIX IPC is so bad that no one ever bothered actually using it for anything - Personally I think it's a misleading API (conceptually, see above, the text example for example) almost to the point of deceptiveness. It's very easy to write correct looking programs that behave far from intended, especially in edge cases. IMHO code using it is practically unreviewable in everything but the most trivial cases. Non-portability is practically guaranteed, you have to test every platform. Portable code usually turns out to be quite ugly due to platform deficiencies and minor API incompatibilities.

rogerhoward 10y ago

Seems to me like POSIX compatibility is actually a cheap pass that gives you access to a huge software environment. Right on the homepage they mention already having packages for Python, Ruby, Git, Lua, and Node... would that, and thousands of other packages, be feasible without a workable POSIX layer?

jprzybyl 10y ago
> would that, and thousands of other packages, be feasible without a workable POSIX layer? I think my problem is the core concept. POSIX stands for Portable Operating System Interface (and X stands for Xtreme?). In an age where we spin up entire operating systems to start a single application, why are we defining portability at the operating system level when network portability works so much better? Keep in mind, this is also an age where systems like Qubes OS can make separate VMs cooperate with each other. The only sell for POSIX I can think of is performance, and I don't know if I buy it anymore. Why do programs have to be cross-compatible when the concept of an operating system no longer means owning the hardware?
- dom0 10y ago
  > and X stands for Xtreme? The X in POSIX is for unIX. Kinda like a pun on all the *nix things that were floating around back then (Xenix, Minix, AIX, Sinix, Ultrix, IRIX, ...)
  - atsaloli 10y ago
    See "The origin of the name POSIX" https://stallman.org/articles/posix.html https://stallman.org/articles/posix.html
- kevin_thibedeau 10y ago
  > why are we defining portability at the operating system level when network portability works so much better A lightweight POSIX-capable system has real value today. Operating systems need to be in more places than just the data center. IoT devices don't have the resources to run a VM or any other fancy containerized environment. POSIX was designed to be used on systems with comparable resources to what many embedded processors now have. It makes sense to leverage the existing codebase where possible.

tssva 10y ago

Microsoft has produced several successful operating systems without POSIX compatibility.

bluejekyll 10y ago
Not quite accurate: https://technet.microsoft.com/en-us/library/cc754351(v=ws.11).aspx https://technet.microsoft.com/en-us/library/cc754351(v=ws.11...
- wamatt 10y ago
  Interix which later became, SFU (Windows Services for UNIX) and then finally SUA (Subsystem for Unix-based Applications) was initially developed in the 90's by Softway Systems, as an optional addon subsystem to the Windows family of OS's. For the record, it did not ship built-in or as part of the kernel. Even within Microsoft, it seemed the project was in perpetual life-support-mode. Still, I do feel a small pang of sadness. There was once a time in the early 2000's, where I would have loved to see this chimeral oddity succeed. [1] https://en.wikipedia.org/wiki/Interix https://en.wikipedia.org/wiki/Interix
  - mathw 10y ago
    And we now have the Windows Subsystem for Linux, which I believe is supposed to be entirely new, but carries on the strange saga of Windows and POSIX userspace coming together.

qznc 10y ago

You can use the Plan9 file system on Linux afaik. Still nobody cares. Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.

i336_ 10y ago
> You can use the Plan9 file system on Linux afaik. Still nobody cares. Actually, start QEMU with some special arguments and a directory path, and the Linux guest inside will be able to see the given directory as a read-write 9P filesystem, mountable with a single command. (New files get QEMU's UID unless QEMU is run as root.) > Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address. An incredibly good point, and why Plan 9 has zero adoption. :(