vacuity

21 ms·

331.
by vacuity 2y ago
Since I still have operating systems on the mind from another HN thread, I would phrase this as being aware of the whole system and optimizing it globally. And speaking as someone with horrendous time management habits, I fully agree with t
332.
by vacuity 2y ago
A core conflict is determining who should hold complexity ("how much" is implied). From an operating systems perspective, I like seL4's approach of being a highly minimal kernel, which necessarily means pushing out significan
333.
by vacuity 2y ago
You're right, but the key thing about description and prescription is that they aren't really separate. You constantly have to ask "does this work well here?", "should I replicate it there?", and so on. They de
334.
by vacuity 2y ago
Unfortunately Unix processes aren't up to snuff, hence we introduced a bunch of dubious add-ons. Recently HN had a post on seL4; microkernels and capabilities were brought up. But of course backwards compatibility is tough...
335.
by vacuity 2y ago
Well, one thing about adapting seL4 is that we shouldn't assume derivatives will be formally verified to the same degree. Ideally we would, but I don't expect this to happen in practice. And having a kernelspace scheduler that is
336.
by vacuity 2y ago
I appreciate your criticism; it is reasonable and relevant in the present and the future. I wrote a reply nearby in the thread[0]. I think it's mostly solveable, but I agree it's not trivial. [0] https://news.ycombinato
337.
by vacuity 2y ago
I agree that a well-designed system for most use cases won't have performance issues, since we should not just be optimizing context switches but also things like kernel bypass mechanisms, mechanisms like io_uring, and various applicat
338.
by vacuity 2y ago
I think NUMA management is high level enough that in a microkernel it would be comfortably managed in userspace, unlike things relevant to performance-critical context switches. And seL4 is currently intended only for individual cores anywa
339.
by vacuity 2y ago
That doesn't seem right. Even with strong hardware protections, how is Linux's TCB comparable to a microkernel? Unless it just recreates the exact same protection domains, there will be more vulnerability in Linux. Rather, the thi
340.
by vacuity 2y ago
Even if it's not exactly seL4, there's good value in taking inspiration for design elements. It would still be a lot more robust than commodity operating systems.
341.
by vacuity 2y ago
I suppose I should ask the other side too, though I am biased to favor microkernels, and am better read on them, but how so? "Safe enough" measured by the standards of this upside-down industry...I'll let everyone decide that
342.
by vacuity 2y ago
The hypervisor/microkernel boundary has blurred, and commercial success for microkernels is more or less as hypervisors, e.g. OKL4 is widely used in mobile devices[0]. And Tanenbaum's Minix is used for the Intel Management Engine.
343.
by vacuity 2y ago
This leads to big units of code, namely multiple OSes, whereas the ideal is being able to use as finely granular units as developers are able to stomach. For example, Xen can work around the issue of device drivers by hosting a minimal OS i
344.
by vacuity 2y ago
Rather, although I believe the seL4 scheduler is sufficiently general, I want a userspace scheduler to minimize policy. The seL4 team recognizes that a kernelspace scheduler violates Liedtke's minimality principle for microkernels, sin
345.
by vacuity 2y ago
The question is always "how big of a replacement are we talking?" Redox seems to be committed to interoperate well with POSIX, which naturally informs its design decisions. And there's a huge difference between having technic
346.
by vacuity 2y ago
People should stop bringing up Mach so much. It should never have been the poster child for microkernels. It's poisoned the discourse when there are plenty of alternative examples. Granted, Mach also did some good work in the space, bu
347.
by vacuity 2y ago
My (admittedly limited) understanding is that IOMMUs still have practical roadblocks to being a solidly established part of the security of the computer. Of course they aren't bad in principle. Perhaps it's just that we aren'
348.
by vacuity 2y ago
It turns out that success is composed of 90% luck, 10% marketing, and 5% talent/technical advantage. A rhetorical question: how do you entice people to turn a movement into a revolution when it isn't likely the movement will succe
349.
by vacuity 2y ago
I will caution that IPC microbenchmarks should not be taken as confirmation that the "academic microkernel" is viable: OS services all in userspace and with fine granularity as is appropriate. Often microkernel-like designs like V
350.
by vacuity 2y ago
I want the magical IOMMUs that are maturely secure like MMUs are now. For now, I think various efforts in verifying/restricting/generating drivers are far better, although they fall particularly flat for proprietary drivers.
351.
by vacuity 2y ago
The dose makes the poison; we're still a long way from fulling embracing microkernels and capabilities. Security is a holistic property and encompasses finer details too. I want a small TCB. I want capabilities pervasively. And in purs
352.
by vacuity 2y ago
I agree, but I think we have to accept that there isn't really a reliable way to convince people of something. People (and I include myself) struggle to discard beliefs borne of intuitive, irrational processes. And personally, when I r
353.
by vacuity 2y ago
Though that name came from Wirth as editor. The original name ("A Case against the GO TO Statement") is somewhat less inflammatory.
354.
by vacuity 2y ago
Sorry, my wording wasn't clear and neither was my direction. I'm mainly talking to the people you replied to, since I find they're pulling a lot less weight in the whole "good faith" endeavor.
355.
by vacuity 2y ago
> In my case that was less out of a desire for supply chain security (impossible if I'm just swapping the std lib) and more to discourage side effects from being produced deep within the core of program logic. Although I like capabi
356.
by vacuity 2y ago
You have some good points, but this store also has an outsized role in the community and a large shock will drastically affect the community. Take a patient who has an infected wound. I guess you would say the prevailing approach was to put
357.
by vacuity 2y ago
It's also frustrating to see people "rationally" telling us to "wait and see" what DOGE will deliver. Sure, I have preexisting biases against DOGE. I guess I shouldn't ask who has preexisting biases for DOGE, b
358.
by vacuity 2y ago
Also, why is "anyone [can] build software without learning to code" a desirable goal? Expanding the range of programmers, sure. Making programming easier for all programmers, sure. But what is the goal of allowing anyone to progra
359.
by vacuity 2y ago
I favor the microkernel philosophy, which means removing code en masse from the kernel even at the expense of typical programmer convenience and possibly performance. I appreciate that TFA presents a counterargument that acknowledges the tr
360.
The File System Belongs in the Kernel [pdf] (1991)(usenix.org)
2 points by vacuity 2y ago|1 comments

More ›