> Can we achieve parity with what what operating systems are used for in today’s world, but with less code, and with fewer pain points? Can we do better? We’d like to try.
Yet Another OS With the Vague Impossible-To-Evaluate Benefit of 'Newness'
edit: not to suggest I have a problem with people trying new things, but rather...why not write up a little essay on the architectural decisions you've made and their impact before releasing it publicly?
Their competition is dsl, arch, raspbarrien and other small/IoT OSs. Not to say their product is worse. But why are they forking instead of supporting existing technologies?
Not saying their work isnt useful. But theres an argument to be made for "why"?
Because taking away mindshare instead of consolidating efforts hurts all parties. Competition is often good when done for very good reasons, iojs vs nodejs, proprietary goals vs purely open source. Their goal is the same goal as many other projects however, instead of supporting those projects they are releasing their own which will likely have to go through a LOT of growing pains to compete with current projects. Simply releasing your own OS (written by two guys) seems naive at best and arrogant at worst.
Please post a link to your microkernel, papers, and any books you have published on the subject so I can learn why monolithic kernels are boring and how to do it better. Thanks.
It depends; if gp has actual things to back-up what they're saying, then I'd actually like to read them. I'm interested in monokernels because of Haiku, but I'm definitely not an expert.
OTOH, somebody releases a whole OS and the response is "Snore! It isn't a microkernel." - Ok, so...why?
Start at "The Paper" here to skip past Linus vs Tannenbaum politics stuff. He describes the common counterpoints and shows with evidence, including existing systems, that they're not as big a deal as people say.
Animats and I think QNX is probably best of commercial ones in balancing all kinds of tradeoffs. It's been used for decades as a self-healing RTOS with good performance. First link is their description of it with second a demo of a product with QNX inside showing how fast it can be on non-desktop hardware.
Open-source one aimed at reliability & legacy compatibility you can play with. Took UNIX decades to get reliable despite all the labor but Minix 3's foundation did it with a handful of people over a few years. That's saying something.
Another FOSS one that aims at high-security integrating many best-of-breed components from CompSci like Nitpicker GUI and seL4 microkernel. First link is descriptive slides with second the actual site. This one is still new so will have bugs.
Finally, it's worthwhile to throw in an exemplary one from capability-security that further isolates things with self-healing properties. Based on commercially successful KeyKOS system on mainframes. No longer maintained but docs and GPL code still available for study or revival. Paper also describes other capability kernels.
So, there's you a few days worth of reading and a few years worth of thinking to do. Hope it helps shed light on why almost every safety- or security-critical system that ever did well in reliability or security was a microkernel-based system. These days, high-assurance is looking at eliminating even it with CPU's with built-in security, compiler techniques for automated safety/security, and DSL's for easy formal verification of OS or system components. Until that's finalized & while using t...
Appreciate it. I try to stay evidence-driven. :) For extra data, Google Gernot Heiser with "L4," microkernel, or OKL4 terms + "evaluation" or "performance." He published lots of comparisons as they put it on lots of phones.
Oh please. You have to start somewhere and this is where they're starting. By comparison, Linus' first announcement was:
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby,
won't be big and professional like gnu) for 386(486) AT
clones. This has been brewing since april, and is
starting to get ready. I'd like any feedback on things
people like/dislike in minix, as my OS resembles it
somewhat (same physical layout of the file-system
(due to practical reasons) among other things).
I've currently ported bash(1.08) and gcc(1.40),
and things seem to work. This implies that I'll get
something practical within a few months, and
I'd like to know what features most people would want.
Any suggestions are welcome, but I won't promise I'll
implement them :-)
Linus (torv...@kruuna.helsinki.fi)
PS. Yes - it's free of any minix code, and it has a
multi-threaded fs. It is NOT protable (uses 386 task
switching etc), and it probably never will support
anything other than AT-harddisks, as that's all I
have :-(.
I don't think this is a first release announcement, it's been around for several years. This is the announcement that they are releasing the code under GPLv3. Previously it was closed source.
They want an OS that's smarter about power management and easier to maintain. They describe their high-level objectives in their FAQ:
Why is a new operating system necessary?
...The design requirements of today's devices have drastically evolved in areas of power management, security, serviceability, and virtualization... By starting from a clean slate, Minoca OS is able to incorporate those core tenets into the very fabric of the operating system...
How is Minoca OS different from other operating systems?
...One of the most noticeable differences at the kernel level is the uniform driver model, which provides a maintainable interface between the kernel core and device drivers... Another very noticeable difference is our strong emphasis on the kernel development environment. Being able to step through code in the kernel, boot environment, and even firmware was something we felt was critical to quickly developing and maintaining kernel-quality code...
We took a look at the operating systems out there, and realized it had been over 25 years since the major operating systems had been written. 25 years is a long time to accumulate baggage, not to mention the leaps and bounds by which the hardware has evolved during that time.
Amazing the submissive tone, and lack of confidence in that message. Compared to the holier than thou attitude Linus presents himself in these days. I would have never guessed he wrote that.
I don't think it's lack of confidence. It's just a realistic acknowledgement that it's a small start and in fact was unlikely to be useful. But he wanted feedback on how to make it useful.
I think Linus is just a practical person who is good at assessing reality. He doesn't get caught up in grand visions without action.
I don't think he is holier than thou now either. He's just busy and forcefully trying to get contributors to come to grips with things he has learned by experience on his project.
I've never really heard Linus preach about other people's projects, except where he intends to do better like svn. His advice is limited to the kernel as far as I can tell, and it's perfectly rational for him to be opinionated about that, because he has skin in the game.
In contrast, Stallman will preach about other projects -- in fact that is his main purpose. So I can see why people would call him holier than thou, but I don't see it with Linus. I do appreciate Stallman to a great degree too.
Ah, yes, as if Linux is not enough as a community driven OS. Let's make other one! Where anyone can make crappy software and be offended if someone pointed it out!
I appreciate the idea of making a difference (I badly want to have and use an unproblematic OS), but making an OS out of the lack of another major alternatives is just... a waste of time!
"Ford already made a car! Making another one is a waste of time!"
"IBM already made a computer! Making another one is a waste of time!"
"Nokia already made a phone! Making another one is a waste of time!"
People choose projects they're passionated about. The majority will likely be a waste of time in the grand scheme of things. Who cares? It's what they want to work on. Is it likely to overtake Linux? No. Is it likely to gain enough adoption to merit taking a look at it? Maybe.
You don't even know if the way its architected would provide a better way at doing something another existing operating system cannot and yet you're immediately writing it off?
I think I have already heard this somewhere: "<something something> should be enough for everybody".
In fact, I wish we had more diversity as far as operating systems are concerned. For example, BeOS/Haiku would seem to me a saner choice for a desktop than an OS primarily designed for servers. (Windows and Mac OS used to be purely desktop OS, but not any more.) RISC OS is another interesting example.
It looks like they have basically adopted the coding conventions of windows API code, down to the /++ --/ comments, style of declaring functions, uppercase types etc. Not that it's is a bad thing, just something I noticed.
Also things like KeCrashSystemEx look very much like KeBugCheckEx in Windows. There certainly is a lot of inspiration.
Edit: I see from Linkedin the OP is actually an ex-MSFTer who worked on Windows' HAL, so this makes sense. I wonder, tho, if this will present legal issues? Could someone say that it is an issue that the API is clearly inspired by the Windows API?
>Under the hood, Minoca contains a powerful driver model between device drivers and the kernel. The idea is that drivers can be written in a forward compatible manner, so kernel level components can be upgraded without requiring a recompilation of all device drivers.
This sounds really smart and it looks great overall <3
There is nothing that prevents a monolithic kernel from using the same model -- no theoretical barrier to it, in any case. Linux doesn't do this because its developers don't want it to.
RHEL/ Centos defines a stable driver ABI, and even has tools that devs can use to check that their binary drivers don't use any symbols outside the ABI.
SUSE does too. As far as I'm aware, most stable distributions use a kABI checker. This is the same reason that Android doesn't have many kernel updates -- because proprietary driver authors don't feel like keeping up to date with kABI changes.
What you're seeing is the serial output. If you plug in an HDMI monitor, you'll hopefully already be at the shell prompt. Email me (chris@minocacorp.com) if you run into further issues.
Hey Chris! Very excited about the potential for a lightweight embedded OS.
I think I understand my confusion now, I was hoping for a shell on the serial port. Most of the work I do with BBB's is headless. Does the exclamation point mean it's finished booting to userspace? Do you think you could rig up the serial port with a shell?
How does Minoca handle GPIO's, and other things like RTC's and SPI? I'm sure you know of device tree and sysfs drivers for GPIO, but I can write you a quick overview!
Took a look at the github page. Sounds really impressive, lads. I only wish it were a microkernel and licensed with an 'or later'. In fact, given how well copyleft works for system software, I'd consider AGPL. Anyway, it definitely deserves a closer look.
I would love to see architecture and comparison to other kernels described!
Also, I wonder if this can be made to run on Cortex M4 with "MPU" but not "MMU" hardware? Something to run on the Teensy 3.6 would be interesting.
BTW: Binary compatible function driver interfaces are great! They served us well on BeOS. The Linux "recompile everything under the sun" approach really gets in the way for many real world situations.
Finally, I'm sick and tired of POSIX I/O. It's a really old model, and a really bad match to modern hardware and use cases. Someone needs to develop and popularize the callback/messaging based kernel/application interface of the future, complete with something other than the main() entry point...
Perhaps a stupid question but where is the architecture doc? (I think that should be the starting point, especially if you want help from a community.)
I'm also interested in what theoretical results from the last 25 years are being used. Some references to papers would be nice. Since the biggest hurdle is separation and thus security, I can imagine the OS has an embedded theorem prover, but I see no mention of it.
Indeed. GPL makes sense in the short term, but in the long run an permissive licensed project forces its branches to contribute back to avoid divergence. GPL makes it harder for commercial entities to invest into it and also a permissive licensed project makes a bigger competition to e.g. Linux.
I felt this way as well (since the mid nineties) until a couple of weeks ago when I read _Social Architecture_ by Pieter Hintjens. It has a strong idealogical flavour. He stresses that you should focus on building a community, with the code and platform as happy side-effects of that community.
For that reason, you want GPL because it forces everything back into the community. He gives examples of a friend of his who slaved on a BSD project that got forked with the friend having nothing to show for it. And NT adoption of much of the code from the BSD sockets API.
> He stresses that you should focus on building a community, with the code and platform as happy side-effects of that community.
Exactly, so license shouldn't matter that much. I'd probably be a lot more interested in it were it BSD licensed, as it is now I have no real desire to play with this new OS.
LLVM has taken off because the code is cleaner and more modular than GCC. Also Apple payed for all the boring grunt work. Maybe Apple would have adopted LLVM with GPL, maybe not.
It looks like the developers want people modifying their code to contribute back, either by giving back the changes or by paying them (they offer an option to purchase a more permissively-licensed version).
"This software is distributed under the terms of the GNU General Public License version 3 (GPLv3). Minoca offers alternative licensing choices for sale. Contact info@minocacorp.com if you or your company are interested in licensing this software under alternate terms."
Have to agree about the good work part. Sadly my personal opinion is that I really, really dislike the NT coding style. Now that makes me wonder how coding style affects peoples will to contribute. Compare this to the Linux kernel coding style and they're on different sides of the scale, I wonder how it will affect contributions.
I happen to have an interest in OS development myself: it seems that two things have combined to make bespoke OS development practical again. First, the world has mostly standardised on amd64, UEFI &c. None of these standards may be terribly good (e.g. I've always x86 and its descendants tasteless compared to 68000, MIPS and others), but they're good enough, and now there's a critical mass of community support out there for them.
Second, readily-available virtual machines have made it easier than it ever was to rapidly iterate on an OS concept.
My own interest is in non-POSIX, non-Unix-inspired, non-consumption-oriented systems: I think that there's some huge headway to be made in building computers meant to augment the human brain, rather than to just reproduce the past or serve as an entertainment-enabler. But Minoca OS sounds pretty neat in itself. Kudos to the guys for putting in the work, and kudos for releasing it as open source. I hope that they're able to make some money from it too — good work deserves to be rewarded.
Use of that phrase was my nice way of saying, being an asshole. Which is why I couldn't believe he wrote that. I guess that's what fame, and power gives you.
I didn't say 100% of anything he says is vitriolic spew. There is no denying the man is a genius with C, but he's certainly built a reputation with his attitude.
195 comments
[ 96.1 ms ] story [ 370 ms ] thread> Can we achieve parity with what what operating systems are used for in today’s world, but with less code, and with fewer pain points? Can we do better? We’d like to try.
I appreciate the uncertainty!
Yet Another OS With the Vague Impossible-To-Evaluate Benefit of 'Newness'
edit: not to suggest I have a problem with people trying new things, but rather...why not write up a little essay on the architectural decisions you've made and their impact before releasing it publicly?
Not saying their work isnt useful. But theres an argument to be made for "why"?
Now you get to answer the "why not?".
> We wanted to see if with 25 years of hindsight and a clean slate we could create something interesting and unique in the operating systems space.
That would be a real good litmus test haha.
I'd be interested if it was based on a post-Liedtke microkernel, but I suspect it's yet another boring monolith.
OTOH, somebody releases a whole OS and the response is "Snore! It isn't a microkernel." - Ok, so...why?
http://cs.furman.edu/~chealy/cs75/important%20papers/secure%...
Start at "The Paper" here to skip past Linus vs Tannenbaum politics stuff. He describes the common counterpoints and shows with evidence, including existing systems, that they're not as big a deal as people say.
http://www.cs.vu.nl//~ast/reliable-os/
Example from high-assurance world that has many features & assurance activities a FOSS attempt at secure microkernels should consider copying:
http://www.ghs.com/products/safety_critical/integrity-do-178...
Animats and I think QNX is probably best of commercial ones in balancing all kinds of tradeoffs. It's been used for decades as a self-healing RTOS with good performance. First link is their description of it with second a demo of a product with QNX inside showing how fast it can be on non-desktop hardware.
http://www.qnx.com/content/qnx/en/products/neutrino-rtos/neu...
https://youtu.be/vPo6gl8N0wM?t=1m20s
Open-source one aimed at reliability & legacy compatibility you can play with. Took UNIX decades to get reliable despite all the labor but Minix 3's foundation did it with a handful of people over a few years. That's saying something.
http://wiki.minix3.org/doku.php?id=www:documentation:feature...
Another FOSS one that aims at high-security integrating many best-of-breed components from CompSci like Nitpicker GUI and seL4 microkernel. First link is descriptive slides with second the actual site. This one is still new so will have bugs.
https://archive.fosdem.org/2015/schedule/event/genode_os_sec...
https://genode.org/about/
Finally, it's worthwhile to throw in an exemplary one from capability-security that further isolates things with self-healing properties. Based on commercially successful KeyKOS system on mainframes. No longer maintained but docs and GPL code still available for study or revival. Paper also describes other capability kernels.
https://www.cs.ucsb.edu/~chris/teaching/cs290/doc/eros-sosp9...
So, there's you a few days worth of reading and a few years worth of thinking to do. Hope it helps shed light on why almost every safety- or security-critical system that ever did well in reliability or security was a microkernel-based system. These days, high-assurance is looking at eliminating even it with CPU's with built-in security, compiler techniques for automated safety/security, and DSL's for easy formal verification of OS or system components. Until that's finalized & while using t...
I'm glad to see you around; A bit of hope to contrast with all the zero-research-done yet anti-microkernel naysayers.
I'm more positive about microkernels these days; Activity is increasing and milestones are being reached.
I guess this is kind of like a re-release after not generating much buzz and seeing a lot of comments asking for open source.
[0] https://news.ycombinator.com/item?id=11662057
Good luck to these people, I hope this becomes one of the major OSes in ten years.
I haven't found something like an architecture overview of the kernel itself, but the docs story isn't bad for a 2-ppl team. Kudos.
Why is a new operating system necessary?
...The design requirements of today's devices have drastically evolved in areas of power management, security, serviceability, and virtualization... By starting from a clean slate, Minoca OS is able to incorporate those core tenets into the very fabric of the operating system...
How is Minoca OS different from other operating systems?
...One of the most noticeable differences at the kernel level is the uniform driver model, which provides a maintainable interface between the kernel core and device drivers... Another very noticeable difference is our strong emphasis on the kernel development environment. Being able to step through code in the kernel, boot environment, and even firmware was something we felt was critical to quickly developing and maintaining kernel-quality code...
http://www.minocacorp.com/support/faq/
I think Linus is just a practical person who is good at assessing reality. He doesn't get caught up in grand visions without action.
I don't think he is holier than thou now either. He's just busy and forcefully trying to get contributors to come to grips with things he has learned by experience on his project.
I've never really heard Linus preach about other people's projects, except where he intends to do better like svn. His advice is limited to the kernel as far as I can tell, and it's perfectly rational for him to be opinionated about that, because he has skin in the game.
In contrast, Stallman will preach about other projects -- in fact that is his main purpose. So I can see why people would call him holier than thou, but I don't see it with Linus. I do appreciate Stallman to a great degree too.
The same Linus that fundementally did not believe in source code management for what 20? Years because it made developers "soft"!?
(a) better late than never!
I would consider the possibility that he knows something that you don't.
Well he is a saint...
https://stallman.org/saint.html
https://github.com/cgag/loc
(I haven't tried this yet, though I do use tokei, which is faster but not this fast. Been meaning to try it out.)
is that not enough?
I do clocs maybe once a week. So waiting for 2 minutes isn't really a huge issue here. (Well, it's less than 2 minutes for my code bases).
Smells like premature optimization ;)
I too get tired of seeing all this "take X and write it in rust".
OTOH it's a new area and the younger crowd gets to try and make a name for themselves in something that isn't already fully established.
But seriously, I've never thought to myself "cloc is too slow" and even if I did, I'd run it overnight.
Big kudos.
Going to look at it when time allows
I appreciate the idea of making a difference (I badly want to have and use an unproblematic OS), but making an OS out of the lack of another major alternatives is just... a waste of time!
"Ford already made a car! Making another one is a waste of time!"
"IBM already made a computer! Making another one is a waste of time!"
"Nokia already made a phone! Making another one is a waste of time!"
People choose projects they're passionated about. The majority will likely be a waste of time in the grand scheme of things. Who cares? It's what they want to work on. Is it likely to overtake Linux? No. Is it likely to gain enough adoption to merit taking a look at it? Maybe.
You don't even know if the way its architected would provide a better way at doing something another existing operating system cannot and yet you're immediately writing it off?
In fact, I wish we had more diversity as far as operating systems are concerned. For example, BeOS/Haiku would seem to me a saner choice for a desktop than an OS primarily designed for servers. (Windows and Mac OS used to be purely desktop OS, but not any more.) RISC OS is another interesting example.
Cool project though and it's nice that they already have a handful of drivers.
EDIT: To clarify, I'm not saying it's bad at all, they're just using a very verbose naming convention that I don't particularly like working with.
Also things like KeCrashSystemEx look very much like KeBugCheckEx in Windows. There certainly is a lot of inspiration.
Edit: I see from Linkedin the OP is actually an ex-MSFTer who worked on Windows' HAL, so this makes sense. I wonder, tho, if this will present legal issues? Could someone say that it is an issue that the API is clearly inspired by the Windows API?
This sounds really smart and it looks great overall <3
Edit: Haaa, use your eyes and you shall see!
http://www.minocacorp.com/download/#beaglebone-black
Edit: Boo :( I haven't gotten it to boot yet. Boot messages are as follows:
What you're seeing is the serial output. If you plug in an HDMI monitor, you'll hopefully already be at the shell prompt. Email me (chris@minocacorp.com) if you run into further issues.
I think I understand my confusion now, I was hoping for a shell on the serial port. Most of the work I do with BBB's is headless. Does the exclamation point mean it's finished booting to userspace? Do you think you could rig up the serial port with a shell?
How does Minoca handle GPIO's, and other things like RTC's and SPI? I'm sure you know of device tree and sysfs drivers for GPIO, but I can write you a quick overview!
Also, I wonder if this can be made to run on Cortex M4 with "MPU" but not "MMU" hardware? Something to run on the Teensy 3.6 would be interesting.
BTW: Binary compatible function driver interfaces are great! They served us well on BeOS. The Linux "recompile everything under the sun" approach really gets in the way for many real world situations.
Finally, I'm sick and tired of POSIX I/O. It's a really old model, and a really bad match to modern hardware and use cases. Someone needs to develop and popularize the callback/messaging based kernel/application interface of the future, complete with something other than the main() entry point...
How do you feel about kqueue or I/O completion ports? Are those something like the "interface of the future", or just greasing the old machinery?
I'm also interested in what theoretical results from the last 25 years are being used. Some references to papers would be nice. Since the biggest hurdle is separation and thus security, I can imagine the OS has an embedded theorem prover, but I see no mention of it.
http://www.minocacorp.com/documentation/developers/knowledge...
For that reason, you want GPL because it forces everything back into the community. He gives examples of a friend of his who slaved on a BSD project that got forked with the friend having nothing to show for it. And NT adoption of much of the code from the BSD sockets API.
Exactly, so license shouldn't matter that much. I'd probably be a lot more interested in it were it BSD licensed, as it is now I have no real desire to play with this new OS.
https://github.com/minoca/os/blob/master/LICENSE
Basically, the old MySQL business model.
I happen to have an interest in OS development myself: it seems that two things have combined to make bespoke OS development practical again. First, the world has mostly standardised on amd64, UEFI &c. None of these standards may be terribly good (e.g. I've always x86 and its descendants tasteless compared to 68000, MIPS and others), but they're good enough, and now there's a critical mass of community support out there for them.
Second, readily-available virtual machines have made it easier than it ever was to rapidly iterate on an OS concept.
My own interest is in non-POSIX, non-Unix-inspired, non-consumption-oriented systems: I think that there's some huge headway to be made in building computers meant to augment the human brain, rather than to just reproduce the past or serve as an entertainment-enabler. But Minoca OS sounds pretty neat in itself. Kudos to the guys for putting in the work, and kudos for releasing it as open source. I hope that they're able to make some money from it too — good work deserves to be rewarded.
In the future we will need these interfaces so if this is built in to the OS that would be nice advantage :)