"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.
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.)
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.
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.
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.
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.
> 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).
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).
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
https://harvey-os.org/
https://www.redox-os.org/