Live data from Hacker News

A Kernel Hacker Meets Fuchsia OS

a13xp0p0v.github.io

261–270 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#261
post #249

Earlier quoted context omitted.

>then surely it should be at worst unsightly? What me and other people are trying to get across to you, is that you only feel this way because you support the cause. The practice of filling every place and institution with your partisan beliefs is a sign of disrespect, essentially a power move. "You're here to read up on an OS, but joke on you, you actually can't escape the all-pervasive hand of my religion. Here's s…

I really can’t see the equivalency between a political stance (imo a movement for racial equality) and religion. The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program. > In the concrete case we're discussing here, only progressive tech companies signal their beliefs in this vulgar way, no conservative tech firm have ever put "Blue Lives Matter" or "Make America Gre…

>I really can’t see the equivalency between a political stance (imo a movement for racial equality) and religion.

Politics and religion are notoriously related. They are both morally charged subjects that infamously degrade people's ability to see the world clearly and discuss pros and cons rationally. I can cite plenty of pro-BLM speech and actions that disturbingly mirror religious language and actions. The fact that most BLM supporters might not speak or act like this is irrelevant too, most Christians don't go to church either.

>The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program.

I'm really puzzled as to how this supports BLM banners in OS design documents though. You said "by necessity", is BLM mottos and iconography necessary to understand micro kernels as much as Cold War terms and timeline is necessary to understand the Apollo program ? that would be an... interesting point to argue.

Even ignoring this, not all politics is created equal. "The Apollo program was created as a demonstration of technical supramecy by the US intended to intimidate the USSR" is politics. "The Apollo program was when we showed those dirty commies who's the boss" is also politics. I hope you agree the first statment is vastly more palatable and neutral than the second. The vast majority of progressive mottos and rallying cries strike my ears like the second statment.

>No, but many will willingly participate in the US military industrial complex, which causes significantly more actual harm.

This is a strange thing to say for more reasons than 1

1- Conservative tech companies aren't any more likely to cooperate with the US military than progressive tech companies. Amazon and Google, hardly bastions of conservatism, are both known contractors to the US military. So if you hate this, you should hate all influential US tech companies, conservatism is not a useful predictor of this any more than random chance.

2- I'm not assessing who is "doing more harm overall", I'm assessing who's asserting ideological power over people in vulgar ways. US military power projection is an entirely different topic for a different conversation, we're now talking about who brings their obnoxious politics into the workplace. There are different ways of disliking things, I dislike the US military power posturing and US progressives power posturing in 2 different ways.

>This kind of banner is uncommon even among Silicon Valley companies.

Which is all the more reason to think it's forced virtue signaling.

>It’s not as if there would be outrage if it weren’t there, or if it disappeared.

I see you're unfamiliar with Twitter.

>Finally, these are all reasons why someone who doesn’t agree with BLM would feel excluded by the banner.

When it comes to religions and religion-like things, "disagree" is anything that isn't "agree". Any Non-Muslim "disagrees" with Islam, not because they have read the history of the prophet (which is awful) or studied Islamic Theology's arguments for why Islam is true (which is weak), but simply because Non-Muslims don't say "No God but Allah" and don't pray 5 times a day. They are non-believers, not dis-believers.

>Do you feel that most people outside of the US view BLM negatively or indeed have an opinion at all?

I can't speak for all the world off course, but I do feel that BLM is entirely irrelevant and unknown in my country, even if the events that sparked and galvanized it was internationally known. Again, no need for intense, explicit disagreement here, although I personally do think it's a destructive obvious scam\religion mix that every person who knows what it does and what kind of people run it should oppose it intensely, but there's really no reason to go that far.

Do you think you need hate or disagree with Islam to despise and hate the hypothetical practice of Muslims writing religious verses in completely unrelated writings? Do you think you need to hate or disagree with Communism to despise the hypothetical practice of Chinese Scientists writing pro-CCP mottos in completely unrelated writings?

My answer to the above question is No, I hate ideological spamming as a pathetic authoritarian practice regardless of the ideology doing it. In fact, sometimes I will hate the ideology itself, for no other reasons but the spam that its fanatics continually pump, and I think my view is a fairly popular and widespread to view things.

Whatever merits BLM might have had, it's completely eclipsed by the fact that their true believers seem to believe that micro kernel developers must hear them when they are reading up on their work.

Re: A Kernel Hacker Meets Fuchsia OS

#262

Earlier quoted context omitted.

It can mean what the parent is talking about, and does in this case. It's an older morph of capability based security than the newer crypto enforced name concept, but equally valid. You can read more about it in Capability Based Computer Systems by Henry M Levy. The Hydra MMP, GE-645, and iAPX 432 are older implementions of this concept in hardware. In both cases (TCB table enforced and crypto one way function enforc…

What you're referring to is how operating systems maintain the integrity of capabilities. This is addressed directly in 'Capability Based Computer Systems'. I would direct you to chapter 1 section 1.1. > A capability thus provides addressing and access rights to an object. > a program cannot access an object unless its capability list contains a suitably privileged capability for the object. > Capability system integ…

In these non crypto enforced capability systems, you don't have any control over other processes' names for resources addressed through capabilities is the point I'm attempting to get across.

Crypto backed capabilities that merge the token with the capability itself are one morph of capability based systems, but that's not the scheme being described here. Leaking the name of a capability (the offset in the cap table) does not leak the capability itself in these TCB schemes. Capabilities are still communicable in these TCB schemes because they're explicitly supported in the IPC mechanisms like SCM_RIGHTS or seL4_Send along side normal data. The token naming a capability then is a per process concept and you can clone an identical capability into several tokens in the same cap table, unlike the crypto enforced scheme which are basically content addressed storage for a secret representing a capability.

Re: A Kernel Hacker Meets Fuchsia OS

#263

Earlier quoted context omitted.

>Unlike Linux, Fuchsia is not under GPL. It's under MIT (the kernel Zircon specifically since comparing with Linux). Whether a license allowing even more freedom is worse is arguable.

I know - it provides google the freedom to lock down the OS further and the freedom to implement proprietary drivers. Yay for arguable freedom.

>the freedom to implement proprietary drivers

That exists already. Vast majority of Android devices require binary blobs in kernel for essential functionality.

Re: A Kernel Hacker Meets Fuchsia OS

#264

Earlier quoted context omitted.

I know - it provides google the freedom to lock down the OS further and the freedom to implement proprietary drivers. Yay for arguable freedom.

>the freedom to implement proprietary drivers That exists already. Vast majority of Android devices require binary blobs in kernel for essential functionality.

> require binary blobs

That's the point. With something like fuchsia there can be entire closed forks of the kernel instead of having to blobs, making closed source easier to develop.

Re: A Kernel Hacker Meets Fuchsia OS

#265

Disclaimer: I made some contributions to Fuchsia and I am clearly biased. I am not sure why there's so much negativity around Fuchsia. From a technical point of view it's finally a serious attempt to do something new in the OS space. It might not be the right and perfect answer, but it might introduce new paradigms and maybe some fork of the project might be able to provide additional benefits for end users down the…

> I am not sure why there's so much negativity around Fuchsia. Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.

Haha.. Take that evil open source OS! Let's see what are you going to do against "We" and our strong slogans.

Re: A Kernel Hacker Meets Fuchsia OS

#266

Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it…

> "(b) being able to be free of the GPL" Wouldn't the easier path have been just for Google to contribute (or fork) Free/Open/NetBSD?

Seems like BSD/Linux seems fundamentally not compatible with what they want to achieve technologically. It is not a license issue.

Re: A Kernel Hacker Meets Fuchsia OS

#267

Earlier quoted context omitted.

I’m not sure how fuschia does it, or how feature-based capabilities work, but Cheri[1] uses capabilities for memory management and isolation. It uses a couple of techniques, like wide/tagged pointers, object ids, and a special hardware managed bit to track illegal modifications. If I had to hazard a guess, those object ids are probably useful for general capability systems. I think apple (maybe as just an arm feature…

> I think apple (maybe as just an arm feature?) can do encrypted pointers, with a per application key tracked by the kernel. ARM has added both pointer authentication codes and memory tagging extensions to their ISA, from (I think) ARMv8.5-A. Apple are the only ones to implement silicon that supports PAC that anyone can buy today but a) this will change fast and b) I might've missed something else. I wouldn't say "en…

PAC is ARMv8.3, and Apple implements their own custom algorithm rather than QARMA.

Re: A Kernel Hacker Meets Fuchsia OS

#268
post #245

Earlier quoted context omitted.

That's just not true. It might not be seen in your particular country, but it's definitely not US centric. Canada, Sweden, and New Zealand are also countries where Chromebooks are sweeping education https://www.neowin.net/news/chromebooks-are-seeing-huge-adop... And the reasons why are pretty straightforward. Kids can't really mess them up, they are highly sharable (eg laptop carts), they are cheap (generally), and t…

In countries where parents pay for kids computers, and worry about what everyone else is using, they don't get any uptakes. Before COVID, most schools were still about pen and paper in most European countries, computers are used at home.

That's yet again not true. Parents are often paying for the Chromebooks used in some of these markets (eg, US & Canada at least). That the school requires a certain OS doesn't change who pays for it, just like parents are still buying TI graphing calculators.

> Before COVID, most schools were still about pen and paper in most European countries,

Gonna need a citation on that one. It'd be quite surprising for European schools to be so far behind

And from what I can find, they weren't. Eg way back in 2006 https://www.theverge.com/2013/4/19/4242022/europe-ict-survey...

"Scandinavian nations like Norway, Denmark, and Sweden are able to provide computing equipment to almost every single student and teacher within their borders"

Re: A Kernel Hacker Meets Fuchsia OS

#269
post #211

Something that I haven't seen brought up yet is the "weird C++ vtable layout." This is actually the "relative vtable layout" that's first described here: https://bugs.llvm.org/show_bug.cgi?id=26723 , and is usable in clang via the -fexperimental-relative-c++-abi-vtables option. The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the…

Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway. Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of…

Almost but not always. Fuchsia saw 1% memory savings (~20MiB) by enabling it:

https://youtu.be/9HGKlDiJy8E

Re: A Kernel Hacker Meets Fuchsia OS

#270

Earlier quoted context omitted.

What you're referring to is how operating systems maintain the integrity of capabilities. This is addressed directly in 'Capability Based Computer Systems'. I would direct you to chapter 1 section 1.1. > A capability thus provides addressing and access rights to an object. > a program cannot access an object unless its capability list contains a suitably privileged capability for the object. > Capability system integ…

In these non crypto enforced capability systems, you don't have any control over other processes' names for resources addressed through capabilities is the point I'm attempting to get across. Crypto backed capabilities that merge the token with the capability itself are one morph of capability based systems, but that's not the scheme being described here. Leaking the name of a capability (the offset in the cap table)…

Semantics aside, is it accurate to say that schemes where the capability is represented as a signed token require care and diligence to mitigate leaks, and schemes where the capability is represented as a table entry (mapping a user/process to a permission) don't require any meaningful care/diligence?
Post reply on HN