Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wish message passing and capabilities based OS had taken off stronger in the 80s because I sometimes feel like there are design goals and approaches latent in what we do now, which we could have been advanced in before now, beyond research models.


I don't think they were as tenable then as they are now.

When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.

A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!


This is why Linux works and is good and most other kernels are slow and don't work. Linux has been optimised over the years based on how software actually works rather than fantasies about how it would work it we got to rewrite the world.


Me too. Containers are so janky compared to what we could have.


ios is capabilities based, no?

Edit, to explain: in ios, everything revolves around mach ports, which are capabilities.

https://docs.darlinghq.org/internals/macos-specifics/mach-po...


Yes. And without over stating it, iOS is an amazingly robust, very secure OS. it has high trust and low trust models, a secure zone, special purpose hardware and an operating system designed around minimum access rights models which manages to keep going, despite app authors worst intentions.

At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach at the core, at one point IIRC


I'd have to disagree -- the lack of OS-level sandboxing primitives such as seccomp-bpf and SELinux[1] means that exploits happen rather regularly in iOS rather often ([2], among others).

[1] https://source.android.com/docs/security/app-sandbox#protect...

[2] https://www.csoonline.com/article/3811322/iphone-users-targe...


Does the Apple Sandbox[1] not count? What about TrustedBSD[2] and the MAC (Mandatory Access Control) subsystem introduced as part of SEDarwin[3]?

[1] https://www.ise.io/wp-content/uploads/2017/07/apple-sandbox....

[2] http://www.trustedbsd.org/mac.html

[3] http://www.trustedbsd.org/sedarwin.html


iOS has a perfectly good sandboxing model that is literally called "the sandbox". You will note that the impact of that bug is limited to the process it is triggered in for precisely this reason.


Not to deny that, but it didn't (for example) break the Secure Enclave. Key exfiltration didn't happen AFAIK.


iOS is without question one of the most secure OS out there today with any amount of real world use but the gap between what it is and what state of the art looks like is also insane. Fuchsia is actually quite well aligned with something that’s actually defendable in the real world and across time.


> despite app authors worst intentions

All app authors must comply with the rigorous App Store guidelines so the technical limitations on what they can do don't really matter anyway.

Add sideloading as an option and we'll get to see how secure iOS really is.

GrapheneOS is definitely secure enough to tolerate sideloading, but I don't know if iOS is or not.


It maybe robust, but it's very very limited in capability. There's no depth to GUI interactions.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: