Matthew Garrett Forks the Linux Kernel

jones_supa writes: Just like Sarah Sharp, Linux developer Matthew Garrett has gotten fed up with the unprofessional development culture surrounding the kernel. "I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn't be bothered asking questions about the reasoning behind a design before trashing it," Garrett writes. He has chosen to go his own way, and has forked the Linux kernel and added patches that implement a BSD-style securelevel interface. Over time it is expected to pick up some of the power management code that Garrett is working on, and we shall see where it goes from there.

Comments

Linux is Dying

[Anonymous Coward]

It is now official. Netcraft has confirmed: Linux is dying

One more crippling bombshell hit the already beleaguered Linux community when IDC confirmed that Linux market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Linux has lost more market share, this news serves to reinforce what we've known all along. Linux is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin to predict Linux's future. The hand writing is on the wall: Linux faces a bleak future. In fact there won't be any future at all for Linux because Linux is dying. Things are looking very bad for Linux. As many of us are already aware, Linux continues to lose market share. Red ink flows like a river of blood.

All major surveys show that Linux has steadily declined in market share. Linux is very sick and its long term survival prospects are very dim. If Linux is to survive at all it will be among OS dilettante dabblers. Linux continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, LInux is dead.

Sincerely, good luck

[HalAtWork]

Good on you for putting wotrk in and not just words in. I'm interested to see how many contributors will support the fork.

Benefit to end users?

[sjbe]

I don't actually mean to sound snide but can someone explain to me why I should care about this as an end user? TFS reads like someone got their panties in a bunch over some arcane detail and couldn't bear to not get his way. Is there some amazing benefit to users in this or is this just some developer having a snit because Linus disagreed with his preferences?

Re:Benefit to end users?

[HalAtWork]

Choice? Options? These people were going to leave kernel dev anyway, now we get to see them try something new. Maybe it'll work, maybe not, but what's the harm in trying?

Re:Benefit to end users?

[serviscope_minor]

I don't actually mean to sound snide

Yeah you do, otherwise you wouldn't have said this:

TFS reads like someone got their panties in a bunch over some arcane detail and couldn't bear to not get his way

Guy gets finally fed up with dealing with insane LKML politics and decides to have his own tree with his own patches. Guy isn't some rando, guy is a long term contributor to the mailing list.

TFA also makes note of another long term technically respected contributor leaving the kernel because of insane LKML politics.

You should probably care because the politics driving away good people means that inevitably the quality will go down when those good people find more enjoyable places to work. And good people always have options.

The thing is many people confuse beinf honest and technically sound with being a raging douchebag. They're not actually the same and you can in fact give honest, harsh technical feedback without being a dick about it. The LKML seems to actualely valye the "being a dick" part over even the technical parts of arguments.

Anyway you shoudl care because the kernel maintainers are overworked and some are leaving because the remaining ones like being dicks.

Re:Benefit to end users?

[serviscope_minor]

Your work is all i care about. Its a meritocracy.

Except it isn't because two long term, well respected contributors have left not because of code, quality or merit but because of the toxic mailing list.

securelevel who?

[fisted]

Just for the people who don't know what the fuck securelevel is (NetBSD's flavor in this case)

Not going back to Linux, but this really is a worthwhile addition.

Re:securelevel who?

[fahrbot-bot]

Just for the people who don't know what the fuck securelevel is (NetBSD's flavor in this case)

Not going back to Linux, but this really is a worthwhile addition.

Furthermore, should something like this be omitted simply because Linus doesn't like it? Is his opinion the only one that counts? Among other things, securelevel is used to implement "jails" but the functionality can be completely disabled (securelevel = -1) -- so Linus can turn it off if he wants.

Is the direction in which Linux is driven simply the whim of people like Linus and Lennart who dictate "my way or the highway"? They are smart, capable, talented people, but not omniscient Gods - despite what they and some others might think.

Hopefully he will maintain it in sync

[Ruedii]

Hopefully he will keep his branch in sync and offer back his contributions like other developers who have done the same thing.

Many developers felt that working on the main Linux kernel tree involved too much politics and in-fighting and chose to maintain their own dev branches for their patches. Any that keep their trees in sync have successfully continued to contribute, and left the politics for when their projects were ready for merging. Any that didn't keep in sync, well . . . at least we don't worry about those projects anymore.

How it should be

[mveloso]

This is how it's supposed to work. Whether he can make a functioning team or not is an open question, but at least he can see if a more polite environment gets better results.

Panic

[Anonymous Coward]

The ideal Linux kernel fork would panic if it detected a systemd infection.

Not really

[Kjella]

Branching happens all the time, either to develop a feature or because it's doing something that upstream won't accept. One man maintaining his own patches isn't a fork. A fork would imply that that you're planning to diverge from or replace the project you branched from, nothing in his post indicates he wants to compete with Linux or the LKML. He's just saying I'll make my own patches and provide them for those who want them, but I'm not going to bother trying to upstream them. Kinda like Debian and Ubuntu, Canonical made a lot of patches for Debian but they weren't trying to fork it. They just rebased off it every six months, being a downstream variation. He's making a downstream variation with some interface from BSD. Big whoop.

It could work.

[grub]

Remember that forks sometimes do succeed.

Take Linux. It forked from OpenBSD which itself was forked from QNX with smatterings of FreeBSD code.

QNX programmed itself from vacuum tubes and trace wires left on the ground at Quantum Software in Ottawa one evening. Dan Hildebrand (RIP) apparently had something to do with this metamorphosis.

Meanwhile across the ocean, FreeBSD was forked from Windows 95 which itself came from the unholy union of MS-DOS and the GEM environment. MS-DOS was bought from a company in Washington State and was a fork of CP/M. GEM was a stand alone thing and should never have been born.

Where was I? Oh yeah, CP/M. CP/M was a copy of Apple's SOS used in the Apple /// series of super-powerful business computers. The source code was left at an airport where Gary Kildall read it when his plane was on auto-pilot.

Apple SOS was a mix/fork of Apple ProDOS and TRS-80's OS; I forget the name, not important. Radio Shack forked their TRS-80 OS from some source code they saw in Lions' Commentary on UNIX 6th Edition.

Fact.

Re:Can't take the heat?

[dhasenan]

Why should a person face a gauntlet of incivility and vitriol, one that you liken to a frying pan, to contribute to an open source project?

Code reviews, design reviews, that makes sense. Being referred to someone at a lower paygrade rather than the top tier of kernel devs, sure. These things are stressful but essential. I'd stand to lose considerable self-esteem from them, but there's nothing I can do about that but get better.

But if I went into a code or design review at work and got a Torvalds-style response, I'd be reporting the person to HR and finding a more civil person to work with. If I couldn't work around them and nobody was making them change, I'd find another job. I could try to modify the problematic person's behavior, but that would be stressful and unlikely to work, and I shouldn't have to act as my coworkers' parent.

Garrett found that there was no HR to appeal to, no way to work around Torvalds, and no way to change him. So he did in fact get out of the frying pan. He doesn't deserve to be seared whenever he gets anything done, so he's not tolerating it. Now he's getting the same things done in a way that normal people will be happier with.

This isn't a deficiency on his part. He merely doesn't want to deal with something that normal people shouldn't have to deal with.

Re:Who?

[Penguinisto]

Although this project will probably never end up being used in any wide way, shouldn't the Linux community be concerned that it's running talent away with a poor culture?

No.

Anyone with any real experience in hacking the Linux kernel already knows what they're getting into. It is also very widely known that Linus is incredibly fair in his assessments. If you provide useful contributions, no worries. If your commit is a total brainfart, you'll get a rejection, but the abuse won't come unless you decide to be a dumbass or get all arrogant about it.

It's about as fair as it gets.

for those wondering about the deepthroating

[nimbius]

https://lkml.org/lkml/2013/2/2... Matt got reamed for this because it was a stupid idea, not because the environment was somehow too immature. from Linus Torvalds himself:

Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

By the time SCALE 11 hit, Matt was no longer working at redhat. people moved on. A Fork was always an option for Matthew...just perplexed as to why he decided to do it 2 years after...

Re:for those wondering about the deepthroating

[JumboMessiah]

For those not wanting to read anything historical. The confrontation comes because the Secure Boot option of UEFI (if enabled) only ships with Microsoft keys in the firmware. Thus, Microsoft's signing service is the only practical signing service and will only sign a PE executable. The solution that Matt and company came up with was to have a module vendor wrap their keys in a PE executable, have Microsoft sign them, and then ship the signed PE executable with the signed Linux kernel module. Verification of the signed Linux module thus requires the Linux kernel to load the PE executable, verify its signature, then extract the vendor keys and continue on.

Linus rightly called out the idea as moronic and stupid. The retorts basically came in the form of "Microsoft created the standard, and is the only viable signing service for the standard". Even though alternative options could of been had, they were deemed to complicated and involved.

Life would of been much easier of Microsoft would just sign X.509 certificates like the rest of the world.

Read more about it here.

Re:Waaaahhhhh!!

[tweak13]

This is the "deepthroating Microsoft" he's referring to: https://lkml.org/lkml/2013/2/21/228

It was a pretty stupid idea, and it isn't surprising that Linus shot it down.

Re: Waaaahhhhh!!

[amicusNYCL]

You don't blame Linus? When people are talking about signing and parsing PE binaries, and whether that belongs in the kernel or in userland, you think that it's perfectly acceptable to talk about sucking dicks? That's effective management to you?

I mean, why can't Linus just make his point without multiple references to sucking dicks? Why is that not an option?

That's the point he's making. He's not talking about whether or not Linus is correct, he's talking about the way in which Linus chooses to communicate.