vacuity

23 ms·

241.
by vacuity 1y ago
I guess I don't understand how much the spec dictates the architecture of Tritium, or the motivation for the Option return type specifically. In any case, it seems like future development will improve upon this. Have fun and good luck!
242.
by vacuity 1y ago
This approach is brittle to upstream code changes, and I don't think it should be used, but at least there is an effort to avoid catastrophic behavior (unlike Linus's philosophy for Linux). Both panicking and arbitrarily-nested er
243.
by vacuity 1y ago
What are examples of the MMU leading to poor abstractions? I agree it's not ideal, and encourages some poor abstractions, but I think it's moreso the case that mainstream operating systems have failed to innovate sufficiently. For
244.
by vacuity 1y ago
I agree with your general premise, in that there are bad actors, and appearance is a powerful classifier, so identifying potential bad actors by appearance is genuinely useful. I think there are many caveats in practice, such as: How do
245.
by vacuity 1y ago
Explicit abstractions should be the default, I agree, and the descriptions of Rust's tradeoffs and objectives as a programming language resonate with me. Although I think more effort is being spent on frontend Rust than is wise, but ma
246.
by vacuity 1y ago
I think you have to standardize a basic object system and then allow people to build opt-in interfaces on top, because any single-level abstraction will quickly be pulled in countless directions for as many users.
247.
by vacuity 1y ago
If everything can be represented as a Foo or as a Bar , then this actually clears up the discussion, allowing the relative merits of each representation to be discussed. If something is a universal paradigm, all the better to compare it
248.
by vacuity 1y ago
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me you
249.
by vacuity 1y ago
I recently came across a much earlier HN submission[0] to this paper. While the points the commenters made (with excellent citations) are correct, I feel that a charitable reading of the paper finds that it is not in opposition. [0] https:
250.
A Rational Design Process: How and Why to Fake It (1986) [pdf](ics.uci.edu)
4 points by vacuity 1y ago|1 comments
251.
by vacuity 1y ago
I certainly can't claim to have discovered these ideas, though perhaps I am one of the earliest to propose gutting the kernel as heavily as I am (the riskiest manoeuver out of my proposals). > This is more radical than the other gre
252.
by vacuity 1y ago
This is mostly untreaded territory, true, but I think going to extremes is instructive for moderation. In this kernel or others, abstractions can be created to build back up to what we are used to, but going far afield is necessary to remak
253.
by vacuity 1y ago
I agree that the decisions will likely be made in the end, but I want to say that the decisions should be made as high/late as possible. It is important to note not just that a decision has been made, but where it has been made, for an
254.
by vacuity 1y ago
An HNer after my own heart! If only Parnas' work had gotten more mindshare. Everyone knows about the benefits of modularity and layering, but most examples are unconvincing. Even simpler than "modularity", in a manner unifyin
255.
by vacuity 1y ago
At its core, it's not too distinct from, say, seL4, but some of the distinctions are useful. I think Hongmeng's work on isolation classes (particularly in transferring components across classes), a performance-motivated partial al
256.
by vacuity 1y ago
I have a general distaste for transparent policies, which I always find to fall short for some use case. In this case, the sender would know best what to do with their message. Moreover, for small buffers, page remapping won't be an op
257.
by vacuity 1y ago
I learned of the idea from some paper or other of Barrelfish, which is a research OS based on seL4. Barrelfish is underrated! Aside from its takes on a kernel architecture, it also has interesting nuggets on other aspects of OS design, such
258.
by vacuity 1y ago
Perhaps it won't be open sourced, but having read one of the papers written for it, the principles behind its advancements can easily be added to the microkernel repertoire.
259.
by vacuity 1y ago
The terms I've seen used and prefer to use are "essential complexity" and "accidental complexity".
260.
by vacuity 1y ago
To be clear, since the other replies to you don't seem to be mentioning it, the major costs of MMU page-based virtual memory are never about setting the page metadata. In any instance of remapping, TLB shootdowns and subsequent misses
261.
by vacuity 1y ago
> I don't think it's reasonable to compare the risk of suffering a large loss with the risk of missing out on a large gain. If your annual income is $N, missing out on a gain of $N is bad, but not nearly as bad a suffering a lo
262.
by vacuity 1y ago
Yes, it is to synchronous programming's great credit that it is simple, and to its great discredit that it is inefficient. Engineering tradeoffs, and all that. Quote[0]: > In Ingo's view, there are only two solutions to any ope
263.
by vacuity 1y ago
Yes; my understanding is that, for kernels designed for 1:1 threading, scheduler activations are an invasive change and not preferred by developers. Presumably, an operating system designed around scheduler activations would be able to bett
264.
by vacuity 1y ago
Thank you for your insights. I think this comes down to a culture problem. Some people such as myself obsess over the low-level details, so every usage of Vec stands out immediately. At the same time, many people like to use Rust in areas w
265.
by vacuity 1y ago
Although not a comprehensive report, people tend to count the source lines of unsafe in a Rust codebase as a metric. Moreover, reputable libraries worth using typically take care to reduce unsafe, and where it is used, encapsulate it well.
266.
by vacuity 1y ago
To be clear, Rust encourages the development of safe abstractions around unsafe code, so that the concern goes from proportion of unsafe to encapsulation of unsafe. Whether you trust some library author to encapsulate their unsafe is, I thi
267.
by vacuity 1y ago
I agree that unsafe Rust is not comfortable or simple, but I think it is usable when appropriately applied. It should very scarcely be used as a performance optimization. The Rust devs are quite invested in minimizing unsoundness in practic
268.
by vacuity 1y ago
Threads as they are conventionally considered are inadequate. Operating systems should offer something along the lines of scheduler activations[0]: a low-level mechanism that represents individual cores being scheduled/allocated to pro
269.
by vacuity 1y ago
As a sibling comment[0] mentioned, pattern types are actively being worked on. [0] https://news.ycombinator.com/item?id=45474777
270.
by vacuity 1y ago
Linux's use of pointer-heavy datastructures is largely justified even today. The low-level kernel bookkeeping requirements rule out many typical suggestions. Modern hardware suggests certain patterns in broad strokes, which are sound f

More ›