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.
"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."
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.)
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.
OK... but at 45 degrees?
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).
Allowing portrait is exactly what 90 degree rotation means.
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.
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.
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.
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.
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.
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.