151–160 of 199 posts
Reminds me of the famous Torvalds Tanenbaum debate. https://groups.google.com/forum/m/#!topic/comp.os.minix/wlhw...
Thanks so much for the share, great gems in here, I still found myself surprised at this: > True, linux is monolithic, and I agree that microkernels are nicer. It's hard to believe that he was only 23 when he wrote this
The title is missing "from a security standpoint". Of course, everything is a tradeoff. TLDR: > We have presented what is, to the best of our knowledge, the first quantitative empirical assessment of the security implications of operating system structure, i.e. monolithic vs microkernel-based design. > Our results provide very strong evidence that operating- system structure has a strong effect on security. 96% of cr…
Earlier quoted context omitted.
and according to someone, your Nintendo console too It's quite crazy to count all the layers cpu microcode cpu isa hypervisor os kernel userspace api browser runtime js vm application your mouse I want my 386 back
Soon it will be: ... webassembly vm (insert variable height custom stack) application ... Sad times.
This is like saying Linux is more secure than Windows because not all of Window's critical vulnerabilities appear in Linux.
Earlier quoted context omitted.
The BB10 phones were just as amazing as the Playbook - the UI was oh so smooth and responsive. I'd still be using my Q10 if it had more native apps or better Android compatibility.
One problem with Android is little delays that happen while typing. I thought a QNX-based platform could avoid that if they made sure UI parts were given adequate time slices. Was there any typing lag in those products?
Earlier quoted context omitted.
Linux on the desktop would have succeeded with a stable driver API. Having hardware with closed source drivers supported could have being a walk in the park for OEMs. Bad 3D, wireless, etc. support is what killed Linux. OEMs would have probably made more and better drivers if they didn't have to make changes to them every few months or go through the effort of releasing and mainlining the source.
This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits. Any operating system that wi…
Creative Fucking Labs.
Someone told me back then that the sound blaster drivers were responsible for more crashes than the next several causes combined, so I started watching and I’ll be damned if I didn’t see the same thing.
Earlier quoted context omitted.
Recently committed Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel framework is going even further in that direction. https://lwn.net/Articles/758745/ > Could allow for APK installable kernel drivers, allowing modules to be upgraded (even live) https://twitter.com/MishaalRahman/status/1029064974805688320
Interesting thanks for sharing. Looking forward for when it pops up on AOSP.
That chart with the growth of the Linux kernel discredits everything. The Linux kernel continues to grow because they are obsessed with keeping all drivers in mainline instead of having a stable API for them as any sane project would.
It's not misleading because most Linux kernel drivers run in kernel space; hence compromising them indeed potentially compromises the whole system, which is exactly the article's point. The fact that they're often buggy and poorly supported, unlike the "real" kernel, makes things worse and doesn't invalidate anything.
You can have hybrid systems where the code runs in isolation but the pull requests are still self contained instead of split into multiple pieces that have to be coordinated.
There is a reason why kernel code run in privileged mode, speed! If you run more kernel code in privileged mode then you do not need to copy as much data between the kernel and user space. Vs a micro kernel you will have to copy more data up to user space. Copying data to user space causes context switches and gives less performance. Larger mono kernels: Speed Micro kernels have advantages such as: smaller privileged…
Code doesn't run faster because it's in the kernel. The speed you're talking about comes from avoiding transitions in and out of a given space. If you stay out or stay in the results are pretty similar. Except for your tooling. Cloudflare article from a couple years ago on why they don't use user-space network stack: https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp... and the tl:dr is a profound lack of f…
Which is impossible when service A and service B are both in user space, because they are in separate spaces.
Ring 0 isn't special, but you need to be monolithic if you want to avoid transitions.
I'd hazard to say that every design is "flawed" in some regards: there's no way to achieve all desirable qualities and none of undesirable qualities. For one, some desirable qualities contradict each other. So "${thing} is flawed" is not precise enough; an interesting statement would be "${thing} is not the best choice for ${conditions}". A monolithic OS is not the best choice for a high-reliability system on unrelia…
If we can't make reasonably secure controllers with only 4KB of RAM, perhaps we shouldn't be making controllers with only 4KB of RAM. Tech and market pressure will make more capable processors affordable if security is prioritised.
For a small system like that, the shining ideal is probably a formally verified single program with no real OS to speak of.