[HN Gopher] HelenOS: a microkernel-based, multiserver OS from sc...
___________________________________________________________________
HelenOS: a microkernel-based, multiserver OS from scratch
Author : nix23
Score : 149 points
Date : 2022-11-19 14:10 UTC (8 hours ago)
(HTM) web link (www.helenos.org)
(TXT) w3m dump (www.helenos.org)
| t43562 wrote:
| Symbian was multiserver and written in C++ - I cannot compare
| with HelenOS but the fact that there were separate server seemed
| to go hand in hand with asynchronous system calls which make
| Linux seem a bit primitive. I'm sure it caused a lot of problems
| in various ways too but I wasn't working on that at Symbian.
| nerdponx wrote:
| Maybe this is a silly question, but if people are building these
| from scratch as a hobby project, why don't we have GNU Hurd
| working yet? Is the problem nowadays that the goal has shifted
| from "make a kernel" to "make a kernel that's bug-for-bug
| compatibile with Linux including driver support"?
| yjftsjthsd-h wrote:
| I'm not an expert, but my understanding is that HURD made some
| uniquely poor choices that make it difficult to work with in
| ways that other microcernels don't necessarily suffer from.
| zasdffaa wrote:
| Be helpful if you could elaborate on those choices
| nix23 wrote:
| HURD (mach) -> Hurd-NG -> back to HURD (mach):
|
| http://walfield.org/papers/200707-walfield-critique-of-
| the-G...
|
| One step forward two steps back...and no actual progress,
| that kills a project who is in competition with something
| like linux (who is obviously not a perfect design but just
| pushes forward)
| tayistay wrote:
| Not a hobby project. Used for teaching at a university. See
| http://www.helenos.org/wiki/FAQ
| pjmlp wrote:
| Because it isn't cool to work on Hurd, most likely.
| nix23 wrote:
| It would be cool if they had a direction...aka let's build on
| mach...oh that's old let's make Hurd NG....wait even less
| people work on that one? ...ok let's get back to mach...and
| what do we do now?
|
| Having a kernel without goals is like a sandbox without
| having fun, no one cares.
| pjmlp wrote:
| I missed that that, yeah.
| pdw wrote:
| Why do you think that GNU Hurd isn't working? The Debian Hurd
| port is completely self-hosting and makes regular releases.
| [deleted]
| YPPH wrote:
| Related:
|
| _HelenOS 0.8_ - https://news.ycombinator.com/item?id=18833124 -
| Jan 2019 (55 comments)
|
| _HelenOS: portable microkernel-based multiserver operating
| system_ - https://news.ycombinator.com/item?id=15046249 - Aug
| 2017 (67 comments)
| dang wrote:
| Thanks! also this one I guess:
|
| _HelenOS GUI - experimental demonstration (2012)_ -
| https://news.ycombinator.com/item?id=12784350 - Oct 2016 (12
| comments)
|
| p.s. nice formatting. (I want to add software to offer to
| inline HN links in this format when people include links to
| past threads in their comments.)
| still_grokking wrote:
| https://github.com/plibither8/refined-hacker-news
|
| Install this and than look at the bottom of this page. :-D
| bluepoint wrote:
| http://www.helenos.org/wiki/FAQ
|
| I find the FAQ to be more enlightening than this page. It
| explains what it is used for (OS research research in Charles
| University, Prague) and how it is different than other operating
| systems (genode, minix, hurd).
| dang wrote:
| Ok, we've changed the URL from
| https://github.com/HelenOS/helenos to the project homepage.
| There's a link to the FAQ from there. Thanks!
| jiangplus wrote:
| What does it mean by being multiserver here?
| fulafel wrote:
| Some microkernel based systems have more monolithic designs
| where there's one big "most of the os" server that might be
| derived from a BSD or Linux kernel and the microkernel's role
| is more like a hypervisor.
| nix23 wrote:
| Like Gnu Hurd or Minix3:
|
| https://www.gnu.org/software/hurd/
|
| >>It is a collection of servers that run on the Mach
| microkernel to implement file systems, network protocols, file
| access control, and other features that are implemented by the
| Unix kernel or similar kernels
| johnisgood wrote:
| It is explained well on the Wikipedia page of MINIX 3[1]:
|
| > To achieve that, the code running in kernel must be minimal,
| with the file server, process server, and each device driver
| running as separate user-mode processes. Each driver is
| carefully monitored by a part of the system named the
| reincarnation server[2]. If a driver fails to respond to pings
| from this server, it is shut down and replaced by a fresh copy
| of the driver. In a monolithic system, a bug in a driver can
| easily crash the whole kernel. This is far less likely to occur
| in MINIX 3.
|
| [1] https://en.wikipedia.org/wiki/Minix_3
|
| [2]
| https://en.wikipedia.org/wiki/Minix_3#Reincarnate_dead_or_si...
| goodpoint wrote:
| Pity it's not under GPL.
| snvzz wrote:
| It is BSD, which is GPL compatible.
| vitiral wrote:
| Really cool stuff. It still uses GCC, which itself is several
| million lines of code. I wonder if they have a desire to port to
| something like QBE (~12k line backend) and cproc (~8k C frontend
| for QBE).
| nerdponx wrote:
| I've never heard of QBE before. It seems like a competitor to
| LLVM, is that accurate?
| forgotpwd16 wrote:
| Precisely. (Well competitors that can coexist.) There's a
| page on their site making a comparison:
| https://c9x.me/compile/doc/llvm.html.
| eqvinox wrote:
| Why would/should it be attempting to replace the compiler?
| vitiral wrote:
| It seems like it's trying to simplify the tech stack, so I
| thought it might be something the author was interested in.
| still_grokking wrote:
| I've tried quite some alternative OSes in local qemu VMs.
|
| HelenOS was one of the few that actually worked.
|
| It feels very snappy. Seems also quite robust. I didn't manage to
| crash it just by playing around, like it's the cases with most
| other "toy OSes".
|
| One of the most "promising" OS projects out there, imho.
| (Promising in the sense that it seems to be at least a serous
| project with constant progress since many years already).
| dleslie wrote:
| How did it compare to, say, Serenity and Haiku?
| still_grokking wrote:
| Serenity is still on the list of things I need to try out.
| Can't say anything about it at the moment.
|
| But I have to admit that regardless the hype around it I
| don't think that it's particularly interesting. I see it as
| just yet another Unix clone; with exactly zero innovation
| behind it. Even Redox, which I consider being a complete
| failure, tried some seemingly new concepts (and uses a micro
| kernel which makes it at least a little bit less
| "mainstream").
|
| Haiku is rock solid. Very interesting project! But I would
| not put it in the basket with toy or research OSes, though.
| It's based on something that had even quite some commercial
| success. But yes, Haiku is definitely an "alternative OS". It
| would have been better if I worded this part differently, I
| guess, as I'm mostly interested in "experimental" OS
| architectures and less in "random" alternative OSes. (So, for
| example I've never tried to run TempleOS, or such things;
| also I didn't put much effort to run historic ones, when they
| where just Unix clones; there are quite some of these out
| there I guess).
|
| Haiku is much more complete than HelenOS of course. You can
| do all the basic computer things with it. It has quite some
| applications. I still remember the time when BeOS, its
| successor, was actually even much more usable in a GUI
| setting than Linux, which barely run X and some fvwm2 windows
| with terminal emulators--whereas BeOS had fancy multi-media
| players and 3D graphics at that time. Haiku has this apps
| still, but that's much less impressive today of course.
|
| Haiku is for example much more polished than say Hurd. There
| is a "working" Debian/Hurd version out there. But it was so
| buggy last time I've tried! Things were constantly crashing
| or not working at all. The last time I've tried to run Haiku
| I didn't find anything that was servery broken there.
|
| HelenOS feels comparable stable to Haiku. But there is almost
| nothing besides the bare OS. I think it had a kind of "packet
| manager" the last time I've tried but this didn't work well
| for me. Also there were almost no applications available. But
| that's not a bad sign as I think the most work goes into the
| OS as such. Which is good! The few things that were there on
| the surface were like I've said snappy and working without
| crashes. Which is imho already an achievement when compared
| with a lot of other OS projects (e.g. Redox, Hurd, unikernel
| / library-OSes, or just a "tuned" Linux build ;-)).
| emfax wrote:
| Could you expand on why you think Redox is a failure? Maybe
| also what you think it got right and what it got wrong?
| JPLeRouzic wrote:
| >> _I still remember the time when BeOS, its successor..._
|
| English is not my native tongue but didn't you mean "
| _BeOS, its predecessor_ " ?
|
| BeOS lived from 1995 to 2001, and Haiku development started
| in 2001 with a first release in 2009.
|
| https://en.wikipedia.org/wiki/Haiku_(operating_system)#Rele
| a...
| still_grokking wrote:
| Oh, yes, of course!
|
| I'm also not a native speaker...
|
| I've expanded on my initial version and didn't double
| check the lengthy edit with some translation service
| because I didn't want to miss the edit window.
|
| But I guess the oversight should be clear form context.
| Can't edit it anyway.
|
| Thanks for pointing this mistake out! :-) (Now I going to
| check this particular word pair more thoroughly next
| time).
| robinsonb5 wrote:
| Oh nice! Hopefully it'll receive a RISC-V port at some point.
| intc wrote:
| > I ported the HelenOS kernel to RV64 in 2016, but I've never
| properly finished the user space support. I hope this board
| will be a good motivation for me to finally push the entire OS
| to the same level as x86-64
|
| https://twitter.com/mdecky/status/1397892220225736711
| snvzz wrote:
| Look into VisionFive2 and Star64.
|
| These aren't just faster than all SiFive's devboards to date,
| but also cheaper, under $100 mark.
|
| Shipping in the long thousands, instead of short hundreds.
| sedatk wrote:
| First thing I've noticed is the lack of a LICENSE file in the
| repository.
| GekkePrutser wrote:
| Wow multiserver, so it would seamlessly distribute tasks to
| different servers? That's really cool if I understand it
| correctly.
| chillfox wrote:
| Their webpage has this to say about it in the FAQ, so I would
| say nope.
|
| "Within the scope of microkernel operating systems, a
| multiserver spreads the operating system functionality over
| multiple user processes. Note how this differs from a single-
| server microkernel that concentrates all these functions into a
| single user process." - http://www.helenos.org/wiki/FAQ
| krylon wrote:
| It's not about clustering, "multiserver" in this context means
| that parts that are stuffed together in the kernel on Linux or
| BSD run in separate userspace processes (i.e. networking, file
| system, device drivers, ...). This approach gives better
| isolation of those components, so a bug in one is less likely
| to affect others, and if one crashes, it can potentially be
| restarted, while the rest of the system keeps running. If done
| right, it can also make these individual parts simpler.
|
| GNU/Hurd tries the same, but with POSIX compatibility and so
| far with mixed success. Other multiserver microkernel systems I
| know off are Minix and QNX. I'm sure there's more.
| mike_hearn wrote:
| Modern operating systems are all microkernel-ish to some
| extent. Linux can run filesystems in usermode processes,
| Windows does run the graphics subsystem in a separate
| process, macOS consists of tons of components running in
| various servers connected by Mach ports and is similar to
| Android in that they're moving drivers progressively out of
| the kernel into processes.
|
| The two classic examples of the networking stack and the
| filesystem generally don't move because they aren't buggy
| enough to be worthwhile, the performance hit is too great and
| because it's unreasonable to expect userland processes to
| cleanly handle a restart of things like that. Like, in 99.99%
| of real programs if every file descriptor is suddenly
| invalidated then that program will crash and the devs won't
| care if you report it as a bug because they'll say, yeah
| well, actually it's on you to fix your buggy OS not on us to
| code around it. Other platforms don't crash their network or
| FS driver every five minutes so why should we do extra work
| for yours?
|
| So the kernel vs microkernel distinction doesn't seem
| particularly relevant or interesting anymore, at least not to
| me.
| snvzz wrote:
| >the performance hit is too great
|
| I see this myth referenced a lot due to misconceptions
| constructed around design issues in early, pre-Liedtke
| microkernels (particularly Mach, used in IOS/OSX) leaving a
| long-lasting impression.
|
| L4 changed everything, and seL4 takes it to the next level.
|
| Some references:
|
| - https://archive.ph/30hhi
|
| - https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-
| sLGbw...
| pjmlp wrote:
| That is why Linux is run on top of hypervisors, alongside
| containers and kubernets orchestration engines, get to use
| that extra performance.
| forgotpwd16 wrote:
| Redox, Fuchsia, Genode, Helios/Ares, are some more recent
| examples.
| mananaysiempre wrote:
| No.
|
| "Multiserver" (a term from the microkernel literature) means
| that the conventional basic OS services are split into several
| "server" processes with distinct responsibilities (a mounted
| filesystem, a network card, perhaps a hardware bus, etc.). This
| is the original conception of a microkernel- (as opposed to
| e.g. an exokernel-) style system and its architectural promise,
| although it's not made necessary by the mere fact of being
| built on top of a microkernel: AFAIK L4Linux is a single server
| so the L4 microkernel basically acts as a simple VMM / HAL
| without further architectural benefits. (For other monolithic
| but userspace OS servers, look at wineserver in Linux, CSRSS
| and LXSS in Windows NT, etc. For multiserver systems of varying
| purity, look at QNX and Minix.)
|
| What you're thinking of is a "distributed OS", although those
| academic efforts look terribly naive from today's distributed
| consensus standpoint. Good points of entry may be Barrelfish
| and Plan 9.
| mycall wrote:
| How would you classify Genode wrt being a multiserver?
| als0 wrote:
| Amoeba is a famous example of a distributed OS
| https://en.wikipedia.org/wiki/Amoeba_(operating_system)
| _448 wrote:
| Apache Mesos, though not a ground up OS, it does have the
| aim of sharing resources across clusters.
| zasdffaa wrote:
| Apache Mesos is an OS??
| nix23 wrote:
| https://mesos.apache.org/
|
| >Apache Mesos abstracts CPU, memory, storage, and other
| compute resources away from machines
| forgotpwd16 wrote:
| Moreover it is also microkernel-based.
| api wrote:
| It's too bad this research didn't continue. Instead we got
| a giant tower of kludges including containers, Kubernetes,
| service meshes, endless API design problems, endless
| reinventing of data serialization and protocols, and so on.
| johnisgood wrote:
| Or something like
| https://en.wikipedia.org/wiki/Sprite_(operating_system)
| but with a microkernel!
| startupsfail wrote:
| Apparently Python was developed for Amoeba. So in a way
| some strands of that research continued.
| 1MachineElf wrote:
| I wish there was a way to run Ameboa and early Python
| together on QEMU, but the HTTP download links on the
| Ameboa site are down.
| mananaysiempre wrote:
| Try the FTP archive at
| https://archive.org/details/2014.11.ftp.cs.vu.nl maybe,
| it seems to have the Amoeba files (unlike
| mirrorservice.org, which only has the Minix ones). The
| ArchiveOS page at https://archiveos.org/amoeba/ linked
| from the Wikipedia page also has some.
| mananaysiempre wrote:
| The academic environment where that research was _the_
| thing to do if you wanted to do systems is the academic
| environment that produced Pike's "Systems Software
| Research Is Irrelevant"[1]. It seems to have succumbed to
| two relatively common afflictions, though I don't know of
| another case of both simultaneously:
|
| - Inbreeding of ideas: researchers inventing and solving
| problems noone actually has, without observing the
| discipline necessary to remain interesting and avoid
| emotional attachments (as is done in maths, with varying
| success). In the distributed OS case, the model in
| people's heads (including Pike's with Plan 9!) seems to
| have been a closed campus network, which is close to some
| of the areas people care now, but still isn't quite any
| of them. The social problem of the system not being able
| to take over the world, thus necessitating explicitly
| specified protocols and loose coupling, also does not
| seem to have received much consideration. (Except for
| Microsoft, who has tried--deliberately or accidentally--
| to weaponize the homogeneity requirements of some of that
| research in building Windows domain networking.) Some of
| the kludges aren't--they are solving social problems.
|
| - Being before its time: sounds glorious and heroic, in
| reality makes people cold, lonely, and more often than
| not broke. The most commonly known instances of this are
| for individuals (or other actors capable of having a
| coherent volition, such as companies), but the
| distributed OS story feels like this happened to the
| community as a whole.
|
| [1] http://doc.cat-v.org/bell_labs/utah2000/utah2000.html
| mike_hearn wrote:
| Great document, thanks for the link.
|
| I think the main issue is actually more related to the
| trend in academia in which the 'least publishable unit'
| is ever more important. Pike's essay touches on this.
| Coming up with an interesting new OS design is hard, and
| implementing one is worse, so people don't try because
| it'd take too long and there wouldn't be enough papers in
| it for anyone. Companies still do OS research (see
| Singularity and Midori by Microsoft, Fuschia by Google)
| but don't publish much about it.
|
| The problem is to become sustainable you need users, and
| to get users you really have to be above the core OS
| these days because that's where you can focus on concepts
| instead of getting distracted by kernel and driver
| writing (not much interesting to do there). If you want
| to experiment with microkernels, do it as a collection of
| processes in the Linux userland and if you want to extend
| that to get users, make it run on Windows too. Chrome is
| in effect a kind of microkernel-ish operating system,
| seen from this perspective. It consists of a pile of
| sandboxed components connected by a sophisticated IPC
| system called Mojo. It also handles properly cases that
| microkernel research sometimes ignores or punts to the
| user, like how to gracefully handle if the other end of a
| connection crashes.
|
| I feel strongly that there's still lots of interesting
| research to do in the operating systems space but if I
| were to do it, I would _not_ start by writing an actual
| OS. I 'd start by exploring the ideas as an set of
| ordinary programs that could run on a regular OS.
| Maximize the window and start gradually eliminating
| dependencies on high level APIs provided by the host, if
| you really want to. Then you can explore concepts like
| single address space OS's, ultra-fine-grained
| microkernels, better shells, polyglot programming,
| distributed computing etc, without getting bogged down by
| irrelevant detail.
| [deleted]
___________________________________________________________________
(page generated 2022-11-19 23:00 UTC)