10 ms·

Marcan certainly can be abrasive (I mean lol, so can Linus), but all the things he points out in the message below are 100% valid - I highly recommend for anyon

• nubinetwork 2y ago
  While I never submitted a patch personally, I had once conferred with some of the input devs to add a trackpad to the synaptics driver... they were queueing up an update to add other trackpads, and they said they would add mine... 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added... On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week. At the end of the day, people are weird sometimes. I wish all the best for marcan.
  • naasking 2y ago
    > 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added. I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.
    • harvey9 2y ago
      this seems very inefficient and the opposite of what I assumed. repeated requests take up time on both sides and are not a very good measure of how important something is.
      • dncornholio 2y ago
        it's not perfect but it works.
        • neoromantique 2y ago
          well, apparently it doesn't.
          • naasking 2y ago
            Well, apparently nobody even noticed for 5 years, so that's 5 years that nobody had to even think about that code.
            • amatecha 2y ago
              Nah, people noticed, and then they thought "Linux always has these kind of issues, I'm going back to [whatever other OS]" because 99.9% of users will never even TRY to report a bug.
            • samus 2y ago
              People just think "that's Linux, it's buggy and we have to live with it"
      • nicce 2y ago
        This is how the most of the open-source development works. There are many projects with thousands of issues and PRs. Those that will get most attention, typically gets prioritized.
        • stusmall 2y ago
          This is even how closed source development works. If you throw issues in a backlog and never follow up to advocate for it then it will never get done.
    • mid-kid 2y ago
      why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?
      • naasking 2y ago
        Requiring people to advocate for their changes is not ill-intent. It handles all cases such as forgetting/missing a patch, and disagreement whether something is needed. The point is there's no system in place to track which patches "should ideally be included but weren't for some reason", it's up for the people who need them to push for them.
    • adastra22 2y ago
      Quite the opposite. If you “pester” for something, they’ll explicitly reject it.
      • naasking 2y ago
        I didn't say pester, I said advocate for it.
        • adastra22 2y ago
          It's the same thing.
  • ogoffart 2y ago
    I tried once to contribute a fix to be able to use the track-pad on my laptop many years ago. But it was not accepted as the maintainer claimed it was an problem in userspace that did not process out of order events correctly. Despite none of the other drivers sent the events out of order. I had no intention to fix the problem on X11 (the only userspace for this at the time), so I used the patched kernel driver locally until I stopped using that laptop. https://bugzilla.kernel.org/show_bug.cgi?id=43591 https://bugzilla.kernel.org/show_bug.cgi?id=43591 https://lore.kernel.org/all/1340829375-4995-1-git-send-email-ogoffart@woboq.com/ https://lore.kernel.org/all/1340829375-4995-1-git-send-email...
  • arp242 2y ago
    People forget things etc. Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"
    • samus 2y ago
      Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.
      • BlueTemplar 2y ago
        But Github, being a platform, is a nonstarter. Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?
        • samus 2y ago
          They "just" need to settle on a platform. GitLab sounds good and is used by a lot of important Open Source projects.
          • BlueTemplar 2y ago
            Did you miss the part where being a platform was most of the issue ? I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...
      • arp242 2y ago
        > exactly the sort of problem that doesn't happen with a Github issue/PR What? PRs or issues being forgotten happens all the time, especially for large projects.
        • samus 2y ago
          It would still be easier to track the progress (or lack thereof) with a proper ticketing system.
  • bsimpson 2y ago
    FWIW, I have submitted a couple small patches to get the display and gamepad for my Lenovo Legion Go recognized correctly - probably similar levels of complexity to your change. One was to input and one was to display quirks. They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.
    • Ecco 2y ago
      Thanks!
• nialv7 2y ago
  Looks like @marcan deleted his existence on mastodon? Does anyone have a copy of what he said on there?
  • hexmiles 2y ago
    You can use the waybackmachine: https://web.archive.org/web/20250204162031/https://social.treehouse.systems/@marcan/113941358237899362 https://web.archive.org/web/20250204162031/https://social.tr... However it seem that you need to disable js as soon as the content load or it will be overwritten by a 404
  • ndiddy 2y ago
    The tweet he got called out for on the thread was "Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. Every experienced kernel submitter has this in their head, maybe it should be finally written down."
    • dralley 2y ago
      The person who called him out for that made some testy social media comments of her own this morning. Personally, seeing > Being toxic on the right side of an argument is still toxic, [...] written unironically, on social media, immediately after that person wrote @marcan > and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
      • ImPostingOnHN 2y ago
        > Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes. This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic. Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.
• busterarm 2y ago
  Up until the point that he tried to leverage social media to get his way in a kernel maintainer dispute? That's just fundamentally not acceptable. Linus was right to reprimand him for the suggestion.
  • seba_dos1 2y ago
    I don't think there's "the point" when it was pretty much modus operandi for years.
    • busterarm 2y ago
      I agree with you, I'm just not personally familiar with their behavior and was trying to be as charitable as possible.
• tptacek 2y ago
  It's not Wikipedia, right? Getting the maximum number of contributors isn't a stated goal? I'm a C programmer with a fair bit of kernel experience, and they don't want me, I'm pretty sure, and I'm completely fine with that.
  • Hamuko 2y ago
    Wikipedia has plenty of gatekeeping too. I once had to submit a single edit three times before the moderators safeguarding the article begrudgingly accepted it.
    • tptacek 2y ago
      They do, but they have a stated goal of maximizing contribution. Linux does not, right? I'm asking.
      • trashface 2y ago
        "Maximum number", perhaps not, but Greg KH did at one point want new contributors: https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/cmhy9l3/ https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah... Q: What would make you even more happy with Linux? GregKH: If you contribute to it.
        • DrillShopper 2y ago
          The kernel dev process is more pathological than what I deal with at $DAYJOB. Why the hell would I wish that upon myself?
          • dfedbeef 2y ago
            A stable career where you can move to any of the companies who have a dependency on your subsystem.
            • 2y ago
• arghwhat 2y ago
  Having contributed a few times, I'd rate it as similar (sometimes much easier!) than contributing to Firefox and Chromium. That is to say that it is indeed extremely time-consuming and frustrating, but when compared to projects of the same scale it does not necessarily come out as more time-consuming or more frustrating - this will never be a small team collaborating on a random Github repo. A simple "swap out X workflow for Y" does not fix these annoyances, and false dichotomies and peer pressure towards is not a way to cooperate. I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.
  • roca 2y ago
    It's way more painful to contribute to the kernel than contribute to Firefox, at least, unless things have changed since I was involved with Firefox. Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you. In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
    • arghwhat 2y ago
      In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI. In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.
      • roca 2y ago
        "The email patch usually gets dealt with within a week or two" is absolutely not my experience dealing with the kernel. Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".
• cataphract 2y ago
  I'm tired of anaphoras. And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
  • Ygg2 2y ago
    Even if you put that aside, the problem is you offer Hellwig two solutions and he NACKs them both. H: I don't want to support multilanguage codebase R: We'll have a maintainer verify R4L is behaving properly. H: I solved issues because they were unified. R: Rust will be mirror of whatever C is, and you're free to break it, R4L will maintain it. H: No.
    • DSMan195276 2y ago
      I'll bite and play devils advocate here - both of those are not a solution to his problem. Ultimately he's the maintainer and he gets the emails if X driver is broken, so because of that he doesn't want to rely on another group to maintain the 'Rust half' of his part of the code. It's also a system that works until it doesn't, the biggest rule of the kernel is no breaking userspace - at some point in the future it won't matter if it's his C changes breaking the Rust drivers, it's still his changes that have to be rolled back if the Rust code isn't updated. And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
      • dralley 2y ago
        That is not a problem. Christoph does not have the right to gatekeep who can use DMA. If he tried to veto an Nvidia graphics driver from using DMA using the excuse that "it might create more work for me", everyone would rightfully tell him to f-off, because that's not his call.
• russdill 2y ago
  I've contributed here and there over there years, even got something merged that broke Linus's printer driver. It really isn't unapproachable, frustrating, or demoralizing.
  • bombcar 2y ago
    You broke Linus’ printer driver and you’re still alive to post? WOW! ;)
• zamadatix 2y ago
  I agree contributing code to the kernel is by no means as approachable or easy going but it's not self-evident that alone is supposed to be the sign of bad things™ unlike more specific examples boiling up to be part of that picture. Are there things and ways I think it could be improved? For sure! I just don't necessarily think they imply the resulting process would be quick and painless.
• zaptheimpaler 2y ago
  Besides the current drama, I'm glad someone of his stature agrees with and can call out the horrible processes and tooling involved in the kernel. Using email and a pile of hacks to mess around with patches just sounds nuts and makes it so much harder to understand or contribute. I don't think decentralized necessitates such a terrible workflow - you can run a local website with a distributed DB, distributed git forges exist, you can use federated chats instead of email, there has to be a better way than email.
  • finnthehuman 2y ago
    I always thought it was a pretty blatant "vibe check" to filter out people who are so uncomfortable with software that they can't customize their environment to create an email workflow that works for them.
    • perching_aix 2y ago
      Can't or won't? Surely what you just read would make you reconsider?
      • finnthehuman 2y ago
        shrug maybe "won't" is a false positive, maybe a true positive, I dunno man, not my vibe check.
    • sangnoir 2y ago
      That sounds about right - the medium is the message. If you can't stand the clunky-but-working, decades-old, patch process, you probably won't stand the clunky-but-working decades-old code. I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy
    • thayne 2y ago
      I've contributed to a couple of projects that use email based workflows. I can customize my environment, but it takes a lot of time, and I would rather do something else than figure out how to filter the firehose of a mailing list to the few emails I actually care about, or learn how to use a new email client that is slightly better and handling patches. The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.
• alberth 2y ago
  And Linus’ immediate reply https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU... (not taking either side, just interesting to read the reply)
  • _fzslm 2y ago
    Definitely interesting to read both sides. I think they both present compelling arguments. There's a need to ensure stability with the kernel and avoid interference with outside forces. I suppose balancing that principle with eventual change is an inevitable difficulty.
  • lonjil 2y ago
    I find this reply interesting. Linus says that what matters is technical stuff, but even before the social media brigading, the whole thread was nothing but non-technical drama. So why is Linus focused only on that and not Hellwig's behavior?
    • pelagicAustral 2y ago
      You have to be pretty clueless not to understand that Martin's is wrong here, he, and the rest of Rust bozos he clicks with should have been kicked out of the Kernel the minute they started with their social media drama... of course, drama and rust are just bound to be hand in hand.
  • roca 2y ago
    This part of the reply exemplifies one of the big problems in the kernel community: > You think you know better. But the current process works. Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar? If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall. And honestly, with maintainers like Hellwig maybe that's what needs to happen.
• ratorx 2y ago
  Having read through the email thread, I think both vocal people are basically in the wrong here. There is a way to constructively disagree and the DMA maintainer did not do that. The Rust maintainer should not have brigaded using social media. The “in hindsight” version of how this should have gone without ego: * Patch adds Rust bindings to C API * Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure. * Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot). * Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up. * These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case). All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised). If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
  • hajile 2y ago
    Both were wrong, but only one was corrected. > If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes). While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.
    • ratorx 2y ago
      You’re right - add insufficient leadership to the list as well. IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it). The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.
• mhh__ 2y ago
  > Marcan certainly can be abrasive (I mean lol, so can Linus) My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him
• renewiltord 2y ago
  Haha it’s funny that this stuff is still going on. The difficulty of getting things into mainline is why Con Kolivas stopped developing his interactivity-prioritizing schedulers for Linux some 20 years ago. It’s just how the project works.