7 ms·

While I never used BeOS, and haven't tried Haiku either, I can't help but hope that something not Unix-based* gains some popularity sometime. At lot of the "inn

While I never used BeOS, and haven't tried Haiku either, I can't help but hope that something not Unix-based* gains some popularity sometime. At lot of the "innovation" happening in desktop OS's today seems incremental. In fact, I'd argue that there's a bit of a monoculture among the various Unix-derivatives that discourages radical changes, for compatibility reasons (which is reasonable). Though I don't think the various Linux distros and BSDs have all that much of a competitive effect on one another, anyway. Or have we reached a point where OS's aren't that interesting any more? * - Other than Windows, that is.

Millennium 14y ago
BeOS had some extremely interesting concepts, and I'd love to see Haiku gain some traction. I'm not sure whether or not to call it Unix-based, though. It certainly isn't based on any known Unix code-wise: it's not even written in C. But it does retain a Unix-like command line, and you can even get much of the GNU toolset for it.
- gecko 14y ago
  Haiku also, far more than BeOS ever did, follows POSIX. Porting Unix applications to Haiku is actually fairly easy these days.
  - pjmlp 14y ago
    POSIX UNIX applications == CLI, not much more.
- deleted 14y ago
  [deleted]
- ZenoArrow 14y ago
  "I'm not sure whether or not to call it Unix-based" Quoting the first comment..."something not Unix-based".
  - ZenoArrow 14y ago
    Why was my previous comment modded down? Haiku is no more Unix-based than Windows, i.e. they both have support for POSIX, but that's about it. BeOS was designed to leave behind the cruft from older systems, not build upon it.
- cturner 14y ago
  > it's not even written in C It was. The internals were entirely written in C. C++ was for application developers.
chimeracoder 14y ago
The problem is that it's seriously hard to improve meaningfully on Unix. Take a look at Plan 9, for example. Plan 9 (which is not Unix), was meant to be the 'next iteration' of Unix, taking the Unix philosophy to the next level. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs The reason Plan 9 failed to catch on, despite being strictly better, is because it didn't provide a significant enough improvement. With non-Unix OSes, you not only face the challenge of providing not just an improvement, but a significant improvement, but you also face the challenge of providing a complete toolset[0] that people have come to expect. Plan 9 mostly failed in this regard, despite not even deviating that much from Unix. I can't imagine how much work it would be to do the same 'from scratch'. [0]Let's not forget that the reason GNU tools (particularly gcc) caught on was precisely because they were able to provide this complete toolchain.
- babarock 14y ago
  Yes, thank you for mentioning Plan9, it's a wonderful example of the limits on current OS research. The arguments you give are spot on, I would only add the need for backwards compatibility, or at least the possibility of maintaining the huge and ever increasing volume of mission-critical systems running Unix (Banking systems, the financial world, the Internet, ...). However, while it's true that Plan9 failed to catch on, a lot of its ideas have been backported to Unix (/proc anyone?). I think that there's something there. Unix can be improved. But no one is going to look at your improvements if it breaks their existing systems.
  - zackelan 14y ago
    To put it another way - any potential future competitor to UNIX will have to include UNIX, via a POSIX compatibility layer. But that won't be enough, because of all the extensions to POSIX. So you really need a Linux compatibility layer (which we see that FreeBSD, for example, already has). So, if you want to make a better UNIX, no matter how good your idea is - you have to implement Linux as well, in addition to all your great ideas. At that point, maybe your time would be better spent working on Linux directly.
- 14y ago
sceadu 14y ago
http://herpolhode.com/rob/utah2000.pdf http://herpolhode.com/rob/utah2000.pdf

Millennium 14y ago

BeOS had some extremely interesting concepts, and I'd love to see Haiku gain some traction. I'm not sure whether or not to call it Unix-based, though. It certainly isn't based on any known Unix code-wise: it's not even written in C. But it does retain a Unix-like command line, and you can even get much of the GNU toolset for it.

gecko 14y ago
Haiku also, far more than BeOS ever did, follows POSIX. Porting Unix applications to Haiku is actually fairly easy these days.
- pjmlp 14y ago
  POSIX UNIX applications == CLI, not much more.
deleted 14y ago
[deleted]
ZenoArrow 14y ago
"I'm not sure whether or not to call it Unix-based" Quoting the first comment..."something not Unix-based".
- ZenoArrow 14y ago
  Why was my previous comment modded down? Haiku is no more Unix-based than Windows, i.e. they both have support for POSIX, but that's about it. BeOS was designed to leave behind the cruft from older systems, not build upon it.
cturner 14y ago
> it's not even written in C It was. The internals were entirely written in C. C++ was for application developers.

chimeracoder 14y ago

The problem is that it's seriously hard to improve meaningfully on Unix. Take a look at Plan 9, for example. Plan 9 (which is not Unix), was meant to be the 'next iteration' of Unix, taking the Unix philosophy to the next level. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs The reason Plan 9 failed to catch on, despite being strictly better, is because it didn't provide a significant enough improvement. With non-Unix OSes, you not only face the challenge of providing not just an improvement, but a significant improvement, but you also face the challenge of providing a complete toolset[0] that people have come to expect. Plan 9 mostly failed in this regard, despite not even deviating that much from Unix. I can't imagine how much work it would be to do the same 'from scratch'. [0]Let's not forget that the reason GNU tools (particularly gcc) caught on was precisely because they were able to provide this complete toolchain.

babarock 14y ago
Yes, thank you for mentioning Plan9, it's a wonderful example of the limits on current OS research. The arguments you give are spot on, I would only add the need for backwards compatibility, or at least the possibility of maintaining the huge and ever increasing volume of mission-critical systems running Unix (Banking systems, the financial world, the Internet, ...). However, while it's true that Plan9 failed to catch on, a lot of its ideas have been backported to Unix (/proc anyone?). I think that there's something there. Unix can be improved. But no one is going to look at your improvements if it breaks their existing systems.
- zackelan 14y ago
  To put it another way - any potential future competitor to UNIX will have to include UNIX, via a POSIX compatibility layer. But that won't be enough, because of all the extensions to POSIX. So you really need a Linux compatibility layer (which we see that FreeBSD, for example, already has). So, if you want to make a better UNIX, no matter how good your idea is - you have to implement Linux as well, in addition to all your great ideas. At that point, maybe your time would be better spent working on Linux directly.
14y ago

sceadu 14y ago

http://herpolhode.com/rob/utah2000.pdf http://herpolhode.com/rob/utah2000.pdf