7 ms·

"I'm getting tired of arguing with kernel maintainers."

47 points by Wowfunhappy 4y ago

smoldesu 4y ago
I'm getting tired of hearing people complain about the governance of GPL projects. If you don't want to cut through the red tape of a globally-sponsored, stable product, then don't use it. The code is GPL, nobody will arrest you for forking it. > Like dude, if you aren't going to step into my world and actually understand what I'm trying to do here, just suck it up and ack my patch. That's literally the opposite of what we should be doing for the Linux kernel! If someone doesn't understand what they're merging, they shouldn't +1 it. That's how we end up with garbage NTFS drivers polluting the kernel, or "University of Minnesota" attacks. Protracted discussions about architecture is how Linux has been maintained for the past 3 decades, if you need to move fast and break things Linux is not a good choice.
- deleted 4y ago
  [deleted]
- nells 4y ago
  > The code is GPL, nobody will arrest you for forking it. People will bitch about that too - see what happens to kernels of Android handsets, people will complain that OEMs don’t want to waste time upstreaming drivers.
  - smoldesu 4y ago
    Asahi isn't the OEM, so I don't really see what you're comparing here. Nobody is mad at Asahi for writing drivers from scratch for black-box hardware, it's just that the Linux kernel isn't really the proper place to hack together cutting-edge shims for unsupported hardware. Linux has a larger obligation to stability than it does to novelty, so naturally it makes sense that the line gets drawn somewhere. Unfortunately the Linux kernel isn't maintained by some trillion-dollar company with the impetus to sort out these problems.
    - derefr 4y ago
      > it's just that the Linux kernel isn't really the proper place to hack together cutting-edge shims for unsupported hardware Presuming that the hacks only exist within a particular kernel module, and that that module only gets loaded when the given hardware is found, don't those hacks then only affect people with the (previously, and still mostly) unsupported hardware? Which — at least for hardware in the critical path to userland interactivity — is strictly better than their hardware not working at all?
      - smoldesu 4y ago
        I agree. The problem isn't with how the Linux kernel brings up new devices, and more with the fact that adding support to unsupported hardware is a long and difficult process. These kernel maintainers have more important, official contributions to concern themselves with. Reverse-engineered software support is tangential to the work that the Linux maintainers do, which is why I'm all-for Asahi unshackling themselves from the Linux project. Hell, they might even find sympathizers in the NetBSD/OpenBSD communities, which have always welcomed unsupported systems with open arms.
      - yjftsjthsd-h 4y ago
        If that's the case, perhaps DKMS is the easy solution?
  - chris37879 4y ago
    People bitch about the Android kernel and its lack of upstreaming because we get stuck with perfectly serviceable devices that are dangerous to use because they don't get updates 3 years after we bought them. Forking a project with your only intent being to get something to market is a bad idea, see the current effort Google is having to put into getting Android back to the mainline kernel, and they're still years away from actually succeeding.
- selfmodruntime 4y ago
  I agree entirely. If you try to get a patch to be accepted, be prepared to explain exactly what it does bit by bit to people whose entire job it is to make sure that the kernel quality does not degrade. If you can't, quit.
  - mekster 4y ago
    It's easy to tell people to quit by either giving an option of 0 or 1 but that's quite disrespectful.
    - selfmodruntime 4y ago
      I do not need respect in my linux kernel, I need it to work without failure. The linux kernel is perhaps the most important software project ever. It makes sense to have different rules.
  - tpmoney 4y ago
    Having read through the email exchanges linked elsewhere in this thread, I don't think the issue is with having to explain what changes do. There appears to be 2 main conflicts in the thread. One is a reviewer who appears to not be taking a large picture view of the patches. It appears multiple points of concern for them are addressed, answered or given relevant context either just a few lines up or down, or in a different part of the file. The frustration here appears to be not that things have to be explained, but that little to no effort was put into understanding it at all. This I think was compounded by the fact that the reviewer appeared to reject multiple suggested revisions while not providing any context for what they're actually looking for, and when the reviewer did make a suggestion, their suggestions apparently weren't even valid C code. The second conflict appears to have occurred around a dispute over the logical organization of the changes, and how they would be called and where the code would live. In this case, it appears the Asahi people organized it in a way that made sense based on their understanding of the hardware in question, the current structure of the code, and in a way that other parts were already laid out. A different reviewer objected to this layout, noting that while they had indeed followed the model of some other code, that was wrong and apparently shouldn't have been there in the first place. Again there appears to have been an amount of back and forth that was ultimately a series of rejections on proposed alternates without any real explanation of what they were looking for and why they thought given the hardware design, this layout didn't make sense. This argument included a directive from the reviewer to just do it "proper" without (to my reading) any real guidance to what "proper" would look like given nature of what is being submitted. While I appreciate that reviewers don't necessarily have all the context and will be asking questions, sometimes on stuff that is answered within the file, I would certainly expect them to not return a review that is almost entirely answered by context within the file. I would equally expect that if they are going to suggest I do something a different way, that suggestion should be valid code, or at least pseudo code that can be made valid. I would honestly also expect a review to include some feedback on what the reviewer would like when the disagreements are about logical organization or coding choices that fall outside the documented code style requirements.
- dottedmag 4y ago
  Please read the message thread yourself, and _then_ judge: https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-2259-c2595bd55b97@marcan.st/T/#r65e02d19410f2f1b43ef552e97e1638c4ee4aca8 https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-...
  - smoldesu 4y ago
    What is notable about this thread? Martin is proposing to replace pre-existing (functional) components of the kernel with his own contributions. The maintainers responsible for these components want to understand this implementation before merging it. Spending 2 months discussing a patch like this is not uncommon, particularly if we're talking about shot-in-the-dark implementations of undocumented hardware interfaces.
  - bheadmaster 4y ago
    Please stop spamming. That message thread is 15 thousand lines long - it is quite disrespectful to demand I read the whole thing without even knowing what I'm looking for. Can you at least point out the relevant parts, or - even better - copy them in a comment for all to see?
    - altairprime 4y ago
      This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out. Whether that’s appropriate or not is what ought to be discussed here; everyone takes for granted that someone else should have to “do the reading”, but that assumption doesn't scale for Linux (nor necessarily for forum discussions).
      - smoldesu 4y ago
        It's not the kernel maintainer's job to care about unsupported hardware any more than they need to worry about upstreaming the Linux fork designed to run on iPhones. This is the problem with trying to maintain community-sourced patches for complex hardware architectures; getting Linux to run on Mac is not a priority. It's not a machine designed for Linux, and Apple makes no effort to cooperate with the maintainers of the Linux kernel. If Apple (the company with ~$200,000,000,000 in cash reserves) worked with the community here, there wouldn't be any issues here.
- daxelrod 4y ago
  > The code is GPL, nobody will arrest you for forking it. The author is literally maintaining a fork already https://asahilinux.org/ https://asahilinux.org/ I do take your larger point about rubber-stamping contributions generally not being a good idea.
  - smoldesu 4y ago
    Right, I was more referring to a fork of the community than a downstream development branch.
    - andrewflnr 4y ago
      Ah, of course, the "just fork a whole community" tactic, no big deal. I mean, really, why would you bother trying to change anything as long as the hypothetical possibility exists of going elsewhere? Is there a single thing you don't like about your current circumstances? Just leave! That will definitely be better for everyone, and there definitely won't be any crippling ongoing costs that result.
      - smoldesu 4y ago
        The kernel developers and Asahi developers ultimately have the same goals, they just develop in different ways with different priorities. The kernel has always moved at a snails-pace, even for longtime contributors. Dealing with the quirks of unsupported hardware isn't their job, it's completely unsurprising that these maintainers don't take M1 support seriously in the same way they treat Intel or AMD-submitted patches. If Apple wanted the Macbook to have quick Linux support, they should have merged the patches themselves. When you leave the community to do a corporation's job, things don't exactly move at a fast clip.
      - lcnPylGDnU4H9OF 4y ago
        But actually, yes. His complaints are seemingly all about how the community is run. > It should not take email chains that don't even fit on my screen to upstream a 1700-line patchset that implements 3 kernel modules. > Between this and drive-by reviewers that make nitpick comments (most of which are wrong), no wonder stuff takes forever to upstream. > It is very frustrating to have to defend it over hours/days/weeks/months ... Regardless of the merit of these things, if this individual doesn't like it then I think it's totally appropriate to challenge them to do it better. Failing that, I'll risk erring on the thought that there are difficulties with running OSS communities that this person is downplaying.
anikom15 4y ago
Sorry, but part of being a good engineer is being able to explain why your work is critical (or isn’t, be honest) and how it works in as reasonably simple terms as possible. I’ve learned to ‘ask first, write later’ when it comes to open source as well, unless I’m willing to fork or just keep the changes for myself. There’s no guarantee all contributions are welcome, so don’t sink the cost until you can be reasonably sure your code will get used.
- throwawayffffas 4y ago
  He seems to misunderstand the dynamic here, he thinks he is doing them a favor writing whatever driver he is. He does not seem to understand that the favor is the maintainers accepting to merge his code.
  - deleted 4y ago
    [deleted]
  - phendrenad2 4y ago
    I think that "Linux on Apple silicon" is such a applauded thing right now, and so many people follow him, that he feels like he's actually doing important work. But in reality, the kernel maintainers are probably much more concerned with patches coming from mainframe and server vendors. That's just the reality of who pays the bills.
- dottedmag 4y ago
throwawayffffas 4y ago
> because the other side doesn't bother to actually stop and think about the problem we're trying to solve and why. The dude is describing his self here, he apparently doesn't bother to actually stop and think about the problem the kernel maintainers are trying to solve. He only wants his drivers to work and the world be damned. He doesn't stop to think that they are going to have to maintain that code practically forever after he gets bored and moves on to something else.
- dottedmag 4y ago
schainks 4y ago
> Like dude, if you aren't going to step into my world and actually understand what I'm trying to do here, just suck it up and ack my patch. > It is not my job to drag you kicking and screaming until you either give up or have a lightbulb moment. Soooo, you're saying if I submit a 1700 line change to _your_ codebase, step into your world and "actually understand" what you're trying to do, you'll just magically _approve_ my commits, no questions asked? Sounds pretty irresponsible. Yes, you do have to drag people kicking and screaming into your better world. They think their world is pretty neat already! Proving yours is better actually takes patience and work.
- dottedmag 4y ago
- googlryas 4y ago
  I can only guess the author isn't thinking systematically about this issue. They know their own motivations, their own coding skills, their own reasons for doing everything, and they know they are submitting well intentioned, beautiful, useful code. But how do the maintainers know that? They have to review and accept patches from hundreds or thousands of people. Maybe everything would be perfectly fine if they just blindly ack'd the patch from this particular author. But that is certainly not what they should just generally do.
bravetraveler 4y ago
I'm sure you wear on them, as well. 'endless arguments about overall architecture' That's the kernel, for you. Your modules don't exist alone
- dottedmag 4y ago
  The usual cycle is: two kernel maintainers have an endless argument about overall architecture, and one or another of them blocks any submission, so nothing could be done until this endless argument is resolved by them.
  - bravetraveler 4y ago
    The only thing I can say circumstances like this is, either try to help push it along, let them do their thing, or simply leave it. I understand the frustration, but complaining is only the first part. It's important to move on -- either to the desired outcome, an upstreaming, or elsewhere I'm nowhere near talented enough to participate in this kind of work, I've only observed things that were interesting enough to come by. One thing I've learned is that particular subsystems/areas are better than others. It's unfortunate, but sometimes it comes with the complexity -- eg: VFS and anything storage A lot of it's surely academic, but I think they somewhat reasonably lean towards what's known/trusted and try to get it right before disrupting things
thethirdone 4y ago
I am a little confused by his expectations. He describes it as a "what should've been a 30 minute fix patch" and "a 1700-line patchset that implements 3 kernel modules". If he is expecting his code to be reviewed at the speed of 1 line / second, that just seems really fast for kernel C. Alternatively, if he is expecting the maintainers to not understand the details of the modules, that is something I would be uncomfortable with as a maintainer. I would want to make sure that new code meets my standards and that I understand why any complexity in the code exists. If he is expecting his involvement in the review to only take 30 minutes that's more reasonable, but for mainlining stuff from Asahi, it seems like having upstream understand what is special about M1 is probably worth your time to explain / convince.
- dottedmag 4y ago
- derefr 4y ago
  I think "should have been" implies here that it wasn't a 30-minute-fix patch — with possible insult intended toward a highly-coupled part of the kernel architecture that made the fix require touch-points than it should have.
dale_glass 4y ago
The main power of a maintainer is to reject code. Once it's merged, it becomes the maintainer's problem. So if they don't understand what's it's supposed to accomplish, or how exactly it works, a good maintainer should reject the code. Merging stuff blindly is just asking for trouble. Sometimes yes, it happens that somebody sends you code that does something you're not familiar with, like interacting with weird hardware you've never seen before. It's still the right thing to do to ask lots of questions about it, so that if that part of the code runs into a problem later you have some sort of idea of what to do about it.
- dottedmag 4y ago
StillBored 4y ago
He is lucky he isn't trying to put ACPI on that machine, because they would have outright rejected 3/4ths of what he is doing. They have already taken a pile of submissions to do things that they swore Linux would never support on arm hardware.
sweden 4y ago
His Twitter thread with a user called Peter Geist is quite an interesting read: https://twitter.com/marcan42/status/1587122439561318400 https://twitter.com/marcan42/status/1587122439561318400 It reveals that there are things that marcan is glossing over and forcefully pushing for his way of doing things. No wonder why the conversation with the maintainer is not going forward. It's also not pretty how marcan is just making fun of the kernel maintainer in other tweets: https://twitter.com/marcan42/status/1587023643380682759 https://twitter.com/marcan42/status/1587023643380682759 He is talking as if these are private conversations and forgetting that this is completely public. I admire his efforts in bringing up Linux on Apple Silicon platforms but this attitude of making a tantrum on Twitter is just sad and not very professional. And I bet a lot of junior developers use him as a role model, which is even sadder as this kind of attitude and snarkiness just keeps propagating.
- Fatnino 4y ago
  He's always been a little like this. Fits the hot blooded Spaniards steriotype quite well. He'll get pissed off about something, fly off the handle and then calm down eventually. In the meantime he may churn out some very cool stuff because he actually is very technically talented.
  - sweden 4y ago
    I wouldn't call it the "hot blooded Spaniards stereotype", it's more like the general snarkiness and arrogance that emanates from this type of social networks. If you feel the need to escalate your view to Twitter and turn it into a one-sided view, then maybe there is a chance you are missing something out.
    - Fatnino 4y ago
      He would get like this on irc and his own blog too
- jbirer 4y ago
  [flagged]
im3w1l 4y ago
My understanding is that he is a very talented and valuable programmer and contributor, and it's a loss for everyone if he has to waste hours and days on arguing. I'm not saying I have the solution or anything, just saying I do think he has a point.
phendrenad2 4y ago
Ah, another feather in my cap. I keep saying that Linux's "drivers-included" model won't scale long-term. I'm just going to sit back and sip some iced tea, soon you all will come around to my way of thinking, and Linus (or someone) will announce an amazing new initiative to move drivers out of the kernel tree.
- phendrenad2 4y ago
  How do I delete comments?
  - Wowfunhappy 4y ago
    You can only delete a comment within two hours of posting it (and only then if nobody has replied). If you want something to be deleted after that window, you can try emailing hn@ycombinator.com.
- deleted 4y ago
  [deleted]

47 points by Wowfunhappy 4y ago

I'm getting tired of hearing people complain about the governance of GPL projects. If you don't want to cut through the red tape of a globally-sponsored, stable product, then don't use it. The code is GPL, nobody will arrest you for forking it. > Like dude, if you aren't going to step into my world and actually understand what I'm trying to do here, just suck it up and ack my patch. That's literally the opposite of what we should be doing for the Linux kernel! If someone doesn't understand what they're merging, they shouldn't +1 it. That's how we end up with garbage NTFS drivers polluting the kernel, or "University of Minnesota" attacks. Protracted discussions about architecture is how Linux has been maintained for the past 3 decades, if you need to move fast and break things Linux is not a good choice.

deleted 4y ago
[deleted]
nells 4y ago
> The code is GPL, nobody will arrest you for forking it. People will bitch about that too - see what happens to kernels of Android handsets, people will complain that OEMs don’t want to waste time upstreaming drivers.
- smoldesu 4y ago
  Asahi isn't the OEM, so I don't really see what you're comparing here. Nobody is mad at Asahi for writing drivers from scratch for black-box hardware, it's just that the Linux kernel isn't really the proper place to hack together cutting-edge shims for unsupported hardware. Linux has a larger obligation to stability than it does to novelty, so naturally it makes sense that the line gets drawn somewhere. Unfortunately the Linux kernel isn't maintained by some trillion-dollar company with the impetus to sort out these problems.
  - derefr 4y ago
    > it's just that the Linux kernel isn't really the proper place to hack together cutting-edge shims for unsupported hardware Presuming that the hacks only exist within a particular kernel module, and that that module only gets loaded when the given hardware is found, don't those hacks then only affect people with the (previously, and still mostly) unsupported hardware? Which — at least for hardware in the critical path to userland interactivity — is strictly better than their hardware not working at all?
    - smoldesu 4y ago
      I agree. The problem isn't with how the Linux kernel brings up new devices, and more with the fact that adding support to unsupported hardware is a long and difficult process. These kernel maintainers have more important, official contributions to concern themselves with. Reverse-engineered software support is tangential to the work that the Linux maintainers do, which is why I'm all-for Asahi unshackling themselves from the Linux project. Hell, they might even find sympathizers in the NetBSD/OpenBSD communities, which have always welcomed unsupported systems with open arms.
    - yjftsjthsd-h 4y ago
      If that's the case, perhaps DKMS is the easy solution?
- chris37879 4y ago
  People bitch about the Android kernel and its lack of upstreaming because we get stuck with perfectly serviceable devices that are dangerous to use because they don't get updates 3 years after we bought them. Forking a project with your only intent being to get something to market is a bad idea, see the current effort Google is having to put into getting Android back to the mainline kernel, and they're still years away from actually succeeding.
selfmodruntime 4y ago
I agree entirely. If you try to get a patch to be accepted, be prepared to explain exactly what it does bit by bit to people whose entire job it is to make sure that the kernel quality does not degrade. If you can't, quit.
- mekster 4y ago
  It's easy to tell people to quit by either giving an option of 0 or 1 but that's quite disrespectful.
  - selfmodruntime 4y ago
    I do not need respect in my linux kernel, I need it to work without failure. The linux kernel is perhaps the most important software project ever. It makes sense to have different rules.
- tpmoney 4y ago
  Having read through the email exchanges linked elsewhere in this thread, I don't think the issue is with having to explain what changes do. There appears to be 2 main conflicts in the thread. One is a reviewer who appears to not be taking a large picture view of the patches. It appears multiple points of concern for them are addressed, answered or given relevant context either just a few lines up or down, or in a different part of the file. The frustration here appears to be not that things have to be explained, but that little to no effort was put into understanding it at all. This I think was compounded by the fact that the reviewer appeared to reject multiple suggested revisions while not providing any context for what they're actually looking for, and when the reviewer did make a suggestion, their suggestions apparently weren't even valid C code. The second conflict appears to have occurred around a dispute over the logical organization of the changes, and how they would be called and where the code would live. In this case, it appears the Asahi people organized it in a way that made sense based on their understanding of the hardware in question, the current structure of the code, and in a way that other parts were already laid out. A different reviewer objected to this layout, noting that while they had indeed followed the model of some other code, that was wrong and apparently shouldn't have been there in the first place. Again there appears to have been an amount of back and forth that was ultimately a series of rejections on proposed alternates without any real explanation of what they were looking for and why they thought given the hardware design, this layout didn't make sense. This argument included a directive from the reviewer to just do it "proper" without (to my reading) any real guidance to what "proper" would look like given nature of what is being submitted. While I appreciate that reviewers don't necessarily have all the context and will be asking questions, sometimes on stuff that is answered within the file, I would certainly expect them to not return a review that is almost entirely answered by context within the file. I would equally expect that if they are going to suggest I do something a different way, that suggestion should be valid code, or at least pseudo code that can be made valid. I would honestly also expect a review to include some feedback on what the reviewer would like when the disagreements are about logical organization or coding choices that fall outside the documented code style requirements.
dottedmag 4y ago
Please read the message thread yourself, and _then_ judge: https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-2259-c2595bd55b97@marcan.st/T/#r65e02d19410f2f1b43ef552e97e1638c4ee4aca8 https://lore.kernel.org/linux-arm-kernel/4faa5e4c-b43b-12e4-...
- smoldesu 4y ago
  What is notable about this thread? Martin is proposing to replace pre-existing (functional) components of the kernel with his own contributions. The maintainers responsible for these components want to understand this implementation before merging it. Spending 2 months discussing a patch like this is not uncommon, particularly if we're talking about shot-in-the-dark implementations of undocumented hardware interfaces.
- bheadmaster 4y ago
  Please stop spamming. That message thread is 15 thousand lines long - it is quite disrespectful to demand I read the whole thing without even knowing what I'm looking for. Can you at least point out the relevant parts, or - even better - copy them in a comment for all to see?
  - altairprime 4y ago
    This is, ironically enough, a microcosm of the post author’s complaint: people are replying to their patches without having done the due diligence of gaining context in their own first, and are offloading that burden of gaining context onto the patch author instead — which is slowly burning them out. Whether that’s appropriate or not is what ought to be discussed here; everyone takes for granted that someone else should have to “do the reading”, but that assumption doesn't scale for Linux (nor necessarily for forum discussions).
    - smoldesu 4y ago
      It's not the kernel maintainer's job to care about unsupported hardware any more than they need to worry about upstreaming the Linux fork designed to run on iPhones. This is the problem with trying to maintain community-sourced patches for complex hardware architectures; getting Linux to run on Mac is not a priority. It's not a machine designed for Linux, and Apple makes no effort to cooperate with the maintainers of the Linux kernel. If Apple (the company with ~$200,000,000,000 in cash reserves) worked with the community here, there wouldn't be any issues here.
daxelrod 4y ago
> The code is GPL, nobody will arrest you for forking it. The author is literally maintaining a fork already https://asahilinux.org/ https://asahilinux.org/ I do take your larger point about rubber-stamping contributions generally not being a good idea.
- smoldesu 4y ago
  Right, I was more referring to a fork of the community than a downstream development branch.
  - andrewflnr 4y ago
    Ah, of course, the "just fork a whole community" tactic, no big deal. I mean, really, why would you bother trying to change anything as long as the hypothetical possibility exists of going elsewhere? Is there a single thing you don't like about your current circumstances? Just leave! That will definitely be better for everyone, and there definitely won't be any crippling ongoing costs that result.
    - smoldesu 4y ago
      The kernel developers and Asahi developers ultimately have the same goals, they just develop in different ways with different priorities. The kernel has always moved at a snails-pace, even for longtime contributors. Dealing with the quirks of unsupported hardware isn't their job, it's completely unsurprising that these maintainers don't take M1 support seriously in the same way they treat Intel or AMD-submitted patches. If Apple wanted the Macbook to have quick Linux support, they should have merged the patches themselves. When you leave the community to do a corporation's job, things don't exactly move at a fast clip.
    - lcnPylGDnU4H9OF 4y ago
      But actually, yes. His complaints are seemingly all about how the community is run. > It should not take email chains that don't even fit on my screen to upstream a 1700-line patchset that implements 3 kernel modules. > Between this and drive-by reviewers that make nitpick comments (most of which are wrong), no wonder stuff takes forever to upstream. > It is very frustrating to have to defend it over hours/days/weeks/months ... Regardless of the merit of these things, if this individual doesn't like it then I think it's totally appropriate to challenge them to do it better. Failing that, I'll risk erring on the thought that there are difficulties with running OSS communities that this person is downplaying.

anikom15 4y ago

Sorry, but part of being a good engineer is being able to explain why your work is critical (or isn’t, be honest) and how it works in as reasonably simple terms as possible. I’ve learned to ‘ask first, write later’ when it comes to open source as well, unless I’m willing to fork or just keep the changes for myself. There’s no guarantee all contributions are welcome, so don’t sink the cost until you can be reasonably sure your code will get used.

throwawayffffas 4y ago
He seems to misunderstand the dynamic here, he thinks he is doing them a favor writing whatever driver he is. He does not seem to understand that the favor is the maintainers accepting to merge his code.
- deleted 4y ago
  [deleted]
- phendrenad2 4y ago
  I think that "Linux on Apple silicon" is such a applauded thing right now, and so many people follow him, that he feels like he's actually doing important work. But in reality, the kernel maintainers are probably much more concerned with patches coming from mainframe and server vendors. That's just the reality of who pays the bills.
dottedmag 4y ago

throwawayffffas 4y ago

> because the other side doesn't bother to actually stop and think about the problem we're trying to solve and why. The dude is describing his self here, he apparently doesn't bother to actually stop and think about the problem the kernel maintainers are trying to solve. He only wants his drivers to work and the world be damned. He doesn't stop to think that they are going to have to maintain that code practically forever after he gets bored and moves on to something else.

dottedmag 4y ago

schainks 4y ago

> Like dude, if you aren't going to step into my world and actually understand what I'm trying to do here, just suck it up and ack my patch. > It is not my job to drag you kicking and screaming until you either give up or have a lightbulb moment. Soooo, you're saying if I submit a 1700 line change to _your_ codebase, step into your world and "actually understand" what you're trying to do, you'll just magically _approve_ my commits, no questions asked? Sounds pretty irresponsible. Yes, you do have to drag people kicking and screaming into your better world. They think their world is pretty neat already! Proving yours is better actually takes patience and work.

dottedmag 4y ago
googlryas 4y ago
I can only guess the author isn't thinking systematically about this issue. They know their own motivations, their own coding skills, their own reasons for doing everything, and they know they are submitting well intentioned, beautiful, useful code. But how do the maintainers know that? They have to review and accept patches from hundreds or thousands of people. Maybe everything would be perfectly fine if they just blindly ack'd the patch from this particular author. But that is certainly not what they should just generally do.

bravetraveler 4y ago

I'm sure you wear on them, as well. 'endless arguments about overall architecture' That's the kernel, for you. Your modules don't exist alone

dottedmag 4y ago
The usual cycle is: two kernel maintainers have an endless argument about overall architecture, and one or another of them blocks any submission, so nothing could be done until this endless argument is resolved by them.
- bravetraveler 4y ago
  The only thing I can say circumstances like this is, either try to help push it along, let them do their thing, or simply leave it. I understand the frustration, but complaining is only the first part. It's important to move on -- either to the desired outcome, an upstreaming, or elsewhere I'm nowhere near talented enough to participate in this kind of work, I've only observed things that were interesting enough to come by. One thing I've learned is that particular subsystems/areas are better than others. It's unfortunate, but sometimes it comes with the complexity -- eg: VFS and anything storage A lot of it's surely academic, but I think they somewhat reasonably lean towards what's known/trusted and try to get it right before disrupting things

thethirdone 4y ago

I am a little confused by his expectations. He describes it as a "what should've been a 30 minute fix patch" and "a 1700-line patchset that implements 3 kernel modules". If he is expecting his code to be reviewed at the speed of 1 line / second, that just seems really fast for kernel C. Alternatively, if he is expecting the maintainers to not understand the details of the modules, that is something I would be uncomfortable with as a maintainer. I would want to make sure that new code meets my standards and that I understand why any complexity in the code exists. If he is expecting his involvement in the review to only take 30 minutes that's more reasonable, but for mainlining stuff from Asahi, it seems like having upstream understand what is special about M1 is probably worth your time to explain / convince.

dottedmag 4y ago
derefr 4y ago
I think "should have been" implies here that it wasn't a 30-minute-fix patch — with possible insult intended toward a highly-coupled part of the kernel architecture that made the fix require touch-points than it should have.

dale_glass 4y ago

The main power of a maintainer is to reject code. Once it's merged, it becomes the maintainer's problem. So if they don't understand what's it's supposed to accomplish, or how exactly it works, a good maintainer should reject the code. Merging stuff blindly is just asking for trouble. Sometimes yes, it happens that somebody sends you code that does something you're not familiar with, like interacting with weird hardware you've never seen before. It's still the right thing to do to ask lots of questions about it, so that if that part of the code runs into a problem later you have some sort of idea of what to do about it.

dottedmag 4y ago

StillBored 4y ago

He is lucky he isn't trying to put ACPI on that machine, because they would have outright rejected 3/4ths of what he is doing. They have already taken a pile of submissions to do things that they swore Linux would never support on arm hardware.

sweden 4y ago

His Twitter thread with a user called Peter Geist is quite an interesting read: https://twitter.com/marcan42/status/1587122439561318400 https://twitter.com/marcan42/status/1587122439561318400 It reveals that there are things that marcan is glossing over and forcefully pushing for his way of doing things. No wonder why the conversation with the maintainer is not going forward. It's also not pretty how marcan is just making fun of the kernel maintainer in other tweets: https://twitter.com/marcan42/status/1587023643380682759 https://twitter.com/marcan42/status/1587023643380682759 He is talking as if these are private conversations and forgetting that this is completely public. I admire his efforts in bringing up Linux on Apple Silicon platforms but this attitude of making a tantrum on Twitter is just sad and not very professional. And I bet a lot of junior developers use him as a role model, which is even sadder as this kind of attitude and snarkiness just keeps propagating.

Fatnino 4y ago
He's always been a little like this. Fits the hot blooded Spaniards steriotype quite well. He'll get pissed off about something, fly off the handle and then calm down eventually. In the meantime he may churn out some very cool stuff because he actually is very technically talented.
- sweden 4y ago
  I wouldn't call it the "hot blooded Spaniards stereotype", it's more like the general snarkiness and arrogance that emanates from this type of social networks. If you feel the need to escalate your view to Twitter and turn it into a one-sided view, then maybe there is a chance you are missing something out.
  - Fatnino 4y ago
    He would get like this on irc and his own blog too
jbirer 4y ago
[flagged]

im3w1l 4y ago

My understanding is that he is a very talented and valuable programmer and contributor, and it's a loss for everyone if he has to waste hours and days on arguing. I'm not saying I have the solution or anything, just saying I do think he has a point.

phendrenad2 4y ago

Ah, another feather in my cap. I keep saying that Linux's "drivers-included" model won't scale long-term. I'm just going to sit back and sip some iced tea, soon you all will come around to my way of thinking, and Linus (or someone) will announce an amazing new initiative to move drivers out of the kernel tree.

phendrenad2 4y ago
How do I delete comments?
- Wowfunhappy 4y ago
  You can only delete a comment within two hours of posting it (and only then if nobody has replied). If you want something to be deleted after that window, you can try emailing hn@ycombinator.com.
deleted 4y ago
[deleted]