121–130 of 408 posts
Remember when they changed behavior of memmove, which broke user code including the damn flash player, and then blamed users for that?
E.g., Drepper seems to be the person who is an opposite of Linus.
John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html ) and promised to handle things better in the future so all is well.
out of curiosity, how does a policy like this translate to microkernel OSes (e.g. Redox) where most everything runs in userspace?
https://www.jwz.org/doc/worse-is-better.html (copy-paste the link in a new tab. Do not click on it)
The worse-is-better philosophy is only slightly different:
- Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
- Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
- Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
- Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
I'm always eager to read Linus's rants. I wish more of my coworkers were like him. I hate the environment where nobody reacts strongly to anything! If somebody fucks up hard and refuses to own up, I (or whoever's in charge) should be able to shout at them. It's only natural.
I disagree. To me he usually comes across as an asshole, albeit an extremely smart and accomplished one. A working environment where the person at the top can be relied upon to react to human failings with an aggressive, sweary [1] rant is not somewhere I ever want to work. [1] I'm aware that use of profanity in everyday speech is common in Finland. I don't mind swearing per se, but I find its over-use a bit tedious.
Earlier quoted context omitted.
I think Rust has done this quite well, managing to have the best of both worlds. Unstable features are only available on the nightly build and need specifically enabling (and their interface may change). Once a feature is considered stable it is carefully maintained. They do have some breaking changes, but they're not common and for unusual edge cases: https://killercup.github.io/bitrust/ This explains the Rust appro…
Rust also uses a sizable fraction of all publicly-available Rust code as a regression suite for compiler updates. This allows them to check edge cases that are "breaking in theory" to find out if there's actually any code that would be broken, or if the edge case had literally not yet been encountered.
They literally run all tests against every crate published to the package ecosystem. That is amazing.
John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up ( http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html ) and promised to handle things better in the future so all is well.
Earlier quoted context omitted.
Rich Hickey has a wonderful talk about it. "Spec-ulation" - https://www.youtube.com/watch?v=oyLBGkS5ICk Which I fully agree with, basically there are no major, minor, patch level changes, in reality every change is a possible breaking changes, because we don't control what downstream is doing with our software.
Oh well, he should try a language with types ... /me runs ...
Earlier quoted context omitted.
I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.
How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?
Mercurial, made by another (in my opinion) much more well-spoken kernel hacker, is what really introduced me to the concept that you do not break interface for downstream users, no matter how wrongly you may think they are using the interface. It’s an attitude that is difficult to convey because software developers always want to have the freedom to “improve” their own software, even at the possible cost of breaking…
If only compiler developers had this attitude.