HelenOS 0.8(helenos.org)
helenos.org
HelenOS 0.8
http://www.helenos.org/wiki/ReleaseNotes/0.8.0
8 comments
Just had a look over Harvey OS, looks like a pretty neat direction to take Plan 9.
But it got me wondering, is there any shared collaberation between any of the next-gen 'Plan 9-like' OS's like 9atom, 9front and Harvey OS?
Also, it looks as though Harvey OS is only using Slack for its discussion forum, which is a bit odd for an open source project.
But it got me wondering, is there any shared collaberation between any of the next-gen 'Plan 9-like' OS's like 9atom, 9front and Harvey OS?
Also, it looks as though Harvey OS is only using Slack for its discussion forum, which is a bit odd for an open source project.
9front views HarveyOS with scorn and I don't think 9atom is developed.
why is that? got any references?
HarveyOS is "plan 9 with gcc" but 9front doesn't like gnu stuff. See cat-v, suckless, and their IRC channel.
ah, yes, i can see the problem.
For those who, like me, wondered "what's HelenOS?" and got little idea from release notes: http://www.helenos.org/wiki/About
Note the following, from the FAQ page (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."
"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."
Unfortunately, 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.
It it wasn't different enough to make porting software difficult, it probably wouldn't be different enough to bother making.
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.
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.)
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.)
Tiny nitpick but the screenshot showing an application window rotated ~45 degrees is a little terrifying. Why would that be allowed?
Why shouldn't it be allowed?
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.
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.
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.
exactly, just like it would be rather easy to add to any compositor based system like it's common now on linux.
> Every feature has a cost. Not just cost to develop, but cost to maintain.
A generic implementation that handles any orientation could just be the implementation with lower development and maintenance costs?
> surely it’s clear why not supporting arbitrary display orientations is at the very least an extremely rational choice from an engineering perspective.
That depends on the engineer. For some it might be easier to consider the special cases (landscape and portrait) first while others don't even want to be bothered with them until optimization time because a generic solution is the more straight forward approach.
A generic implementation that handles any orientation could just be the implementation with lower development and maintenance costs?
> surely it’s clear why not supporting arbitrary display orientations is at the very least an extremely rational choice from an engineering perspective.
That depends on the engineer. For some it might be easier to consider the special cases (landscape and portrait) first while others don't even want to be bothered with them until optimization time because a generic solution is the more straight forward approach.
You assume that everyone has their monitors the way you do.
At work, I have two large 16:9 monitors rotated in portrait orientation (tall), so this would be useful to me.
Currently macOS only allows 90-degree rotation increments. This allows you to have your monitor in portrait orientation, or mounted from the ceiling or a shelf, hanging upside down so there's nothing taking up space on the desk in front of you.
I've been in a couple of events in the field where having arbitrary application window rotation would have been nice because there was no place flat to put the monitors.
At work, I have two large 16:9 monitors rotated in portrait orientation (tall), so this would be useful to me.
Currently macOS only allows 90-degree rotation increments. This allows you to have your monitor in portrait orientation, or mounted from the ceiling or a shelf, hanging upside down so there's nothing taking up space on the desk in front of you.
I've been in a couple of events in the field where having arbitrary application window rotation would have been nice because there was no place flat to put the monitors.
I suspect this is to show off the compositing GUI: I recall this sort of things in screenshots of compiz/beryl when compositing window managers were new to Linux.
> Currently macOS only allows 90-degree rotation increments.
Windows has supported landscape/portrait switching since forever, I think it was already there in windows XP almost two decades ago, if not it was in 7 for sure (and it's in 10 since I use it right now).
Windows has supported landscape/portrait switching since forever, I think it was already there in windows XP almost two decades ago, if not it was in 7 for sure (and it's in 10 since I use it right now).
Landscape-portrait switch _is_ 90-degree. Parent poster is pointing out that this OS supports finer grained orientation rotations.
True though this may be, the quoted parent did not say "only macOS allows". They're asserting that on macOS, the only available options are in 90-degree increments.
> > Currently macOS only allows 90-degree rotation increments.
> Windows has supported landscape/portrait switching since forever, I think it was already there in windows XP almost two decades ago, if not it was in 7 for sure (and it's in 10 since I use it right now).
Allowing portrait is exactly what 90 degree rotation means.
> Windows has supported landscape/portrait switching since forever, I think it was already there in windows XP almost two decades ago, if not it was in 7 for sure (and it's in 10 since I use it right now).
Allowing portrait is exactly what 90 degree rotation means.
Windows has supported landscape/portrait switching since forever, I think it was already there in windows XP almost two decades ago, if not it was in 7 for sure (and it's in 10 since I use it right now).
I wasn't trying to make a comparison to Windows, or start an OS war. I'm not sure why you even brought up Windows, since this discussion is about HelenOS.
But for what it's worth, Macs have supported portrait mode since 1989†, back when Microsoft was still pushing Windows 2.
† https://everymac.com/monitors/apple/classic_monitors/specs/a...
I wasn't trying to make a comparison to Windows, or start an OS war. I'm not sure why you even brought up Windows, since this discussion is about HelenOS.
But for what it's worth, Macs have supported portrait mode since 1989†, back when Microsoft was still pushing Windows 2.
† https://everymac.com/monitors/apple/classic_monitors/specs/a...
My bad, for some reason I read "only macOS" instead of "macOS only"
> At work, I have two large 16:9 monitors rotated in portrait orientation (tall), so this would be useful to me.
OK... but at 45 degrees?
OK... but at 45 degrees?
To easily change timezone on an analog display clock? ;-)
I've been in a couple of events in the field where having arbitrary application window rotation would have been nice because there was no place flat to put the monitors.
Non-desk applications: vehicle, industrial, marine.
oooooh, stays steady with the boat pitching/rolling
You don't want that.
With the boat pitching and rolling, so does the people on board looking at the instruments, so having the instrument tilt would be rather disorienting! as if sailing by itself isn't disorienting enough. ;)
Yes! I meant more, you have awkward spaces to fill and it may be convenient to mount a panel at some odd angle but still have it display things aligned with the floor.
It is just a demo of compositor effects; pretty much just a lo-fi version of classic Compiz wobbly windows and rotating cube.
IIRC, You could also do this in Squeak (a Smalltalk implementation).
I was an audio visual technician for years, and we had quite regularly requests to stick monitors at weird angles for visual effect. I could have definitely used this feature to do some cool looking stuff.
I like the concept. It sounds like a modern take on some of the plan9 ideas. Decoupling of system components into components that work together through a message passing framework.
Sounds a bit like QNX actually
Is QNX used anywhere? Sounds interesting.
It's in millions of devices. Blackberry acquired them IIRC. You don't run across it much on HN because it's a standard commercial license.
[deleted]
I’ve seen other comments describe QNX being used in embedded systems needing rock solid performance.
Is there a 'distrowatch' for OSes other than Linux/BSD-based? I can't keep up with them all anymore.
There are sometimes articles here about "off-the-beaten-track" OS: https://www.osnews.com/
osnews.com was once pretty good, but I haven't read it in a while and they did have some recent problems.
Yikes, it does seem like OSnews have had a rocky few days. (TLDR: "It certainly seems like we’ve had a breach.")
https://www.osnews.com/story/128924/what-happened-here/
To their credit, it looks like they're now trying to find ways to run the site profitably, so they can pay people to maintain the site part/full-time instead of relying on volunteer help.
https://www.osnews.com/story/128924/what-happened-here/
To their credit, it looks like they're now trying to find ways to run the site profitably, so they can pay people to maintain the site part/full-time instead of relying on volunteer help.
Interesting. Anyone got this running on a Raspberry Pi?
How is it different from [Minix3][1]? It seems to accomplish the exactly same goal.
[1](https://www.minix3.org/)
[1](https://www.minix3.org/)
You mean because they are both microkernels? In that sense windows and Linux accomplish the same goal as well.
What kinds of tasks are slower on a micro-kernel? Are there use-cases where a micro-kernel is just as fast as a monolithic?
> What kinds of tasks are slower on a micro-kernel?
Crossing from usermode to kernel is slower, and generally doing complex things in kernel is much slower. (Where complex means cross-cutting concerns, so multiple different kernel processes need to be involved.)
> Are there use-cases where a micro-kernel is just as fast as a monolithic?
Anything that doesn't really involve the kernel much at all, and things that take a lot of time in kernel but do so in one part of it with no need for input from other parts.
Generally, when you go for a microkernel you need to accept that it will be slower than monolithic. It might still be worth it for the advantages of microkernels, namely being easier to verify, understand and secure.
Crossing from usermode to kernel is slower, and generally doing complex things in kernel is much slower. (Where complex means cross-cutting concerns, so multiple different kernel processes need to be involved.)
> Are there use-cases where a micro-kernel is just as fast as a monolithic?
Anything that doesn't really involve the kernel much at all, and things that take a lot of time in kernel but do so in one part of it with no need for input from other parts.
Generally, when you go for a microkernel you need to accept that it will be slower than monolithic. It might still be worth it for the advantages of microkernels, namely being easier to verify, understand and secure.
The basic issue is that, when you make a syscall in most kernels, it needs to do permission/capability checks.
With a micro kernel, it’s more or less inevitable that you have a lot more traffic in and out of the kernel so the overhead tends to be higher.
If your application doesn’t make a lot of syscalls then you won’t have the issue so much e.g. something very compute heavy.
You mitigate the issues, on the kernel side, by making the checks as fast as possible and removing them if it’s safe. On the userspace side, you try to avoid syscalls in performance critical code. Like you would with a monolithic kernel.
With a micro kernel, it’s more or less inevitable that you have a lot more traffic in and out of the kernel so the overhead tends to be higher.
If your application doesn’t make a lot of syscalls then you won’t have the issue so much e.g. something very compute heavy.
You mitigate the issues, on the kernel side, by making the checks as fast as possible and removing them if it’s safe. On the userspace side, you try to avoid syscalls in performance critical code. Like you would with a monolithic kernel.
https://harvey-os.org/
https://www.redox-os.org/