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.
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.
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.
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.
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.
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.
I don't think we disagree? My point is, "just fork it" is a ridiculous response to complaints about a community, and furthermore it's a special case of a broad category of ridiculous responses to complaints about how systems are run. It's just a cheap[0] way to avoid assessing the complaint on its merits, which we do both seem to think is necessary.
[0] Quite possibly a victim-blaming way, though not necessarily, depending first and foremost on the merits of the complaint...
I suspect I was just unclear with my comment[0]. I do mean to say that even if there is merit to the person's complaints, it is a valid response to tell that person to go and do it themselves. I'm not convinced that they'll make something half as good and that's very relevant if they're going to be complaining. I'm less likely to take a person seriously if all they can add to a topic is, "This is bad and someone needs to make it better!" while remaining unwilling or unable to be that "someone". The minimum would be even just a suggestion of what to do instead.
Anyway, I actually think this is rather controversial with valid opposing perspectives, so I don't intend to invalidate yours! This is just where I land.
[0]
> if this individual doesn't like it then I think it's totally appropriate to challenge [said individual] to do it better
Gotcha. A couple rejoinders. First: I think it's important to be able to name a problem, even if it's too hard to propose a solution right away, without people yelling at you to propose a solution or STFU. That just becomes, again, a cheap way to avoid acknowledging hard problems.
Second: that's still a much more reasonable objection than "just fork the community", which usually has costs ranging from obnoxious to crippling. The mere attempt could destroy lots of value for no benefit, and even if it succeeds things are likely to suck for a while for everyone involved. This is not an appropriate option to push just because there's an alleged process problem. Not even if the complainer genuinely should have proposed a solution, offered to do the work, or whatever.
Forking whole communities is allowed, encouraged, and often has positive effects in open source. Does anyone suggest XEmacs (being both a code and community fork) or Wayland (being a community fork) as being wholly bad ideas?
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.
> 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.
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.
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.
> 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?
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.
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.
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?
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).
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.
> 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
Eh, I get it. Understanding anything takes effort, and each one of us has a limited amount of mental energy per day. Nobody likes wasting it for what they feel is responsibility of another. I wouldn't criticize the author for what happened in the kernel discussion - I don't have enough skill or experience to understand why or how is anyone right or wrong.
What I do have a problem with, is posting an article like this on HN, then shutting every comment down with "read these 15000 lines, peasant, before you even dare to speak". Most people on HN are not kernel hackers, so why the (if I may be blunt - pretentious) gatekeeping? There must be some better way of explaining why someone's comment is wrong than "here, read this large text, figure it out yourself and don't come back until you figure it out". That's just lazy and disrespectful.
I agree, from a ringside commentary viewpoint; for general chatter on a forum, that’s too much to demand.
I think that I’d have preferred a detailed analysis of the hundreds of messages for one patch broken up into segments and assigned categories. For example, and this are made up:
15% of messages stemmed from mis-application of Intel/AMD assumptions to Apple Silicon.
Because doing so without naming names, in an opinionated manner, would really help make or break their point. It would also provide ground for the “read all 15,000 lines” viewpoint: either one is arguing that the assessment is improperly conducted, in which case you would need to conduct your own and provide that — or one is arguing that the assessed categorizations are not the correct ones to use, which is a separate useful debate that does not require reading all the messages.
> 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.