I think I've got the gist now. Although I think Gernot Heiser doesn't consider the following to be ideal, I think it's fair to say that true claims have undergone some sensationalization. I don't think people generally lie when they say their product has achieved some impressive performance, but those results exist in the context they are taken under. In the embedded roles LionsOS is being targeted for, I have no doubt that they represent a real improvement over existing Linux systems, and probably any Linux system short of a magical one. However, in a general-purpose OS (which is what I focus on), which is the same as saying that many distinct user bases are simultaneously involved, the kernel is far from being the only load-bearing component. Also note that the functionality compared is not 1:1, nor is Linux the final contender of monolithic systems.
Something I want to explore, and which has some viability in the LionsOS model too, is that a general-purpose system may still liberally cut out unused functionality if highly modular and easily configurable. Like Legos.
In conclusion, props to the people at Trustworthy Systems as always, but it's safe to say that the OS field is still far from settled. My best compliment to seL4 is that it has raised the bar and simultaneously paved the way for future generations of advances. It's a seminal work that was desperately needed.
I think the framing of "monoliths vs. microservices", with the implication that you must either have a mountain of a codebase or a beach of grains of code-sand, is not helpful. Good modularity means that different levels of tradeoffs can be made without huge effort.
Presumably no one thinks "I love using [dynamically-typed language] because I can make mistakes easier", but on the other hand, isn't it the case that large codebases are written with low initial friction but high future maintenance?
I will check those out tomorrow, but in the meantime: I don't mean to say that a microkernel-based system is necessarily worse on performance. However, I think a highly optimized monolithic system will probably always be somewhat faster than a highly optimized microkernel-based system. And note that the seL4 system is probably less mature, and that I have many criticisms of Linux in being a supposedly highly optimized system. I'm all for microkernels. I'm planning to write one myself. But there are some aspects that microkernel-based systems have to work harder on.
Note: IPC performance isn't the only factor in overall OS performance. Especially for a "traditional microkernel", where programs are split up into separate processes liberally, performance degrades due to the sheer number of cross-boundary interactions. A whole system is performant if the design of the whole system, not just the design of the kernel, is aligned with performance. This is not to put down seL4; on the other hand, it continues the trend of L4 microkernels demonstrating the viability of stricter designs. But keep in mind that more time and effort is necessary to implement larger systems well.
Note: IPC performance isn't the only factor in overall OS performance. Especially for a "traditional microkernel", where programs are split up into separate processes liberally, performance degrades due to the sheer number of cross-boundary interactions. A whole system is performant if the design of the whole system, not just the design of the kernel, is aligned with performance. This is not to put down seL4; on the other hand, it continues the trend of L4 microkernels demonstrating the viability of stricter designs. But keep in mind that more time and effort is necessary to implement larger systems well.
I'm bullish on capabilities too, but I don't know much about MAC. Can you explain your last sentence?
More generally, even if someone says something questionable, there may be something to learn from what they said. Always seek to learn and grow, because all that you can learn from is before you.
It may not be the case for statins specifically, but my main concern is side effects. If there was a panacea, I would support giving it to everyone, but lifestyle changes are usually more available, if not easier.
I think the error type stuff should be less prominent, and really shouldn't be front-and-center in the standard library, or any library. Error handling is undoubtedly important, but its expression in the API is a different matter. I don't have fully formed opinions, but I do feel that the common recommendations are bad.
On the topic of allocators, I noticed some PRs to add allocator support to more types recently...great, now we just need to stabil—oh, wait. Although I care more about not stabilizing a bad API than eternal unstability, if it comes down to that.
Given the troubles with shipping Polonius, I imagine that there isn't much more room for improvements in "pure borrow checking" after Polonius, though more precise ways to borrow should improve ergonomics a lot more. You mentioned borrowing just the field; I think self-referential borrows are another.
You're exaggerating heavily, which undermines your claims. While Rust claims to allow fearless concurrency, there is plenty of official documentation to show that the limitations are acknowledged. Anyone telling you Rust prevents memory leaks and race conditions is lying, straight up, and this is trivial to verify. You shouldn't be repeating it. Your comments on Send/Sync and unsafe are similarly exaggerated. I have to say, you must be interacting with Rust zealots beyond what I've ever seen, if this is truly your belief.
The borrow checker is an approximation of an ideal model of managing things. In the general case, the guidelines that the borrow checker establishes are a useful way to structure code (though not necessarily the only way), but sometimes the borrow checker simply doesn't accept code that is logically sound. Rust is statically analyzed with an emphasis on safety, so that is the tradeoff made for Rust.
I could argue on technical aspects, but firstly, how do you square what you're saying with Rust code used in production codebases? Do they not do multithreading, or shared memory, or complex allocation patterns? Sure, Rust is not a silver bullet (nothing is), and it has many pain points, but the picture you're presenting is entirely incongruous with the reality of programs written in Rust.
You used "they" several times, so I took a certain usage to mean "Rust", and I was asking who specifically "Rust" entails. Who defines the "Rust beliefs"?
> > Being on a side suggests an unwillingness to part ways
"Suggests", as in, "it is likely implied that" (emphasis on "likely"), though I should've been more clear.
> I have to assume their politics is more intimate to them than the maintainers of a programming language, and that they used it here because the conversation we are having is around rust.
The primary topic is politics.
---
I find issue with the framing of "taking sides". I hear it and think of fragmentation for the sake of fragmentation. There is a distinct difference in saying "I side with Rust" and "I agree with Rust", the latter being reducible to "Rust believes [a belief]" and "I believe [the same belief]". The former can be used to mean the latter, but I choose to focus on the likely implication.
Your comment is really quite interesting. Thanks! What you're saying all sounds plausible to me.
I note that, while different circles may call for "purity" (fans of, e.g., Unix, Lisp, or Haskell), I think honestly pursuing the purity of writing programs to achieve one's goals means rejecting dogmatism and accepting pragmatism. Adherence to beliefs is fine if, and only if, the beliefs are fundamentally justified....
I think I see most Rust threads here. Perhaps there is a low presence in most threads, but I didn't notice a significant rate as the baseline. Though this thread is burning up, certainly.
I think that many people leaning toward the latter are "merely" misguided, though I certainly don't think that to correct them would be easy. However, I genuinely think some people are taken to be hateful when they aren't. Discussion of such cases should not be taken with the presumption that the accusations of hate are true, because then truth gives way to opinion. A good cause is a good cause, but realization invites bias.
Not quite your fault, but the framing of "people you don't agree with" juxtaposed with the implicit statement of "people who promote hate" (or similar) doesn't make for a clear discussion. To be clear, those two types are well separated. If someone is of the latter type, really truly they are, then they can be removed without further ado (and I think GP would agree). I think the situations that are less clear cut will make people in good faith fight.
Morality partially stems from autonomy (in the sense that "I should be able to act as I please"). According to autonomy, a person should be able to act freely, and two people should be able to interact similarly. One person's policy will be judged by any other, who is free to act by a distinct policy. But autonomy alone doesn't make for a good person, or a good society. The other factor in morality is non-hypocrisy (in the sense that "I should act how I say I should act").
I've laid out a neutral response. Of course I have my personal beliefs, as one does, but I speak here without pretense. Believe what you will.
I think this is rather hostile. There is moderation from not using dependencies or from using too many dependencies. I don't think GP is advocating for no dependencies, either. Even vendoring and pinning dependencies provides benefits.
But who is "they"? What does it mean to be "on the same side as Rust"? What if Rust maintainers disagree? Being on a side suggests an unwillingness to part ways, which is more commitment than merely agreeing to a set of beliefs at some time. If Rust is a worthy rock in the political sphere for the moment, then there is no trouble in believing alike, but only for the moment. Every actor should prove themselves constantly, not to be orbited.
> Instead they hear voices from the LGBT community
Oftentimes, the voices are outside.
I think you're somewhat optimistic, and "the middle ground" is not a magical place. It's easy to fall into a false sense of security that comes from making (likely valid) criticisms of caricatured groups. Middle ground should not be sought for its own sake, or else it becomes useless (akin to Goodhart's law; roughly "when a measure becomes a target, it ceases to be a good measure"). People should embrace a diversity of values, but the burden is to stay true to a set of values and push for the truth.
I agree with you, although of course "don't be an asshole" is only simple to enforce in practice. In the current climate, I expect that people considered "conservative" will still be highly hostile to good faith (let alone not) enforcements.
No matter the person, it's really disappointing that we're still entrenched in the mentalities of tribalism, anti-intellectualism, "if you're not with us, you're against us", "an eye for an eye", "someone hurt me, so I'm going to hurt someone", and so on. And by "person", that includes me.
The Earth politics patch really can't come soon enough. How much do we pay the devs, again?