How do you learn that solution curve and their tradeoffs? Swap jobs and hope you see them all in your lifetime? Read articles and hope you pick everything up correctly?
The V-model is interesting. I'm a student and kinda new to the different development models.
How to decide whether such meticulous design is necessary or not? In hindsight Btrfs may have benefited, but how to decide when to and when not to in the future?
I would also be interested to know what tools are used for this. The ones I looked at seemed quite dated.. :-)
Thank you for answering! This is very interesting to learn about
Can you tell how such evaluation on a design is done? Is some kind of formal verification, analysis or rather experimentation to figure out its properties normal?
Do other parts stomp often? :) But true that can happen. Especially on non-ECC systems.
I didn't think about the hardware issues, hmm. I can't see how to do that, when the compiler guarantees get invalidated by hardware. Checks are also needed like in C? (assuming there are checks which do not get compiled out..)
> C is generally not the problem when it comes to performance issues in the kernel, which means rewriting that thing in Rust wouldn’t magically make it faster.
Agreed.
> The point being, it’s not clear yet, and to solve that requires understanding the problem, not effecting a needless rewrite in a new language.
Which is why the first question is why btrfs has issues others do not have. Some mention its CoW architecture, system design, too many features and not limiting storage to 90% and so increasing complexity. Others mention usual kernel issues.
Others mention that they had no issues to begin with and that its mixed reputation is unwarranted. I'm not clear who is right, but they are data points.
Thank you for your input in cautioning of rewrites to avoid needless work, I appreciate it.
I thought the Rust compiler solves issues that you wouldn't immediately see with pure C, which is why I had the idea.
I didn't know this requires certain features which are not available inside the kernel. I only knew all existing interfaces may be unsafe because they are in C though. Rust does not seem as useful then.
Interesting decision they made, I wonder whether they would decide differently now after seeing all the complexity.
So Rust does not decrease the complexity, but only removes certain kinds of errors which the compiler can detect.
Neither logic errors nor speed regressions.
Any rewrite must be carefully evaluated, true. And it may not be advisable. I'm trying to understand the issues.
Are they not solvable because the kernel does not give enough guarantees as it gives to userspace, because the c-interfaces of the kernel have to be wrapped in unsafe or because of other reasons (architecture, data model, kernel constraints, ...)?
Why does btrfs have those issues compared to other filesystems? I'd love to use btrfs too. Note that I deeply respect people who can write such complicated code, which I couldn't.
250 sounds nice, compared to 220 retina ppi for macs. If its only constrained by the display that would be good. I will love buying 3080/5950x as my new workstation. hmm
I only use the desktop mac so that's not much an issue probably, there it is probably 2x scaling. Interesting how Windows can handle anything as long as the hardware supports it!
When SwiftUI came out I learnt it by trying out each question about it. This way it was easy to get an introduction, because all were new to the technology and so were interested in figuring the questions out. And the questions were simple enough because no one had much of a grasp.
With old technology you do not necessarily have enthusiasts who try to "figure it out too" at the moment and so it gets more difficult.