Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
A Linux kernel organization?

By pulsar in Technology
Sun Dec 24, 2000 at 03:37:58 PM EST
Tags: Software (all tags)
Software

With all the talk about forking the kernel here, there, everywhere would it not make sense to have an organization with the sole purpose of developing the kernel? No offence to Linus, Alan, etc. but the only people who are allowed to code for the kernel and actually get that code into a releases are those who they feel are elite.


Another problem with the current development is everything moves at the speed of Linus.. (again, no offence meant) IMO the best thing for the whole community would be to setup a non-profit org (like Debian) that has the sole purpose of kernel development/design.

One of the biggest problems I've had with Linux development is support for non-x86 platforms. I am a Alpha user and developer. I use Alphas all day long, every day. Getting things fixed for non-x86 platforms is a lot harder then most people realize. I cannot tell you how many patches, that fix major fatal errors, I've seen rejected because the problem couldn't be produced on x86 systems and hence "there is no problem."

Another advantage to setting up a org is that there could be commercial backing which means there could be (more) full time (read paid) kernel hackers.

Also having a org responsible for Linux would mean Linux coudl finally get offical UNIX(TM) branding - if your into that sort of thing.

There are several non-profit orgs out there that work. The two largest I can think of are FSF and Debian

What do other K5 readers think? Could this be done without upsetting Linus and Alan?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
I think an org for kernel development is a:
o Good idea 48%
o Bad idea 32%
o don't care 16%
o huh? 2%

Votes: 85
Results | Other Polls

Related Links
o FSF
o Debian
o Also by pulsar


Display: Sort:
A Linux kernel organization? | 24 comments (23 topical, 1 editorial, 0 hidden)
yippie (3.50 / 6) (#1)
by 31: on Sat Dec 23, 2000 at 04:15:02 PM EST

tyrrany of an organization vs. tyranny of linus/friends. Do you want code put in the kernel that isn't up to snuff? I know I don't, and I think having a commercial backer decide what goes into the kernel is a bad bad answer.

And beyond even that, this just sounds like whining of someone who didn't get their stuff in the kernel (I got that impression skimming it, before I looked back for the work 'rejected'). Well, tough. Do you think a commercial backer woulda been nicer to you, getting a patch on a system with a very small share of users?

-Patrick
Not quite... (4.00 / 3) (#2)
by pulsar on Sat Dec 23, 2000 at 04:23:02 PM EST

I haven't had anything reject for a LONG time, this is not "whining of someone who didn't get their stuff in the kernel." I'm just really tired of the way both Linus and Alan treat non-x86 platforms. Go back and read what I wrote.

[ Parent ]
So what is it then? (3.25 / 4) (#4)
by vastor on Sat Dec 23, 2000 at 05:22:29 PM EST

So if you haven't had anything rejected for a long time, maybe it is no longer an issue?

Besides, there is nothing stopping companies sponsoring kernel developers now, you don't need an organisation just to take many from corps and to dish it out to developers - why create a middleman where none is needed (the only benefit I could see to it is so that a company that did want something improved/whatever would need to know who is working on it to direct funds to).

On the other hand, you could start up an organisation yourself and fork the kernel regardless of what Linus etc think. Linux development seems to be going along at decent rate to me, switching it to an organisation just creates overhead for a system that is already working quite well IMO.

If your patches aren't getting rejected, what is it about how the non-x86 platforms are treated that is causing you bother?


[ Parent ]
It's... (3.75 / 4) (#7)
by pulsar on Sat Dec 23, 2000 at 05:42:09 PM EST

So if you haven't had anything rejected for a long time, maybe it is no longer an issue?
Ah but other, and more import, patches have been rejected. There are people who do a LOT more kernel hacking that make good (and needed) patches to the kernel. I constantly (read: on a weekly/monthly basis) see needed patches get rejected. These patches (as-is untouched) usually end up in the kernel, but not after a long fight about it that lasts 3 - 4 releases.
Besides, there is nothing stopping companies sponsoring kernel developers now, you don't need an organisation just to take many from corps and to dish it out to developers - why create a middleman where none is needed (the only benefit I could see to it is so that a company that did want something improved/whatever would need to know who is working on it to direct funds to).
Correct and I actually meant that as hardware and money dontations rather then flat out backing (my bad).
On the other hand, you could start up an organisation yourself and fork the kernel regardless of what Linus etc think. Linux development seems to be going along at decent rate to me, switching it to an organisation just creates overhead for a system that is already working quite well IMO.
Yes I could, but I don't want to. I don't want to fight Linus and the majority of the community (who most of follow what Linus says).
If your patches aren't getting rejected, what is it about how the non-x86 platforms are treated that is causing you bother?
It's that needed fixes don't get put into the kernel tree. In example: most of the kernels between 2.2.0 and 2.2.9 would not work at all on the majority of Alphas. Also between 2.2.0 and 2.2.13 wouldn't work on EV4 Alphas (needed fix got left out). I typically see every 2 - 3 kernel releases won't work at all on Alphas without outside patching. In nearly all of these cases it was because the patch was ignored, for who knows why. It usually isn't until one of the elite people say "xxx is broken" that is gets fixed (usually using the patch provided as-is). I've seen Alan Cox say, if not once 100's of times, he doesn't care because it isn't his problem. There are only about 4 people who do real (IMO) kernel hacking for Alpha (I'm not one of those by a long shot) of those 4 people, only about 1 of them gets listened to.

[ Parent ]
re: It's (4.00 / 1) (#13)
by 31: on Sat Dec 23, 2000 at 07:46:52 PM EST

well, if the head people don't care about what's going wrong with alphas, they should be just as unconcerned if you fork from them (at least long enough to get recognized)... if you got the 4 major alpha hackers (which just sounds much cooler than x86 hacker) to head it, with the one they listen to handing the diffs over to cox/torvolds, things should be good...
And if they do get upset, or think you're trying to start a fight, I think that's a good sign that it's time to leave linux alone, and go help the bsd people.

(me trying to make up for bitchy earlier post)

-Patrick
[ Parent ]
Well... (4.00 / 1) (#14)
by pulsar on Sat Dec 23, 2000 at 08:10:12 PM EST

well, if the head people don't care about what's going wrong with alphas, they should be just as unconcerned if you fork from them (at least long enough to get recognized)... if you got the 4 major alpha hackers (which just sounds much cooler than x86 hacker) to head it, with the one they listen to handing the diffs over to cox/torvolds, things should be good... And if they do get upset, or think you're trying to start a fight, I think that's a good sign that it's time to leave linux alone, and go help the bsd people.
This very thing was discussed between myself and a few others. I didn't want to fork. I really wish things were different. If they fight, then it's time for a fork and time for Linus/Alan/whoever to go away. It would be so much nicer if we could all just get along! I don't speak for those said hackers, but I hope they are listening...
(me trying to make up for bitchy earlier post)
hehehe :)

[ Parent ]
Same on PowerPC (4.33 / 3) (#23)
by Otter on Mon Dec 25, 2000 at 05:46:37 PM EST

The top PowerPC developers have exactly the same complaint. My impression is that this is definitely a valid concern.

[ Parent ]
Alpha/other non-x86 Platforms (3.66 / 3) (#3)
by djpotter on Sat Dec 23, 2000 at 04:43:37 PM EST

Actually, this is a trend that I see continuing. Of course, please correct me if I'm wrong. :)

Seriously, since Red Hat dropped support for Sparc (right?) with Red Hat 7, and Alpha users are somewhat ... scarce ... (prepares for deluge) - I can see where this could be a problem for Alpha guys. Or Mac guys with Linux PowerPC.

So - I'll admit, I'm an x86 user. I'm not adverse to learning something new, or examining 'why is this cool.'

If we can get more interest behind the Alpha, other platforms, perhaps the kernel code could be more on-track for all of us?

Or I could be just insane and uninformed. :)

DJP


"Anyone remotely interesting is somehow mad." - Dr. Who
Re: Alpha/other non-x86 Platforms (4.00 / 1) (#9)
by pulsar on Sat Dec 23, 2000 at 05:57:31 PM EST

Actually, this is a trend that I see continuing. Of course, please correct me if I'm wrong. :)

No, it's gotten better over the last 2 years, but it's by no means where it should be.

Seriously, since Red Hat dropped support for Sparc (right?) with Red Hat 7, and Alpha users are somewhat ... scarce ... (prepares for deluge) - I can see where this could be a problem for Alpha guys. Or Mac guys with Linux PowerPC.

Actually AFAIK they just didn't release RH7 SPARC, it was developed but they just didn't release it. This had no effect on the rawhide stuff, just the 7.0 release. Supposedly (again AFAIK) they will continue support with 7.1

So - I'll admit, I'm an x86 user. I'm not adverse to learning something new, or examining 'why is this cool.'

I didn't base everything on that, I was mostly talking about fixes that allow the kernel to actually boot! (see some of my other posts in this article). If we can get more interest behind the Alpha, other platforms, perhaps the kernel code could be more on-track for all of us?

Or if Linus, Alan, etc. would just accept patches that are good and usually end up in there eventually (after 2 or 3 more kernel releases). Or I could be just insane and uninformed. :)

No comment. ;-)

[ Parent ]
Why an organization? (3.71 / 7) (#5)
by Miniluv on Sat Dec 23, 2000 at 05:22:50 PM EST

Why not just fork the damn thing yourself? If you, or people you know, can write patches which fix the problem on the alpha, the GPL allows you to do so as long as you follow it's terms. Not everything has to be incorporated into the "main" kernel branch, and honestly does everything belong there?

This is something that's been bugging me for a while, why do I have to answer S/390 questions when selecting kernel options if I'm on an x86? Why should Sparc users be presented with x86 options and so forth? Why not just fork it for each platform and then optimize for platforms on the internals side and just have one standardized interface TO the kernel?

Maybe I'm missing something here, but I don't see that this would be such a damn hard thing to do, nor do I see what damage it would do to the community as a whole. Open source, or Free Software, is all about survival of the best code and competition along with collaboration right? The big iron guys have been bitching that linux doesn't scale well enough, but nobody is willing to fork it for fear of community backlash. I just don't see why that backlash has to happen. If IBM wants to write kernel patches that Linus doesn't like because it means linux won't run as well on a 386 with 8 megs of ram, why can't IBM just write the damn patches and make their revised kernel source freely available as either patches or a unified tree of code.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

Why? (3.75 / 4) (#8)
by pulsar on Sat Dec 23, 2000 at 05:50:24 PM EST

Why not just fork the damn thing yourself? If you, or people you know, can write patches which fix the problem on the alpha, the GPL allows you to do so as long as you follow it's terms. Not everything has to be incorporated into the "main" kernel branch, and honestly does everything belong there?

Why is going to use a forked kernel by Mr. so-and-so? Your right not everything needs to be in the upstream source tree, but things that allow the kernel to actually boot or compire are needed!

This is something that's been bugging me for a while, why do I have to answer S/390 questions when selecting kernel options if I'm on an x86? Why should Sparc users be presented with x86 options and so forth? Why not just fork it for each platform and then optimize for platforms on the internals side and just have one standardized interface TO the kernel?

For the most part you don't get presented these things... When was the last time you built a kernel? I do it on a weekly basis and rarely see things like that.

Maybe I'm missing something here, but I don't see that this would be such a damn hard thing to do, nor do I see what damage it would do to the community as a whole. Open source, or Free Software, is all about survival of the best code and competition along with collaboration right?

In some cases yes, but why can't we get needed fixes in there?

The big iron guys have been bitching that linux doesn't scale well enough, but nobody is willing to fork it for fear of community backlash. I just don't see why that backlash has to happen. If IBM wants to write kernel patches that Linus doesn't like because it means linux won't run as well on a 386 with 8 megs of ram, why can't IBM just write the damn patches and make their revised kernel source freely available as either patches or a unified tree of code.

If you fork the kernel, you are going to end up with duplicated efforts and incompatabilities. I don't want a fork, they are usually messy.

[ Parent ]
Responses (4.00 / 2) (#10)
by Miniluv on Sat Dec 23, 2000 at 06:06:45 PM EST

Why is going to use a forked kernel by Mr. so-and-so? Your right not everything needs to be in the upstream source tree, but things that allow the kernel to actually boot or compire are needed!
What I'm saying is that we don't need to submit to the main tree, if instead we maintain a separate tree for a given project/platform/etc. If I'm an Alpha user complaining about alpha support in linux, and I see a project claiming to have fixed nagging issues with the linux kernel that I can drop in seamlessly, or even with some small effort, and improve my operating environment I'll give it a try. Sure I'm not gonna put it into my enterprise network's most crucial server untested, but I'll certainly test it. Linux is only as good as the reputation of it's developers, same as any other project. Asking this is the same as asking why I should use OpenBSD, NetBSD or Windows. Reputations are created through quality work, not just existing. Linus had no reputation before the initial release of the linux kernel, and the community was unknown until the product reached a certain level of quality and people began using it as more than an experimenting environment.

For the most part you don't get presented these things... When was the last time you built a kernel? I do it on a weekly basis and rarely see things like that.
You're right, my statement was a bit disingenous, if you make a standard config it's normally one question per specific platform and if you answer that you don't need any support you see nothing further. The point still stands that we have highly complex configuration utilities to maintain this incredible cross-platform proliferation. I don't think this is necessarily the best method, and it could be improved upon if someone would take the lead.

In some cases yes, but why can't we get needed fixes in there?
Has it not been made abundantly clear by Linus/Alan/et al. that this is the way it's going to continue to be? This is their perogative as leaders of the project, and you will be subject to it for as long as you continue to use their work. Perhaps you can pressure some of these fixes into place by maintaining a sucessful and stable fork for some platform until they recognize that the code is solid, it does work and there is a demand for it.

If you fork the kernel, you are going to end up with duplicated efforts and incompatabilities. I don't want a fork, they are usually messy.
Yes, there will be duplicated effort. That is an unavoidable fact. There is already plenty of duplicated effort out there in terms of overall projects directed at specific problems. Sometimes it's unavoidable though, and this seems to be one of those situations.

Incompatabilities are another thing though. Why must there be incompatabilities if the fork is mainly directed at bug fixes? Is there some lack of documentation of the linux kernel that would prevent parallel developement within a constant interface? Again, am I missing something here that requires there be incompatabilities?

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

Re: Responses (3.50 / 4) (#11)
by pulsar on Sat Dec 23, 2000 at 06:29:10 PM EST

What I'm saying is that we don't need to submit to the main tree, if instead we maintain a separate tree for a given project/platform/etc. If I'm an Alpha user complaining about alpha support in linux, and I see a project claiming to have fixed nagging issues with the linux kernel that I can drop in seamlessly, or even with some small effort, and improve my operating environment I'll give it a try. Sure I'm not gonna put it into my enterprise network's most crucial server untested, but I'll certainly test it. Linux is only as good as the reputation of it's developers, same as any other project. Asking this is the same as asking why I should use OpenBSD, NetBSD or Windows. Reputations are created through quality work, not just existing. Linus had no reputation before the initial release of the linux kernel, and the community was unknown until the product reached a certain level of quality and people began using it as more than an experimenting environment.
How are you going to keep all these seperate trees in sync? I'm not talking about reputations or letting anyone submit code into the kernel, I'm just talking about getting needed fixes in there. No one wants to have 6 differerent kenrel sources. From a distro point of view it would be a nightmare!
Has it not been made abundantly clear by Linus/Alan/et al. that this is the way it's going to continue to be? This is their perogative as leaders of the project, and you will be subject to it for as long as you continue to use their work. Perhaps you can pressure some of these fixes into place by maintaining a sucessful and stable fork for some platform until they recognize that the code is solid, it does work and there is a demand for it.
I guess it comes down to: I'll believe it when I see it. Linus has several Alphas, all of them sitting in his garage. One of them is an AlphaServer DS20 for crying out loud!
Incompatabilities are another thing though. Why must there be incompatabilities if the fork is mainly directed at bug fixes? Is there some lack of documentation of the linux kernel that would prevent parallel developement within a constant interface? Again, am I missing something here that requires there be incompatabilities?
Ok let's just say there was a fork right now that only works on bug fixes for [insert your favorite platform]. How do you get these fixes in the upstream source?

[ Parent ]
Main tree unnecessary (4.00 / 4) (#15)
by Miniluv on Sat Dec 23, 2000 at 08:54:10 PM EST

Ok let's just say there was a fork right now that only works on bug fixes for [insert your favorite platform]. How do you get these fixes in the upstream source?
That's where the pressuring comes in. The complaint is that they aren't getting into the mainstream source through normal means, does that not make it time to try something else?

How are you going to keep all these seperate trees in sync? I'm not talking about reputations or letting anyone submit code into the kernel, I'm just talking about getting needed fixes in there. No one wants to have 6 differerent kenrel sources. From a distro point of view it would be a nightmare!
Maintaing synchronization on the trees would obviously be the maintainers responsibility. The thing is, I don't think it would necessarily be that much work as stable releases of the main tree don't come out that regularly. Besides which, not every branch would need to keep up with the brand new features and such as long as it didn't break overall compatability.

I don't know if this is the answer or not, but I think it's one that may have some merit for some situations.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

Are you sure? (4.00 / 3) (#16)
by pulsar on Sat Dec 23, 2000 at 10:20:38 PM EST

That's where the pressuring comes in. The complaint is that they aren't getting into the mainstream source through normal means, does that not make it time to try something else?
Pressure from who? That's part of the problem right now, there isn't any...
Maintaing synchronization on the trees would obviously be the maintainers responsibility. The thing is, I don't think it would necessarily be that much work as stable releases of the main tree don't come out that regularly. Besides which, not every branch would need to keep up with the brand new features and such as long as it didn't break overall compatability.
So x86 gets all the new stuff and everybody else is SOL? I think you fail to see how things currently are. When a new kernel feature is added, it is added to all platforms (unless it's specific to one or another). People have to test it (usually through the devel kernels) on all platforms to make sure it's ok. When it breaks on one platform, you fix it and submit a patch.. here is where one of the problems lie. Getting the patch accpted.
I don't know if this is the answer or not, but I think it's one that may have some merit for some situations.
I don't know either, that's why I posted.. to start a discussion! :)

[ Parent ]
Towards the same ends... (5.00 / 1) (#17)
by Miniluv on Sat Dec 23, 2000 at 11:05:46 PM EST

Pressure from who? That's part of the problem right now, there isn't any...
That, I would think, would be one of the things that forking in this way would generate. You'd have a userbase of people saying "Look, the patch works, we all use it...we all need it. Now merge the bastard."

So x86 gets all the new stuff and everybody else is SOL?
Not at all, what I'm saying is that new features do not come along on a fantastically regular basis...a lot of it is drivers and whatnot which doesn't matter to other platform people. I am quite familiar with the linux kernel release schedule, seeing as I track stable on a regular basis for machines here at work.

When it breaks on one platform, you fix it and submit a patch.. here is where one of the problems lie. Getting the patch accpted.
Before the patch becomes mainstream it is still useable no? Why not have a place where people can use things in the interim while people are persuaded to accept patches? Some form of ad-hoc Alpha patch testing as an example?

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Sounds good on paper... (4.00 / 1) (#18)
by pulsar on Sun Dec 24, 2000 at 12:05:59 AM EST

That, I would think, would be one of the things that forking in this way would generate. You'd have a userbase of people saying "Look, the patch works, we all use it...we all need it. Now merge the bastard."
Maybe, but there is no real good way of knowing for sure.
Before the patch becomes mainstream it is still useable no? Why not have a place where people can use things in the interim while people are persuaded to accept patches? Some form of ad-hoc Alpha patch testing as an example?
Umm.. have you ever tried to maintain a patch against the kernel across several kernel releases? It's hard, damn hard.
Before the patch becomes mainstream it is still useable no? Why not have a place where people can use things in the interim while people are persuaded to accept patches? Some form of ad-hoc Alpha patch testing as an example?
We do have places like that. One such place is ALO FTP site. How do we persuade peple to use them? See above.

[ Parent ]
CML2 (4.00 / 1) (#21)
by Jim Dabell on Sun Dec 24, 2000 at 06:39:19 AM EST

The point still stands that we have highly complex configuration utilities to maintain this incredible cross-platform proliferation. I don't think this is necessarily the best method, and it could be improved upon if someone would take the lead.

ESR is developing a new build/config system for the kernel, called CML2.



[ Parent ]
Two problems. (3.50 / 4) (#6)
by simmons75 on Sat Dec 23, 2000 at 05:37:21 PM EST

Other than the fact that you're making an arguably false assumption ("the only people who are allowed to code for the kernel and actually get that code into a releases are those who they feel are elite") I see two problems here:

1. Starting an organization simply to take the development focus of the Linux kernel away from Linus and AC will almost by necessity create a code fork. Some people would go with the organization; some with Linus & Co.

2. Unless you want the Linux kernel to turn into a sophomore-level class project on a global scale, the organization will have to steer the direction of development and have some guidelines on what will be accepted/rejected--in other words, you'd have an organization doing something that's happening already. Starting an organization isn't a way to let all kinds of code in--it's a way to control what happens. :-D
poot!
So there.

Re: Two problems. (4.00 / 2) (#12)
by pulsar on Sat Dec 23, 2000 at 06:34:54 PM EST

Other than the fact that you're making an arguably false assumption ("the only people who are allowed to code for the kernel and actually get that code into a releases are those who they feel are elite") I see two problems here:
Obviously you must not deal with these sort of issues. I see it constantly just reading linux-kernel list, let alone doing it first hand.
1. Starting an organization simply to take the development focus of the Linux kernel away from Linus and AC will almost by necessity create a code fork. Some people would go with the organization; some with Linus & Co.
Why does it have to be completely taken away from Linus, Alan, etc. ? Why couldn't they just join the org?
2. Unless you want the Linux kernel to turn into a sophomore-level class project on a global scale, the organization will have to steer the direction of development and have some guidelines on what will be accepted/rejected--in other words, you'd have an organization doing something that's happening already. Starting an organization isn't a way to let all kinds of code in--it's a way to control what happens. :-D
I never said it'd be easy or that it would work perfectly from day one. However I think something needs to be done. I cannot tell you how many 1000's of hours I've wasted trying to figure out why something in the kernel (or the kernel itself) doesn't work, only to find out that a patch wasn't included that should have been...

[ Parent ]
What I've seen (4.16 / 6) (#19)
by ppetrakis on Sun Dec 24, 2000 at 12:12:20 AM EST

Let me enlighten those who dont know anything that goes on in Alpha land. There are basicly a few people (and I mean few) who are considered to be the head Alpha guys. Now say you want to submit a patch that is going to make some big changes but are overall benificial though you have a problem. You've never submited a kernel patch before. 99% of the time when some one posts on linux kernel a patch like I just said they get IGNORED.

I know folks who've written said patches and have said "they dont know who I am, I have no tenure ". So their only option is the lead Alpha guys because no one else is going to listen or care about the subject. Now the head individual is damn busy and doesnt have the time to look through even all the Alpha patches so he asks the individual to submit the patch in pieces.

So instead of getting discounted outright you are instead having your patch fed in piece by piece who are reviewing this when they can and doing the other things they normally do. All the lead Alpha guys are NOT exclusive kernel developers. Richard Henderson is a perfect example , he does ALOT of work on gcc and he does most of the critical alpha port stuff.

So the end result? Thinks that are broken take longer to get fixed and major changes take a very long time to reach "released" kernels.

Worse now is some of this "big" changes like oh being able to support all the ram your Alpha can handle are still seperate patches that SHOULD be part of the main kernel. So the author has to improve his patches and keep track of the damn linux kernel. Instead of it being part of the released kernel. C'mon. I have to get patches so I can support 1 > GB of ram? Take a look at andrea archangela's kernel patch library for his big mem support. He them against every release and almost every pre kernel. Would you rather a developer like that managing his code or working on NEW code.

Now tell me. Do you want to be the guy sent this and that alpha patch just because the rest of the linux community doesnt give a shit to even look because you havent made a name for yourself? There was a /. disscusion on just this topic but not architecture specific about a month ago.

The general response was. "keep on trying, someone will pick it up eventualy". I dont think anyone is looking foward to being in that guys posistion.

I disagree. Without resources devoted to managing this code the kernel will eventually fork and it's going to be a dirty , nasty, name calling , I'm never gonna speak to you again fork. Just like OpenBSD and NetBSD who havent collabaratted with each other for over the last 5 years.

Peter

--
www.alphalinux.org
Peter Petrakis Warrior/Engineer ppetrakis@alphalinux.org
"Oh my God! They killed Xena! You bastards!!"
"<BLAM!!> Who the hell are you!? Name's Ash <click clock> Housewares..."

This isn't a kernel issue. (4.00 / 4) (#22)
by ghjm on Sun Dec 24, 2000 at 10:14:34 PM EST

In this instance the kernel is only reflecting the culture of the broader Linux community - perhaps focused a bit more intensely, but unchanged in its essence. Basically, the problem is that ESR's concept of reputation and/or gift economy is right on target. You're a hacker when other people call you a hacker. In order to have code accepted into major projects, you have to be cool. In order to be cool, you have to have code accepted into major projects.

So what happens to programmers with mortgages? They aren't cool and they never will be cool, because coolness is a game for bored 17-year-olds. The freakish geniuses become kernel hackers, the less-gifted become warez couriers, but the psychology--and the required time commitment--is basically the same. Programmers with mortgages simply can't compete. The good ones can code like a bat out of hell, but they need to be paid.

The LKML filtration method (ie, we don't even look at your code if you're not sufficiently cool) is simply a response to overwhelming time pressures on the key people. These time pressures exist because there aren't enough people working on the project. There aren't enough people working on the project because the bulk of the talent in the world can't pass the filters. Classic catch-22. Without systemic change, this isn't going to get better. In fact, it's getting worse as the old guard, previously-very-cool people start to have trouble making the payments on their reputations. Ref: "The kernel only moves at the speed of Linus."

Which brings us to what I consider the most important question facing the free software movement today: How can we recruit more of the talented, for-pay, uncool people? Because as long as we don't have the talent edge (and we don't), proprietary software will remain on top. So what do we do about it?

-Graham

ps. People are probably mad at me now because I don't have basis to make these comments. I'm not cool enough. On the other hand, I do have two great kids, and yes, a mortgage. :-)


Other examples of organizations (4.50 / 2) (#24)
by Derek Moeller on Wed Dec 27, 2000 at 02:01:32 AM EST

First, I have also seen this x86 arrogance on behalf of the chiefs with platforms such as the PowerPC. Those that work hard on the PPC platform do not receive their fair representation. People love to claim that Linux is extremely cross-platform, but in reality it only exists in a perpetual state of brokenness for many non-x86 platforms. I know that I have had to deal with many problems related to indifference towards the PPC platform.

Some in the discussion have claimed that an organization would merely repeat what is already been done, or would not work as well. This is untrue. The reason that the organization is a better option is a more equal representation of parties involved. In the current system, you've got one or two bosses who frankly are not concerned by non-x86 machines. In a well-designed organization, you've got groups responsible for powerpc, alpha, sparc, etc development. The development will not race off without them.

Additionally, when the social organization is done right, code organization starts looking better as well. For example, take a look at the BSDs, especially NetBSD. They use a distributed structure mechanism. Their entire kernel structure is also more organized. They've got some incredibly cool stuff in there--for example, drivers that are abstracted from the bus. Where we've got particular drivers for this-type-of-card on PCI, and this driver for the same thing on ISA, or for buses on other platforms, they've got one driver for all the different busses. This, as well as a bunch of other interesting designs, leads to a cohesive codebase that -- time for a shocker -- generally works well for each platform involved. Not only that, but they keep each platform maintained and working with a fraction of the workforce required in the Linux dictatorship system.

(Note that in some cases, dictatorships work well. Programming languages like Python are a good example. However, programming languages do not (should not, at least) change with the frequency that an OS does -- no new drivers, no big structural belches, and so on. Operating systems and their kernels do not work as well with dictatorships as with BSD/Debian style nonprofit organizations.)

Some here are equating the organization of kernel development with commercial backing. Erase that thought from your mind, as it is not empirically proven by the other similar organizations out there (Debian, NetBSD, OpenBSD, only recently has FreeBSD gotten involved with BSDi).

Of course, it is unlikely this will happen, because while Linus would not be overly bothered by a fork, he would be bothered by his loss as a 'leader' in the current system. Actually having to expend occasional energy to make sure that all sections of the kernel are operating nominally sure is a pain, especially when it is not a personal concern. (The fact that it is not a personal concern would be acceptable if the responsibility were delegated to someone who was concerned.)

People, the egotistical "coolness" system has got to stop if we want a streamlined, functional, transparent kernel development. It is quite entertaining to endlessly write about it (ESR), but as far as efficiency and functionality of the cohesive unit, it is a flop. There are examples out there of better methods of development -- all it needs is a good look at how they work and a little emulation.
-- Derek Moeller

A Linux kernel organization? | 24 comments (23 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!