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.
Good on you for putting wotrk in and not just words in. I'm interested to see how many contributors will support the fork.
Twinstiq, game news
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?
Twinstiq, game news
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.
It must have been something you assimilated. . . .
Nice to see someone actually following through. It might not go anywhere... but I fucking hate ego-driven development so much that I would back this type of move regardless of the dspecifics. Linus (and the mentality he spreads) can die in a fire for all I care.
I don't want to speak for Matthew but when I read his post I see someone who simply didn't like the toxicity level that can or often does occur. Then he saw someone important, a maintainer, leave because of that same toxicity. He's right that he doesn't have to put up with that, it's free software. If forking the kernel is what he needs to keep his hands in the game he loves while being able to feel good about the environment then more power too him. I hope he succeeds. At the very least I can see some like-minded devs coming on board even if the project doesn't see wide-stream adoption.
There are only 10 kinds of people in the world. Those that understand binary and those that don't.
a) A fork is not the end of the original project. It can be. But usually it's not.
b) "In October 2014, Garrett stated on his blog that he would no longer contribute Linux kernel changes relating to Intel hardware" - That's pettiness, and I'm sure the kernel came to a grinding halt that day too.
c) If you can't get your changes past other people, to the point that you have to fork and maintain an entirely separate branch on your own, that's usually the sign of messy code or absolute loss. It means that you want only YOUR way to be the way. That kind of lack of co-operation isn't the way forward, but you are more than free to pursue that. The number of followers of that fork versus the stock kernel is likely to be tiny, and changes likely to come back in the "accepted" format into the stock kernel before you see any real usage of it outside developers and testers.
d) "He is a recipient of the Free Software Award from the Free Software Foundation for his work on Secure Boot, UEFI, and the Linux kernel". Ah! All the bits that I *don't* want in the kernel. Did he work on systemd too?
It's not about "interminable arguments over the naming", the only one doing that is no else than Matthew, in attempt to pigeonhole his agenda.
This dates way way back to 98. Matthew tried to push gradual openbsd-ish "lock down everything" levels few times, while Linus and his club keeps firm stance "inherited bitmaps or gtfo" every time.
This is ultimately BSD "give user limited but easy to use tool" vs linux "provide powerful [albeit not as intuitive] tools, let user do the job". Think pf vs iptables. I personally stand with linus on this one, as providing flexible tools (instead of easy to use, but limited) is ultimately what made Linux a winner - people can bend the system for more usecases, instead of being restricted by simple and easy to use, but often hopelessly limited tools.
i have little coding knowledge and have no idea how kernel coding collaboration works
but i tend to side with linus
if he verbally abused me i'd first make sure i didn't do something so stupid it warrants such a response (in case you want to say 'nothing warrants verbal abuse', we're adults, not children) before deciding to move away.
Here's an example of Linus ranting on someone:
https://lkml.org/lkml/2012/12/...
Yes, it's pretty harsh. But I can't honestly say that what Linus said was wrong.
Only in theory. In practice, hypervisors have had more security issues, not to mention performance issues. Jails are faster and more secure if you look at their track record. Some of the most reknown kernel programmers who have been working on kernels before Unix had a name, and have worked in both hypervisors and jails, have said that hypervisors are a complicated mess for both software and hardware and securing them is a huge issue. Jails are much simpler and with anything security, simpler is better.
A guy complaining about unprofessionalism uses the term "deep throating". Ok then.
1. There is no gauntlet of vitriol, only for quality code and design. Linus only whips out the big guns for deserved behavior/code. It's very rare, but, historically, when it happens, it saves a ton of time and stress for everyone else. Honesty is more important than shielding sensitive people from bad feelings.
2. garrett wasnt' seared 'whenever he got anything done.' That bit about the PE binaries was pretty stupid on his part.
3. appeals to what 'normal people' are, implying that kernel devs are not, is just ad hominem.
It's an european vs american problem. Americans think: "Why can't he make his point without being vulgar." Europeans (minus the English, probably) think: "He's a a bit childish, sure, but why do these american prudes make such a fuss about it, it's not that important." (And they're mostly not offended at all.)
Actually, it's probably more correct to say north-european. I'm certain nobody in the netherlands or scandinavia whould give a damn about it. I'm a bit less sure about france/spain/italy but I wouldn't really think it would be a real problem there either.
Furthermore, the term 'deep-throating microsoft' *was* very to the point. I challenge you to express the same disgust of the proposed patch in a more civilized manner which would also make it immediately clear how disgusted you are.
Given the downmods each of us got in the pile, it seems this is a contentious issue.
Personally, I disagree with your assessment, but that said, I am aware that one person's fair assessment followed by a harsher and unequivocal reply if the assessment is rejected, may easily be seen by another as undue abuse.
I make no apologies for the list, because it reminds me exactly of a typical USAF flightline. Doing something dumb or misguided will get you a direct and to-the-point talking-to; first logical and fair, but increasingly harsher if you continue to resist even listening.
The reasons why are different but just as serious: in the kernel, screw-ups in design and/or direction can eventually destroy the kernel's usefulness and flexibility. On the flightline, screwups in procedure or behavior will eventually get you killed.
The harshness against any whining and/or backtalk in either case is not just someone being a turd - it's a reminder that there are reasons for things being as they are, and any proposed changes had better have a damned good reason up-front.
HTH a little.
Quo usque tandem abutere, Nimbus, patientia nostra?