The first version which boots on RISC-V hardware (and QEMU) out of the box. Previous versions needed out of tree patches[1] for essential IRQ and device driver support. Excellent work by many people getting these upstream.
I'm afraid to say there's a small correction after I went to the RISC-V BoF tonight[1]. This kernel only boots on QEMU (which I had tested), but still requires a small number of driver patches to boot on the HiFive Unleashed board - I did not get around to testing this because our boards are all consumed building Fedora and it's not very convenient to reboot them. They are expecting these extra drivers will be upstream in 4.20.
> Add EROFS (Enhanced Read-Only File System), a lightweight read-only file system with modern designs for scenarios which need high-performance read-only requirements, eg. firmwares in mobile phone or LIVECDs
and
> It is a experimental project, under the staging directory, and still expects to make changes to the on-disk layout.
I see it's included in the 4.19 branch of the Raspberry Pi fork of the kernel as well.
There is no public, open source mkfs utility/integration for it yet far as I can tell, but it seems from the original public announcement of EROFS on LKML that it will be released eventually.
> the open source of erofs-mkfs is _still_ in progress, it will be released as soon as the internal process ends.
That's really nice. I remember having to use Read-Only on a few Raspberry Pi projects because they have a tendency to corrupt SD cards. Getting a free storage performance boost would really improve usability for my past use cases.
I recommend only writing when it is necessary, so e.g. you might want to log to /dev/null or tmpfs (I chose the latter but it adds up in RAM). Also, disable swap if at all feasible.
On top of that I recommend industrial grade SD cards using (a)MLC. They might be a bit more expensive but it is worth the stability.
I learned this from these posts (among others in the same thread 'Raspberry Pi microSD card performance comparison') [1] [2]
Coincidentally, for those projects I did end up mounting to a tmpfs, syncing configs from a server, and writing them to a SPI flash chip with FEC. Fun to know that others suggest the same!
I was just thinking along the lines of performance improvement for the absolute garbage SD card speeds. I just remember how flipping long it would take to load a program off those things.
With haptic feedback support? That's amazing, I just bought one of these (as it is the best trackpad available by a long shot). Even Windows doesn't support this. I did find this one [1], but it doesn't seem to be signed so a shady source.
With Linux, the latest kernel will allow for bluetooth connectivity. If you search for `Linux Magic Trackpad 2` you'll see some of the discussions.
It takes a bit of messing around, but once you get it, it'll stay working nicely.
One issue I had with Linux, which is probably an easy fix, is that Powertop wanted to sleep the trackpad after 10s of non-use.
With Windows, I tried to get the bluetooth working on a non-bootcamp install and couldn't get it going. I don't doubt that they'll sort it out. A few versions of W10 ago some were using the bootcamp drivers with moderate success.
I'm on 4.18.16-041816 Generic and just paired it with bluetooth, which is surprising to me. I typically keep it wired since Windows doesn't always play nice with the MT2.
Okay I'm on 4.18.14 and just tried plugging my MT2. It _basically_ works, but the trackpad feel is as bad that of my Thinkpad's. And none of the gestures, including two finger tap, works.
EDIT: looking at dmesg, it is registered as `hid-generic`. So not using the new driver?
I found that I had to modify the 50-mtrack.conf and also the 90-magictrackpad.conf to get the two-finger tap for context menus. There's probably a better overall configuration, but I'm still fresh to this specific thing.
When I get back to that system I can post some more detailed information.
I've read a few things about the latest happenings with regards to Linus and the kernel, but I feel like I'm missing something here. Can someone summarize for me, or point me at a good summary?
Edit: Who is Greg KH and why is this significant and what is the relationship between Greg KH and Linus (and the community)?
Haha, I found a possible Freudian slip in the article: "Code of Conflict (CoC)". Yes, it says "Conflict", which is unintentionally true, as it indeed caused more conflict than not. [1]
>Greg Kroah-Hartman is a major Linux kernel developer. As of April 2013 he is the Linux kernel maintainer for the -stable branch, the staging subsystem, USB, driver core, debugfs, kref, kobject, and the sysfs kernel subsystems, Userspace I/O, and TTY layer.
Greg Kroah-Hartman is the stable kernel maintainer for quite some time. In addition to multiple subsystems. Probably the best guy to work with out of all the maintainers.
The idea is that Linus stepped away for a second to reconsider his style of responding on mailing list and which caused the Code of Conduct silliness.
Greg KH is Greg Kroah-Hartman, Linus's second in command and I think the maintainer of the stable branch. He's currently filling in for Linus as the overall kernel maintainer.
He's good people. Gives a shit about kernel quality. Otherwise Linus wouldn't have trusted him with such a high post.
You're using a line of argument that I see quite often in day to day stuff (outside the kernel) so I have to push back on this.
>would have more weight for me if [...] It came from major Linux contributors.
The group of people you would give the most weight to the opinion of are also the group under the most pressured not to voice dissent publicly.
It isn't wrong to look to them or give large weight to their positions. The error is in assuming that we can know their position beyond their choice not to rock the boat. It might be very easy (they're in full agreement) or very tricky (blood boiling, but "not their hill to die on").
All we know is that they do not dissent to the level that they are willing to risk their involvement in the project at hand, or have a damaged reputation when they try to participate in another.
Perhaps. But usually if their blood is boiling they will leak indirectly as anonymous sources, via unnamed "friends", or whatever other euphemism the press likes to use.
A "New Yorker" writer has publicly claimed credit for Torvalds' change of heart. There was a massive hit piece ready to go if he didn't accept the CoC and step down.
If he hadn't stepped aside it would have been paired with activists calling for him to be forced out and putting pressure on corporate partners to denounce him and take over control of kernel development.
I’m seeing a lot of people stating that they’re worried about this code of conduct. Since I’ve not read it or any commentary about it, can someone tell me why it’s so worrying? Is there a sincere fear that Linux will be damaged as a result? If so, how?
> Given a choice between only two extremes, I'd far rather have Linus Torvalds telling me I'm an idiot and my code is shit, then exist in an offense taking culture where various forms of criticism are re-branded as "harassment."
I would like to extend this point: "I'd rather have Linus Torvalds telling me I'm an idiot and my code is shit, than ... releasing kernel with my shitty code and EVERYONE thinking that I'm an idiot".
Of course there exist examples of Linus calling or even implying that individual people / organisations are "idiots" and they are wrong (and he has acknowledged this). But in the vast majority of cases the criticism is aimed at the code itself and I genuinely don't see the issue with this.
I believe the biggest worry is that the CoC is loosely worded, but gives lots of power for removing people from the community that don't abide by the too-loose rules.
This leads people to fear that contributors, some of them long-term, may be removed because of things like political views, even if they don't come up in a mailing list discussion, or if they were said by the person 30 years ago on Usenet.
A lot of other people feel it wrongly shifts the focus from code-quality to political correctness and feelings, which are far harder to measure objectively. See paragraph 1.
I see. I agree that any such code of conduct should be limited to communications involving the project directly, and be the minimal set of rules necessary to ensure civility.
"Communications involving the project directly" is a good goal, but is ambiguous when e.g. one developer is belittling another in a semi-related forum like their personal Twitter account where they regularly have technical conversations, their HN account, etc. If (hypothetically) Linus were to be nice and polite on LKML, and reply to tweets about bugs saying "Yes, that's a bug, the developer should be retroactively aborted," I think we'd still not have solved the problem of people not wanting to contribute because they don't want to subject themselves to that.
I do agree on the other hand that digging up 30-year-old Usenet posts would tend to just get everyone in trouble and a code-of-conduct process should ignore them, or at most provide ample opportunity to distance oneself from those statements and then go with what's said today.
My preferred solution is to make sure the party handling the code of conduct process is someone who seems level-headed and likely to use their judgment well. It means you move away from codified rules, but it also means rules can't be gamed. For Linux the enforcement body is the Technical Advisory Board, which I think is a little weird precisely because it's a technical body and not necessarily a good-at-people one, but we can see how it goes. For small projects the enforcement body is typically the project founder, and if you don't think the founder will handle things reasonably, no code of conduct can make them trustworthy.
Your example isn’t that ambiguous, that’s a public communication directly about the project. That should be covered by the CoC.
However unrelated statements, even very politically incorrect ones, should be outside it’s remit. If for example someone was a virulent racist on twitter. That’s arguably a bad thing, but those statements are unrelated to the project and should have no bearing on contributions to it.
(Now that’s going to be an unpopular sentiment. Downvotes ahead.)
No downvotes from this guy here. I work with some terrible engineers who I wouldn't trust to design a tire pressure gauge but they're pleasant to be around. On the other hand, I've worked with world class engineers who are abrasive as hell but still write/design good gear. Code shouldn't have a thing to do with their political leanings. To quote an old OpenBSD saying: "shut up and hack".
Then you’re into territory where the CoC controls everything that a contributor says on every platform, as another contributor can always claim some indirect harm.
Always? All sorts of speech cause indirect harm to someone, analogous to "virulent racism"?
If that's really true, doesn't "shut up and hack" apply all the more? If you really cared about the code, you could keep your political opinions to yourself.
(Also, this is precisely why many codes of conduct define the exact harms they care about - so racism is an excluded harm, but, say, making Hans Reiser feel bad about being a murderer isn't. If you're a fan of racism, you might use this as an indicator to avoid the project and find another one, or fork it under the license.)
Which is all just censorship by the back door. With the possible implied accusation of racism aimed at me. I’ll spare both of us the usual freedom of speech rationales, I assume you’ve heard them before. It seems from your posts that you personally really do wish to use CoCs as a tool of wide-ranging ideological enforcement, exactly as their detractors fear. Or have I misinterpreted you?
However on forking I do tend to agree. There appears to be an audience for projects with less controlling, or less ideologically intended rules. These projects should be formed and developers should make their own choice between them.
The CoC can be used as a stick by Linux Foundation platinum members to get a grip on more outspoken maintainers. That way they can put more generic programmers who are used to corporate "professional" culture on the kernel.
Linux means big money now, you can't leave that in the hands of the rabble.
> Some elements of the Code are unobjectionable; sexual advances, for
instance, have no place on the lkml (though they may at, say, a conference, and not everyone can reliably predict whether they are unwelcome)'
I feel like one of the neat things about a code of conduct is it provides cleanly defined answers for people who are genuinely unsure whether sexual advances are welcome at professional conferences.
>it provides cleanly defined answers for people who are genuinely unsure whether sexual advances are welcome at professional conferences.
So chatting at the convention center bar with other attendees falls outside CoC scope?
Or are you saying that the clearly defined "no" exists exclusively for the kind of people that would be unsure, while the answer remains "yes" for people who are self-assured?
The clearly defined "no" should exist for both. If a code of conduct does not apply to everyone, it's simply another tool for those confident in their status and power to do what they want and the rest to watch helplessly—which is the entire problem being solved by codes of conduct in the first place.
(A fear that a code of conduct will not be applied equitably without regard of persons is an entirely valid reason to object to one.)
it's just one of many fronts in the ongoing culture war. Allegedly, progressive activists are pushing CoCs onto open source projects and other people are opposed to this. Obviously, you'll get different explanations for the motivations involved by asking different parties so I can't speak to that objectively.
People who don't have the ability to create and maintain the quality of the linux kernel seeking to have power, via social, political and economic ostracism, over those who do actually have the skills and competence to do so.
From reading peoples' complaints, they're worried that the CoC can/will be used to beat "problematic" developers into submission and reduce their ability to speak and discuss freely.
I think it's completely overblown. If a person's ability to discuss software development requires them to belittle others for their sexuality or political observation or gender or anything else not related to software development, then they should feel unwelcome and they should make a hasty exit from the community.
The CoC makes room for everyone except serial harassers. If a person can't work on professional terms as part of a larger development community, they should go somewhere else and probably work on their own instead.
Which is exactly why there's a board, requiring 2/3rds majority in a vote, after reviewing the evidence in question. A person cannot simply accuse people they don't like and get them excluded for breaching the CoC. It doesn't work that way.
And harassment/belittelment is always a question of feelings. You can't set up a clear concise objective standard. It's a case by case thing.
So instead of merely depending on the feelings of the accuser, it depends on the feelings of two thirds of the board? That's not much better. You can make objective rules that are not subject to feelings, you just have to be willing to not please everyone. When you don't have objective rules, people are less likely to participate in the game because people can't be sure that they aren't breaking a rule.
The board has a set of rules, that is the CoC. However as in any case where people are involved, they will have to deliberate and discuss to reach a conclusion.
Perfectly normal.
If you have a set of strict objective rules, some people will find a way to game them, and still harass people.
Linus may have been sincere in his writing, people saw him as this verbally abusive boogeyman who would tear people apart, which led him to become that type of person more and more.
The embrace and extend going on over in Redmond right now is threatening though, what better time to use your clout and power over a competitors org (that your a member of now) than when you have forked what depended on their software, extended it to work on your platform, and now want to take the wind out of their sails.
The recent reaction from Valve is telling, I think Gabe is fearful about the current state of affairs. We really don't know all the pieces of this puzzle though, so best to watch our backs. Avoid vendor lock-in, its the devil.
I'm as skeptical of Microsoft as any Linux user who read the Halloween documents, but your comment is overly conspiratorial.
People have been worried about scaling Linus for years, but it seems like there was not much focus on scaling the Linux developer community in general. Contribution quality was maintained through harsh criticism and personal attacks at times, and Linus didn't seem to care if this intimidated people into never contributing at all. Linux has matured, and it's time to acknowledge that some of the rough edges (antisocial aspects) of hacker culture need to go to ensure the project can continue to grow and attract the best code from everyone.
Re: Valve, they've been working on Linux support ever since the Microsoft app store was announced. They see it as a threat to Steam, so first they made the Steam box, Steam for Linux, and now the new DirectX -> Vulkan translation layers (they've also contributed a lot of work to the graphics stack). This isn't some new reaction, it's a strategic hedge they've been working on for the better part of a decade.
> The embrace and extend going on over in Redmond right now is threatening though, what better time to use your clout and power over a competitors org (that your a member of now) than when you have forked what depended on their software, extended it to work on your platform, and now want to take the wind out of their sails.
Can you explain that a bit more? Are you saying Microsoft is using their clout to change the linux kernel to their benefit and the detriment of others? How so?
I got down voted last time I mentioned this like it is some sort of conspiracy and not historical fact, but Microsoft literally used the phrase "Embrace, Extend, Extinguish" [1] as a strategy to defeat competition. So anytime you hear of them embracing something you would do well to be skeptical of their motives.
True but maybe they will be applying the tactic at Azure.
Their new strategy appears to be cloud services, all in [1]. Desktop, mobile, hardware, patents, dev tools... everything ties back to encouraging Azure use now. They're offering massive partnerships and credits (first one is always free) to attract new migrations. In the last year their managed service primitives (db's, queues, lambdas, lb, etc etc) has matured tremendously, so now it's convenient and practical to quickly build full hosted applications. Like AWS but different.
As they make more open source contributions, forking popular projects and making their own spin on things, there can be MS flavored Kafka and Classic Kafka, for example.
Then once your service is hosted in Azure, with forked nonstandard services and APIs, it's inconvenient to leave: things aren't close enough to other clouds so you need to re-invest. This is the definition of lockin.
Here at $work we have swallowed the whole lure: investment, credits, partnership, migration, custom services. And that lure has big treble hooks in our gills.
EEE [1] still happened under Ballmer's reign. Ballmer was CEO from 2000 till 2014, a confident of Gates (being employee #30 and the first business manager being hired by Gates) [2].
The Halloween documents [3] also contain FUD [4] disinformation from 2002-2004: Shared Source Initiative, Microsoft's 'investment' in The SCO Group, and the 'Get The Facts' campaign. That SCO lawsuit shenanigans lasted till when, 2008?
I have no issue when people argue Microsoft has changed since Ballmer left and Nadella took charge but like Gates, Ballmer was no angel either.
Microsoft could lock out 3rd party app stores like Steam, and already has on certain versions of Windows.
Valve is trying to protect themselves from irrelevancy, they have all their eggs in the Windows basket, while consoles and mobile are owned by companies that are massive comparatively.
Linus has a reputation to protect. As he said in that BBC writeup, the last thing he wants is to be associated with that horrible scum on the internet. Personally and professionally, he wants to distance himself from the alt-right.
Among the most vocal activists for change in the OSS community, "alt-right" means anyone who does not accept intersectional feminism as a fundamental tenet of their worldview, and given their penchant for "call-out culture" they won't hesitate to put you on blast across Twitter and wherever else.
Having someone else manage merges into the stable kernel branch isn't new. In the old kernel dev model (circa 2.x kernels) after the first few patches in a new stable kernel, Linus always used to delegate stable maintenance to someone else (Alan Cox) so he had more time to work on the experimental branch. So Alan would maintain 2.0 and Linus 2.1 for example.
This was my biggest issue with 4.17 & 4.18. I just recently upgraded my system to a Ryzen 2400 and I have had quite a few issues. Keeping up with the latest kernel builds with ukuu has helped but it would be nice to have a stable kernel that works with my CPU/GPU. Hopefully, 4.19 will make it to stable tonight and I can upgrade tomorrow. :)
I have Vega 56 and was bugged by it in 4.17/4.18 cycle. Finally 4.19-rc fixed it. But there are a few DisplayPort 1.2 related annoyances that still remain.
I think the code of conduct stuff worked out well in the end, especially as cooler heads prevailed.
In the `code-of-conduct-interpretation.rst` document they write:
```
The initial Code of Conduct Committee consists of volunteer members of the TAB, as well as a professional mediator acting as a neutral third party. The first task of the committee is to establish documented processes, which will be made public.
```
```
Any decisions by the committee will be brought to the TAB, for implementation of enforcement with the relevant maintainers if needed. A decision by the Code of Conduct Committee can be overturned by the TAB by a two-thirds vote.
```
Ultimately this tempers the worries of many about the C-o-C resulting in a tool used by those with politically charged agendas.
The CoC being a political document is expected, it is laying the boundaries that define acceptable behavior, an inherently political task.
On that ssamw tangent, the GPL series of license is inherently political. I personally like the political ideology espoused, but some do not despite how other licenses leave these developers with many users and proprietary forks, buf no added code, docs or community.
Developers need to understand something: CoC a political document written by someone opposing one of important principles of free software, meritocracy. https://postmeritocracy.org/
Now here's a big difference: linux was developed under GPL from the very beginning. If you didn't like the politics behind GPL, you didn't contribute. Now, there are people who try to push their politics everywhere, because "everything is political", even math.
Why should you accept their politics? Why should linux change its politics? Why must CoC be accepted? Why should developers accept the politics of CoC, after making contributions under promises of GPL?
You should accept the politics if you agree with them. Linux should change its politics if its major contributors agree they should be changed, and at least seven of them - including Linus himself - do.
I'm not sure why this is controversial - the people who can implement the CoC are the same people who generally decide where the project goes, same as always (just ask the people behind GRSecurity).
I'm not sure why some people have this illusion that they somehow have a (moral?) veto power to stop any changes they dislike.
I think the problem has to do with how this potcular CoC came about to be the de facto CoC. There is a lot of evidence in screenshots and wayback machine that suggest that this CoC was strongarmed into a lot of projects, and the ones that resisted have been put into a bad light.
Not to mention the author of the CoC started this process while working at Github by making it easy to add a CoC and badgering projects that don't have a CoC to add one. Low and behold the author's CoC is the first one and recommended for all projects.
I think many people who seem to hate the CoC would be fine with a community driven and created CoC -- what they really dislike is the particular CoC and the political agenda of the author of said CoC. I wonder how it got into 40k+ projects near overnight... And then this used as a beating stick "40k others have done it why have you not?". This type of attitude is unhealthy for everybody.
The said CoC is the "Contributors Covenant".
There is so much more to say about this CoC. I can only hope that the open source community will build a proper CoC that is truy community driven and actually has the goal of bringing people together vs being a stick to hit people with.
I believe most of the community would be totally fine with a CoC that banned things commonly agreed as bad (sexual harassment, trolling, etc) with no ulterior motive.
As you said, that's not what happened here. As the writer of the "Contributors Covenant" has made clear, there is an ulterior motive. She has a political agenda.
I think if Linus chose any other CoC, there would be no uproar.
Meritocracy is meaningless without an utility function.
And communication is (or should be) an important component for a lead dev.
Linus is a great guy, but some remarks of his were completely unnecessary and overly abrasive. (Without exact technical details about why the code is shit.)
> Meritocracy is meaningless without an utility function.
I'm not sure what you mean in the context of Free Software/Open Source. FOSS is something that is useful to everybody, and meritocracy ensures that the folks who are the most knowledgeable decide how it's developed.
The issue is that calling a system meritocratic doesn't give a functional definition of merit, and people tend to evaluate merit in very biased ways; see e.g. the halo/horn effect [1]. Possibly the simplest and most pervasive bias, though, is that work by familiar people is viewed as more valuable than work by unfamiliar people (cf. nepotism, cronyism, NIH).
OK but this is a completely different discussion: defining what meritocracy means vs. rejecting it altogether.
The dynamics of open source projects is a very interesting issue, but in general in most healthy environments it works like this: someone sends a patch, and it looks really good. They send another one, and another, and everyone can see that these patches are actually useful (not fixing typos in the comments...). With time, whether in formalized or informal way, that person has more and more to say as others respect their opinion. Why? Because they demonstrated they know the project, they devote their time to it, they can make reasonable decisions. So they are trusted more than a random guy who just joined yesterday, even though the same person - with time - can prove themselves and reach the same or better position in the project. This is called "meritocracy" and it's the base of most FOSS projects.
Of course it's not ideal and there are abusers - overly protective maintainers who refuse patches from anyone, or small groups of friends who dislike newcomers - but in general it works very well and I see no reason to destroy it.
It allows us to codify the spirit of the law, to be used as a fall-back plan when the letter of the law is being gamed. CoC's allow judgement, in contrast to zero tolerance policies which prohibit judgement.
One of orgs I volunteer for had our own #metoo drama. Actual rape, assaults, harassment, etc. Some stomach turning stuff. It made the news. There have been some out of court settlements.
Per the bylaws, we didn't have any way to remove the perpetrator. Adopting a CoC allowed the org membership to impeach the leader. (Maybe like a vote of no confidence works in parliamentary systems.)
Concerns about CoC's being weaponized, misused, abused... Whatever. Of course there's always oversteer, friendly fire. As if abuse didn't exist before CoC's.
I happily accept those occasional failures and let the balance be figured out over time. Rather than going back to denial and inaction.
In other words, I choose 98% awesome over 100% terrible, and happily work to further reduce that 2% gap.
That is neither here nor there. The GPL is ideological in a way that sits well and has done so for a very long time with, I assume, pretty much the entire Linux community. This also seems to have been the case with the previous CoC, as well as the CoC:s that a lot of other communities use. A CoC does not need to be inherently partisan and divisive. The Contributor Covenant is, though.
This old GPL hoary chestnut comes up again and again. The GPL is not a political document. It is an economic document that aims to give end users the right to modify their equipment.
Virtually any one who owns a fully mechanical device has access to its workings and with the necessary tools and knowledge (which can be hired or bought) can make changes and improvements to the device. If you own an old Mercedes, Ford, or (place your favourite car here), or a John Deere or Massey Ferguson tractor before critical functions become software controlled, you can make any modifications you want and not only that anyone you sell the device to also gains the benefits of those modifications, make any changes and can pass them on the next user.
Is that a political benefit or an economic benefit?
The GPL extends this facility to computer programs. How does this become a political thing? It only becomes political when there is the desire to use the legislative and judicial systems to subvert end users ability to enjoy, enhance and repair the products they have bought.
> It only becomes political when there is the desire to use the legislative and judicial systems to subvert end users ability to enjoy, enhance and repair the products they have bought.
I mean, even if one were to accept all your promises, this is exactly the world we live in, so the GPL is indeed political. You can put curtains up between Economy and Politics if you want. I guess.
And instead one should... Attack the ``status quo''? This line of reasoning is inherently partisan and extremely political as well as divisive. Believing that meritocracy is bad is a fringe belief, and in this case there really is nothing that suggests that adhering to the ``status quo'' is the non-insane alternative.
Edit: I'd also like to highlight that this is a classic version of the ``you're either with us, or against us''[1] argument, i.e. a false dilemma.
It’s really not a fringe belief outside of your circles - “meritocracy” is one of those things that sounds like a good idea, like “communism”, but organisations and structures defining themselves by those words very rarely practice what they preach. A meritocracy would never allow harassment of people on the basis of things that have nothing to do with their code - it would take a hard stance against sexism and harassment, it would attempt to communicate in a way that doesn’t drive people away from the project in a biased manner, since those and many other behaviours drive away people who may have merit. If anything, a well-designed code of conduct can create something closer to a real meritocracy, as you don’t drive away contributors on anything but the merit of their contributions.
>but organisations and structures defining themselves by those words very rarely practice what they preach
Is there some sort of evidence for this?
>A meritocracy would never allow harassment of people on the basis of things that have nothing to do with their code - it would take a hard stance against sexism and harassment, it would attempt to communicate in a way that doesn’t drive people away from the project in a biased manner, since those and many other behaviours drive away people who may have merit
I can buy that. But that means that you do believe in merit as a central principle. The new CoC is founded on an ideology that explicitly rejects it.
>If anything, a well-designed code of conduct can create something closer to a real meritocracy, as you don’t drive away contributors on anything but the merit of their contributions.
If that were the purpose of the new Contributor Covenant, I don't think anyone would be complaining.
> The new CoC is founded on an ideology that explicitly rejects it.
The GPL is also founded on an ideology that rejects proprietary software, yet Linux is used by plenty of companies who develop such software. "Foundations" are just an origin story. What part of the actual text of the CoC prevents a meritocracy?
> If that were the purpose of the new Contributor Covenant, I don't think anyone would be complaining.
Reusing the previous example, the purpose of the GPL was to drive out proprietary software; yet the people using it in Linux do not yield it that way. It doesn't matter what purpose the original writer had in mind, only the purpose of those who have the power to interpret and implement it. Do you believe the TAB has any other purpose in mind?
> Reusing the previous example, the purpose of the GPL was to drive out proprietary software; yet the people using it in Linux do not yield it that way.
That was an outcome that was hoped for, not a purpose. The purpose is pretty explicit in the preamble paragraphs [0] - to promote a certain style of freedom. As a body, the Free Software community wouldn't deny that if creating non-free software is legal, then free software can be used to achieve that goal. They have a more fundamental objection to the government creating and then enforcing the concept of copyright.
The kernel community has been very aggressive about securing that freedom for themselves, particularly in arenas such as allowing non-free drivers into the kernel. They don't take a politically activist stance of lobbying to change the law, but they don't seem to deal with code that they can't legally modify themselves.
The kernel community may well be cherry-picking from the GNU strategy, but the GPL is being used as intended - to promote and secure freedom for users.
> What part of the actual text of the CoC prevents a meritocracy?
The part where it sets out that the Technical Advisory Board (aka the TAB) will presumably remove people form the community who are in breach of the code of conduct, without language that exempts people who have a long history of positive technical contribution.
Everything involves tradeoffs. Being a meritocracy means that individuals of technical merit are given leeway to fumble, or even potentially abuse, the status of their position.
Good example is Hans Reiser - the case was rendered moot by him being imprisoned, but a meritocracy says "the code is good, let him keep contributing" and a non-meritocractic community would presumably say "we don't want to associate with murderers".
Obviously nobody wants the to encourage bad behavior, but the question being asked is /how much/ slack do great technical contributors get if they happen to be, say, autistic and antisocial. Historically, the answer has been lots of slack. In future, the answer looks like it will be corporate-acceptable-behavior, which is a higher standard. Presumably if there is a group who thinks this change is needed it will be followed by a purge of the community where marginal maintainers are pushed out.
You can be autistic, not good in social situations, and still not abuse, harass, or discriminate against people. Associating abuse and harassment with being a fundamental part of autism is not ok. Autistic people can fully understand "do not perform this behaviour again" - they can also understand consequences of their behaviour, including both positive ("people like to talk to me more and are more accepting of my ideas if I do X") and negative ("I will be removed from this community if I do X"). If anything, a clear, structured description of what behaviour is and is not acceptable - such as described in a code of conduct - is incredibly useful for many autistic people.
Please do not make the argument that autistic people cannot learn to control their behaviour again.
In the incredibly rare cases where a person, autistic or not, cannot learn how not to abuse people, they need a full-time carer, who will be able to help them interact with the world in a way which doesn't harm other people. It is not the responsibility of people involved in an arbitrary software community to suffer abuse just to make an abuser happy.
Finally - if you allow abusive people to exist within a community, you by definition exclude everybody who they would abuse. You exclude a number of people who may have greater merit, whether individually or collectively. You just can't see that because you're supporting an abusive person over and above anybody else who might wish to contribute. You're supporting them even while they drive out countless contributors, who you can't see the "merit" of because they're no longer contributing. All you can really see is the merit of abusive people, and you ignore the merit of those they abuse.
I suppose you are arguing that meritocratic communities aren't the best setup for a community - which is a pretty reasonable one. I mean, the big successful countries aren't meritocracies, they are democracies. So fair enough.
> Finally - if you allow abusive people to exist within a community, you by definition exclude everybody who they would abuse.
You are going directly to how a meritocratic society might fail. Meritocratic communities can fail, but so can communities with any ideological underpinning.
Sometimes you have a choice between someone who knows exactly what they are doing but has questionable behaviors vs. someone who doesn't know quite as much but is better behaved. A meritocracy gives power to the first person. We can have long conversations about whether that person should strive to improve themselves over time (pretty easy to answer that question), but change is slow and in the interim a choice has to be made.
I’m suggesting that your meritocracy doesn’t exist - if your organisation is structured to exclude people who may (and likely do) have contributions of merit, it is not a meritocracy. Then, the question is simple - who do you exclude? People who abuse others, or the people they abuse?
Note that this is a community issue, not a code issue. If somebody wants to sit on their own, publish patches to their own website, and somebody else wants to import those patches into a community project, fine - there’s no non-technical interaction needed there, and little actual reason to exclude their code. It’s excluding them from the community that we’re talking about here.
> I’m suggesting that your meritocracy doesn’t exist
Nothing ideologically pure exists - technically there are no democracies in the world either, because, eg, places like the US dilute the will of the masses with the court system (which is not democratic). It is still a pretty democratic country.
> if your organisation is structured to exclude people who may (and likely do) have contributions of merit, it is not a meritocracy
Sure it is. That is like saying you can't have a democracy in Australia if people in Tanzania who aren't Australian citizens, because a a palce ruled-by-people is excluding people. It is reasonable to argue that excluding people who have great potential is a bad idea, which it is, but you can still have a meritocracy.
> Then the question is simple - who do you exclude? People who abuse others, or the people they abuse?
No, that isn't the question at all. The question is simple and it is "how do we support the people making the greatest technical contributions?". In an extreme case, that might mean putting up with some off-color characters who happen to be inspired technical experts.
It isn't perfect. What is? But that is what meritocracies do.
I happen to have autism (and, it seems Hans Reiser also has autism, or perhaps his father merely argued that I am not sure). Autism is no excuse for harmful behaviour (such as rude behaviour). As part of a project of reintegrating in society I received specific training to act like NTs in a corporate environment. In any social setting there are lower limits which are lines which should not be crossed. Don't want that? Hire someone who acts like a middleman in those social settings e.g. a secretary.
I haven't read the source quotes, but I would argue that a pure meritocracy does not organically establish and maintain itself. Humans don't behave like perfect robots, we're messy. We have cognitive biases, sometimes we act irrationally, we like to form tribes and in-groups and out-groups. We trust some people and distrust others, and that can affect our judgement both consciously and subconsciously. Without rules and governance, there is nothing to enforce a consistent meritocratic system.
>CoC assumes contributions are primarily due to the conduct of the community and not the intellect/interest of the contributor
No. That you choose to read into that this way doesn't make it factual. I'd even argue that someone that doesn't behave accordingly (with a sane CoC) doesn't show that much "interest" in a certain way. A contribution shouldn't be accepted on the sole basis that a person actually respected the CoC, and it's never been the goal of this. But it's another condition now.
> The quality of a community isn't primarily measured by its conduct but rather its accomplishments
Measuring the two is a possibility. That you don't, yourself, include the conduct of a community in your measure of its quality is your choice and yours only.
I'm curious as to what led to this broadly wrong evaluation of the situation. What lead you to believe that?
>> CoC assumes contributions are primarily due to the conduct of the community and not the intellect/interest of the contributor
> No.
Yes. If that weren't the case there would be no need for a CoC. Kroah-Hartman's justification for the CoC is the longevity of the project, but the longevity of the project is not affected in any significant way by the conduct of its contributors. Evidence of that is the current success of Linux, which had no CoC for 20 years. Adding the CoC condition will have no noticeable positive effect on the longevity of the project: Linux isn't going anywhere, CoC notwithstanding.
>> The quality of a community isn't primarily measured by its conduct but rather its accomplishments
> Measuring the two is a possibility. That you don't, yourself, include the conduct of a community in your measure of its quality is your choice and yours only.
It's not my choice, it's the truth. Community conduct is not a requirement for a successful project but accomplishments are. Never have seen a project with good conduct but no accomplishments succeed, but I've seen many projects with bad conduct and many accomplishments succeed.
>> I'm curious as to what led to this broadly wrong evaluation of the situation. What lead you to believe that?
You're the one who is wrong, as shown in my trivial counter examples. Simple logic and evidence are the tools I use to evaluate situations accurately.
If you seriously think BSD has anywhere near the same mind share as Linux then I don't know what to tell you. "Taken over the world" might be hyperbolic if read literally but such slight hyperbole is common in regular English.
For example, I might say that Linux is used "everywhere". Of course this isn't true if read extremely literally but my meaning should be clear: you don't have to go far to find something that uses LInux. Websites (and web infrastructure for that matter), smartphones, DVD players, etc.
I feel really worried about the Kernel project now that they have let Identity Politics breach their walls. These kind of things have a tendency to split a community rather than unite it.
The kernel project is surely one of the most successful software projects ever. Having survived for 20 years, why change a winning formula?
I have always considered Linus un-political and more interested in getting sh*t done and getting it right above anything else, so why he would sign-off on this is a mystery to me.
I don't think it was, at least not that black and white. If the community really was that split the project would not have survived for 20 years. Surely we would have seen a fork where the involved factions split off.
I think this is a very vocal minority in play here. From my understanding these changes did not come from any of the core contributors but rather from activists. The used divide and rule; if you don't sign off on our political documents you are with "them" and we will let everyone know what a horrible human being you are.
It seems the loud voices about how bad the CoC is aren't actually kernel devs...
But there is atleast one known kernel dev who spoke up about Linus' behaviour, and eventually just quit developing for the kernel.
edit: not to mention those who don't want to touch the kernel because of his behaviour. one guy said the only contributions he makes to the kernel are for his employer. if it wasn't for that, he'd not touch it.
For the 30 years where it was one project, the community was split? And now that it has been forked because of outside political issues being forced in, that's the same amount of split as the last 30 years?
Either that, or some people tend to see "vegetarianism" and "dictatorship/genocide" as orthogonal, while seeing "low-life scum on the internet" and "complaining about too much political correctness" as not orthogonal?
Should the separation not be between ``low-life scum on the internet'' (the far right) and ``not being explicitly politically correct'' (being apolitical)? ``We need more political correctness'' (the far left) is on the reflected axis of ``complaining about too much political correctness'' (the far right).
>evoking Hitler was a bad way to make your original argument
You'll notice that I was reducing to the reduction to Hitler, not reducing to Hitler himself. And this is not such a long stride to take, as the reduction to nazism had already occurred in the quote that I was criticizing.
It is very disturbing for me to see Greg KH being at the top and deciding what goes into Linux. There is history of agenda that doesn't align best with kernel user interests. Can't forget d-bus events very related to this person. I did switch to FreeBSD couple of years ago but I love linux and it is not easiest to observe all the latest events.
Greg KH already decides what goes into the "stable" Linux series (4.y.z, for instance 4.18.15), which is what most people actually use. Besides, he assumed after the 4.19 merge window, and he's handed the 4.20 merge window back to Linus; it's in the merge window that new features come in (after the merge window closes it's mostly only bugfixes), so it's still Linus who gets to decide.
Is stable different from latest? I am not sure how much independent decision space he has, otherwise we would have d-bus in stable long time ago. Maybe I don't know the process well enough but I would be surprised that Greg can merge something that isn't approved in latest.
Fingers crossed it is only 4.19, I am kind of seeing this as a bigger event but I may be wrong.
Yes, I am aware of that but are LTS kernels in any for different from the mainline kernel? Can LTS kernel contain code that is not approved and tested in mainline first? They are 'older' but they contain same feature set that is already approved by Linus, right?
[1] https://github.com/riscv/riscv-linux