Live data from Hacker News

Minoca OS: A new open source operating system

blog.minocacorp.com

131–140 of 196 posts

Re: Minoca OS: A new open source operating system

#131

Earlier quoted context omitted.

So true. it really is my biggest problem with the monolithic Linux kernel.

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.

Re: Minoca OS: A new open source operating system

#132

I would like to see a built-in natural-language interface so I can, for example, "ps -elf | grep something" with a voice command. In the future we will need these interfaces so if this is built in to the OS that would be nice advantage :)

"need". I don't think you understand what the term really means.

Well if you want to play that game, we don't "need" any computers at all.

Re: Minoca OS: A new open source operating system

#133

Any images out there for Beaglebone? Quite interested! 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: Minoca Firmware Loader Boot Device: 00000008 Launching bbonefw.bin. Jumping to 82000000... !

Chris from Minoca here. 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!

Re: Minoca OS: A new open source operating system

#135

Earlier quoted context omitted.

> 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…

> 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.

Re: Minoca OS: A new open source operating system

#136
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…

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. Operating systems definitely should make it possible to deal with the raw byte streams, but the default and preferred method of text handling should be a standard higher-level interface.

> 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 because nobody is willing to just admit that to the OS, file names should be sequences of bytes, which are easy to share between machines running different OS's.

The basic issue is that text encoding and decoding exists because bytes have meanings. But unless/until we invent artificial intelligence, computers can't deal with meanings (because the meanings are not simple computable functions of the bytes). And OS's, particularly, should not even try. Applications might have to try, but the cost if they get it wrong is much less.

Re: Minoca OS: A new open source operating system

#137
post #120
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…

> have an OS try to muck about with encodings

Hardware encode/decode often requires DMA capabilities. There are many optimizations that kernel mode can bring.

Re: Minoca OS: A new open source operating system

#138
post #35

I wish them well, but I'm rather surprised to see no support for 64-bit architecture. Seems an odd place to start.

well, like they wrote, they want to support small, power limited devices as well.

Today even smartphones are ARM64. They are powerful, yet power limited.

Re: Minoca OS: A new open source operating system

#139
post #137
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…

> have an OS try to muck about with encodings Hardware encode/decode often requires DMA capabilities. There are many optimizations that kernel mode can bring.

> Hardware encode/decode

Of text?

Re: Minoca OS: A new open source operating system

#140
post #73

Earlier quoted context omitted.

That's the "port driver"+"mini port driver" model of Windows.

Not surprising considering the Minoca founders both worked on the Windows kernel team, according to Linked In. :)

Honestly, the inside looks rindunculously like the NT kernel.
Post reply on HN