'It's really hard to find maintainers...' Linus Torvalds ponders the future of Linux Linux creator Linus Torvalds spoke about the challenge of finding future maintainers for the open-source kernel, at the Open Source Summit and Embedded Linux conference under way this week online. Torvalds does not do keynote talks these days, but he was willing to sit down with VMware's chief open source officer Dirk Hohndel …
If you think about all the instances of the Linux kernel operating right now - from phones and embedded devices via servers and network devices in data centres, through to high performance compute clusters, isn't the desktop operating system aspect (i.e. endpoint client) almost of measure zero? Nice to have but it hardly defines the project.
Is it not amazing that a self organised group of programmers managed this huge project?
Linux creator Linus Torvalds spoke about the challenge of finding future maintainers for the open-source operating system,
Seriously? People aren't queuing up to be told:
"SHUT THE **** UP!
"It's a bug alright -- in the kernel. How long have you been a maintainer? And you *still* haven't learnt the first rule of kernel maintenance?
And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously.
Fix your ******* 'compliance tool,' because it is obviously broken. And fix your approach to kernel programming."
I'm shocked, shocked, I tell you.
Linus' potty mouth notwithstanding, let's not forget that some of this shit is hard - my last tussle with the kernel was way back in the 2.mumble days where I had to write a couple of drivers for some hardware in my lab - my C chops were a lot better back then but even so, hacking on the kernel was not for the faint of heart (one bit of hardware was sorta-kinda supported, which made life a bit easier, but the other wasn't so I had to work from datasheets and whatnot and write everything from scratch) - still gives me nightmares.
You want documentation? Well, there's the code itself ... other than that, good luck!
I probably wouldn't even know where to start now.
There's also the 'some of this stuff is boring' aspect - whilst you'll probably have no shortage of people queuing up to work on the latest shiny shiny or the $ARCHITECTURE_DU_JOUR, there's no escaping the fact that the 'boring' stuff in the kernel will need occasional care and feeding as well, and that's not as sexy by half and people will be less inclined to do anything once the current maintainers have moved on[*]
[*] - I'm one of those developers who actually enjoys working on the 'boring' stuff. It's a dirty job, but someone's gotta do it ...
It's all just ones and zeroes. If it isn't a one then it's a zero. How hard can that be?
Getting the ones and zeroes is the easy bit ... it's putting them together in the right order that's the trick.
As the late, great Eric Morecambe once said: I'm playing all the right notes, just not necessarily in the right order ...
;-)
As the late, great Eric Morecambe once said: I'm playing all the right notes, just not necessarily in the right order ...
The following simple technique can be used to address that. Decide how big your program needs to be. If you get that right then the technique is absolutely guaranteed to produce the desired bug-free program.
Allocate a block of memory of the necessary size and initialize it to all zeroes. Then:
1. Execute it as a program. If it does what you want, then job done.
2. Otherwise, treat it as one single very wide multibyte binary number and increment it. (first time round 000...000b->000...001b, second time round 000...001b->000...010b etc)
3. Go to step 1
That's a very poor starting position. Functional programmes tend not to have all their bits set to zero. Start with it filled with random data. That way there is a "chance" it will work first time. In the unlikely event it doesn't you will hit one of the many possible solutions sooner than starting with all zeros..
That's a very poor starting position. Functional programmes tend not to have all their bits set to zero. Start with it filled with random data. That way there is a "chance" it will work first time. In the unlikely event it doesn't you will hit one of the many possible solutions sooner than starting with all zeros..
I guess that is true. 00 is quite often a NOOP instruction - it is on ARM, MIPS and Z80 anyway - so an all zeroes initial condition could be a valid, but very dull, program on those but probably not on anything else.
Best plan would be some sort of very complex quantum computer that could try all possible bit patterns simultaneously.
Best plan would be some sort of very complex quantum computer that could try all possible bit patterns simultaneously...... Smooth Newt
What about a best plan being some sort of very complex quantum computer that has already tried all possible bit patterns simultaneously, has processed all metadata and now shares the resultant deliberation on the ways forward to a global market fully reliant upon mass multi media presentation of current stealthy operating system utilities with extremely rare, attractive remote virtual facilities servering and servicing novel abilities.
A Simple Start for that Program to Realise the View and See that All of it is True, is to Treat it as True in a New Way of Doing Everything Differently and Better with SMARTR Partners rather than denying and doing vain battle against its obviously apparent existence and virtual presence. And share the news that it can no longer be denied from common knowledge.
The question then being ....... If everything is new, what would you like Programs and ProgramMING to Present you so Everything can move Forward in any Number of Novel Noble Directions Equipped with All of the Right Means and Memes?
Or would you prefer and defer all those sorts of almighty decisions to Programs and ProgramMING which Instruct and Advise Earthly Assets in the Secret Levers of Almighty Command and Immaculate Self Control which deliver Unassailable Lead Events ..... Mega Metadata Beta 0Days?
Nuclear Armageddon Morphs into NEUKlearer HyperRadioProACTive IT Operations which are Terribly Silent and Much More Deadly in Deployment than ever was Discovered Underground Testing?!.
"What about a best plan being some sort of very complex quantum computer that has already tried all possible bit patterns simultaneously, has processed all metadata"
Such a hypothetical machine would, by definition, know everything that there was to know. Gut feeling is that it would probably immediately suicide out of extreme boredom, just to find out what (if anything) was on the other side.
Linus' potty mouth notwithstanding, let's not forget that some of this shit is hard
Some of what my team do is hard too, but if someone spoke to a member of my team in the manner described by the person to whom you responded, I would take a dim enough view to invite them to a non-discretionary meeting to adjust their attitude.
People do their best work when they're supported by those above them in a hierarchy, and where mistakes are learned from rather than punished. Every shit boss I ever had or have ever seen has had the same poor attitude to 'subordinates' as described by the OP. They all had their "reasons" and they all had excuses, and while Linus is undoubtedly smarter than most crap bosses, he's still got a crap boss attitude.
That he has achieved a lot is beyond question. Could he have achieved more? Maybe.
In his book "Just for Fun" he says:
"I don’t proactively delegate as much as I wait for people to come forward and volunteer to take over things... I try to manage by not making decisions and letting things occur naturally. That’s when you get the best results.”
Also on being a manager:
"...while my Linux management style, such as it is, was earning high marks in the press, I was an undeniable failure during my brief stint as a manager at Transmeta. At one point, it was decided that I should manage a team of developers. I flopped. As anyone knows I'm totally disorganized. I had trouble managing the weekly progress meetings, the performance reviews, the action items. After three months it became obvious my management style wasn't doing anything to help Transmeta, despite the praise I was getting from journalists for the way I was running Linux...."
My take is that likes to be an engineer or gatekeeper more than a boss.
What did anyone with a clue expect?
A Corporation is almost always an oligarchy mixed with a plutocracy, usually with at least a hint of gerontocracy.
The Linux kernel developers are as pure a meritocracy as we have on this dampish rock.
People like Linus are wasted in the traditional management role. I've been saying for decades that in this day and age, where Technology is so important, corporations should have separate Management and Technical tracks for advancement to more senior positions. Management takes care of management, and techs take care of the increasingly more complex technical side. Occasionally, but very, very rarely you can find someone who is both capable and has the capacity (and competency!) to wear both hats.
I don't expect traditional management to grok this in my lifetime, because quite frankly they aren't equipped to understand the concept.
What sport do you and your team play?
Writing software for HF Algorithmic trading for a bank you have heard of, mostly. There's quite a lot of money on the line so every lesson is expensive, but regardless of the cost of a mistake, if you punish it instead of learning from it you're much more likely to have someone repeat it.
If the person that screwed up is around to tell the story then everyone joining the team learns to avoid the error. Our team is all in the one boat - if we crash into the rocks everyone goes under but if we make it to port then we all get shore leave.
Or are they a team as in horses?
No, but they are led by a donkey.
People do their best work when they're supported by those above them in a hierarchy
Indeed. But the problem there is the hierarchical structure. In an effective collaborative environment, one person can have a good old rant about what someone else has done, and as there's good peer relationships, the problem gets resolved and everyone moves on to the next challenge.
It's a (long) while since I even looked at the kernel dev process, but despite an initial appearance from the outside of it being a pyramid with Linus at the top, that wasn't how it worked.
Though quite how systemd got its claws in remains.a mystery to me. Unless RedHat have gone to the dark side......
"Though quite how systemd got its claws in remains.a mystery to me."
Let's be perfectly clear here ... we are talking about the kernel. The systemd cancer is not now, and never will be, a part of the kernel. There is absolutely no need to run the systemd cancer on a Linux system, not now and not into the future.
"Unless RedHat have gone to the dark side......"
Well, yes. They have ... just how long was your last nap, anyway?
I seriously doubt the folks who will take over after Linus gets hit by a bus will be in any hurry to include anything anything to do with the systemd cancer in the kernel. Nothing that it does belongs in there. There are many reasons why init is separate from the kernel, and nothing they can add to the systemd cancer will ever change that.
With that said, I strongly suggest that anybody already using Linux and GNU FOSS solutions also look into the BSDs. All it will cost you is a little time ... and options are always good.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
