12 ms·

To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he ha

• koverstreet 1y ago
  When rules and authority start to take precedence over making sure things work, things have gone off the rails and we're not doing engineering anymore.
  • ranger_danger 1y ago
    I think this attitude is exactly why this happened. I would have done the same thing. Do you argue with your school teachers that your book report shouldn't be due on Friday because it's not perfect yet? I read several of your response threads across different websites. The most interesting to me was LWN, about the debian tools, where an actual psychologist got involved. All the discussions seem to show the same issue: You disagree with policies held by people higher up than you, and you struggle with respecting their decisions and moving on. Instead you keep arguing about things you can't change, and that leads people to getting frustrated and walking away from you. It really doesn't matter how "right" you may be... not your circus, not your monkeys.
    • charcircuit 1y ago
      Your analogy fails to account that after "Friday" bug fixes are still allowed. A file system losing your files sounds like a bug to me. Edit since you expanded your post: >The most interesting to me was LWN, about the debian tools, where an actual psychologist got involved. To me the comment was patronizing implying it was purely due to bad communication from Kent's end and shows how immature people are with running these operating system are. Putting priority on processes over the end user. >respecting their decisions and moving on. When this causes real pain for end users. It's validating that the decision was wrong. > really doesn't matter how "right" you may be... not your circus It does because it causes reputational damage for bcachefs. Even beyond reputational damage, delivering a good product to end users should be a priority. In my opinion projects as big as Debian causing harm to users should be called out instead of ignored. Else it can lead to practices like replacing dependencies out from underneath programs to become standard practice.
      • wavemode 1y ago
        You still seem to be arguing that, shipping the change was the "right" thing to do. But that's not what's in dispute. Rather it is that, if what you think is right and what the person who makes the rules thinks is right are in disagreement, the adult thing to do is not to simply disregard the rules (and certainly not repeatedly, after being warned not to). This is the difference between being smart and being wise. If the goal of all this grandstanding was that, it's so incredibly and vitally important for these patches to get into the kernel, well guess what, now due to all this drama this part of the kernel is going to go unmaintained entirely. Is that good for the users? Did that help our stated goal in any way? No.
        • charcircuit 1y ago
          >the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.
          • nirava 1y ago
            > The adult thing is to do best by the users Best by users in the long term is predictable processes. "RC = pure bug fixes" is a battle tested, dependable rule, absence of which causes chaos. > Critical file system bugs are worth blocking the release "Experimental" label EXACTLY to prevent this stuff from blocking release. Do you not know that bcachefs is experimental? This is an example of another rule which helps predictability.
            • charcircuit 1y ago
              This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for. >"Experimental" label EXACTLY to prevent this stuff from blocking release In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.
    • motorest 1y ago
      > All the discussions seem to show the same issue: You disagree with policies held by people higher up than you, and you struggle with respecting their decisions and moving on. I think it's less subtle than that. The straw that broke the camel's back was quite literally abuse towards other kernel developers. https://lwn.net/Articles/999197/ https://lwn.net/Articles/999197/
      • ranger_danger 1y ago
        I think that abuse falls under "struggling" to respect their decisions, but yes I agree that was a big part of it.
      • koverstreet 1y ago
        You might want to read the full story on that one.
        • motorest 1y ago
          > You might want to read the full story on that one. I read the full story. Everyone else can do the same. Somehow it seems you opt to skip it and prefer to be deeply invested in creating an alternative reality.
  • lokar 1y ago
    There are import differences between small scale (individual or a few people) engineering and larger scale engineering. For many humans to work together over time on something very complex is hard. Structure and process are required. And sometimes they come at the expense of what some might call “pure” engineering. But they are the right trade offs to optimize for the actual goal. If you can’t accept that, stick to solo projects.
  • motorest 1y ago
    > When rules and authority start to take precedence over making sure things work, (...) Didn't Linus lambast you for "lack of testing and collaboration before submitting patches", to the point the patches you were trying to push weren't even building? https://ostechnix.com/linus-torvalds-expresses-frustration-with-bcachefs-development-process/ https://ostechnix.com/linus-torvalds-expresses-frustration-w...
    • koverstreet 1y ago
      Linus has broken the build more recently than I have. (In the time since bcachefs went upstream, we've both done that once, that I've seen). Linus doesn't seem to believe in automated testing. He just seems to think that there's no way I could QA code as quickly as I do, but that's because I've invested heavily in automated testing and building up a community of people doing very good testing and QA work; bcachefs's automated testing is the best of any upstream filesystem that I've seen (there's a whole cluster of machines dedicated to this), and I have people running my latest branch on a daily basis. Nearly all of the collaboration just happens on IRC. For big changes I wait for explicit acks from testers that they've ran it and things look good; a lot of people read and review my code too, it's just typically less formal than the rest of the kernel.
      • righthand 1y ago
        Yeah but you don’t get to make the calls. Linus does and your “well kernel daddy does it too” and “actually I’m doing it better than my critics understand” don’t play well with the kernel daddy (or really any bdfl). Do you not see your comment as dismissive? All your comments are dismissive of the criticisms so far and you’re shrugging your shoulders as to why. It’s great you’re able to reason and defend yourself but Linux as a whole is larger than you and refusing to submit to their ways will make technology move no where.
      • motorest 1y ago
        > Linus has broken the build more recently than I have. Even taking your claims at face value (which from this thread alone is a heck of a leap) I'm baffled by the way you believe this holds any relevance. I mean, the kernel project has in place a quality assurance process designed to minimize the odds of introducing problems when preparing a release. You were caught purposely ignoring any QA process in place and trying to circumvent the whole quality assurance process and sneak into a RC features that were untested and unverified. There is a QA process, and you purposely decided to ignore it and plow away. And then your best argument for purposely ignoring any semblance of QA is that others may or may not have broken a build before? Come on, man. You know better than this. How desperate are you to avoid any accountability to pull these gaslighting stunts?
  • nullc 1y ago
    Collaborative projects don't work on pure engineering. There are significant resource management components that basically amount to therapy, psychiatry, and side show entertainment because the most critical resources are human minds. Excellent engineering management largely isolates engineers from having to deal with this non-engineering stuff (except for the subset that is specifically for their own personal benefit)-- but open source tends to radically flatten organizations that produce software, such that every contributor must also be their own manager to a great degree. In a well run project you don't necessarily have to be good at or even interested in all the more socially oriented components of the project organization. But if you're not you must be willing to let someone else handle that stuff and go along with their judgements even if they seem suboptimal from the narrower perspective you've adopted. If you can't then from a "collaborative development as a system" view you're a faulty component that doesn't provide the right interface for the system's requirements (and are gonna get removed!). :) Another way to look at it is that it would be ideal if every technical element were optimal at all times. In small systems with well understood requirements this can be possible or at least close to possible. But in big complex and poorly scoped systems it's just not possible: We have imperfect information, there are conflicting requirements, we have finite time, and so on. The system as a whole will always be far from perfect. If anyone tried to make it all perfect it would just fail to make progress, deadlock, or otherwise. The management of the project is always trying to balance the imperfections. They know that their decisions are often making things worse for a local concern, but they do so with belief that over time the decisions result in a better system overall. Linux has a good reputation in large part due to a long history of making good decisions about the flaws to accept or even introduce, which issues to gloss over vs debate to death.
    • koverstreet 1y ago
      yes, which is why I've been saying for years the kernel community needs to get better at actual conflict resolution...
• quotemstr 1y ago
  > Being correct comes second to being agreeable in human-human interactions Prioritizing agreeableness above correctness is the reason the space shuttle Challenger blew up. The bcachefs fracas is interesting and important because it's like a stain making some damn germ's organelles visible: it highlights a psychological division in tech and humanity in general between people who prioritize 1) deferring to authority, reading the room, knowing your place and people who prioritize 2) insisting on your concept of excellence, standing up against a crowd, and speaking truth to power. I am disturbed to see the weight position #1 has accumulated over the past decade or two. These people argue that Linus could be arbitrarily wrong and Overstreet arbitrarily right and it still wouldn't matter because being nice is critical to the success of a large scale project or something. They get angry because they feel comfort in understanding their place in a social hierarchy. Attempts to upend that hierarchy in the name of what's right creates cognitive dissonance. The rule-followers feel a tension they can relieve only by ganging up and asserting "rules are rules and you need to follow them!" --- whether or not, at the object level, a) there are rules, b) the rules are beneficial, and c) whether the rules are applied consistently. a, b, and c are exactly those object-level does-the-o-ring-actually-work-when-cold considerations that the rule-following, rule-enforcing kind of person rejects in favor a reality built out of words and feelings, not works and facts. They know it, too. They need Overstreet and other upstarts to fail: the failure legitimizes their own timid acquiescence to rules that make no sense. If other people are able to challenge rules and win, the #1 kind of person would have to ask himself serious and uncomfortable questions about what he's doing with his life. It's easier and psychologically safer to just tear down anyone trying to do something new or different. The thing is all technological progress depends on the #2 people winning in the end. As Feynmann talked about when diagnosing this exact phenomenon as the root cause of the Challenger disaster, mother nature (who appears to have taken on corrupting filesystems as a personal hobby of hers) does not care one bit about these word games or how nice someone is. The only thing that matters when solving a problem of technology is whether something works. I think a lot of people in tech have entirely lost sight of this reality. I can't emphasize enough how absurd it is to state "[b]eing correct comes second to being agreeable in human-human interactions" and how dangerously anti-technology, anti-science, and-civilization, and anti-human this poison mindset is.
  • 1y ago