Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minoca OS: A new open source operating system

blog.minocacorp.com

Post reply on HN
Print view View original

171–180 of 196 posts

Re: Minoca OS: A new open source operating system

#171

Post by cmrdporcupine »

kevin_thibedeau wrote: post #135
jprzybyl wrote: post #110

Earlier quoted context omitted.

> POSIX was designed to be used on systems with comparable resources to what many embedded processors now have. But not comparable environments. Most IOT environments are very small parts of very big systems, and POSIX defines a system with a teletype and a line editor. I seriously doubt the value of the existing codebase. Saying code made for a server (like most existing unix code!) is fine for IOT feels wrong, and…

> Saying code made for a server (like most existing unix code!) is fine for IOT feels wrong, There was a time when people ran Linux/SunOS/Ultrix/etc. with tiny amounts of RAM and swap. It's not unusual for an embedded device to have 8, 16, 32 MiB, or more RAM available. Many traditional *nix programs can run unchanged on such hardware.

I think the parent's comment was more along the lines of: just because an embedded device _can_ run a Unix doesn't mean it should have to adopt the semantics and history of the *Unix environment that POSIX mandates. In particular the model of TTYs, filesystems, Unix-style file/IO, Unix-style virtual memory / mmap, etc. It's not that this stuff is expensive on modern embedded systems (which as pointed out often have the hardware capacity of high end systems from 20 years ago), it's that these capabilities are either not needed, or impose a conceptual model of what a computer and operating system have to be that don't match up to what the machine is designed for.

Re: Minoca OS: A new open source operating system

#172

Post by nickpsecurity »

analognoise wrote: post #112
nickpsecurity wrote: post #65

Earlier quoted context omitted.

I have such links. I just can't tell if you're being serious or sarcastic.

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 with this paper which lays the reliability benefit out pretty well with specific examples:

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 traditional hardware, it's best to build on methods that already worked for decades.

Re: Minoca OS: A new open source operating system

#173

Post by nickpsecurity »

kevin_thibedeau wrote: post #101
jprzybyl wrote: post #95

Earlier quoted context omitted.

> would that, and thousands of other packages, be feasible without a workable POSIX layer? I think my problem is the core concept. POSIX stands for Portable Operating System Interface (and X stands for Xtreme?). In an age where we spin up entire operating systems to start a single application, why are we defining portability at the operating system level when network portability works so much better? Keep in mind, th…

> why are we defining portability at the operating system level when network portability works so much better A lightweight POSIX-capable system has real value today. Operating systems need to be in more places than just the data center. IoT devices don't have the resources to run a VM or any other fancy containerized environment. POSIX was designed to be used on systems with comparable resources to what many embedde…

There's a whole market of suppliers that's been going strong for decades. Especially for safety-critical embedded with untrusted, Linux/POSIX apps in separate partitions. QNX is one of best examples far as commercial adoption:

http://www.qnx.com/content/qnx/en/products/neutrino-rtos/neu...

Example of embedded product in case you wonder about performance cost of all that isolation, healing, and context switching:

https://youtu.be/vPo6gl8N0wM?t=1m20s

EDIT to add the QNX Desktop Demo that came on a single floppy. Throwing it in since you were mentioning resource-constrained systems further down. A floppy is 1.44MB with base QNX running in ROM's of embedded systems. Can scale such architectures it up or down however you wish. :)

http://crackberry.com/heres-how-qnx-looked-1999-running-144m...

Re: Minoca OS: A new open source operating system

#174

Post by qz_ »

majewsky wrote: post #107

Since Minoca seems to be a Corp., does anyone know what their business strategy will be? I could imagine a) a paid enterprise edition, b) paid support or c) paid consultancy (as in "contract the actual maintainers to implement device drivers for your servers"). Whenever a project is corporate-backed, I like to know the business plan upfront before I consider contributing to it.

From the CONTRIBUTING.md:

>We at Minoca are trying to make open source work as a business model. One of the ways we're doing that is by offering Minoca OS source for sale under more proprietary licensing terms. To do this Minoca needs to own the copyright to its source. In order to support this business model while also allowing community contributions, we ask that contributors sign a Contributor Assignment Agreement. We're using Harmony Agreements. Before submitting patches, please fill out the CAA for individuals or companies.

Re: Minoca OS: A new open source operating system

#175

Post by EvanGr »

c-smile wrote: post #115

Question to authors: do you have any graphics layer in-place? Or at least thoughts about its future architecture? I am thinking about porting my Sciter [1] HTML/CSS UI Engine to an OS that can be used on small (IoT) devices. I think that HTML/CSS as a UI definition/declaration language is quite convenient. [1] http://sciter.com

OP here. Sciter looks cool, nice site too. Currently Minoca has support for a basic framebuffer, which we use to display our green terminal. Our biggest obstacle to having a GUI now is the lack of accelerated graphics drivers. We'd like to add them, but it will be a very large undertaking and probably require cooperation from one of the major graphics vendors.

Re: Minoca OS: A new open source operating system

#176

Post by zeveb »

pdonis wrote: post #120
dom0 wrote: post #99

Earlier quoted context omitted.

I think the main issues with POSIX are: - (Correct) IO is ridiculously non-portable and painful in so many ways that it isn't even funny anymore - Locks are ridiculously non-portable and painful to the point where you're better off just using "mkdir" - POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. This makes it painful and hard to implement proper text handli…

> POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. I actually view this as a feature. Encoding/decoding of data should be an application level thing, not an OS-level thing. As far as the OS is concerned, data should be bytes. (Of course, it is true that, since POSIX defines a terminal spec, it has to at least specify how bytes are mapped to characters that print…

> As far as the OS is concerned, data should be bytes.

If the OS knows the type of those bytes, it can do things like implement global garbage collection, intelligent caching, intelligent snapshotting &c. It can also enforce invariants across all user code.

Re: Minoca OS: A new open source operating system

#177

Post by pdonis »

wtallis wrote: post #141
pdonis wrote: post #136

Earlier quoted context omitted.

> Applications have for the most part proven that they cannot be trusted to get text encoding and decoding right, especially not in any consistent way. That's because text encoding and decoding is a mess. Operating systems doing it doesn't make it any less of a mess; it just inserts the mess deeper into everything. For example, look at all the quirks and edge cases in file name handling between different OS's, simply…

Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings. Completely ignoring the problem and leaving it up to applications further up the stack just ensures that there will be incompatible competing standards for how to tell applications how to decode the string data…

> Regardless of whether operating systems get involved in tasks like re-encoding text, they really should at least carry along the metadata about encodings whenever they're handling bytes that represent strings.

I have no problem with this as long as the metadata itself is just additional bytes. But if the metadata needs to be decoded in order to figure out how to decode it, we have a problem... :-)

Re: Minoca OS: A new open source operating system

#178

Post by pdonis »

zeveb wrote: post #176
pdonis wrote: post #120

Earlier quoted context omitted.

> POSIX is stuck in the "everything is bytes and we slap an encoding on it some of the time" era thinking. I actually view this as a feature. Encoding/decoding of data should be an application level thing, not an OS-level thing. As far as the OS is concerned, data should be bytes. (Of course, it is true that, since POSIX defines a terminal spec, it has to at least specify how bytes are mapped to characters that print…

> As far as the OS is concerned, data should be bytes. If the OS knows the type of those bytes, it can do things like implement global garbage collection, intelligent caching, intelligent snapshotting &c. It can also enforce invariants across all user code.

To me this means you have an application, not an OS--or perhaps an application that also happens to be an OS. (Emacs comes to mind...)

Re: Minoca OS: A new open source operating system

#179

Post by zeveb »

pdonis wrote: post #178
zeveb wrote: post #176

Earlier quoted context omitted.

> As far as the OS is concerned, data should be bytes. If the OS knows the type of those bytes, it can do things like implement global garbage collection, intelligent caching, intelligent snapshotting &c. It can also enforce invariants across all user code.

To me this means you have an application, not an OS--or perhaps an application that also happens to be an OS. (Emacs comes to mind...)

Well, I think that OSes could do a lot more (and kernels a lot less … but that's a different story). Why _shouldn't_ an operating _system_ do an awful lot to ensure user safety, resource utilisation &c.?

Re: Minoca OS: A new open source operating system

#180

Post by mwcampbell »

EvanGr wrote: post #175
c-smile wrote: post #115

Question to authors: do you have any graphics layer in-place? Or at least thoughts about its future architecture? I am thinking about porting my Sciter [1] HTML/CSS UI Engine to an OS that can be used on small (IoT) devices. I think that HTML/CSS as a UI definition/declaration language is quite convenient. [1] http://sciter.com

OP here. Sciter looks cool, nice site too. Currently Minoca has support for a basic framebuffer, which we use to display our green terminal. Our biggest obstacle to having a GUI now is the lack of accelerated graphics drivers. We'd like to add them, but it will be a very large undertaking and probably require cooperation from one of the major graphics vendors.

Once you get at least one accelerated graphics driver implemented, would you design your own GUI framework/toolkit, or use an existing one like Qt?
Post reply on HN