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

351–360 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#351

Post by PrimeMcFly »

F3nd0 wrote: post #308
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,…

> What, exactly, is supposed to be so bad about that? The eventual users of the hypothetical commercial OS lose their freedom. (Or don't get their freedom, depending on your point of view.) Permissive licences grant users freedom, but don't preserve those freedoms in derivative works, so the original work can end up helping derived software disrespect users' freedom. For those who believe that users' freedom should a…

Freedom includes allowing users to choose a less free alternative because they derive benefits in doing so.

Re: Maestro: A Linux-compatible kernel in Rust

#352

Post by drtgh »

samus wrote: post #350
drtgh wrote: post #332

Earlier quoted context omitted.

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

Containers are portability tools, that can partially control a benign application, but in no way will contain a Trojan. The community warns such tools give a false sense of security.

As long as the Trojan is moderately advanced, there is nothing to stop it (currently, mouse and cat).

The only thing one can do is to detect signs of its activities, just routine.

When the least unexpected day one detect the signs, one notify to the work circle that the machine has been compromised for to rescind our permissions, it is tried to find out how entered and get an idea of the time during which the data leak has occurred, as anything relevant you did in that machine is on some public page on internet.

Re: Maestro: A Linux-compatible kernel in Rust

#353

Post by tredre3 »

SpaghettiCthulu wrote: post #254
rhabarba wrote: post #15

Earlier quoted context omitted.

People who want stable interfaces should not touch anything Linux with a ten-foot pole.

That's only in terms of the driver interface, right? My understanding is that the userspace interface is extremely stable.

> My understanding is that the userspace interface is extremely stable.

Assuming you compile a static binary that doesn't even rely on libc, then yes, something compiled 20 years ago will still run.

But in the real world you have to recompile your software constantly due to breakage in dependencies (including glibc). And a binary won't work cross-distros without adding efforts despite running the same kernel (sure, that part isn't the kernel's fault).

It's often memed that the most stable interface on Linux is win32 (via wine), and that meme isn't entirely off-base.

Re: Maestro: A Linux-compatible kernel in Rust

#354

Post by hnfong »

evanjrowley wrote: post #346
hnfong wrote: post #344

Earlier quoted context omitted.

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

> what license was Java provided under

In addition to other commercial licenses, Java was released under GPLv2. Yes, the Oracle v Google case was technically a GPL case. (The tech community talks a lot about GPL being tested in court, but somehow often overlooks this one as a supreme court decision on software covered by GPL... even though the GPL here does not matter for the decision at all)

There are parts of the Java API that was not released under the GPL, and I don't know whether Google copied those too, but it doesn't really matter that much here.

> how was Google's decidedly fair use copying of Java APIs not in violation of it?

Fair use is a defense to copyright infringement for the jurisdictions that recognize it.

Fun fact: if Oracle sued Google about android in jurisdictions that did not recognize fair use, it could be fun... I don't really know why they didn't do that already.

> Furthermore, what are legally defensible types of fair use redistributions of GPLv2 code that contradict the license terms?

This requires a comprehensive review of the copyright law regime. Get a lawyer (or a law degree) for that...

Re: Maestro: A Linux-compatible kernel in Rust

#355

Post by evanjrowley »

hnfong wrote: post #354
evanjrowley wrote: post #346

Earlier quoted context omitted.

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

> what license was Java provided under In addition to other commercial licenses, Java was released under GPLv2. Yes, the Oracle v Google case was technically a GPL case. (The tech community talks a lot about GPL being tested in court, but somehow often overlooks this one as a supreme court decision on software covered by GPL... even though the GPL here does not matter for the decision at all) There are parts of the J…

I was not expecting it to be a GPL case. That's incredible. I wouldn't be able to sleep without more details about the licences at play here, so I found this helpful article that satisfied my curiosity: http://www.fosspatents.com/2015/12/google-switches-to-open-s...

Re: Maestro: A Linux-compatible kernel in Rust

#356

Post by hnfong »

evanjrowley wrote: post #355
hnfong wrote: post #354

Earlier quoted context omitted.

> what license was Java provided under In addition to other commercial licenses, Java was released under GPLv2. Yes, the Oracle v Google case was technically a GPL case. (The tech community talks a lot about GPL being tested in court, but somehow often overlooks this one as a supreme court decision on software covered by GPL... even though the GPL here does not matter for the decision at all) There are parts of the J…

I was not expecting it to be a GPL case. That's incredible. I wouldn't be able to sleep without more details about the licences at play here, so I found this helpful article that satisfied my curiosity: http://www.fosspatents.com/2015/12/google-switches-to-open-s...

FWIW, fosspatents was one of the first commentators to side with Oracle on the claim that APIs are copyrightable (according to existing copyright law). The tech community at large seemed to think fosspatents was a shill blog hired by Oracle for propaganda. There's a lot of info about the case on the blog too, since the legal dispute spanned many years.

It's also useful to note here that the FSF's stance that software using GPL libraries need to be GPLed (i.e. the "viral" mechanism) was largely based on the idea that APIs are copyrightable and software that uses these APIs (by copying their definitions during compile and linking phase) need permission to do so. You've probably realized this by now, since it is analogous to the kernel syscall issue. It was very interesting how the community generally accepted the FSF's stance but vehemently opposed Oracle's (hint: they are the same w.r.t. to API copyrightability).

People these days are beginning to realize Google could be the asshole too (not that Oracle has ever been the innocent one), so this stuff is probably less "controversial". But it was a very contentious issue back then.

Re: Maestro: A Linux-compatible kernel in Rust

#357

Post by BatmanAoD »

sylware wrote: post #328
BatmanAoD wrote: post #311

Earlier quoted context omitted.

So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?

This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extr…

Nobody said anything about RISC-V being "perfect" or not. The problem isn't how good RISC-V is or isn't; it's that your desire for software to target one and only one type of hardware just doesn't make any sense. That's not how computers have ever worked.

By the way, what do you mean by "PI lockfree"? Googling "ISA PI lockfree" just leads me to...another hacker news thread where you're arguing that RISC-V should replace everything.

Anyway, yes, please do "investigate how much out-of-the-box-thinking and disruptive this is" before continuing to have these inane arguments.

Re: Maestro: A Linux-compatible kernel in Rust

#358

Post by shiroiuma »

surajrmal wrote: post #248
ahmedfromtunis wrote: post #233

Earlier quoted context omitted.

From what I understood, I think the big difference here is the human factor: Windows and Android are maintained by employees, who have no choice but to work on things even if they don't like doing it. Linux on the other hand is a collective effort of people doing what they want to do on their free time.

That's a myth. Most Linux contributions come from paid employees from various companies not unpaid volunteers.

They come from employees of various companies, not employees of some company that owns Linux itself. All those various companies have different goals, and are only contributing because doing so is in their economic interest. Having a stable ABI would require a lot more work, and these companies have zero incentive to invest in this effort: it doesn't help their profitability, it just makes things easier for others outside their companies. Arguably, it also makes the kernel code a lot more complicated and bug-prone.

It makes sense for MS, for example, to want a stable ABI to make things easier for 3rd-party devs so they'll target that platform, and for MS to shoulder the effort of maintaining that ABI cumbersomeness. It doesn't really makes sense for Linux. You could argue that this hampers adoption of Linux as an alternative to Windows on desktop machines, but even if that's true, no one involved really has an economic incentive to change this. In the places where Linux is dominant (Android + servers + embedded), a stable ABI isn't really helpful or needed.

Re: Maestro: A Linux-compatible kernel in Rust

#359

Post by samus »

drtgh wrote: post #352
samus wrote: post #350

Earlier quoted context omitted.

> Wrong. > Oxymoron. Cheap words. Care to explain?

Containers are portability tools, that can partially control a benign application, but in no way will contain a Trojan. The community warns such tools give a false sense of security. As long as the Trojan is moderately advanced, there is nothing to stop it (currently, mouse and cat). The only thing one can do is to detect signs of its activities, just routine. When the least unexpected day one detect the signs, one n…

That was exactly what I was referring to. One would have to at least use a VM to mitigate that danger, or completely airgap the system. Logging suspicious accesses for forensic purposes is surely useful, but expecting the user to review all these notifications won't improve security, unless this is intended to become their job.

Re: Maestro: A Linux-compatible kernel in Rust

#360

Post by pas »

goodpoint wrote: post #84
pas wrote: post #62

Earlier quoted context omitted.

The road paved with good intentions and all. Sure, users are 1-bit entities in need of protection, no questions 'bout that, but also given that premise they are best served by good software that helps them get their job done. If a kick ass GPL software can do that, great. They will even pay for it. If not? They will pay for the non-OSI one that bundles the GPL and will laugh at GPL enforcement attempts. Licenses are…

Such snarky tone sounds unnecessary on HN. > unless it's well-enforced AGPL3++ GPL has been successfully enforced in various occasions, and it can be enforced effectively especially when large companies need to protect their R&D investments from freeloading competitors. A new, stronger "AGPL3++" can be written and enforced. Many companies have been experimenting with new licenses to find more sustainable options than…

It seems necessary when a comment is throwing around hard claims like MIT is bad for FOSS without any supporting evidence/argument, with a side dish of maximum pathos of "think of the poor users".

> especially when large companies need to protect their R&D investments from freeloading competitors.

That sounds interesting, I haven't heard about instances like these. Can you name a few examples?

Post reply on HN