Minoca OS: A new open source operating system • Hacker News Board

Re: Minoca OS: A new open source operating system

#181

Post by i336_ » Tue, Nov 01, 2016, 10:30 PM UTC

qznc wrote: post #154

jprzybyl wrote: post #80

I'm very excited about this! Minoca is an interesting system, and I applaud any attempt to make driver-writing less inherently horrible. Minoca OS has been around for a while, but the news is that they're GPLv3. I think that's a great thing! The MIT license is good for software that wants to permeate through everything , but for building a community, the GPL is a good idea. It seems that for any operating system to b…

You can use the Plan9 file system on Linux afaik. Still nobody cares. Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.

> You can use the Plan9 file system on Linux afaik. Still nobody cares.

Actually, start QEMU with some special arguments and a directory path, and the Linux guest inside will be able to see the given directory as a read-write 9P filesystem, mountable with a single command. (New files get QEMU's UID unless QEMU is run as root.)

> Mounting my sound card across the network sounds like a nice hack. It is more important that sound does not stutter though. That has soft real time requirements, which Plan9 does not address.

An incredibly good point, and why Plan 9 has zero adoption. :(

Re: Minoca OS: A new open source operating system

#182

Post by wtallis » Wed, Nov 02, 2016, 1:50 AM UTC

pdonis wrote: post #177

wtallis wrote: post #141

Earlier quoted context omitted.

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

That's untenable. A higher-level API for strings with encodings needs to get the OS involved in the semantics to at least some extent, or else it merely obfuscates the problem instead of solving it. If the OS provides a way to store strings with a metadata field representing the string encoding, but doesn't define which bit pattern means UTF-8, then all of that extra complexity at best serves to call attention to the fact that encoding matters, but it does nothing to help applications ensure that they correctly interpret data created by a different application. If you're going to give your platform official APIs to address the very real problem of handling string encodings, then they ought to be useful enough to truly make it less of a problem. And since none of this actually precludes also including low-level byte-oriented APIs, there's no justification for stopping with a super-minimalist half-solution.

Re: Minoca OS: A new open source operating system

#183

Post by cdbattags » Wed, Nov 02, 2016, 2:06 AM UTC

johnp_ wrote: post #67

no_protocol wrote: post #11

I ran `cloc` on the minoca/os repository, here are the results: github.com/AlDanial/cloc v 1.70 T=22.43 s (84.3 files/s, 63498.9 lines/s) ----------------------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------------------- C 1023 296251 262652 530443 C/C++ Header 438 93833 117592 69529 Assembly 95 9588…

Shameless plug of `loc`, a rust implementation of `cloc` that is 100+ times faster: https://github.com/cgag/loc

Aw maaaan. No homebrew yet?

Re: Minoca OS: A new open source operating system

#184

Post by pdonis » Wed, Nov 02, 2016, 4:20 AM UTC

wtallis wrote: post #182

pdonis wrote: post #177

Earlier quoted context omitted.

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

That's untenable. A higher-level API for strings with encodings needs to get the OS involved in the semantics to at least some extent, or else it merely obfuscates the problem instead of solving it. If the OS provides a way to store strings with a metadata field representing the string encoding, but doesn't define which bit pattern means UTF-8, then all of that extra complexity at best serves to call attention to the…

> If the OS provides a way to store strings with a metadata field representing the string encoding

You're missing my point. The OS should provide a way to store bytes. That's it. The meaning of the bytes is up to the application. If, to the application, the bytes represent text with a certain encoding, then it's up to the application to figure out how to translate the bytes, possibly using other stored bytes to decide. The OS doesn't need to get involved in any of this.

> it does nothing to help applications ensure that they correctly interpret data created by a different application

This is already a solved problem, and it isn't solved by OS's. It's solved by standards. For example, every web browser constantly has to correctly interpret data created by a different application. It can do so because HTML, CSS, JS, etc. are all standards that define how the bytes sent from the server to the client are to be interpreted. The browser doesn't even have to care what OS it's running on; all the OS is doing is giving it network sockets and a place for local data storage.

> If you're going to give your platform official APIs to address the very real problem of handling string encodings

If "platform" means "OS", then no, I'm not. If "platform" means "application framework", then sure, but an application framework is not the same thing as an OS. The fact that many OS's insist on also being application frameworks does not make the two things the same.

Re: Minoca OS: A new open source operating system

#185

Post by wtallis » Wed, Nov 02, 2016, 8:32 AM UTC

pdonis wrote: post #184

wtallis wrote: post #182

Earlier quoted context omitted.

That's untenable. A higher-level API for strings with encodings needs to get the OS involved in the semantics to at least some extent, or else it merely obfuscates the problem instead of solving it. If the OS provides a way to store strings with a metadata field representing the string encoding, but doesn't define which bit pattern means UTF-8, then all of that extra complexity at best serves to call attention to the…

> If the OS provides a way to store strings with a metadata field representing the string encoding You're missing my point. The OS should provide a way to store bytes. That's it. The meaning of the bytes is up to the application. If, to the application, the bytes represent text with a certain encoding, then it's up to the application to figure out how to translate the bytes, possibly using other stored bytes to decid…

> If "platform" means "OS", then no, I'm not. If "platform" means "application framework", then sure, but an application framework is not the same thing as an OS. The fact that many OS's insist on also being application frameworks does not make the two things the same.

As I said originally, we tried that, and it doesn't work. Even within the context of a single locale, .NET applications will happily emit UTF-16 to be consumed by a Python script expecting all strings to be UTF-8, and with only byte-oriented APIs there's no side channel to convey that there's a mismatch that needs to be reconciled. Extending this problem from file and pipe contents to filenames is moving in the wrong direction. Operating systems absolutely should get involved in helping applications safely and usefully exchange information; that doesn't destroy the concept of an application framework, it just means that your OS is more than a hypervisor.

Re: Minoca OS: A new open source operating system

#186

Post by braveo » Wed, Nov 02, 2016, 3:59 PM UTC

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…

> 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 they get from the OS.

I think it's naive to think Operating Systems aren't going to fragment in order to offer "features" (and lockin), and then papering over all that fragmentation has to happen in the application anyway.

unless there's a standard, and if there's a standard the application itself can deal with it.

Re: Minoca OS: A new open source operating system

#187

Post by braveo » Wed, Nov 02, 2016, 4:00 PM UTC

wtallis wrote: post #185

pdonis wrote: post #184

Earlier quoted context omitted.

> If the OS provides a way to store strings with a metadata field representing the string encoding You're missing my point. The OS should provide a way to store bytes. That's it. The meaning of the bytes is up to the application. If, to the application, the bytes represent text with a certain encoding, then it's up to the application to figure out how to translate the bytes, possibly using other stored bytes to decid…

> If "platform" means "OS", then no, I'm not. If "platform" means "application framework", then sure, but an application framework is not the same thing as an OS. The fact that many OS's insist on also being application frameworks does not make the two things the same. As I said originally, we tried that , and it doesn't work. Even within the context of a single locale, .NET applications will happily emit UTF-16 to b…

That's an integration problem and the solution is to pipe it through something that knows enough to do the conversion.

Re: Minoca OS: A new open source operating system

#188

Post by braveo » Wed, Nov 02, 2016, 4:01 PM UTC

pdonis wrote: post #139

mycall wrote: post #137

Earlier quoted context omitted.

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

but is it webscale?

Re: Minoca OS: A new open source operating system

#189

Post by braveo » Wed, Nov 02, 2016, 4:09 PM UTC

kybernetyk wrote: post #102

johnp_ wrote: post #67

Earlier quoted context omitted.

Shameless plug of `loc`, a rust implementation of `cloc` that is 100+ times faster: https://github.com/cgag/loc

Has it any remarkable features other than "it's written in Rust"?

lol.

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.

Re: Minoca OS: A new open source operating system

#190

Post by pix64 » Wed, Nov 02, 2016, 4:37 PM UTC

gumby wrote: post #93

barbs wrote: post #83

Earlier quoted context omitted.

> It seems that for any operating system to be successful, it has to carry around POSIX compatibility like an extremely expensive entry pass. Curious - what are your main objections with POSIX? Is there another system you prefer?

The best thing about POSIX at this point is back compatibility, nothing to be sneered at! But it carries a lot of (in retrospect) bad habits and decisions from the 60s and 70s as well as a tendency to redundancy due to some competing standards that were unified and need for some back compatibility. Now not everyone agrees on what is good and what is bad, so some experimentation in this area is good for everyone. Exam…

Is there any interest in developing a newer, better standard or is this something we're going to be stuck with forever?