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.
Minoca OS: A new open source operating system
131–140 of 196 posts
Re: Minoca OS: A new open source operating system
#132I 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.
Re: Minoca OS: A new open source operating system
#133Any 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.
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
#134Re: Minoca OS: A new open source operating system
#135Earlier 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…
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
#136Earlier 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.
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
#137Earlier 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…
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
#138Re: Minoca OS: A new open source operating system
#139Earlier 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.
Of text?