Linux 4.19
lkml.org
lkml.org
[1] https://osseu18.sched.com/event/Fwx7/bof-risc-v-sw-ecosystem...
The more interesting component this cycle is the fact that the release notes were written by Greg KH--worth the read in my opinion.
That is because Greg handled this release cycle to let Linus take time off. Linus will be back for 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.
https://github.com/raspberrypi/linux/tree/rpi-4.19.y/drivers...
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.
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.
Original source: https://github.com/robotrovsky/Linux-Magic-Trackpad-2-Driver
I've been using this since last night, and with some tweaking, it works really well.
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.
For Windows, try https://github.com/imbushuo/mac-precision-touchpad/releases
I went through a lot of sketchy drivers like that one you mentioned, but this one worked the best without any helper apps to mess around with.
Its a shame its taken so long for other OSs to support such a great device.
I noticed a few things from the link: the Apple Magic Trackpad 2 support is "not stable", and it does not appear to be usable via Bluetooth.
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.
Edit: Who is Greg KH and why is this significant and what is the relationship between Greg KH and Linus (and the community)?
>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.
This ZDNet article summarizes some of the points Linus made, if you want the short version: https://www.zdnet.com/article/linus-torvalds-answers-5-quest...
[1] Archived: https://web.archive.org/web/20181011105751/https://www.bbc.c...
https://www.linuxfoundation.org/blog/2015/03/on-the-linux-ke...
He's good people. Gives a shit about kernel quality. Otherwise Linus wouldn't have trusted him with such a high post.
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.
a) It came from major Linux contributors.
b) It didn't assume a conspiracy to not only oust Linus but also get him to dance to their tune.
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.
https://www.itwire.com/open-source/84590-new-yorker-claims-c...
[0]: https://www.newyorker.com/science/elements/after-years-of-ab...
>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.
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.
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.
Perfectly normal.
If you have a set of strict objective rules, some people will find a way to game them, and still harass people.
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 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.
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.)
Does "shut up and hack" apply to telling them to keep their racism to themselves?
(I realize you didn't say anything about racism, but you replied supportively to a comment about it, so I'm not sure where you stand.)
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.)
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.
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.
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?
(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.)
> 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."
However, the Linux copy has cut one of the more malicious paragraphs: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Or, "releasing kernel with my shitty code and ruining the day for a lot of people."
They could just refuse your code without calling you an idiot.
Linux means big money now, you can't leave that in the hands of the rabble.
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.
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.
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?
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
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.
https://www.forbes.com/sites/bobevans1/2018/07/26/why-amazon...
I would argue that they are still driven by sales and bottom lines.
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.
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
[2] https://en.wikipedia.org/wiki/Steve_Ballmer#History_with_Mic...
[3] https://en.wikipedia.org/wiki/Halloween_documents
[4] https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
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.
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.
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.
[1] https://twitter.com/CoralineAda/status/1041465346656530432
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.
I agree that both CoC and GPL are political.
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?
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.
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.
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.
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.)
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 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.
Made up percentages but I understand what you are trying to convey.
The problem is THIS CoC has an explicit agenda, which can lead to it being "weaponized, misused, abused".
If the community all came together and chose a non-biased CoC, there would be no uproar.
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?
Try doing that with your Tesla, https://www.youtube.com/channel/UCfV0_wbjG8KJADuZT2ct4SA/fea..., or your new John Deere.
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.
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.
[1]: https://twitter.com/CoralineAda/status/1041501017651793922
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.
[1] https://en.wikipedia.org/wiki/You%27re_either_with_us,_or_ag...
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.
What type of evidence would change your mind?
> 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?
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.
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.
> 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.
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.
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.
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 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.
Fingers crossed it is only 4.19, I am kind of seeing this as a bigger event but I may be wrong.
A good number of Linux distributions are based on an LTS release instead of a mainline release.