5 ms·

For those who, like me, wondered "what's HelenOS?" and got little idea from release notes: http://www.helenos.org/wiki/About http://www.helenos.org/wiki/About

yjftsjthsd-h 8y ago
Unfortunately, http://www.helenos.org/wiki/DiffFromUnix http://www.helenos.org/wiki/DiffFromUnix presents it as different enough to make porting software difficult. On the other hand, they say they've got GCC and Python, so it's doable.
- AnIdiotOnTheNet 8y ago
  It it wasn't different enough to make porting software difficult, it probably wouldn't be different enough to bother making.
- asveikau 8y ago
  I am frankly not very impressed with a quick glance at the networking API. What they show would not be difficult to implement as a library atop sockets, and I'm not convinced their callbacks capture the full flexibility of the old APIs. Meanwhile not providing at least a wrapper to handle the most simple socket scenarios to aid in porting strikes me as a bit stubborn. They determined a priori to hate sockets and that's it.
- elihu 8y ago
  Some of those actually sound like nice improvements. I think the Unix-style API is in need of a bit of modernization, and it's nice to see someone trying some minor adjustments. If users need a plain Linux-compatible API, then presumably someone will build a library to handle that. No need to make the raw system call API exactly the same as Linux just for historical compatibility reasons, especially when the opportunity presents itself to clean things up a little. (I could rant at considerable length about what I would change if I were creating a system-call interface from scratch.)
toyg 8y ago
Note the following, from the FAQ page (http://www.helenos.org/wiki/FAQ#WhatisHelenOSusedfor http://www.helenos.org/wiki/FAQ#WhatisHelenOSusedfor): "At this point we don't consider HelenOS usable for something different than development and research, but we're getting very close to the point where it will be usable for something really practical."
warent 8y ago
Tiny nitpick but the screenshot showing an application window rotated ~45 degrees is a little terrifying. Why would that be allowed?
- jstanley 8y ago
  Why shouldn't it be allowed?
  - mwfunk 8y ago
    Every feature has a cost. Not just cost to develop, but cost to maintain. Every feature has a benefit- how useful is it, for how many users? If the cost outweighs the benefit, then it shouldn’t be allowed, for the sake of keeping the code maintainable and minimally fragile. Portrait orientation for displays isn’t unheard of, but it’s very very uncommon amongst even technical users. I’m sure a bunch of people reading this have all sorts of anecdotal evidence otherwise- congrats, you’re special, and either have very specialized needs or want to cosplay as someone with very specialized needs (usually the latter). But that’s portrait orientation. That’s on the cusp of not meeting the bar for being worthwhile to support, but in general most OSes err on the side of supporting it for certain pro users. Extend that it into arbitrary rotations and you’re dealing with a feature that is way, way more niche than supporting portrait mode, and way more complicated than people might think. All for a feature that has no justification other than, “if it can be done, why not? Might as well right?!?” Now, maybe there are other benefits that I’m not aware of or taking into account, but surely it’s clear why not supporting arbitrary display orientations is at the very least an extremely rational choice from an engineering perspective.
    - im_down_w_otp 8y ago
      I understand what you're getting at here, but it's also possible that this wasn't a directly pursued feature, and may have just naturally fallen out trivially from their display system's architecture & implementation as a by-product. If so, then the cost would be to exclude the capability explicitly.

yjftsjthsd-h 8y ago

Unfortunately, http://www.helenos.org/wiki/DiffFromUnix http://www.helenos.org/wiki/DiffFromUnix presents it as different enough to make porting software difficult. On the other hand, they say they've got GCC and Python, so it's doable.

AnIdiotOnTheNet 8y ago
It it wasn't different enough to make porting software difficult, it probably wouldn't be different enough to bother making.
asveikau 8y ago
I am frankly not very impressed with a quick glance at the networking API. What they show would not be difficult to implement as a library atop sockets, and I'm not convinced their callbacks capture the full flexibility of the old APIs. Meanwhile not providing at least a wrapper to handle the most simple socket scenarios to aid in porting strikes me as a bit stubborn. They determined a priori to hate sockets and that's it.
elihu 8y ago
Some of those actually sound like nice improvements. I think the Unix-style API is in need of a bit of modernization, and it's nice to see someone trying some minor adjustments. If users need a plain Linux-compatible API, then presumably someone will build a library to handle that. No need to make the raw system call API exactly the same as Linux just for historical compatibility reasons, especially when the opportunity presents itself to clean things up a little. (I could rant at considerable length about what I would change if I were creating a system-call interface from scratch.)

toyg 8y ago

Note the following, from the FAQ page (http://www.helenos.org/wiki/FAQ#WhatisHelenOSusedfor http://www.helenos.org/wiki/FAQ#WhatisHelenOSusedfor): "At this point we don't consider HelenOS usable for something different than development and research, but we're getting very close to the point where it will be usable for something really practical."

warent 8y ago

Tiny nitpick but the screenshot showing an application window rotated ~45 degrees is a little terrifying. Why would that be allowed?

jstanley 8y ago
Why shouldn't it be allowed?
- mwfunk 8y ago
  Every feature has a cost. Not just cost to develop, but cost to maintain. Every feature has a benefit- how useful is it, for how many users? If the cost outweighs the benefit, then it shouldn’t be allowed, for the sake of keeping the code maintainable and minimally fragile. Portrait orientation for displays isn’t unheard of, but it’s very very uncommon amongst even technical users. I’m sure a bunch of people reading this have all sorts of anecdotal evidence otherwise- congrats, you’re special, and either have very specialized needs or want to cosplay as someone with very specialized needs (usually the latter). But that’s portrait orientation. That’s on the cusp of not meeting the bar for being worthwhile to support, but in general most OSes err on the side of supporting it for certain pro users. Extend that it into arbitrary rotations and you’re dealing with a feature that is way, way more niche than supporting portrait mode, and way more complicated than people might think. All for a feature that has no justification other than, “if it can be done, why not? Might as well right?!?” Now, maybe there are other benefits that I’m not aware of or taking into account, but surely it’s clear why not supporting arbitrary display orientations is at the very least an extremely rational choice from an engineering perspective.
  - im_down_w_otp 8y ago
    I understand what you're getting at here, but it's also possible that this wasn't a directly pursued feature, and may have just naturally fallen out trivially from their display system's architecture & implementation as a by-product. If so, then the cost would be to exclude the capability explicitly.