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

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

341–350 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#341

Post by hnfong »

phkahler wrote: post #331
bigstrat2003 wrote: post #292

Earlier quoted context omitted.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version,…

Linux has a LOT of paid commercial developers. Imagine those companies closed source and produced a commercial kernel that's way ahead of the open one - because they could and would if the license allowed. The public code couldn't keep up and would be kind of useless. On the other hand, the scenario you describe where everybody wins is already proven to work with the GPL since that is the Linux story. That is the poi…

Interesting you mentioned GPL proven to work in the Linux story.

It was specifically GPLv2.

I feel the GPL lost a lot of momentum with FSF's GPLv3 push.

Linus was publicly against it. Not only for Linux, but generally and philosophically against it. I presume a lot of others felt the same too.

In theory you could continue using GPLv2 for new projects, but given that FSF had basically deprecated v2 in favor of v3, it seems that the momentum for v2 just slowly died out, and v3 was too controversial to gain widespread acceptance.

Without a GPL default, the developers who didn't want to get too deeply involved in ideological questions probably just adopted MIT as the new default.

Re: Maestro: A Linux-compatible kernel in Rust

#342

Post by Aerbil313 »

I’m surprised to see no one mentioned Theseus OS. It’s a WIP OS built from scratch with Rust, using Rust compiler’s guarantees around memory safety for automatically providing many things which require careful plumbing in conventional OSes. As an example it’s SPL, SAS (single privilege level, single address space) and yet is secure. All parts of the OS are hot pluggable too. The drawback is that all native code needs to be Rust, though a WASM runtime is implemented last year. Related thread from 3 years ago: https://news.ycombinator.com/item?id=25741729

Re: Maestro: A Linux-compatible kernel in Rust

#343

Post by hnfong »

drtgh wrote: post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

This is already mostly achievable on Linux with ptrace

It's not a popular thing, but there are ptrace-based sandbox implementations.

I've written one myself 20 years ago for a very limited use case (sandboxing of programs that are supposed to only read/write from stdin/stout and pretty much disallowed from anything else).

From a quick search I found this to be promising: https://developers.google.com/code-sandboxing/sandbox2/expla...

Re: Maestro: A Linux-compatible kernel in Rust

#344

Post by hnfong »

elromulous wrote: post #242
evanjrowley wrote: post #237

[flagged]

The supreme court ruled[0] that copyright (and thus copyleft?) does not apply to APIs. [0] https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America... .

The case was subject to a lot of FUD and misunderstanding. This is one of them.

> The supreme court ruled[0] that copyright (and thus copyleft?) does not apply to APIs.

That is what they specifically stated was not the case.

The text of Wikipedia (as of now) says:

Breyer concluded that "we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google's copying did not violate the copyright law."[77] This conclusion rendered the need to evaluate the copyright of the API unnecessary.[79]

But let's look at the original Supreme Court decision (this is just the beginning first paragraph):

""" JUSTICE BREYER delivered the opinion of the Court. Oracle America, Inc., is the current owner of a copyright in Java SE, a computer program that uses the popular Java computer programming language. Google, without permission, has copied a portion of that program, a portion that enables a programmer to call up prewritten software that, together with the computer’s hardware, will carry out a large number of specific tasks. The lower courts have considered (1) whether Java SE’s owner could copyright the portion that Google copied, and (2) if so, whether Google’s copying nonetheless constituted a “fair use” of that material, thereby freeing Google from copyright liability. The Federal Circuit held in Oracle’s favor (i.e., that the portion is copyrightable and Google’s copying did not constitute a “fair use”). In reviewing that decision, we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google’s copying did not violate the copyright law.""" (emphasis mine)

The Supreme Court basically weaseled out of their responsibility of deciding the law (of whether APIs are copyrightable). The usual logic is to consider fair use after determining that a subject matter is subject to copyright. Pretty sure no lawyer or judge just jumps to fair use without first considering copyright. Anyway. In all fairness it was a difficult case.

FWIW, it is arguable from an academic perspective that since the Supreme Court only reversed the decision on fair use but did not reverse the decision on copyrightability of APIs, the decision of the lower court stands.

Re: Maestro: A Linux-compatible kernel in Rust

#345

Post by plagiarist »

jodrellblank wrote: post #305
plagiarist wrote: post #152

Earlier quoted context omitted.

I don't think the metaphor applies because kitchen utensils' forms are dictated are their purpose, but software interfaces are abstractions. A fairer analogy would be if everything in the kitchen was bowl-shaped, but you could do bowl-like actions and get non-bowl behavior. Drop the carrot in the peelbowl and it is peeled, drop the carrot in the knifebowl and it is diced, drop the cubes in the stovebowl and they are…

The counter would be that different tasks are different and that's why everything isn't bowl shaped. Analogously, programming languages which are strongly opinionated (purely functional, array-based, strictly static) are far less generally popular than programming languages which are multi-paradigm and flexibly typed. People have access to user-mode filesystems and FUSE, people could have made everything have a file-…

The function defines the shape of the kitchen utensil, yes. That's not a counter, those are physical objects. In software, we have far more flexibility as to what "shapes" are available.

Having a common interface for working with things is indeed why the flexibly-typed languages are popular. Everything is an object. You call methods on every object in the same way. You don't need to figure out how to interact with the network card, someone has written a library to make that into objects. You don't need to figure out how to interact with a file system, someone has figured out to make that into objects. Bringing up popularity of programming languages is an argument in favor of "'everything is a file' is a useful abstraction."

Either people will write FUSE plugins or they don't want consistent interfaces is a false dichotomy.

When you are interacting with programs, you use mostly keyboards and mice. Why not create a bespoke hardware interactions for each program so they can behave more like kitchen utensils? Deleting a file is a different action than creating one, so I should have to shake my computer like an Etch-a-Sketch to delete images and rub the trackpad like an eraser to remove text files.

Re: Maestro: A Linux-compatible kernel in Rust

#346

Post by evanjrowley »

hnfong wrote: post #344
elromulous wrote: post #242

Earlier quoted context omitted.

The supreme court ruled[0] that copyright (and thus copyleft?) does not apply to APIs. [0] https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America... .

The case was subject to a lot of FUD and misunderstanding. This is one of them. > The supreme court ruled[0] that copyright (and thus copyleft?) does not apply to APIs. That is what they specifically stated was not the case. The text of Wikipedia (as of now) says: Breyer concluded that "we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google's copying did not violate the copyright law…

Thanks for your insightful comment.

It seems like the hypothetical question of whether this Maestro project is legally dubious hinges upon whether it counts as fair use of Linux APIs and code, which are copyrighted by various Linux contributors and provided under the terms of GPLv2.

This makes me wonder, what license was Java provided under, and how was Google's decidedly fair use copying of Java APIs not in violation of it? Did any of the court proceedings address this?

Furthermore, what are legally defensible types of fair use redistributions of GPLv2 code that contradict the license terms? Does it include redistributions of portions of GLPv2 code under a different license that contradicts GPLv2? How about the Linux ABI?

The fair use question may take precedent over whether or not Maestro was written from scratch.

Re: Maestro: A Linux-compatible kernel in Rust

#347

Post by smaddox »

loeg wrote: post #287
smaddox wrote: post #276

Earlier quoted context omitted.

You would probably need to pass around a context type that encodes information about the current context and which interrupts are possible. You would then acquire the lock via that context, which would handle disabling those interrupts.

Still need to set the context correctly on entry to your interrupt handlers, I guess, and passing it around is kind of ugly. In C kernels you often stash contexts in CPU-locale variables, maybe you could do something like that instead of passing it around.

CPU-local could work, but would give up the possibility of static type verification. Agree passing around context can be tedious, but Rust currently doesn't have a way to implicitly pass context (although there have been some proposals along those lines).

Re: Maestro: A Linux-compatible kernel in Rust

#348

Post by PrimeMcFly »

sylware wrote: post #259
jodrellblank wrote: post #257

Earlier quoted context omitted.

> " If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN. " It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, t…

Again, this is wrong, actually a lie in regards of what I have been saying on this thrtead. I have been giving my opinion and explaining all along in all parts of this threads my views and opinions. This is so bluntly disregading everything, I think you may very probably be a AI bot with a very small context window.

I'm not a bot. Can you clarify your answer for me, please?

Re: Maestro: A Linux-compatible kernel in Rust

#349

Post by snvzz »

hnfong wrote: post #340
lifthrasiir wrote: post #168

Earlier quoted context omitted.

seL4 actually has an end-to-end proof, which proves that the final compiled binary matches up with the formal specification. There are not many places that bugs can be shifted---probably the largest one at this point is the CPU itself.

The bugs are shifted into the spec, or the proof.

Not really shifted.

If you think about it, a bug in the proof will require a bug in the code.

This visibility is a good thing.

Overall, note that the critical code, such as the microkernel itself, is small (kLoC wise) to begin with, which minimizes the odds a bug will go undetected for long.

Re: Maestro: A Linux-compatible kernel in Rust

#350

Post by samus »

drtgh wrote: post #332
samus wrote: post #312

Earlier quoted context omitted.

SELinux precisely allows things like restricting applications to specific ports or specific files though. Pretty sure that it would also be possible to restrict internet access and things like that. What it needs is better UIs. The potential for process injections is severely reduced by design on systems such as Android or when containerizing applications, for example with Flatpak. Modulo kernel bugs or being root, i…

> when containerizing applications, for example with Flatpak. Modulo kernel bugs or being root, it's simply not possible to mess with the processes of another user. Wrong. > Advanced desktop users have better things to do than reviewing security warnings all day long. I get paid to write code instead of investigating what my applications are doing. Oxymoron.

> Wrong.

> Oxymoron.

Cheap words. Care to explain?

Post reply on HN