Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×


This is Bad? (4, Insightful)

Rachel Lucid (964267) | about 7 years ago | (#19717827)

They're probably getting older, too.

Perhaps the less coding you do the higher you get up in the management ladder is for a reason, after all...

Re:This is Bad? (4, Insightful)

houghi (78078) | about 7 years ago | (#19719633)

I would say it is the other way around. The higher you get up, the lesser you code.

I also do not see this as a bad thing. One good coder with manager skills or manager with coding skills can be more productive when he manages people.

Re:This is Bad? (1)

Lockejaw (955650) | about 7 years ago | (#19720479)

I also do not see this as a bad thing. One good coder with manager skills or manager with coding skills can be more productive when he manages people.
Exactly. It's a lot like comparative advantage [] , applied to labor.

Better management... (1)

SanityInAnarchy (655584) | about 7 years ago | (#19719647)

Oh, how I wish some of my day job bosses had ever written a single line of code in their lives...

Getting older and coding (4, Insightful)

mckyj57 (116386) | about 7 years ago | (#19720009)

Programmer burnout is a well-known, if not well understood, phenomenon.

As far as older, I don't think age has much to do with burnout. I started a major open-source project after the age of 40, my first big programming project after a career change. (I am one of the few managers that then became a coder.)

I am now pretty burned out. It isn't that I can't write code -- in fact, I am better than ever. I just don't *want* to write code any more.

Should have used Eiffel (0, Troll)

Meor (711208) | about 7 years ago | (#19717831)

This is what happens when you write large procedural code programs with no Design by Contract. You spend more time rechecking old things than writing new things.

Re:Should have used Eiffel (2, Interesting)

ajs318 (655362) | about 7 years ago | (#19718441)

Eiffel? No, they wanted something that would actually run.

That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.

With all these fancy-arsed "designed so mistakes are impossible" languages, you can spend longer trying to write a "demonstrably-correct-first-time" program than you would chasing down bugs in a nearly-right one. Or at least, that's what it feels like.

Re:Should have used Eiffel (3, Insightful)

Fujisawa Sensei (207127) | about 7 years ago | (#19718735)

Perhaps you need to get a little deeper into kernel development to find out why Eiffel is a bad choice:

  • Exceptions in kernel space suck. You can look through AROS ML archives for an example of this.
  • In kernel space you don't have access to the standard C libraries, malloc() for instance.
  • Not only don't you have access to standard C functions, you don't want your memory managed for you, that's the kernel's job.

In summary languages that do stuff for you behind the scenes suck for kernel development.

Re:Should have used Eiffel (0)

Anonymous Coward | about 7 years ago | (#19718881)

In summary languages that do stuff for you behind the scenes suck for kernel development.
Yeah. Those LISP machines, they were really terrible.</sarcasm>

Re:Should have used Eiffel (0)

Anonymous Coward | about 7 years ago | (#19718957)

LISP machine kernel didn't have to worry about virtual memory management.

Re:Should have used Eiffel (0)

Anonymous Coward | about 7 years ago | (#19720121)

LISP machines are a special case: the hardware was built specifically to run LISP well, and implicitly supported the sorts of magic LISP expects. You wouldn't write a kernel in LISP on top of bare commodity hardware though.

Re:Should have used Eiffel (3, Informative)

ari_j (90255) | about 7 years ago | (#19720299)

You wouldn't write a kernel in LISP on top of bare commodity hardware though.

You're right, you wouldn't. People who spell it the modern way, Lisp, however, would [] .

Oh, please (1)

WindBourne (631190) | about 7 years ago | (#19718885)

what is the link to your OS that is based on eiffel? I can not seem to google, yahoo, msn, dogpile, or anything to find it.

will has nothing to do with it (5, Insightful)

Anonymous Coward | about 7 years ago | (#19717835)

the talented get promoted to managing because they care about what's happening, how it gets done, and they know what's going on. This doesn't equate to "I don't feel like coding" as the article suggests.

"That's all I do, is read patches these days," he said during a discussion at the Linux Symposium in Ottawa last month.

This doesn't read "I don't want to code" it reads "I haven't time to code"

Re:will has nothing to do with it (0)

Anonymous Coward | about 7 years ago | (#19718963)

Shouldn't there be better way? Those who are talented in managing (and presumably not so in coding) gets promoted as managers, those who excel at coding gets to work on challenging stuff. Why take top coders and make them managers? It seems corporate ways have infected open source developers: keep promoting the talented up to a position where they are least qualified and let them stuck there.

Re:will has nothing to do with it (1)

Torvaun (1040898) | about 7 years ago | (#19719355)

Yeah, have people who are talented coders get promoted to designers or code supervisors. Actually writing code can easily be a generic position, easily swappable (assuming company coding standards). Code design, writing the pseudocode or flowchart or whatever to define the steps code must take to be functional, that's the stuff for coders who can think of a task in the same way a computer does. Code supervising would then be the review of code being produced by the low level code monkeys. This kind of promotion goes to the coders who are also good proofreaders, the ones that have a knack for spotting inefficiencies and unintended features (bugs). Those are the difficult parts of coding.

Re:will has nothing to do with it (2, Insightful)

sick_soul (794596) | about 7 years ago | (#19720167)

> Actually writing code can easily be a generic position,
> easily swappable

This is what most companies get wrong.
Coders are not easily swappable, no matter how much policy
you try to set up: the differences in skill have a
tremendous impact on the quality of the code, and if a
more talented supervisor must always veto/fix the code of its
underlings, it is a waste of time for everyone involved.

Only good coders should work on the code base in any position.

Those who also show management skills should get burdened by
the additional task of actually managing people and
distributing work, and they will slowly code less and less,
while the good coders which do not show management skills
should just code on.

Will, no. Innovation, yes. (0)

Anonymous Coward | about 7 years ago | (#19719353)

Linux is just about finished right now. Just wrap it up and ship it.

a good or bad thing? (5, Interesting)

brunascle (994197) | about 7 years ago | (#19717839)

that's odd. the article [] covering the same event made it sound like the kernel team thought it was a good thing that there were more developers, and the work was more spread out.

I think the question is more ... (4, Insightful)

khasim (1285) | about 7 years ago | (#19718015)

... how has the amount of code they actually approve and that gets into the kernel changed?

Once you become a guru coder, you may write less code yourself, but you may approve more code over all. That would be code written by other people that you check, tell them where the bugs are and they fix the bugs and re-submit the code.

When the code is up to your standards (and the evidence is the flat rate of bugs) then the code is included in the kernel.

There was a time (long ago) when Linus wrote ALL of the code himself. If you look at just that metric, Linus barely writes anything anymore (percentage-wise).

Re:I think the question is more ... (1)

timeOday (582209) | about 7 years ago | (#19720217)

So what happens when these gurus take one more step up the ladder and OSS becomes overburdened with PHB who make life miserable for everybody :)

Re:I think the question is more ... (3, Insightful)

zCyl (14362) | about 7 years ago | (#19720423)

When the code is up to your standards (and the evidence is the flat rate of bugs) then the code is included in the kernel.

There was a time (long ago) when Linus wrote ALL of the code himself. If you look at just that metric, Linus barely writes anything anymore (percentage-wise).

This of course implies that code is now checked more times and more carefully BEFORE inclusion, which is a win for everyone.

Re:a good or bad thing? (1)

bjourne (1034822) | about 7 years ago | (#19718819)

And they do think it is a good thing. Unfortunately, you won't be able to find out without reading TFA. :)

So? (2, Insightful)

Actually, I do RTFA (1058596) | about 7 years ago | (#19717851)

This is what happens as projects get bigger. It's not that they lose the "will to code", it's that they spend all their time as managers of other coders. There's more to developing a large codebase than writing the code after all.

Will? (4, Informative)

truthsearch (249536) | about 7 years ago | (#19717855)

I read the first page and didn't see anything about them losing their will to code. It seems just the sheer number of innovative contributions means they have more to manage and less to write. This can't be a surprise with so many individuals and companies now contributing.

Re:Will? (-1, Offtopic)

merreborn (853723) | about 7 years ago | (#19718005)

Those mugs are lame. Especially because the string constant 'coffee.php' is unquoted on the PHP mugs.

Re:Will? (0)

Anonymous Coward | about 7 years ago | (#19718969)

Notice: Use of undefined constant coffee - assumed 'coffee' Notice: Use of undefined constant php - assumed 'php' Warning: include(coffeephp) [function.include]: failed to open stream: No such file or directory

Re:Will? (3, Funny)

Anonymous Coward | about 7 years ago | (#19719281)

I think it's appropriate that a PHP mug has an error on it. I think the next one should have a sql injection attack.

Re:Will? (1, Informative)

Anonymous Coward | about 7 years ago | (#19719157)

Don Marti did not use the phrase "will to code" anywhere in his article. An editor at probably made up that title; it probably wasn't Don Marti, he just wrote the article.

Git (2, Insightful)

CarpetShark (865376) | about 7 years ago | (#19717857)

Isn't this what Linus said that Git was supposed to fix?

I wonder are the rest using it... I wonder are the rest even delegating.

Re:Git (4, Informative)

CarpetShark (865376) | about 7 years ago | (#19717931)

To clarify: Linus gave a talk at google, where he spoke of Git as part of the solution to this problem, and his shear lack of interest in helping "subordinate" (my word, for want of a better one, not his) developers. He said, essentially, that if people don't write proper patches, or if they write patches that conflict with other patches, he doesn't spend time integrating: he throws it back, and says do it again. Likewise, he doesn't manage tons of individual patches; he delegates to others, who spread the load. If the "lieutenants" aren't handling their part, they just need to learn from Linus.

Re:Git (-1, Troll)

DogDude (805747) | about 7 years ago | (#19718343)

they just need to learn from Linus.

Actually, I'd say that Linux sounds like a piss-poor manager. With management like this, I'm not surprised that Linux is still playing catch up, 10+ years into it.

Re:Git (0, Flamebait)

CarpetShark (865376) | about 7 years ago | (#19718373)

Sure, keep telling yourself that, as you PAY THOUSANDS at Microsoft to make an inferior but shiny OS.

Re:Git (0)

Anonymous Coward | about 7 years ago | (#19718463)

Or switch to a real OS like *BSD or Mac OS X. Microsoft isn't the only or best alternative to Linux.

Re:Git (0, Offtopic)

CarpetShark (865376) | about 7 years ago | (#19719469)

OS X seemed like a good idea once. I even bought an iBook for that. After actually trying to get a decent workflow setup on it, my iBook runs KDE now :)

Re:Git (1)

CarpetShark (865376) | about 7 years ago | (#19719499)

Oh, and no FreeBSD newer than 4.x will even boot on my x86 box, which runs other OS's just fine. I agree that *some* things are done better in the *BSDs though.

Re:Git (1)

DogDude (805747) | about 7 years ago | (#19718567)

How is that relevant as to whether or not Linus is a decent manager?

C'mon. That was a pretty weak troll.

Re:Git (1)

CarpetShark (865376) | about 7 years ago | (#19719427)

Ermm... the same way that your entirely baseless accusation of Linux "playing catch-up", and LinuS being a bad manager is related to whether Git is a good solution to an entirely new situation? (Hint: microsoft don't have any of the new situations to deal with that a large open source project has, and they still had to cut back on most of Vista's features, before most of the critics calling their project a failure)

Re:Git (1)

WindBourne (631190) | about 7 years ago | (#19718945)

  1. linux is an OS, and yes, it makes a lousy manager over ppl (but a good one over hardware resources.
  2. Exactly what is Linux is playing catch up on?
  3. And I am guessing that you think Linus is a poor manager. What do you base that on?

Re:Git (4, Insightful)

Dan Ost (415913) | about 7 years ago | (#19719299)

This is actually an example of good management (or, more correctly, management knowing its own limits).

Bouncing the patch back to the original author is exactly the correct thing to do. There's no way that Linus can be as familiar with the patch code as the person who wrote it, so why would he think that he could do a better job integrating than the original author?

It's just maturation: projects evolve (2, Insightful)

postbigbang (761081) | about 7 years ago | (#19717891)

New projects open all the time. As the FOSS code base increases, it's easier to move code around. Once one takes on responsibility for a project, the new code vs maintenance code is always going to change. And there are thousands of projects where someone gets bored, moves on, or whatever, where the project then becomes stuck in the mud. SourceForge is full of them. It doesn't mean there's anything wrong, it's the fits-and-spurts of how coding works.

Nothing to worry about. It's natural.

Everyone can help in some way. (1)

Dareth (47614) | about 7 years ago | (#19717903)

You do not have to be a top coder to help develop Linux. The top developers have the skill sets needed to write and manage code. These talents are needed. The top developers can mentor the next generation/level of talent and raise them up to a higher level. This helps to ensure quality and continuation of so many great projects past the time when the original "guru(s)" have moved on to their next itch.

Everyone can help in some way. The newbies who read the "Linux Recipes" online and point out areas of confusion are helping. I would even dare say the "Grammar Nazi" who helps correct documentation helps too.

Re:Everyone can help in some way. (0)

Anonymous Coward | about 7 years ago | (#19718171)

I would even dare say the "Grammar Nazi" who helps correct documentation helps too.

You're missing a comma before "too".

Re:Everyone can help in some way. (1)

ajs318 (655362) | about 7 years ago | (#19718631)

Not necessarily. There are two schools of punctuation: one, which believes in including a punctuation mark -- a dash, a comma, a semicolon or a colon -- at any point in a sentence where a pause, or a change of inflection, might reasonably be indicated; and the other which believes that unnecessary punctuation marks serve only to clutter up sentences and reduce visibility.

Good news (-1, Troll)

Anonymous Coward | about 7 years ago | (#19717911)

America's Urban Black Population Falls Dramatically
As Many As One Tenth Of Black Population Dead Over Past Five Years

6/30/2007 10:49:41 AM
Discuss this story in the forum
Overthrow Staff

Washington, DC -- A new report, cited in the Economist magazine, indicates America's black population has fallen dramatically over the past five years, despite Census bureau estimates and demographic doomsayers' prediction of growth that would overwhelm whites.

In America's three largest cities -- New York, Los Angeles, and Chicago -- black populations dropped by one tenth due to the cumulative effects of murder and disease.

Discussing "the disappearance of blacks", the Economist writes, "Roughly half of America's murder victims and about the same proportion of suspected murderers are black. In five years America's three biggest cities lost almost a tenth of their black residents ..."

One tenth of America's black population -- over 3.8 million Negroes -- lived in those three cities, and the disappearance of 380,000 of them due to AIDS, murder and other causes represents a one percent decline in America's overall black population.

The trend is similar to that in Africa, where nations such as South Africa have seen AIDS and crime cause their national population to begin falling at a rate of one half to one percent a year, and where acts of war and genocide -- Negro crime taken to an exponential level -- have destroyed a tenth or more of the population of central African nations every several years.


Published by: / White Politics, LLC
ATTN: Bill White, Editor

Post Office Box 8601
Roanoke, VA 24014 []

Re:Good news (0)

Anonymous Coward | about 7 years ago | (#19720067)

I know its feeding the trolls, but its been a while, and trolls need to eat too..............

The census is correct, minority numbers are growing... There are fewer of them in the urban areas perhaps, but there are a LOT more in the suburbs. Its a slow uphill march, but situations do improve for some members of minorities, and its amazing that the fact that a percentage have managed to "improve" their situation enough to move out of crime ridden urban centers can somehow be twisted into a negative statement about them.

Not loosing the will (2, Interesting)

realdodgeman (1113225) | about 7 years ago | (#19717973)

They are not loosing the will to code. They just have too much other work, like reviewing others code. So they do not have enough time left to code. RTFA. The headline is not reflected in the article itself at all.

Re:Not loosing the will (4, Funny)

All Names Have Been (629775) | about 7 years ago | (#19719099)

They are not loosing the will to code. They just have too much other work, like reviewing others code. So they do not have enough time left to code. RTFA. The headline is not reflected in the article itself at all.

I'm loosing the will to spell.

Re:Not loosing the will (1)

realdodgeman (1113225) | about 7 years ago | (#19719839)

I'm loosing the will to spell.
Keep commenting like that. I am not English, and this is the only way I can learn it. Anyway, it is not like I have anything to loose...

Re:Not loosing^H^H^H^H^H^H^H losing the will (0)

Anonymous Coward | about 7 years ago | (#19719309)

Losing, not loosing, for the sake of Webster's spinning corpse, you damnable corpse-spinner!

Time for a.. (0)

Anonymous Coward | about 7 years ago | (#19717979)


The Mythical Man Month (4, Interesting)

$RANDOMLUSER (804576) | about 7 years ago | (#19717983)

Described this in 1975. As you add more people to a project, communication takes up more time than coding. From Wikipedia [] :

Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).

* Group Intercommunication Formula: n(n 1) / 2
* Example: 50 developers -> 50(50 1) / 2 = 1225 channels of communication

Re:The Mythical Man Month (4, Insightful)

flaming-opus (8186) | about 7 years ago | (#19718133)

This assumes that the kernel is a single common software project.

It isn't. A few filesystem developers might have to make changes to elevator, or allocator code, but most developers of XXXXfs don't really need to make changes outside of that directory. Developers writing a driver for the XXXX model scsi controller, don't really need to interact with the people mucking with Alsa, or gart, or whatever.

The kernel might be contained in a single source repository, but it's really a few hundred, mostly-independent software projects.

Re:The Mythical Man Month (2, Insightful)

CoughDropAddict (40792) | about 7 years ago | (#19718993)

That's exactly why it's totally ridiculous that it is contained in a single source repository!

Need a newer version of the USB subsystem, or a fix to a driver? Have fun downloading a new version of Linux, which has an ungodly number of changes across the entire kernel.

People tend to think of monolithic/micro kernel only in terms of run-time technical advantages/disadvantages. But equally important IMO is the impact on development processes. With a good microkernel architecture, it would be totally reasonable to think that you could upgrade an entire subsystem (like USB) without touching the rest of the OS. Each subsystem could be run as an independent project with its own releases, and there could be competition for who can make the best subsystem.

Re:The Mythical Man Month (0)

Anonymous Coward | about 7 years ago | (#19719759)

They aren't *actually* independent. There are a lot of inter-dependencies there; core functions and structures change often, and to accomplish something like that you'd need the added complexity of some dependency checker/updater and expect end-users to be able to operate it. On the other hand, if you're looking for one fix to a particular driver, just search the mailing list. Patches are posted regularly in an accessible format with great descriptions and discussion.

Re:The Mythical Man Month (1)

timeOday (582209) | about 7 years ago | (#19720517)

What you describe isn't unusual within Linux at all. If you have a problem with a module, you can often visit a developer's page, and fairly often get a later version of the driver which is still compatible with the kernel version you're running (e.g. IVTV [] ). Then you either patch your kernel tree or compile the modules outside the kernel tree (for instance the pcmcia subsystem) and load it in. As for competing subsystems, think about oss vs alsa, or ipfwadm vs ipchains vs iptables, or udev vs devfs [] . It's just that all this is usually left to distro maintainers, because most people don't care. Maybe what you think you want is rock-steady kernel interfaces so a given driver is compatible with more versions of the kernel - but then you can kiss progress goodbye. I think Linux has it right: support the current way of doing things, plus the outmoded way of doing the same thing for a year or two, then get rid of it. Otherwise you're going to replicate the 20 year transition period it took Microsoft to get from DOS to XP.

Re:The Mythical Man Month (0)

Anonymous Coward | about 7 years ago | (#19718351)

> (without a hierarchy)

Since linux has a "web of trust" (==explicit hierarchy) your post becomes largely irrelevant. Also, the MMM is talking about a situation where the new programmers have to be trained. One interesting thing about Linux programming is that the experts don't "have to" train the newcomers. They are allowed to ignore them. Now, I'm not saying that the MMM doesn't have many truths which could apply here, but we applying them in such a new situation is very difficult and needs a little more careful analysis.

Re:The Mythical Man Month (1)

eMbry00s (952989) | about 7 years ago | (#19719605)

This is only true when you have code depending on other code, and thus people needing to communicate with others. Open source software obviously does not suffer from this as Linux's thousands of contributors do not need to communicate with all of each other. Re-read the Cathedral and the Bazaar.

Book needed (1, Offtopic)

jshriverWVU (810740) | about 7 years ago | (#19717999)

There really needs to be a howto or book on how to write a linux device driver. I feel even more people would be willing to help out if they had a bridge between "just learn C" to "you're now a kernel guru"

Granted if you're a good enough programmer you can traverse the source tree and pick up things on your own, but that is very time consuming versus "here's a quick overview" then look at the code for specifics.

Re:Book needed (5, Informative)

fattmatt (1042156) | about 7 years ago | (#19718075)

Re:Book needed (1)

jshriverWVU (810740) | about 7 years ago | (#19718103)

Sweet! and it's under a creative commons license so you can download it as a pdf. Though if it is as good as it seems I'll definately support it by buying the pulp version. Thanks for the link.

Re:Book needed (0)

Anonymous Coward | about 7 years ago | (#19718153)

+5 informative

Re:Book needed (1)

janrinok (846318) | about 7 years ago | (#19718737)

Thank you. I've nothing constructive to add to the discussion but I felt that your efforts needed acknowledgement!

Re:Book needed (1)

quanticle (843097) | about 7 years ago | (#19718173)

I feel even more people would be willing to help out if they had a bridge between "just learn C" to "you're now a kernel guru"

Just a little searching on Google and Amazon netted me the following two titles:

The resources for understanding the Linux kernel are out there, you just have to have the motivation and interest to look for them.

Re:Book needed (4, Insightful)

MROD (101561) | about 7 years ago | (#19718265)

The problem is that with almost every minor kernel version revision the driver interface is changed, so any book that goes into print will already be almost worthless by the time it got into the shops.

This is why the current fluid kernel/driver interface specification is unsustainable and unmanagable in the long term (and why ultimately the kernel development process will bog down).

The solution? Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version. Then the kernel developers can concentrate on the pure internals of the kernel which no-one but them should need to know about and the work which currently takes place to recode the hundreds of drivers each time there's a tweek to the driver interface could be redirected to more productive efforts... and the patch load should be less as well.

There is a side benefit to this as well, the energy barrier for 3rd parties to write drivers would be lower and hence it would be far more likely that they'd actually write them rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.

I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers." There will also be those who believe the dogma of, "but the driver interface needs to change often so as to be Better(tm) so you can't set the interface in stone."

Antithetical. (2, Insightful)

wild_berry (448019) | about 7 years ago | (#19719149)

The kernel developers have decided that black-box/proprietary drivers aren't welcome in their kernel and ask that companies submit their drivers as patches to the existing kernel. That's why 52% of the kernel tree is driver code. It also means that the drivers are free-as-in-GPLv2 and can't be withdrawn later on. If they become abandonware, they are freely available to be updated by a third party. I see these as advantages sufficient to support the present Kernel Development method.

Re:Antithetical. (2, Insightful)

MROD (101561) | about 7 years ago | (#19719483)

I didn't actually mention black-box binary-only drivers or even those not released under the GPL, that's a totally separate issue. This is a maintainability issue and the costs to companies to keep modifying their code almost every time there's a minor kernel version change.

If a company can assign programming resources once off for a driver project and not have to spend extra resources every few months just because of a change in the kernel interface then they will look far more kindly on the idea of developing a driver, be it GPL'd or not. Remember, Linux is a small player for the hardware people and hence only minimal budget can be allocated to any driver project. Recurring costs (other than for bug fixes) are a major financial barrier.

Re:Antithetical. (1)

wild_berry (448019) | about 7 years ago | (#19719565)

I was proposing that the inclusion of a device driver in the mainline kernel tree fixes the maintainability issue: it is updated with the kernel tree.

Re:Antithetical. (1)

MROD (101561) | about 7 years ago | (#19719883)

Which means that it's more work for the core kernel developers... Which is the whole point of the original posting.

Separate the drivers currently in the kernel source ball out into a separate project and define a kernel/driver programming interface and that work is decreased hugely. The side effect would be that hardware companies would find it far easier to develop and maintain drivers so that their management may actually think it worth the resources they can afford to give it. Again, this has nothing to do with whether the drivers are open, closed, GPL'd or released with any other license or even fully public domain.

Re:Book needed (1)

Hognoxious (631665) | about 7 years ago | (#19718379)

Is something like this [] what you mean?

Re:Book needed (1)

Triddle (793231) | about 7 years ago | (#19718411)

If you need a book then I don't really want you messing with my kernel. I'm a C programmer with 20+ years experience, but while I am good at what I do I am not as knowledgeable as those guys so I don't get in their way. I'd like to, very much, but the Linux kernel is beyond the level at which I can contribute in a meaningful way. If you think you can do so without knowing exactly what you are doing, then I admire your will to help but please, wait until you *know* your contributions will cause less work than you put into them.

Where you may be able to provide real assistance is in the documentation. All coders hate documentation, but it still needs to be done.

OMG, u r teh 733t! (1)

edittard (805475) | about 7 years ago | (#19718561)

If you need a book then I don't really want you messing with my kernel.
Nonesense. Kernel programming is so different from the application side that even for a competent C dude there's a lot to learn - why not benefit from someone else's experience?

Oh, it's probably his kernel he wants to hack around with. I don't have any problems with that, and I don't see why you should.

Re:OMG, u r teh 733t! (1)

Triddle (793231) | about 7 years ago | (#19718851)

I've done UNIX kernel programming. Have you? Don't comment until you have. I'm a very competant 'C dude' who earns his living writing embedded code. Operating systems are my particular interest, but I know my limits. Don't you dare fuck my kernel up for me. His kernel *is* my kernel. He clearly does not have the knowledge to create his own, whereas I have in the past. For UNIX, LINUX and XENIX. Here's where you get to present some credentials instead of just sprouting bullshit. You move...

Re:OMG, u r teh 733t! (1)

edittard (805475) | about 7 years ago | (#19719039)

I've done UNIX kernel programming. Have you?
No. So what?

Don't comment until you have.
Who died and made you king?

Don't you dare fuck my kernel up for me.
Or you'll do what?

His kernel *is* my kernel.
No it isn't. You're laughable.

Here's where you get to present some credentials instead of just sprouting bullshit.
I'm an astronaut, before that I was a brain surgeon, so yah boo sucks.
P.S. competant, LOL.

Re:OMG, u r teh 733t! (0)

Anonymous Coward | about 7 years ago | (#19718999)

There's a difference between programming for you own use and programming for the masses. By definition any [good] changes you make to Linux must be presented for possibkle addition to the codebase. The aforementioned overworked and their minions get to decide if the code is worthy of inclusion in the general release kernel.

It's clear that it is possible for an inexperienced coder to make incorrect changes to the kernel and get them included. That's a big problem. Let them play with their own kernel by all means, but don't touch the publicly avaliable one until they actually know what they are doing.

Re:OMG, u r teh 733t! (1)

Dog-Cow (21281) | about 7 years ago | (#19719379)

You are beyond stupid. A newbie coder playing with his copy of the kernel source can do anything he damn well pleases and he doesn't have to present his work to anyone else at all. If he wants to give someone else his copy of the kernel, he has to present his changes in source form as well. But that won't get his code into the mainline tree. The whole point of the code managers which the article discusses is that there is a mechanism in place to keep out bad code. It doesn't matter who writes the bad code; there will be someone reviewing it. Even Linus has his code reviewed, even if there is absolutely nothing but social pressure to keep his own bad code to himself.

Is that so bad? (0)

Anonymous Coward | about 7 years ago | (#19718039)

Seems to me this is a great way to teach a burgeoning mass of hackers to become better/good kernel hackers, and that is surely a good thing.

An inevitable outcome of growth (1)

simong (32944) | about 7 years ago | (#19718085)

It happens in every aspect of IT, or certainly the ones I have been involved in. As manpower increases, the longest served ops, sysadmins, programmers, whatever, get more responsibility pushed on them and therefore do more managing and less of what they were hired to do. Linux is a classic case of a large scale software project and I would expect the 'names' of the project to do less, perhaps even against their wishes. Someone mentioned Git, which is a very good way of managing this kind of project, but I guess that would take a form of its own and end up with some people managing and others contributing code. So the wheel goes on...

Maximize value (1)

nuggz (69912) | about 7 years ago | (#19718225)

If you only have X hours to spend on a project you should choose the activities that will be most beneficial.

As much as technical guys don't want to think about it, good management is an excellent productivity multiplier, alternatively no/poor management is a productivity destroyer.

Some well directed management and control will often result in the team getting more additional work being done than if the "manager" did it himself.

Think about all the times the senior guy, or the suits rejected blocked or otherwise stopped something you thought had great value. You should consider that perhaps if YOU were the manager, some of those good things would happen, you might be more useful doing the managing than technical work.

Not only is this natural but it is also Good (1)

ThePopeLayton (868042) | about 7 years ago | (#19718229)

As the number of contributors grow and the network becomes more and more complex you NEED management who understand the task at hand. Dilbert, and I'm sure most people out there, suffer from BAD management. We all know how bad management can doom a great project.

I am sure that they miss coding but are they working on linux to satisfy their own coding desires or to make linux a better product. If it is the former then they have no reason to be in management, but if it is the later then they are needed where the are. As the network gets bigger and more complex we are going to need people who have a better grasp of the BIG picture. Without this linux will die.

Losing the Wii to code... (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#19718247)

Sadly, this seems to be the trend. Initially, games are produced for the sake of fun and excitement. Yet as of late, game developers certainly seems to be getting lost in other aspects of development, such as coding. I hope this isn't the case for upcoming titles.

Perhaps in writing response to what I want the article to say, I can, in fact, change the content of the article. Or at least humor myself.

UDEV (0)

Anonymous Coward | about 7 years ago | (#19718325)

If that means that Greg can stay away from coding/designing another jewel like UDEV, I see that only as a Good Thing.

this always happens (1)

SolusSD (680489) | about 7 years ago | (#19718327)

...and ike any long term programming project new people will replace the once core coders and will be overseen by previous core coders. why is this news?

Welcome to programming (2, Insightful)

hikerhat (678157) | about 7 years ago | (#19718335)

This is how it always works. Once you have enough experience doing anything, from building houses to writing code, you start to spend more time sheepherding the less experienced and less time implementing. It's the circle of life. I didn't rtfa.

tr0ll (-1, Troll)

Anonymous Coward | about 7 years ago | (#19718473)

BSD machines, 80s, DARPA saw BSD []? Oth3r member5 in and as BSD sinks well-known United States of

Where's the beef? (2, Insightful)

billsf (34378) | about 7 years ago | (#19718977)

People simply tend to get more managerial as they get older. This extra proofreading, checking and review has resulted in a fantastic product. While BSD is my primary computer interest, I've maintained a Linux box since 2.6.16 to follow the most current developments. I'm running 2.6.22 now and have great respect for the way they use SMP to enhance reliability. Short of a hardware failure, it simply doesn't crash. The way I use a computer, getting an hour uptime out of XP would be rather remarkable.


Not news, this is normal (1)

CodeShark (17400) | about 7 years ago | (#19719003)

Within every IT organization I have ever dealt with, Open Source or not, all but a few of the most talented programmers inevitably move to code oversight roles, and for a simple reason: their knowledge of the "why(s)" in the code becomes vastly more important than the code itself. Consider these two:
  • Samba (for example): Which is more important now, for the original coders to write new code, or do be able to oversee the current code base and insure nothing that M$ can use as a "we own the patent" hammer creeps into the code.
  • Data quality and security conformance to government rules: which is more important for the talented programmer, to write new code, or make sure that the code as written and the data rules as written meet Sarbanes Oxley compliance?
The other aspect of code oversight being a role for the most talented is the fact that programmers in the 18-35 age range tend to be willing and able to put in the extreme hours of coding time required for prodigious quantities of code, but there is no guarantee of quality without oversight by a more experienced hand. So one senior coding guru's guidance of many newer programmers is a much better use of time.

Circle of life! (1)

ceeam (39911) | about 7 years ago | (#19719243)

More appropriate caption would be "Top Linux developers are replaced with new ones as time go by".

Stop the presses! (1)

MrZaius (321037) | about 7 years ago | (#19719347)

Stop the presses, stop the presses! We've got to go with a new lead story: "People gain experience, get old, assume managerial positions!"


Management is just another form of coding (2, Insightful)

Fractal Dice (696349) | about 7 years ago | (#19719359)

They haven't stopped coding, they just code in a higher language - just as C can take care of all that dirty assembler for you, a human coder can take care of all that dirty C. You just sit back, watch the code flow past, filter it and nudge it in the directions you need it to go. It's bleeding edge technology, it's just the system requirements are a little steep for most of us to assemble - give it a few decades and I'm sure we'll all be coding this way :)

Better Headline (0)

Anonymous Coward | about 7 years ago | (#19719623)

Top Linux Developers Using the Wii To Code!

As time goes on, it sounds very similar to (0)

Anonymous Coward | about 7 years ago | (#19719723)

Communism. With the communist nations, people got tired of trying to innovate anything or working as they got nothing for it. Where is the drive for anything with communism? This is the biggest reason communism has failed and will always fail. This is why Linux "or open source period" has failed and will always fail.

This isn't meant to troll or flamebait, but the evidence is pointing in that direction.

Reviews are important (1)

zdzichu (100333) | about 7 years ago | (#19719801)

Reviewers are important. Just about anyone can write code. It takes much more skill to analyze somebody's else writing, think about impacts, possible bugs etc. Reiser4fs was stalled so long because there was no person simultanously fluent in filesystem and willing to review its codebase.

Reviewers are often unrewarded for their work. At the end of the day, person who wrote code takes credit, not all those nitpickers who helped raise the code quality.

Re:Reviews are important (0)

Anonymous Coward | about 7 years ago | (#19720411)

> Reiser4fs was stalled so long because there was no person simultanously fluent in filesystem and willing to review its codebase.

It doesn't help that Reiser wrote it in a highly idiosyncratic code style, then when people asked him to code it to the kernel standard, he pitched a hissy fit, accused everyone of conspiring against him, and threatened to take his ball and go home (and more than once, the response was "there's the door", but he never took it).

Wii? (1)

Monoman (8745) | about 7 years ago | (#19719865)

I read Wii (instead of Will) at first and second glance. I don't have one but it is obviously in the headlines too much. :-)

Fundamental Flaws (4, Insightful)

rAiNsT0rm (877553) | about 7 years ago | (#19720243)

I spend a lot of time online trying to get through to folks on this issue but everyone just blows it off. I have been a Linux user/contributer for over 12 years now and have nothing but the best interests in what I say. The biggest problem is the fact that the only area to have any management and direction is the kernel. The rest is far too chaotic and self-serving to ever become a cohesive system.

Some examples: OS X. In ten years or so a fairly small team has taken BSD and turned it into what it is. In over 12 with Linux I still see many of the same issues and problems persist... why? Because Apple *focuses* their efforts and the entire project is properly managed and steered. Imagine with the same focus and direction what the huge amount of OSS talent could accomplish?

Interoperability. Most applications are one-off programs made with no thought or care as to how it fits in the bigger picture. Unification, interoperability, and consistency are very important.

Fleeting Nature. Projects worked on while in college, hosted on random servers, work/girlfriends/distractions. These all can bring even successful and popular projects down overnight.

What needs to happen is to work under a single focus to create the most perfect distribution possible with clearly defined goals and concepts. Democracy, choice, and chaos have their place and they can be utilized still... just with some oversight and management before it goes live. Once there is a very good foundation (such as how OS X is now) then folks can branch out and work on their own projects and offshoots. I'm not suggesting that all choice needs to be eradicated, just that instead of trying to build a million individual sandcastles on a foundation of Jell-o we could be building a mansion on a sheet of bedrock.

The talent is here, the passion is here, the momentum is here... the oversight and direction is not.

Re:Fundamental Flaws (0)

Anonymous Coward | about 7 years ago | (#19720401)

It's always nice to run across someone who has all the answers.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account