Aging Linux Kernel Community Is Looking For Younger Participants 332
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.'"
Well, I'll tell you why I'm not interested.. (Score:5, Insightful)
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.
Re:Well, I'll tell you why I'm not interested.. (Score:4, Insightful)
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.
Re:Well, I'll tell you why I'm not interested.. (Score:5, Informative)
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.
Re:Well, I'll tell you why I'm not interested.. (Score:5, Informative)
I've been working on the Linux kernel for 10 years with numerous commits upstream, and I've never communicated with Linus.
Re: (Score:3)
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
Re:Well, I'll tell you why I'm not interested.. (Score:4, Interesting)
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.
Re:Well, I'll tell you why I'm not interested.. (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re:Well, I'll tell you why I'm not interested.. (Score:5, Interesting)
And that ^^ is exactly the kind of "alpha male" talk I mean.
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?
Re:Well, I'll tell you why I'm not interested.. (Score:5, Insightful)
in that sort of environment.
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
Re:Well, I'll tell you why I'm not interested.. (Score:5, Interesting)
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.
"environment" (Score:5, Insightful)
Well clearly you do not understand what the word "environment" means.
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.
Re:"environment" (Score:4, Insightful)
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.
Re:"environment" (Score:4, Insightful)
congrats on proving my point perfectly (Score:3)
No, see, the thing is, your feelings are supposed to be your responsibility, not the group's.
It is, at a minimum, the group's responsibility if they are community of VOLUNTEERS are trying to attract new members, to not be a bunch of assholes to each other.
Your extremely hostile, nasty, aggressive, ignorant, threatened response perfectly demonstrates the issues we're talking about. Also: stop narcissistically blaming everyone around you for how they react to the way you act towards them.
Re:"environment" (Score:4, Insightful)
Well clearly you do not understand what the word "problem" means
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.
Re:Well, I'll tell you why I'm not interested.. (Score:5, Interesting)
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.
Re: (Score:3)
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
Re:Well, I'll tell you why I'm not interested.. (Score:5, Funny)
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?
OP responding.. (Score:3, Funny)
*assess. Bazinga.
Re: (Score:2)
Also, not.
Re: (Score:2)
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->vmlinuz
Linus->Linuz
If the compressed version of Linus is a raging asshole, what the hell is the uncompressed version? Goatse?
Re: (Score:2)
Re:Well, I'll tell you why I'm not interested.. (Score:5, Interesting)
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."
Re: (Score:3)
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...
Re:Well, I'll tell you why I'm not interested.. (Score:5, Informative)
"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.
Re:Well, I'll tell you why I'm not interested.. (Score:4, Informative)
If this is what people think of upstream kernel maintaining, they should probably not troll anonymously.
This is about as far from truth as it is from reality. The man is abrasive, yes, but if you think he's just going to come after you then the problem is absolutely your own perception and not Linus.
Re: (Score:3)
because I've seen how much of a raging asshole Linuz can be.
So, fork it and run your own fork.
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)
Re: (Score:3)
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
Re: (Score:2)
I've seen how much of a raging asshole Linuz can be.
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.
Re:Well, I'll tell you why I'm not interested.. (Score:4, Informative)
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.
issue is overblown (Score:4, Interesting)
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.
It's a generation gap (Score:3, Insightful)
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
They seem to think that since it's their code an
Re: (Score:3)
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
Re:Well, I'll tell you why I'm not interested.. (Score:4, Interesting)
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.
Re: (Score:2)
[The kernel is] somewhat of a wall-garden amongst the dev community
Yeah, that's really a problem. Now if only we could fork the whol-- oh, wait.
Don't worry (Score:2, Insightful)
Really don't worry. It is commercial enough and if the community just winds down, the companies will just staff the kernel developer ranks,
Hope is not a plan. (Score:2)
Really don't worry. It is commercial enough and if the community just winds down, the companies will just staff the kernel developer ranks.
Which companies exactly? --- and who gets to make the final decisions about the evolution of the kernel and Linux as a whole?
Re: (Score:2)
Get on my Lawn (Score:5, Funny)
Get on my Lawn!
What's it pay? (Score:2, Funny)
Benies? Dental? Vaction days? Sick days? Comp time or overtime? Weekends off? All national holidays?
Re: (Score:2)
The benies for being a volunteer are great - all the vacation you want, and you get paid triple-overtime for any work in excess of twenty minutes a week.
As someone who is taking OS course (Score:5, Insightful)
This semester, I am taking OS course at UMBC. ......there should be one, centralized place with all the useful materials for the beginners + it should be constantly updated.
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)
Re: (Score:2)
At least it's not BSD.
Seriously, though, mainstream OS implementation is 10% OS theory and 90% careful engineering. So your course will be useful, but it won't be nearly sufficient.
Re: (Score:2)
At least it's not BSD.
Seriously, though, mainstream OS implementation is 10% OS theory and 90% careful engineering. So your course will be useful, but it won't be nearly sufficient.
You are aware of that the BSDs are carefully engineered, well documented, etc?
Unlike GNU and Linux, which rather have grown.
Re: (Score:3, Funny)
Flame war! Flame war! Flame war!
Re: (Score:2)
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).
Re: (Score:2)
Why do you think that's the case (honest curiosity - no intent to start a flame war)?
Re: (Score:2)
For me it was true, but that may also be due to the particular portions of code I was looking at.
Re: (Score:2)
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).
And BSD is obviously a particularly good example for networking code [kohala.com].
Re:As someone who is taking OS course (Score:5, Informative)
There is: http://kernelnewbies.org/ [kernelnewbies.org]
Re: (Score:2)
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!
Re: (Score:2)
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
College Outreach (Score:5, Funny)
Perhaps a campus tour where the senior kernel devs can personally tell prospective developers that they are retarded and kick them in the balls.
Consider the possibility it might be done (Score:3, Interesting)
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.
Re:Consider the possibility it might be done (Score:5, Insightful)
I know I've mentioned this before, but you need to consider the possibility that your software might be done.
Considered and considered stupid, because suggested in the context of operating systems. Operating systems are only done when hardware is 'done', which is unlikely to happen any time soon IMO.
Re: (Score:2)
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
Re: (Score:3)
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.
With Linux as a whole, the logical next step is to repeatedly
Re: (Score:2)
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.
Re: (Score:2)
We studied the circuit diagrams for radio receivers ... They're done.
Really? I wish you'd told me that before I started my latest design. BTW, what's in your cell phone or WiFi?
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:3)
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
My reason for not getting involved. (Score:5, Interesting)
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.
Re: (Score:2)
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.
Its a trap!!! (Score:5, Funny)
Netcraft Has Confirmed: Linux is old. (Score:2)
Younger kernel devs? (Score:2)
If they get a lot of younger kernel devs, do we stand a chance of seeing the kernel equivalent of Unity?
youth subculture - we need it (Score:2)
Judging by GSoC, perhaps they deserve it? (Score:2)
Propose projects on which newbies can start (Score:5, Insightful)
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.
The real problem is in not hiring junior anybody (Score:5, Insightful)
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.
Re:The real problem is in not hiring junior anybod (Score:5, Informative)
The fact that the Linux kernel was initially created by a 15 year old kid on a home computer says much about that.
Linus Torvalds was born in 1969. The Linux Kernel project began in 1991. He was not 15.
Re:Not just young folk... (Score:5, Informative)
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.
Re: (Score:2)
In which case, *BSD is the answer to your prayers. You only get the featues you actually ask for, and once you have got them, they stay got!
Re:Not just young folk... (Score:4, Insightful)
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 the complexity begins its lift off.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
The younger people want to hear the ka-ching sound when writing code, not the fact that they wrote something to scratch an itch.
Right, back in the 90's nobody even thought of making a buck off of writing code.
Re: (Score:2)
It seems like most young programmers are way more interested in getting paid.
FTFY.
Welcome to the Casino Economy - if it ain't making the House richer, it ain't worth paying anyone to do.
Re: (Score:2)
Kids today... Geez
Re: (Score:2)
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
Hurd?
Re: (Score:2)
Yeah, I understand that Hurd is going to be big and professional, unlike Linux [google.com].
Maybe something with a microkernel architecture (Score:2)
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
Maybe something with a microkernel architecture rather than a monolithic kernel? :-)
Re: (Score:2)
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
"It works great! Throw it out and start again!" Your idea is bad, and you should feel bad.
His idea is pretty much like the idea that Linus had many years ago.
Re: (Score:3)
He's said he would have probably contributed to BSD if they hadn't been tied up in court with AT&T over copyright issues at the time.
Re: (Score:2)
No, no, no.. He was saying HE could do it better.
Which is still a bad idea, and HE should feel bad..
Re: (Score:2)
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
Re: (Score:2)
It doesn't have to be C++
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
Re: (Score:2)
You're pulling a Linus - but without the creds.
Re: (Score:2)
written in a language 20 years beyond chic
No, you'd be coding in C.
Re: (Score:2)
you don't understand the value of C or C++
Ask Linus what he thinks of using C++ in the kernel.
Re: (Score:2)
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
Re: (Score:3)
In fairness, look at it from Linus' perspective.
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
Re: (Score:2)
Re: (Score:2)
And thus you prove the GP's point.
Re: (Score:2)
See OP's step 1.
So Tanenbaum was correct ... (Score:2)
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. :-)
Re: (Score:2)
But the code should be enough documentation right?
You mean you want *comments* in the code too? Newbies...
Sarcasm aside... You newbies learn from this. DOCUMENT your projects. Do it FIRST because it saves you a lot of time when you are developing, and you will never have time to do it later.