Warning: this article contains profanity.
On September 16, 2018, Linus Torvalds released the 4.19-rc4 version of the kernel, and he also announced he was taking a break from Linux development in order to consider his own behavior and to come up with a better approach to kernel development. This was partly inspired by his realization that he wasn't looking forward to the Kernel Summit event, and he said that "it wasn't actually funny or a good sign that I was hoping to just skip the yearly kernel summit entirely."
He also wrote that it was partly inspired when:
...people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.
So he said, "I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately."
He compared the situation to the kind of "pain points" the Linux kernel project has experienced on a technical level in the past, like moving from tarballs to BitKeeper, and from BitKeeper to git. And he remarked that "We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me."
He also added, by way of clarification, that "This is not some kind of 'I'm burnt out, I need to just go away' break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades."
That was the last post Linus sent to the mailing list, up to the time of this writing. However, he and several other kernel developers signed off on a patch to the kernel tree, incorporating a new Code of Conduct policy. It's fairly boilerplate—basically, don't be mean, don't discriminate, violations will be investigated, and appropriate measures taken.
It's not a new idea. Long ago, Richard Stallman used to troll the mailing list trying to start an argument about "Linux" vs. "GNU/Linux", until the mailing list maintainers threatened to ban him if he kept it up. They phrased it as a general rule, not unlike a code of conduct.
There's been a wide range of responses to Linus' announcement and to the Code of Conduct itself. Some felt that Linus' earlier behavior had been community-strengthening, encouraging people to respond as equals and duke it out with Linus on the issues they cared about.
Some felt that Linus was taking a really wonderful step, seeking feedback and reflecting on the issues, and they in turn offered their own insights and assistance.
Some, on the other hand, felt that it was wrong to start welcoming political agendas in software projects. They felt that adopting codes of conduct was a way for certain interests to gain other forms of control over software projects.
Some people felt that the Code of Conduct had not been properly discussed in a public forum, as other patches were, and should not go directly into the kernel without that kind of process.
Some felt that the "Code of Conflict", which had been in the kernel source tree since 2015, was plenty good enough and did not need to be revised into this new Code of Conduct. The two are very similar—both call for investigations to be conducted by the Linux Foundation's Technical Advisory Board (TAB)—but the Code of Conduct is more explicit about the types of communications that would be considered violations. Some people felt that the added specificity was not needed and shouldn't be adopted.
Michael Woods made a particularly impassioned case against a code of conduct:
Whomever convinced you to add the Code of Conduct was convincing you to give control over to a social justice initiative that has no interest in the kernel's core function or reason for existence.
Codes of conduct are tools used by the incompetent to wrest control away from the people who own the project, so they can feed on the corpse and wear the skin of the project as a fetish play.
Examples of these people trying to introduce codes of conduct, with commentary on the emotions and motivations driving CoC introduction:
- LLVM: http://voxday.blogspot.com/2018/05/the-costs-of-code-of-conduct.html
- PHP: http://voxday.blogspot.com/2016/01/initial-sjw-attack-defeated.html
- PHP 2: http://voxday.blogspot.com/2016/01/a-second-sjw-attack-on-php.html
- Ruby: http://voxday.blogspot.com/2016/01/more-sjw-attacks-in-tech.html
- Ruby 2: http://voxday.blogspot.com/2016/01/the-sjw-war-on-ruby-continues.html
- Node.js: http://voxday.blogspot.com/2017/08/how-sjws-react-to-defeat.html
- Awesome-Django: http://voxday.blogspot.com/2015/10/exposing-true-face-of-sjw.html
- Go: http://voxday.blogspot.com/2015/06/you-cant-run-you-cant-hide.html
Pavel Snajdr replied to Michael's argument by saying, "how about if we viewed the new Code of Conduct as about the same thing as BitKeeper was for the development process? It was not perfect, but was *something* for a start. And I believe that Linus will probably come back with a Git of CoC, or something in that fasion."
Meanwhile, Luke Kenneth Casson Leighton objected to the Code of Conduct perhaps even more forcefully than Michael, saying directly to Linus:
this is beginning to remind me of dr who films, the comedy film "the world's end", and various other b-movie horror shows where people were taken over through mind-control or replaced.
so i apologise, i'm going to stop pussy-footing around and ask HAVE YOU FUCKING LOST IT, GET YOUR HEAD OUT YOUR ARSE, STOP FEELING SORRY FOR YOURSELF AND GET BACK TO BEING AN ENGINEER, YOU ARE ON A CHEARRRRGEUUH YOU SORRY LITTLE PROGRAMMERRRRR
*cough*. enough NLP-esque shock tactics with a bit of comedy thrown in to take the sting out of it...allow me to return to rational insights.
(1) you apologised for your behaviour, and it's fantastic that you recognised that there was a problem and asked for help. however, you *may* be feeling a little guilty, and it's clearly knocked your confidence, and that unfortunately has allowed political correctness to "creep in" where we know it never, ever belongs: in engineering.
the next thing you know, the fucking guilt-ridden morons who want the words "master" and "slave" erased from the history books will be telling you that we have to change SPI's "MOSI" and "MISO" to...god...i dunno..."ROWI and RIWO" - "requestor" and "worker" or something incredibly stupid:
Requestor: "i'm awfully sorry, if you wouldn't mind, if it's not too much trouble mr worker, when you have the time and you're not on your union-mandated break, could you deal with this bit-change for me?"
(2) more and more people are raising the fact that the change was made without consultation. this *is* going to bite everyone. i strongly, strongly suggest reverting it: i made the point very clear that it wasn't the actual CoC that was the problem, it was that you, yourself, were not really obeying it (so nobody else could, either).
(3) let's look at what toxic documents named "codes of conduct" look like from an engineering perspective:
#define BEHAVIOUR_GOOD() ((~BEHAVIOUR_BAD) == 0) #define BEHAVIOUR_BAD BEHAVIOUR_SEXIST | BEHAVIOUR_RACIST | BEHAVIOUR_NAZI | BEHAVIOUR_UNPLEASANT | BEHAVIOUR_RELIGIOUS_EXTREMIST .... #define BEHAVIOUR_RELIGIOUS_EXTREMIST \ BEHAVIOUR_ANTI_CHRISTIAN \ BEHAVIOUR_ANTI_MUSLIM \ ... .... .... #define BEHAVIOUR_ANTI_MUSLIM 0x1 #define BEHAVIOUR_ANTI_CHRISTIAN 0x2 ... ... ... // oops fuck we're gonna run out of bits extremely quickly....do you see where that's going? do you get the point already? if an engineer proposed the above patch to create the toxic CoC document that insidiously crept in recently, you and pretty much everyone would think that the submitter had a fucking screw loose and needed psychiatric help.
these toxic documents do not have to spell it out, but they *imply* that there are (deep breath...) [insert list of racist names here] and their mothers too all trying to ATTACK the project, and we'd better make sure that they're all excluded, otherwise we're all in trouble, eh?
i apologise for using these words: if you are a decent human being you should by now be feeling physically sick to your stomach at having read that paragraph, that those words were even used...yet they're not actually *in* that toxic document, but they don't have to be: people are still thinking them. like the "don't think of a pink elephant" our subconscious mind cannot help by strip out the "don't".
bottom line: the *entire linux kernel project* has now been *completely poisoned* by that document.
put another way: an engineer would go, "wtf??" and would say "we don't need to fill every single bit in the bitfield and then invert it for god's sake! just say 'good behaviour is expected' and be done with it!!"
so why not say, instead of that absolute god-awful list, "everyone is welcome; everyone belongs". you see the difference? you see how simple and empowering that is? it's INVITING people to participate, and it's pretty obvious that if someone feels *UN*welcome, the rules have been broken and they can raise it as an issue. rather than absolutely terrifying and sickening absolutely everybody.
the analogy is the story of mother theresa being invited to an "anti-war" rally. she declined...and said, "if ever you hold a PEACE rally, i'd be delighted to attend".
so come on, linus: wake up, man. just because this is outside of your area of expertise does not mean that you have to let go of the reins. *get a grip*. use your engineering expertise, apply it to the problem, work with *EVERYONE* and work out an *ACCEPTABLE* solution.
This particular topic was more about everyone responding to Linus' announcement, than about discussing the issues among themselves. In general, some people were in favor of the new Code of Conduct, and some were opposed.
For myself, I hope Pavel Snajdr is right—that the Code of Conduct is the "BitKeeper" of this particular issue. The last time Linus took a break from kernel development, he came out with git, a transformative tool that completely changed the way people developed software all over the world.
But it may not be very realistic to expect Linus to pull something like that out of his butt in this case. This isn't just a technical issue. It's a political issue, with strong, uncompromising feelings on all sides of it—not to mention powerful entities with a vested financial interest in seeing Linux itself fall to ruin. If Linus returns to kernel development with anything like the "git" of community relations, maybe we should then ask him to take a longer break from kernel development and address the issues of race, poverty, global warming and the rise of fascism.
Dmitry Safonov wanted to implement a namespace for time information. The twisted and bizarre thing about virtual machines is that they get more virtual all the time. There's always some new element of the host system that can be given its own namespace and enter the realm of the virtual machine. But as that process rolls forward, virtual systems have to share aspects of themselves with other virtual systems and the host system itself—for example, the date and time.
Dmitry's idea is that users should be able to set the day and time on their virtual systems, without worrying about other systems being given the same day and time. This is actually useful, beyond the desire to live in the past or future. Being able to set the time in a container is apparently one of the crucial elements of being able to migrate containers from one physical host to another, as Dmitry pointed out in his post.
As he put it:
The kernel provides access to several clocks: CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME. Last two clocks are monotonous, but the start points for them are not defined and are different for each running system. When a container is migrated from one node to another, all clocks have to be restored into consistent states; in other words, they have to continue running from the same points where they have been dumped.
Dmitry's patch wasn't feature-complete. There were various questions still to consider. For example, how should a virtual machine interpret the time changing on the host hardware? Should the virtual time change by the same offset? Or continue unchanged? Should file creation and modification times reflect the virtual machine's time or the host machine's time?
Eric W. Biederman supported this project overall and liked the code in the patch, but he did feel that the patch could do more. He thought it was a little too lightweight. He wanted users to be able to set up new time namespaces at the drop of a hat, so they could test things like leap seconds before they actually occurred and see how their own projects' code worked under those various conditions.
To do that, he felt there should be a whole "struct timekeeper" data structure for each namespace. Then pointers to those structures could be passed around, and the times of virtual machines would be just as manipulable and useful as times on the host system.
In terms of timestamps for filesystems, however, Eric felt that it might be best to limit the feature set a little bit. If users could create files with timestamps in the past, it could introduce some nasty security problems. He felt it would be sufficient simply to "do what distributed filesystems do when dealing with hosts with different clocks".
The two went back and forth on the technical implementation details. At one point, Eric remarked, in defense of his preference:
My experience with namespaces is that if we don't get the advanced features working there is little to no interest from the core developers of the code, and the namespaces don't solve additional problems. Which makes the namespace a hard sell. Especially when it does not solve problems the developers of the subsystem have.
At one point, Thomas Gleixner came into the conversation to remind Eric that the time code needed to stay fast. Virtualization was good, he said, but "timekeeping_update() is already heavy and walking through a gazillion of namespaces will just make it horrible."
He reminded Eric and Dmitry that:
It's not only timekeeping, i.e. reading time, this is also affecting all timers which are armed from a namespace.
That gets really ugly because when you do settimeofday() or adjtimex() for a particular namespace, then you have to search for all armed timers of that namespace and adjust them.
The original posix timer code had the same issue because it mapped the clock realtime timers to the timer wheel so any setting of the clock caused a full walk of all armed timers, disarming, adjusting and requeing them. That's horrible not only performance wise, it's also a locking nightmare of all sorts.
Add time skew via NTP/PTP into the picture and you might have to adjust timers as well, because you need to guarantee that they are not expiring early.
So, there clearly are many nuances to consider. The discussion ended there, but this is a good example of the trouble with extending Linux to create virtual machines. It's almost never the case that a whole feature can be fully virtualized and isolated from the host system. Security concerns, speed concerns, and even code complexity and maintainability come into the picture. Even really elegant solutions can be shot down by, for example, the possibility of hostile users creating files with unnaturally old timestamps.
Note: if you're mentioned in this article and want to send a response, please send a message with your response text to ljeditor@linuxjournal.com, and we'll run it in the next Letters section and post it on the website as an addendum to the original article.
The views and opinions expressed in this article are those of the author and do not necessarily reflect those of Linux Journal.
Zack Brown is a tech journalist at Linux Journal and Linux Magazine, and is a former author of the "Kernel Traffic" weekly newsletter and the "Learn Plover" stenographic typing tutorials. He first installed Slackware Linux in 1993 on his 386 with 8 megs of RAM and had his mind permanently blown by the Open Source community. He is the inventor of the Crumble pure strategy board game, which you can make yourself with a few pieces of cardboard. He also enjoys writing fiction, attempting animation, reforming Labanotation, designing and sewing his own clothes, learning French and spending time with friends'n'family.
