Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Lemeowski writes "Time has been good to Linux and the kernel community, with the level of participation and volume of activity reaching unprecedented levels. But as core Linux kernel developers grow older, there's a very real concern about ensuring younger generations are getting involved. In this post, Open Access supporter Luis Ibanez shares some exciting stats about recent releases of the Linux kernel, but also warns that 'Maintaining the vitality of this large community does not happen spontaneously. On the contrary, it requires dedication and attention by community members on how to bring new contributors on board, and how to train them and integrate them alongside the well-established developers.'"

I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.

This. I've tinkered with the kernel, written device drivers, blah, but there's no way in hell I'd ever try to contribute upstream, because I know I'm not an experienced kernel hacker, and frankly I'm not sewn for the sort of macho abuse that dorks like to give each other.

There are other things I do as a hobby where I'm surrounded by people who are highly experienced, well-respected, but also excellent teachers - e.g. ham radio. There, I'm happy to do as much as I can for the community.

N.B. I'm not saying that I'd necessarily be good enough to contribute to the official kernel, merely that I wouldn't even try in that sort of environment.

there's no way in hell I'd ever try to contribute upstream, because I know I'm not an experienced kernel hacker, and frankly I'm not sewn for the sort of macho abuse that dorks like to give each other.

Sounds like a matter of perception. Linus yells at the people high up in the hierarchy because they are experienced and shouldn't be making dumb mistakes - right or wrong you aren't likely to get on the wrong end of that. As a newbie contributor any work you would do would go through a couple of levels of people vetting it for you. If you make dumb mistakes chances are the person who notices them will be a lot more gentle in pointing them out because dealing with newbies is part of the role in the hierarchy. No system is perfect, I'm sure there are some newbies who have received overly harsh responses, but that's going to be rare.

Yah, it sort of matters which subsystem you work on. Some of the maintainers are dicks others ignore people... Etc.. My dealings with Linus himself were a decade ago. Now everyone is pretty much one or two layers below him. So peoples experiences are often dependent on which subsystem they are working in.

Frankly, all my recent commits have been "bug" fixes, and these are often a PITA to get in because 1: You first get ignored, then you get shot down, then eventually someone picks up your fix. None of my rec

If someone wants to right to yell at me, he's going to have to pay me (well) for the privilege. I would have taken Steve Jobs' abuse, as long as he kept the paychecks coming. Some prick who expects me to VOLUNTEER for the honor of having him dress me down like a bitch? Not so much.

It's funny how different perspectives can be. If I wanted to contribute to the kernel and someone ended up being severely impolite, I'd find it weird and either reply or don't. On the other hand, if my boss was being abusive, I'd switch jobs ASAP. I guess what I'm trying to say is that I find random interpersonal abuse way less disturbing than workplace abuse, since in the latter case you're at a clear hierarchical disadvantage and actually depend on your boss to get your paycheck.

And, by the way, it's interesting that you say "some prick who expects me to VOLUNTEER for the honor of having him dress me down like a bitch? Not so much." while posting on/., where that kind of free verbal aggression seems to be mandatory.

The last several articles involving Linus involved, as I recall, him specifically telling people not to do something and then they did it anyway, or them making very obvious poor coding decisions. In which case, yes, they should be yelled at to get it through their thick skulls.

I have no interest in proving "myself" - I just want to contribute good code. If I don't contribute good code, that's fine - reject it and tell me what's wrong with it. I'll try again. You have no good reason to shout me down unless I'm causing you immediate harm. If I'm simply wrong about something, and you have the final say, what exactly motivates the aggression?

I'm a fairly competent mathematician. I've worked with people who are smarter than I could ever dream to be. My peers are occasionally mocking when I fuck up, and I can take a friendly jibe, but no senior has ever made an insulting, showboating remark to me - not even one to one, let alone in public. This macho culture is something I've only really seen professionally in engineering (software and mechanical).

It doesn't matter in the slightest how successful Linux is. That's not an excuse for complacency. In fact, if you look at the very topic of this Slashdot post, it's the worry that there's not enough fresh blood. Arguing that the problem must be with everyone else isn't going to get you that new talent, is it?

Well clearly you have never once 'been to' the LKML but instead built your opinion on the basis of stories-posted-on-slashdot.Otherwise you would know that the LKML receives around 400 mails per day, the vast majority of which are polite, friendly and helpful.
Compare that with the number of posts offensive enough to make a story on/.

Well clearly you have never once 'been to' the LKML but instead built your opinion on the basis of stories-posted-on-slashdot.Otherwise you would know that the LKML receives around 400 mails per day, the vast majority of which are polite, friendly and helpful.Compare that with the number of posts offensive enough to make a story on/.

I *have* posted bugs on LKML, and gotten responses. I have interacted with at least two high level developers, as well as Mr. Torvalds. The one time I got a reply (Len Brown, INTEL senior systems engineer) plus asked to download software to dump the rom from hardware, followed by an analysis and a change to the kernel (which I then applied, re-compiled and tested with reports. About 200,000 people were affected by that bug (and I got email from around the world). I've also gotten several very polite replies from Alan Cox and a few others. The trick is that you have to 1) know about computers, be able to describe the bug fully, what you have tried to fix the bug, and how it affects things. 2) be able to reply to questions / do more testing 3) re-compile a kernel with a fix and see if it fixes the bug. Most people can't do #3.

If someone makes a sexist, derogatory joke in the weekly programming meeting and someone is offended and complains, it's not a defense to say "well it was only one joke, in one meeting, from one person."

The problem is not the one joke. The problem is that the environment was conducive, accepting, and tolerant of the joke. Linus's abusive treatment of others is not only tolerated, but accepted, excused, and justified, both there and on other communities (like Slashdot, right now...) Because he's in a leadership position, it sets the example and tone for how others are treated...

The response to people saying "I'm not comfortable contributing" is not "stop being a baby." If it is, you don't actually care about getting people to contribute.

No, see, the thing is, your feelings are supposed to be your responsibility, not the group's. If you're 'offended' like that, to the point where you want to sue people and/or get that person's employer to fire him/modify his behavior for you, you are the one with the problem. These entitlement attitudes bred into the culture from political correctness confuse the issue and the definitions of these words for a lot of people. Young people today suffer from this a great deal more than the previous generations, as recent as the 1990s.

No, the phrase "I'm not comfortable" is newspeak for "I am a timid coward who wants others to limit the diversity around me to acceptable parameters". In this case, diversity of thought and expression. You don't have to agree with everything others said, and you're welcome to voice your displeasure, but if you 'feel uncomfortable' on a regular basis just because of what others said, the weakness is you, not them.

Yeah, I used to think like that. Then I worked out that being a dick to people around me is actually not OK. I get it, it's really easy to think like this when you're a straight white male. But it's just bullshit. Grow up and get over it.

Apparently it means that the kernel community is looking for more (younger) participants.

Funny how all the a-holes on this thread are posting A/C, eh? Besides that, every business school researcher who's looked at this issue has found that the environment the parent loves reduces productivity. It's the hazing culture that perpetuates it.

Yeah. Sometimes projects can wind up in a nightmarish situation in terms of getting new contributors, because the bar to contribution is perceived to be high (even if it might not be).

I used to be a contributor to a fairly large open source project - Overall it was good, but the leads could be downright pricks. They would often trash talk potential contributors, even ones that did show potential. (Sadly, this particular area had a lot of "wannabes" out for glory too...) - While their smacktalk would keep the "wannabes" at bay, it also drove away some exceptional talent.

I was always frustrated by some of these "lone wolf" developers that weren't upstreaming, until myself and a few contributors had a massive disagreement with the project leadership regarding an attempt they made to obtain dual-license commercial rights to a contribution. We started working on founding our own project, and we've found that many of those who I originally (mistakenly) perceived as "lone wolves" and not contributing because something was wrong with them were actually not contributing because there were so many things wrong with our former project and we had been drinking the kool-aid. Quite a few of them have proven to be spectacularly talented and excellent team players.

To be fair we are talking about one man who is the gate keeper for a kernel which has grew from a hobby project to major player in the operating system landscape. Just put yourself in his shoes for a minute. Your student project turned hobby now runs on/in everything from phones to supercomputers, refrigerators to robots and cars to space craft. It is quite an achievement and a large amount of responsibility. Most of his explosions happen when someone does (bad code/design) or says (git should use C++) some

I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.

You've managed to asses that he is 'a raging asshole', but now how to properly spell his name?

I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.

You've managed to asses that he is 'a raging asshole', but now how to properly spell his name?

vmlinux->vmlinuzLinus->Linuz

If the compressed version of Linus is a raging asshole, what the hell is the uncompressed version? Goatse?

After watching a few videos of "Linuz"... I can assure you that he's pretty harmless, at least in person. I think he puts on the aura of raging narcissist on purpose and if you think about it, the whole persona serves him and Linux well. So far the Kernel project hasn't been fragmented and the project has been extremely stable for many years. This is not the normal course of an open source project, especially one of this visibility. This is largely due to "Linuz" and his persona.

But this is not to say I think the kernel is in good hands with him at the wheel. I worry about succession should "Linuz" become unavailable (say he's hit by a bus to use his illustration about why you should use git). I worry that the succession battle would be bad for the Kernel and the transition from the dictator rule to something else would be bumpy. Linuz could fix that by starting to transition what he does to his trusted few, and publish a clear future succession plan. But the future is "Difficult to see. Always in motion is the future."

I have a theory that people who deal with computers as a career require at least a little bit of assholishness to be able to function in the field (I include myself in that stereotype). But maybe you could make that same argument about life in general...

I have contributed some bug reports and fixes to LKML and I have yet to encounter anything other than a terse but helpful and friendly nature amongst those that picked up my reports and directly communicated with me to fix the code. The only people who get reamed on LKML or get a middle finger are the ones that do egregiously foolish things and should know better. Linux is a massive project that spans thousands of cultures and subcultures in the meatspace department, and there is no time at all to address every error with compliment sandwiches and a facade of "bless your heart" pseudo-kindness.

"Show me the code" is the mantra. If your code is shit and you're new, you'll be politely pointed at a resource such as the coding style guide or KernelNewbies to correct it. If your code is shit and you manage a whole kernel subsystem, you can expect to be told "your code is shit and you know better!" by Linus directly, because....get this: you tried to feed shit code into the kernel (which hurts everyone else because they ALL have to maintain your code down the line) and you're high enough on the food chain that you know better.

If enough people think like you (and think you're better than Linus), your fork will quickly reach a critical mass. Then you can either hire someone to deal with Linus, or ignore him altogether and let his followers seek out your patches to pull the part they want..

(and if you think I'm being sarcastic - I'm not - this is pretty much how a lot of the major distros work)

I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.

Well, the other thing is, it works.

Linus is managing in a style similar to Steve Jobs, and it's getting stuff done, like Jobs did as wel

I can understand how working for a loud mouthed prick is a real downer. Thing is, there are a lot of LMPs in this industry. Far more asshat managers than civilized ones. Do you think Ballmer, Jobs, Ellison are/were any better? If you are seriously interested in this line of work, don't let the LMPs run your future. Make your career moves wisely, and with professionalism, and you'll do well no matter how much of a "raging asshole" you previously worked for.

Linus yells at experienced devs who should know better and it is a fairly uncommon occurance. Spend some time in the kernel mailing lists and you will see you are 100% incorrect.

I have even seen newbies try to take Linus to task and he was exceedingly polite to them, far more than they deserved. The one that comes to mind was the newbie complaining about GOTO's and trying to trumpet his terrible solution(it blew up the cache and corrupted the critical path) as things should be done.

I've worked on the kernel (and other low level stuff) professionally for ~10 years. I've had code submitted into the kernel. I've interacted with Linus directly, I've met him in person, etc.

Yes, on occasion he flies off the handle. It doesn't happen often, and when it does it's mostly at things that would drive many people nuts. I think he could deal with it a bit better sometimes, but most of the time it's not a big deal.

Generally when people get flamed it's not a new contributor, and it's for things that they've done wrong multiple times.

So for new people looking to contribute, go ahead. It's fun, and the quality of the code that you'll see is generally pretty high.

I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.

I've been in the Linux scene very early, and I've watched contributors come and go

The one thing that I've observed is that it's kinda generation gap

The older crop (age 40+) were the ones who like to take on challenges - and even when they have been shouted down, they still come back again and again, with better and better code implementation, to prove others wrong

The younger crop (age 35 or younger), on the other hand, can't stand people criticizing their code

Yay a linus-is-mean bandwagoneer.. Good, stay away. No one wants your simpering spineless entitled twatlike attitude. Whatever talent you have is lost when it's submerged beneath all that effeminate bitchiness.

However, if you have a modicum of self respect and like programming C you should give it a shot.. If your patches are good and you aren't a blowhard, linus will never yell at you. In fact, you probably won't even interact with him until you've been involved for a bunch of years. Newbs talk to peopl

I'm just saying that he's about par for the course if you work with teams that actually get things done instead of teams that just putz along

Bull. The best teams I've worked with are often composed of people that play nice with others. Sure tempers flare sometimes, but on the whole the people are reasonable. In fact that's part of the reason the teams are good - yelling and finger pointing are not very productive. It also turns people into stubborn defensive asses that play NIH. In a good team, even when somebody screws up, it's politely pointed out to them, even to the point of not directly blaming them. Good people know when they've screwed up, and work hard to fix it and make sure it doesn't happen again. If they don't do that, get rid of them. Want to vent? Go yell at your dog.

This semester, I am taking OS course at UMBC.Course is easy, material is easy. Hard part - figuring out how the fuck you should write Linux Kernel code.Why there are no good tutorials that on how to write basic kernel code, good guides on its structure (many book sold on Amazon are outdated)......there should be one, centralized place with all the useful materials for the beginners + it should be constantly updated.

Too bad it's not BSD though. Linux code is very often very obtuse and difficult to understand whereas a lot of BSD kernel code is comparatively straight forward. If I were to teach an OS class using source code I'd point students to BSD first (netbsd or openbsd at least, or even 4.2BSD).

THIS is how to get new people coding on Linux! When I tool my OS course at UMBC we wrote a file system, and a few other tiddly bits. But actually looking at or modifying Linux kernel code would have been awesome!

Now I'm not a kernel developer, but I suspect there's a lot of old stuff that's still extremely relevant. How much has the kernel really changed in the last eight years? Lots of bug fixes, a few major features, a couple things cut, and lots of new modular components added in. All mostly irrelevant to a newbie-level overview, and if you want to get your hands dirty you need to dig into the sort of cutting-edge details of one particular aspect that has no place in a "getting started" overview. There might

I know I've mentioned this before, but you need to consider the possibility that your software might be done.

Take TeX for example. The last stable release is 5 years old. It's done.

At some point even the OS kernel will switch from "active development" to "something people study". We studied the circuit diagrams for radio receivers, memory circuits, and even more complicated things like 8-bit ALUs. They're done. We weren't developing that stuff in school. We were just understanding it.

The Linux kernel will end up in a text book some day. People will want to understand it. Nobody will want to develop it. That's a good thing. It means that this phase of technology is approaching the done phase.

What's the next phase? If you're young that's where you should be looking.

The kernel is not like most software project though because of what it does. It provides an interface to hardware for other software. That other software might be done but as long as the hardware changes the kernel is never done.

You could argue that something like a scheduler might one day be done, but the rules change, memory is cheap in plentiful even on the smallest devices, it was a major constraint when Linus started Linux. Now its okay for your scheduler to use much more memory if that gets you to

The next phase is almost always to replace the technology or some portion thereof with something that does the same thing, but in a better or easier to use way.

With TeX, the logical next step is HTML/CSS typesetting. I'm pretty sure you could replicate most of the interesting parts of LaTeX in only a few thousand lines of JavaScript, assuming you had a browser that supports most of CSS3, but you'd also get lots of stuff that LaTeX can't handle.

Not really, because hardware isn't done. Operating systems keep evolving to keep up with the hardware. Also software isn't done, so operating systems keep evolving to keep up with newer paradigms in software. Linux is constantly changing, and not just to keep some old coders busy.

I would agree some utilities have a point where they will be "complete"./bin/cat perhaps, or/bin/yes.

However, the one thing that keeps the Linux kernel from being "done" is the security race. The kernel will never be "complete" because of today's and tomorrow's security risks. Right now, Web browser (and add-ons) are compromises. It could be in the future that physical compromise and armed robbery of data centers would be a major threat, so the kernel would have to be modified to keep as much data as p

TeX doesn't even have a useful GUI yet. It's not even 1/10th the way to "done".

It'll be "done" when you can hand it to a random person on the street and they can quickly and easily figure out how to use it to produce a complicated document. The only reason you think it's "done" is because you've pigeonholed it into a tiny niche.

Not at all. I've built and installed drivers that aren't part of the kernel source tree on several occasions. The entire driver stack has to be part of the kernel, by necessity, but not the drivers themselves.

IMO, the Linux kernel should pull all of the drivers out of the kernel source tree and into separate projects so that they can be separately maintained. The "everything in the kernel project" model means that every fix to every driver

The "everything in the kernel project" model means that every fix to every driver is dependent upon the upstream maintainers taking the changes. That's a maintenance nightmare.

How so? Getting drivers upstream isn't hard unless you're doing something really, really bonkers and or have to duplicate code for some reason. Spreading drivers to the winds would only make it harder to keep them up to date with the kernel, let alone finding them when you need them. Out of tree drivers are a huge pain to manage, som

It is just too damn big, hard and complex. Why would I want to learn the ins and outs of such a large codebase unless somebody is paying me to?

It is not like the old days when you could pick up a "... in a nutshell" book, start hacking up a driver, then get it accepted into the kernel. I don't want a three year unpaid intership while I get up to speed and gain respect in the comunity.

I'll spend my time working on my project on either a microcontroller (AVR, PIC...) or a bare-metal build on ARM.

I've thought about getting involved in some of the more established projects, what I found was a large codebase and not a lot of documentation. I just don't have the time required to play that much catchup so they get bug reports when I see them. If I ever manage to retire, I won't be bored cause then I'll have the time.

Perhaps a major part, or a major branch (experimental revisited?) needs to be handed over to the control of young blood. It'd be difficult for the old guard... young guys take risks and make more mistakes, but they bring energy and ideas. In any case an area under the control of a new generation MUST happen for a young Linux subculture to further develop, and considering the importance of community as a motivation this is overdue. The size, momentum and commercial interest in Linux will could make this

Don't get me wrong, I'd have hard time living without The Linux Foundation's products, but when this year I wanted to work for The Linux Foundation in Google Summer of Code, I gave up after reading their proposals. I wanted to learn some kernel development stuff and couldn't find a single suggestion related to that. Instead, there were some higher-level projects like OpenPrinting, which I personally find totally uninteresting.

I'm actually managing an OS course for graduate students, and it's heavily based on linux (userspace and kernelspace). We do a few exercices (like writing a kernel module that computes averages), but nothing fancy. I've always been looking to propose them some projects related to kernel dev, but as I'm not a kernel hacker myself, I have clearly no idea of what seems reasonable.

So here's the deal: If you are involved on some subsystem of the linux kernel and you have something you want to get coded that can be a first experience with kernel dev, and that can be done under about 100 hours (the length of a typical project), you contact me. I'll do as much as possible as a first step filtering so that you won't get spamed. It's a win-win situation: I have great projects for my students, you get free work. For this year, it's a bit short, because projects are from September until January, but next year is ok.

When Linux was first released, it was relatively easy to break into the IT field and get directly into programming with limited experience and resources. The fact that the Linux kernel was initially created by a 15 year old kid on a home computer says much about that. My saying so doesn't lessen Linus Torvald's genius in any way, but it does underscore how those opportunities to create haven't been extended to future 15 year olds in the same manner.

Or anyone of working age. When was the last time a company hired junior admins and other flunkies specifically for the purpose of training them up to a competent level of expertise? That was common in the 90s, and is almost non-existent 20 years later. The last two companies I've worked for flat out refuse to hire junior staff and train them. Many companies refuse to future proof their IT (ops and dev) staffing in any way. This has led to a huge gap in expertise.

The final issue that was birthed out of refusing to hire inexperienced staff is all of the certification programs that arose as a result of such parsimony. Am I the only one who thinks that being able to turn on a few services *doesn't* make someone a systems administrator? I'd be more concerned about their ability to write and update their own changes to services, and to the man pages, and submitting complete work back to the relevant project- but THAT isn't (generally) taught in the cert programs, even though that will make someone a better administrator and/or developer. This just weakens expectations in the field, and severely limits a self-selected candidate pool of future kernel programmers.

Why release a simple system, when you can bloat it with a zillion tweaks of dubious value and then charge money to keep the whole mess working?

I don't think it's really as malicious as that. The larger problem is that everyone has a slightly different definition of what makes a simple, stripped down system. You only want the features you want, I only want the features that I want. You want a rock-solid server; I want a responsive and feature-rich desktop system; my brother just wants to play video games. You can't do it all without a little bit of complexity.

And look at what happens when they try. Someone proposes a new window compositing system that will make development easier and performance more responsive, and people get all bent out of shape because it breaks the X11 spec.

Microsoft is a whole other ball of wax. Chronic mismanagement, perverse incentives to sabotage any product which might cannibalize the Windows/Office products, and an attempt to maintain backwards compatibility as much as possible, going back to DOS systems from a quarter century ago.

Feature-rich and stripped down are opposites. You want features to be available to you on a whim, learn to install new software.

You are missing the point. A stripped down system can still have a feature rich kernel. If I want a feature rich desktop then I need a kernel that has features that enable the sort of high performance UX I need.

Right down to a scheduler that's friendly to interactive user processes. But maybe that scheduler's not as optimal for what you were doing with your server, so now we want a tunable scheduler that can be adjusted towards either.

And maybe they go for the ka-ching because they have bills to pay, little savings to live off, and are trying to establish themselves so that they can continue that bill-paying thing. Don't be so bloody condescending.

There is also the fact that there is an attitude change. The "stone soup" of days past is gone, with only the old guard in place. The younger people want to hear the ka-ching sound when writing code, not the fact that they wrote something to scratch an itch.

Being a skilled Linux kernel hacker is a great career move, though. I routinely get interviewers contacting me for top-tier Linux kernel architect jobs when there's barely a suggestion in my resume that I could actually do that work. Demand far outstrips supply there, even compared to other senior positions.

If you want to attract new people, then you will have to bite the bullet and switch to a language that does RAII or a similar predictable resource management technique. Nobody in his right mind will write those mind-numbing goto constructs, when the compiler can do this. It doesn't have to be C++, it could be some modern form of C with classes or D.

There is a completely irrational hatred and fear of C++ among C kernel hackers. It's so steeped in the culture I'm not sure it can change (though a flux of young people would help). The funny thing is, when I've spent enough time with veteran kernel hackers to show exactly how RAII would work in their code, they were accepting that it actually works and would make life easier, but were still unwilling to change.

I suspect a big part of it is simply that so much of your day-to-day work habits as a good kerne

How wrong can one be? I *might* give you C (but with classes is really just C++), but why would you do that? C++ has its issues, but as a language to write a kernel in I'll take the issues and get the predictable performance in return. You simply cannot do garbage collection in a kernel and get predictable performance for interrupt routines, context switching, signal delivery and the like. C and C++ are very common Kernel languages and for very good reason, pointers. Folks hate them, misuse them, cast them

Really? My impression is that he very occasionally dishes out a ration of vitriol on one of the "upper management" who has insisted on doing something against the publicly established guidelines, usually despite repeated applications of more polite dissuasion. Of course some of the more polite stuff can still seem aggressive, but there's only so many ways you can say "you are wrong and your project will not be incorporated / your attempt to shift the blame will not be tolerated" while avoiding misundersta

He's been running this project for DECADES and it is successful, stable and very valuable. He's made many mistakes, paid the price for them and then corrected them. He is also heavily invested in this project both privately and professionally.

Then comes the flock of green horn newbies, with the ink still wet on their diplomas (if they graduated in the first place) who make predictable stupid mistakes over and over. The SAME predictable and stupid mistakes t

The problems with the Linux Kernel itself are fundamental and unfixable: too big, at a million lines, and not designed from the beginning for minimum trust of all the many components... all manner of malware has been written, some of which also appears to accomplish useful work, or corrupts things that do useful work, and it is time for a system that intrinsically distrusts any programs or drivers it is running to do the right things, and ensures that the system owner can retain control.

So Tanenbaum was correct. Monolithic kernels are the past, microkernels are the future.:-)