Slashdot Mirror
Linus Does Not Scale
EmilEifrem writes: "Seems like everybody's getting more and more frustrated by Linus' (in-) ability to handle patches. Rob Landley just wrote an "RFC on Penguin Patch Management" wherein he proposes a "Penguin Patch Lieutenant" system that he believes would scale better. The full discussion can be found on the Linux kernel mailing list. Linus seems to dislike it, as usual, source code maintenance tools/organization are for wimps!, but a lot of others find it a good idea. Anyway, it's a very good read."
Why is there not a CVS for the linux kernel?
After all, that's what you get with a monolithic kernel and it is only going to get worse. The writing is on the wall and the solution is over here.
How we know is more important than what we know.
It's got to be a pretty small group of people who are annoyed by Linus' in-ability to handle patches... specifically those writing the code! I'd think it pretty important to keep those folks happy, since without them our beloved little OS wouldn't progress as quickly as it does.
"This above all, to thine own self be true"
To make a long story short; Because Linus doesn't want one. It has been proposed many, many times, but Linus has always shot it down. Logistically, it would be a bear anyway.
You know... If we had a Beowulf Cluster of Linuses...
*rimshot*
How about a RAIKA? A redundant array of Kernel Admins? Maybe keep them hot-swapable? That way, if one goes out to the pub, the other one can keep things going....
OK, I'll just shut up now...
Objects in the blog are closer then they ap
I can see where Linus is coming from; Linux and Linus Torvalds are inextricably linked in the public perception, so any huge blunders that occur with the Linux kernel will sully his reputation. If it's his reputation on the line, he probably wants to keep control of potential disasters close to him.
Better to get blamed for your own mistakes than for someone elses.
but is there really anything wrong with using CVS?
Tarsnap: Online backups for the truly paranoid
Linus seems to dislike it, as usual, source code maintenance tools/organization are for wimps!
This attitude seems pretty common, even to me, and I don't run Linux. Linus takes a lot of flack for his methods of running the kernel development, mostly from people who think that they have a better way.
Try to remember something. It's his baby. It's his kernel. He doesn't owe you a goddamned thing. And if you've got a better way, start your own Unix style OS project.
(Reminds me of the book _The Moon is a Harsh Mistress_ -- after the Revolution on the moon is complete, then all of the armchair politicos come out of the woodwork to say how it should be. The analogy to the current situation is an exercise left for the reader.)
--saint
I thoroughly agree. Like many people I hold a fair bit of respect for Linus. However, Linux is starting to get to the stage where one man cannot possibly keep up with what's going on.
With this proposed system he could still maintain control, yet pass on the mundane task of merging. Seems like a great idea.
-- main(s){printf(s="main(s){printf(s=%c%s%c,34,s,34
Of course it doesn't scale; it's a monolithic OS. Hopefully, someone will fork it and bust it into bite-size microkernelish pieces. Or, better yet, kernel developers will migrate to HURD.
I personally think this is a good idea. Coordination would speed up development and improve the linux kernel
You know, with Linus's many comments about kernel latency and pre-emptive kernels, you'd think that he'd be all for imrpoving kernel development latency!
Moderation: Put your hand inside the puppet head!
not integrated into the kernel? That is FRIGHTENING!!!
It wont be long before the MS camp picks up on this and starts to use it as a weapon - not that we havnt had to wait a year or two for bug fixes from them in the past. But Mr Torvalds isn't doing himself or us any favours on this one.
David U.
# Hack the planet, it's important.
How long before the Linux kernel is forked by someone that actually does version management with CVS? Linus' Linux versions could be patched back into the CVS/Linux code, while developers could focus on the actual problems at hand instead of messing with patches, submissions and the general frustration of getting you patchest dropped by Linus.
Before everyone flames Linus for his dislike of CVS and other management tools ....
From Kernel Trap:
His general point is summarized with this statement, "One 'patch penguin' scales no better than I do. In fact, I will claim that most of them scale a whole lot worse". He goes on to explain this statement quite thoroughly, adding: " In short: don't try to come up with a 'patch penguin'. Instead try to help existing maintainers, or maybe help grow new ones. THAT is the way to scalability".
Say what you want about Linus' attitude - Having a kernel lieutenant probably wouldn't help either. Either way, there's only so much one person can do.
It all worked before because (1) Linus could wrap his head around the entire mass of kernel code, and (2) the kernel itself was much simpler, and (3) there were far fewer people submitting code to Linux.
This is all out the window now. The kernel is very large, and continues to grow, and Linus can no longer track the project just using his head.
In short, Linux is growing up. What it grows up to be I guess we'll see in a year. Either it starts using professional tools to manage this increasingly professional project, or the bloat (yes, the kernel is bloating) leads to unmanageable chaos, and the bloom goes off the Linux rose.
*during the war...*
my 0.02 Eu:
I used to work in an environment (nuclear power) where we had a robust and comprehensive engineering change system, with umpteen layers of peer review, administrative interlocks and independent assessments for any changes to the System. The root of it all was the Quality Assurance Policy, under which were the Management Control Procedures and then the people doing the work. It may be overkill for and OS kernel, but maybe these guys need to think of using such a system (but cut down) on their kernel?
I'm out of my tree just now but please feel free to leave a banana.
Rik van Riel on Kernels, VMs, and Linux certainly has a few complaints regarding this issue!
It's bound to be said, so why not by an AC?
FreeBSD core/committers is an excellent model,
indicative of the relative maturity/experience
of the individuals involved.
No egotistical "I must approve everything".
;-)
Slashdot angers me. Long story short, it's a bad solution for a problem already being fixed properly.
For those who don't care to read the discussion, Linus essentially feels that this is a bad idea because no general patch manager is going to scale better than he does or get burnt out less quickly than Alan Cox.
He then goes on to say that the solution to the problem of the scalability of one maintainer is to partition the different subsystems of the kernel to such an extent that there would be precious few patches that actually require a knowledge of the entire kernel source.
this same subject pops up. It's the same on Debian lists: every now and then people say how frustrated they are with the slow pace of releases and propose some new scheme which usually doesn't even differ from the old one.
Software problems are solved by coding. The core kernel people, like core Debian people, have thought about these things before, and are doing their best. All these blatherings do is waste everyone's time.
If one Linus doesn't scale ... maybe we should try out a beowolf cluster of Linuses.
Linuses? Linusi?
For example, there was a bug in the ne2000 driver that Alan Cox points out here. According to Mr. Cox, "this is one tiny example of maybe thousands of other similar flaws lurking. There is no obvious automated way to find them either."
Lots of corporate/management types have the negative impression of Linux as an OS that has no professional control over kernel development. It's seen as a souped-up hotrod modified in the garage that runs like a dream but could fall apart at any minute. Hell, even a lot of BSD people see it this way. If (*if*) a goal of the Linux community is to gain wider acceptance or be taken more seriously, one way to do that might be to give more than one person final say over the kernel.
Yeah, it's Linus' baby -- but once IBM is advertising your OS during the superbowl, it might be ok to expand the development structure a little bit.
Who is Linus?
That kid with the blanket out of Peanuts cartoons. Everyone knows that!
"Information wants to be paid"
i for my own like the idea getting XFS included into the kernel tree.
I thought somewhere along the way, the developers that be, agreed to accept a star method. Where people submit their patches to the Lieutennants (sp?) and then they do most of the work, and then just pass them on to Linus as appropriate?
Maybe we just need more Lieutennants?
Maybe we just need fewer patches!
If Linus were to have a CVS, then he'd loose control.
He LIKES being 'in charge'. CVS means instead of a dictatorship, you get a Republic. (And if you were submitting code to Apple's CVS for Darwin, it would be just like the USA, a coprerate sponsored republic)
I will take no stance on this issue, as i only work with things that are profitable to me - I'm not a religious fanatic when it comes to Linux, *BSD, or any other operating system - I'll defend them all on their benefits and acknowledge their weaknesses. But i do need to propose the question: Do you think any other "upstart" operating system could gain the popularity and momentum of Linux?
that we need to fingure out how much of linux is linus... if linux belongs to linus then it is his to do with it as he likes... as much as we all hate it, it is our fault for using something that is dpendent on someone else
the way that people are complaining here kinda reminds me of a stranger coming into your living room and demanding that you change the channel becasue he does not like it.
If you dont like the channel, then why are you in the room. You have no right to make demands when it is not your property, no matter how much you may be dependent on it
The war with islam is a war on the beast
The war on terror is a war for peace
A prediction, pulled from my ass: Here's what I think will happen.
i) A respected developer (Alan Cox, perhaps) who already has their own patch tree will open it up via some source management system
ii) Other developers, including those frustrated ones, will begin to use it, including keeping it roughly in sync with the official tree.
iii) The forked tree will develop as fast/faster than Linus' tree (assuming the pro-CVS people are right)
iv) LT will realise that its not a bad idea, and essentially adopt the forked tree as his own, complete with CVS.
In short, theoretical arguments for CVS will continue to cut little slack with LT. A demonstration of its effacacy will be very persuasive.
If (iii) is untrue, the argument will be moot anyway (why have source control if it doesn't help?)
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
I think this problem points out the biggest issue in regards to Linux--its almost anarchist style of code development.
I think the folks at IBM and Oracle ought to seriously have a LONG talk with Linux Torvalds himself and convince him to create a true clearinghouse where every improvement is approved by a committee. That way, Linux improvements happen in an organized fashion, which makes things way easier for developers and IT managers.
You married yourself?
The basic premise he makes is one that many developers seem to miss. To quote Linus:
From that, he goes on to point out that people tend to have a small group of people they work well with and trust; perhaps 5 - 10 people. So, in essence, if Linus appoints 5 - 10 maintainers of major subsystems (which he has), and each of them has 5 - 10 people the trust to maintain specific aspects of their subsystem, then there is no problem.We're not there yet. But that is the only direction I can see that will work, long term. It just takes time for the appropriate people to move into their spots; trust takes time to build, and the structure has taken time to modularize enough to allow this to work.
And, though I would prefer to see it in use just to make the maintainers' jobs easier, CVS will do nothing to solve the problem. It is a tool, not a process. We need a process. Actually we have a process, it just isn't fully implemented yet.
No, strike that. We have two processes. The first, used by the bulk of the kernel hackers, is not fully implemented yet. The second, used by a minority of the kernel hackers and a large part of the pretenders, is simple: whine alot, and, when that doesn't work, whine some more.
Linus says it much better, and in his own unique ... er ...
Idium, sir?
Yes, in his own, unique idium.
Now, how to move forward and expand the circle without diluting the value that he brings. Something like CVS can help, but the base problem isn't technical and the solution won't be technical, either.
The real problem is factoring out that part of the Linus load that Linus does better than anybody else can do, and offload other parts to those who can do them better than a loaded-down Linus.
The hard part for everyone, Linus included, is to understand how much the "other" part feeds into Linus's ability to do the "Linus" part.
Sometimes, even mundane tasks help you to maintain the vital connection needed to do the great things well.
I'm just glad I'm not the one having to work all of this out!
Go from a mostly working project to mostly not working project. Wow. That's progress.
To avoid the problem of Linus and the Linux kernel, I'll suggest here, here, or perhaps here You could even go get Debian/NetBSD, or Apple's Darwin if that floats your boat.
When ideals and/or ego enter the fray you have to be careful. This could alienate the very people that are needed at this time and cause Linux to loose steam. Yes, it's his toy, yes he can take his ball and go home. But hopefully this won't cause a major split similar to what happend to Unix in the 60's/70's.
Personally, I hope I'm wrong.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Errr, but the new Mac's ARE BSD.
I think it's only a matter of time before the official Linux kernel development switches to a "core group" model working against a private source tree using version management software rather than a straight hierarchy. Core developers can check in, everyone else sends patches. When it happens it will be quick and the scalability benefits will be obvious.
I'm not saying this as flamebait or to say so-and-so is wrong. I have a great deal of respect for Linus Torvalds but his brain-child has outgrown him and at some point he needs to let it go outside the house.
He's not getting any nookie till he patches the holes in his girlfriend.
ba-dum-bump
So you wouldn't be able to call it Linux? If you think you can do it better than Linus then by all means do! As long as you release the source code you are within GPL.
Copy the Linux kernel source to another location, and import it into a CVS database under a new name. Of course, then you're playing with Linux the game which BSD plays with all software projects. You'd better be sure you can organise your code to easily import features and fixes when Linus gets something you don't have.
--- Nothing clever here: move along now...
If it becomes necessary, we can always fork and branch the development tree further though that will further burden the main development branch so we'd like to avoid it if at all possible.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I think most people who read the email assumed that the "patch penguin" was a machine with out reading the email. But the proposal is that someone (Dave Jones) take everyone's patches and filter them on to Linus.
It's not that Linus doesn't like organization, it's that he likes patches to come from maintainers. If Dave Jones gets all the patches he's going to be as overloaded as Linus is.
There is absolutely nothing wrong with using CVS. Your question raises a larger issue, however. As with any large project, it is difficult if not impossible for one person to have knowledge of the entire scope. Linux has become bigger than Linus.
From its very beginning, Linus has kept a tight rein on Linux, and everybody in general let it go if for no other reason than he's a smart guy and by God, he wrote the thing! Don't get me wrong. That was a Good Thing (tm). Now, however, we are finding that it is becoming less and less practical for Linus to handle all of the patches.
Linux is becoming more and more like a cathedral and less and less like the bazaar. Whether he likes it or not, for Linux to continue to thrive (perhaps even to continue as we know it) Linus is going to have to decentralize the way patches are brought into Linux. I don't claim to have all the answers, but there must be a way to make a CVS-a-like system work and keep Linus' ability to make the final say if he wants to. Another alternative is for Linus to put more trust in his maintainers and let them accept patches for their respective subsystems.
The problem here is the star network topology that we have with respect to patches. If Linus is not willing to release his hold on the center of that star, then Linux could have a MAJOR problem!
Ben
The fact that a company that's been going out of business for twenty-five years has adopted BSD is just proof that *BSD is dying .
Yes, if it provides significant advantage over everything else available. That's how Linux became popular when people were asking 'Do you think any other "upstart" operating system could gain the popularity and momentum of Windows?'
Higher Logics: where programming meets science.
Correct me if I wrong, but I don't see any good reason why a very big project (Linux kernel) still has one maintainer for active development.
Now I'm no kernel hacker, but I do think the current system could use some improvement. Wouldn't it make sense for the kernel to be split into sections (device drivers, memory/thread manager, etc) with each section having a maintainer and one "integration manager"? (Applicable areas that could be subdivided, like drivers, could divide by type again.) If the system were properly modular, the integration manager would just have to make sure that the interfaces between the systems were well designed, don't change frequently, are thourally examined between changes, and that when they must change they are reimplemented nearly simultaniously in all affected subsystems. (Hopefully, any given subsystem could also undergo rewrites without affecting other subsytem code.) Again, I'm not seriously looked into the kernel code (yet!) so I have no idea how things work right now... but the scale IMHO requires a division of the labor. (Formatting the code to match would serve to further reduce the labor involved in maintainance.)
Do you like Japanese imports?
So everyone is supposed to have their own copy of the tree to make patches to? Without a 'source' CVS to sync it up to before submitting a patch, why would anyone WANT do that?
What if I submit my patch, and make changes that conflict with SamtheEagle's source tree he's workting off of?
I think there should be a source CVS tree, that Linus maintains. Before I submit my patch, I should sync my CVS to Linus', and apply the patch. Then submit the patch, referring to the current tag on the source CVS maintained by Linus. That way, Linus can apply all patches serially, and make requests to developers to resync submitted patches, when a new CVS tag is created.
No 'patch' management program, just a way to serialize patches for applying to the source.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
I think I'm not alone when I say that, when I came to linux a few years ago, I was very impressed. Stability, speed, tons of functions, and a lot of configuration...
Well, that was all well and good. What was not all well and good is that, like so many others, I didn't actually write anything for the kernel. I assumed it was in good, and (as I have no real OS-level programming experience) more capable hands. I know that was what I was thinking when I explained to others why linux was so cool, and would always keep getting better. People would keep on sending in improvements, and these improvements, when approved for absolute stabiity (Alan Cox's old job mentioned in the leter, wasn't it?), they would be integrated into the sacred source.
Sigh. Well, that assumes the improvements get accepted or even seen in the first place, doesn't it? Linux is a huge development project (I mean, come on, it's an OS), and anything made in last I don't know how many years of development of any significant size had ought to have a tighter system of management; human or not. I'm a little worried that Linus has any opposition to these sorts of things. I'm actually amazed that linux got this far without more- I always assumed there were some definite mechanisms of the sort involved (hence my regret for never messing with the "sacred source"). I always just assumed there were.
Now I am surprised there wasn't a call to action before this. In a project of this nature, with so many people, projects, and significant economic forces putting their investments of time, money, and effort into this, you'd think that something would have been done when good patches started getting dropped. If that is the case something has to be done now.
Like I said, I never messed with the source. I never fixed anything; I never submitted patches; therefore I never had this problem. In short, I never knew. I was never involved, and never felt I had to be- I mean, better heads than mine were on the job, right (I said the source was "sacred")? Well, not all heads are better at everything, and I think that the more heads invoved, the better off this would be (at the very least, we would have reached this crisis point sooner and come to some decision on how to handle it). Maybe if some of the right people got in on it earlier, an appropriate management system would have been advocated and introduced- and these problems would have been minimized.
Possibly not. But more has to be done on this. Linus' counterpoints are well argued, but if lots of valuable code patches are really being (uneccesarily) lost due to the current system, are they good enough?
That's right! To help humans and the activities of these humans. Now, here we have a complex organisation-related problem (software versioning), which takes a lot of effort and energy from the human(s) involved. Instead of using computers and specialized software to HELP the humans involved and thus make the process a lot simpler, the human(s) involved disagree and try to keep the process non-automated and without computers.
Hello? What if a big company says: "To hell with computers, we do all our business-directing by hand, without decision support systems etc..", is that a clever move? No! Humans are not capable of processing a lot of complex data CORRECTLY. Computers do. Use them, whenever they can help. To avoid using computers in software versioning is IMHO one of the most stupid things you can do. What do you think, that Microsoft used Bill Gates' brain to organise the 35 million lines of sourcecode of Windows 2000?
Never underestimate the relief of true separation of Religion and State.
The economic conditions and overall attitude of the IT world was a lot less foreboding then. In the IT shops i've been in recently, Linux is a word not to be thrown around, especially on anything the investors may read. If, say, HURD or a BSD could do such a trick, i believe it would take at least $x amount of time before the world would be ready for it.
FYI, Linus is married... he has children.
From that, he goes on to point out that people tend to have a small group of people they work well with and trust; perhaps 5 - 10 people. So, in essence, if Linus appoints 5 - 10 maintainers of major subsystems (which he has), and each of them has 5 - 10 people the trust to maintain specific aspects of their subsystem, then there is no problem.
There is theoretically no problem, when there are small 'patches' (or better: fixes for glitches) which fall totally in 1 subsystem's area. However, what if a patch spans more than one subsystem? Or better: what if a patch needs changes on another subsystem? In an OS, it's placing foundation on foundation, layer on layer, they all depend on the layers/functionality blocks below that layer. You can't just say: "Hey, John, you do VFS and you, Dave, you do the VM", because the VM needs services of the VFS and vice versa.
If you have a designmanifest which has to be implemented, you can point to people which control certain parts of the project, WHICH don't have to be subsystems necessarily (vertical segmentation), but can be seen as horizontal segmentation: one group does the core layers, other groups do the layers ontop of those core layers.
Never underestimate the relief of true separation of Religion and State.
Although Linus has done a great many things for the Linux community, the development of the kernel is far to large a project for one person, especially if that person is actively developing. It would benefit the Linux community greatly if Linus stepped down from patch management, and if he gave some of the kernel development "okay" power to a group of people. Linus appears to be doing nothing more then slowing down the development of the kernel. If he's not willing to do this, it might be a good idea to split off the kernel development to another group without his okay. I know, fued.
GeneralKael -- Slacker Extraordinaire
What is the solution? There are lots of possibilities, but they all come down to either changing to some other programming language, or emulating what other programming languages have built in "by hand".
Something like an Objective-C runtime, where you can replace classes and methods at runtime and where most important function calls go through the runtime, would allow most of the kernel functionality to be changed and enhanced by separately developed modules without requiring patching all over the place. Such runtimes are very efficient and would probably not make a lot of difference in terms of performance. Another approach is a Mach-like microkernel. If people want to stay with plain C, another solution is to add lots of hooks for everything (kind of like you have in Emacs).
Even if this were to make the kernel run a little slower, what good is it to have a kernel that runs blindingly fast but doesn't do what I want and doesn't have drivers for the devices I want to use?
I'm reading lots of comments on this list about "the patch penguin will scale only as well as Linus, or maybe worse", or "Linus is right". But I'm not so sure that I agree. Having read the original proposal and the entire thread (as of last night around 1am EDT) I think that the proposal is a way of getting Linus to do what he does best (architecture) and relieving him from the mundane duties like trying to make sure that a submitted patch actually applies properly. Once the patch penguine does that kind of stuff, then Linus can review it.
Of course the advantage of this is that the mundane stuff can be done in parallel to the architectural stuff.. thus allowing more than one thing to get done at a time. Where as Linus himself can only do this serially.
The reason that this is important is that there is a very large backlog of patches that are simply not getting applied. Allegedly the whole VM issue could have been resolved if Linus had enough time to look at and apply RvR's patches. What this means is that Linux, with the inability of kernel maintainers to effectively submit patches, is turning into Minix. Remember that Linux was born out of Linus & others reaction to the fact that patches submitted to Minix couldn't get applied and redistributed (for copyright reasons). Which meant that in order to get a reasonable system, you first had to download the unpatched code, then go through a little patch-o-rama. It was ineffective. The current patch log reminds some of that situation, and has some fearing a potential kernel fork.
Of course, the biggest question that I have for the proposal is that Rob wants to just "formalize" a position that already exists and is being done, to some extent, already. If the position is already in place and already operating, then why is there still a patch backlog? How does formalizing it actually improve the situation?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Disclaimer: I'm a FreeBSD fan and generally consider Linux et al to be one of the most choatic and sloppy large-scale development projects ever created. Just being a Linux user requires dealing with an absolutely insane about of pointless choas; I fear to imagine what trying to be a maintainer must be like...
That said...
"Just use CVS" isn't anything remotely close to an answer. SCM, release control, whatever you'd like to call it is 99% about the PROCESS, not the tools. CVS is a tool. It's a great tool and one I highly recommend, but at best it's 1% of a solution. It seems quite obvious that Linus's current process is incredibly flawed. It would seem a drastically different process needs to be devised. Only once you have figured out what your process is going to be can you even start shopping for tools (CVS, whatever) to help you create it (and even then...the tools are only 1%, if you even have tools. The PROCESS is what's important).
Of course "CVS forks" of Linux failed. Anyone with even the slightest understanding of CM could have easily predicted such an end. You've got a handful of people, not even the top people, trying to constantly fold in the efforts of thousands of contributers all using a completely different process (ad-hoc patches emailed to devnull@linus.org). What did you expect?
You have two choices. Devise a workable process which Linus will agree to (with or without CVS, whatever). Or, you can devise a workable process that everyone else is happy with...and simply throw Linus off his paper throne. The first option will likely never, ever happen...at least if every single word Linus has ever uttered on the subject isn't true. The second option might actually welcome the dawn of a non-choatic Linux, one which wouldn't be so easily cast aside as a cheap toy made by a small man with a big ego.
Linux/Linus Flame (-1k Karma)
My
... but neither does kerneltrap ...
This is NOT an empty signature.
Well, the subject says it all. Why not provide read-only CVS access? You could even open it up as read/write to non-developers who have something to contribute (say, folks working on documentation... mmm, a well-documented kernel! What a concept!)
It can be carry out in two steps:
- E-mail bugs to the bugzilla system.
- Only accept bug from bugzilla
(bugzilla.kernel.org idea)That's only an opinion, IMHO .
If you read Linus' reply to this you'll see he argues that the 'patch penguin' merely replaces him with someone else, and does not actually help distribute the work. He also comments that it may be better to submit patches to subsystem maintainers.
This being the case, why not just automate that? Subsystem maintainers are effectively maintainers for a known group of source files. Its not hard to figure out (automatically) from a patch which files are affected - and from that, which maintainer(s) the patch is relevant to. Given how Linus describes his 'trust network' it looks like he wants a hierarchy of subsystem managers who can merge patches for him to accept upstream. I can see that scaling a lot better than the proposal in the article.
For this to work of course, you'd have to hope the patches had reasonably local scope - if most patches affect >1 subsystem this isnt worth doing at all.
- Baz
The whole kernel thing has to stop being like the Holy Roman Church and more like a democracy. Although commercial, closed software benefits from a hierarchical leadership system where a small number of people have the final say on where a product is going, an open project that is so visible as Linux needs a more "for the people, by the people" approach. I understand the need for one person to maintain a semblance of control, the entire decision process as far as Linux is concerned is hampered by the autocratic style under which it has operated since it began to grow so explosively.
Linux doesn't need a "patch manager", it needs a House Of Commons or a Congress or whatever you want to call it. It can't do away with the president and the chiefs of staff, but it has to have a heck of a lot more checks and balances than it does now. And it definitely needs to be a lot less autocratic.
Eventually, we're going to see more and more forks as people begin to understand that the OS is no longer Alan and Linus' own private playground but a heritage of the people who use it every day. While they bicker and fight over who gets to play king on a given week, someone is going to pull the rug from under them. Royalty has always been tolerated while the populace is enamored with its trappings, but revolutions do happen once in a while.
Worst case scenario the coders fork and tell linus to screw himself. Yes, that would be harmful in many ways, but it would also probably bring a lot of new interest to the project.
Grew a beard, i bet by the time he reached 40 some kids would call him all sorts of name, and say that he is a threat to the movement, just as some are saying about this bearded weirdo who wrote some strange license.
more seriously, i think linux is still very much linus's baby, and making him accept this is gonna be pretty difficult.
it'd probably be a good thing though and certainly speed up the developpement.
hopefully we wont end up with some mad dramas, but experience as shown Linus is not always the kindest of leaders when presented with ideas that differs his
if the sites slashdot links to get slashdoted, how come slashdot itself never gets slashdoted??
Hey, he's in need of an oversight committee to keep him in check! I nominate myself as committee head! Oh, ok, I don't understand most of what kernel development is all about let alone program myself out of a paper bag but wouldn't I be perfect for the job? I think so. I could be his tool to keep the whiners at bay so he could stop defending himself and get on with what he does best. My salary only needs to be 50% of what he earns as chief kernel architect. Let's see 50% of 0 = hmmmmm?
Get a life guys!
by no means is my programming skill good enough, however, I believe if Linus never touches a line of code again, he is a pretty good project manager. However, I haven't read the kernel list in quite a while. Am I wrong? Is he really a bad proj. man.?
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
All the talk about how amazing it is that Linux is done by amateurs in their spare time, etc. (to the extent it is true), just points out how susceptible it is to hitting this ceiling. I've worked on commercial OS projects for a Really Big Company, and we did bigger releases, quicker, and with fewer problems than we're seeing in Linux lately. The group I worked with was not necessarily smarter or better programmers than the Linux developers, but we were all full-time employees who had careers on the line. Few things motivate programmers (or anyone else) to do a good job like that kind of pressure.
I think people should focus on making Linus' job
easier rather than trying to divy up his job.
Instead of developing a heirarchy of control over
the linux source code, we should develop a system
for more efficient patch management for Linus to
use. Perhaps some sort of tool that would
auto-build kernels and provide an easy way for
Linus to see diffs of an particular patch and
comment on it to the submitter. If the patches
were all archived in a system of this type, we'd
likely hear the end of "you ignored me" complaints. The system wouldn't really have to
replace any existing mechanisms as it could just
ride on top of an email address and suck off the
patches (if they were submitted in some standard way).
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
I'm sure Linus is healthy and a good driver, but as misfortune befell a former colleague at another job (her car was parked at a light on the off-ramp which was below the highway, a driver from the other direction suffered a cardiac arrest, crossed the median and opposite lanes and went airborne, landing on her car as she waited for the light to change. Gone, just like that,) unfortunate things happen. It would be very tragic for his wife and child to lose a father. It would be a disaster for Linux, as the unifying person would be gone and in the aftermath someone would have to take control. I imagine Linus has already considered this, but his tight grip on the kernel is a bit worrying. He should delegate more.
A feeling of having made the same mistake before: Deja Foobar
I completely agree with you!
The part that makes *ALL* of these arguements stupid is that the Linux kernel is Open Source. If you or anyone else doesn't like the way that Linus is hadling patch management, or anything else for that matter, they are *free* to do their own. Go ahead, and fork your own kernel. Hell, build your own from scratch if you like. If your way is truely better it will be the defacto choice simply because it is better.
But, if you don't want to do it on your own and you instead *choose* to follow Linus and the direction *he* chooses to take, then you ought not complain about the way he does his work. You are not forced to follow Linus! You choose to follow Linus so if you don't like what Linus is doing, STFU!!!!!!!!!!!
Equally, get IBM/RHAT/other sponsor to donate a whole load of different hardware. Write a autobuilding process that runs lots of little tests -- puts up ethernet connections, pings the framebuffer, etcetc. If the machine is down, then the most recent patches broke it.
Mozilla development does this, but is obviously easier as it's not the Operating System they're testing, just a single application.
-- Azaroth
yeah boyee Red Hat HURD!
"...source code maintenance tools/organization are for wimps!"
I almost don't believe what I'm hearing. How do you manage development branches? How do you roll back your code to undo an enhancement you thought would work? How do know which bug fixes are tied to a particular instance of code? Wimp? More like "anyone who ISN'T using source code maintenance is a fool."
From what I've seen, in most companies you've got a lot of people offering opinions and a lot of people who should be making decisions but aren't. Then you've got one guy that is actually doing all the work.
From 30,000 feet, this doesn't look any different to me. There's a bunch of people offering up crap and one guy doing the quality work. Quality takes time, so those offering crap sit around and complain while the quality work is being done.
Rediculous, as opposed to what, greendiculous, bluediculous, PLAIDdiculous?
Ok, ok, I know coders can't spell... ;)
A feeling of having made the same mistake before: Deja Foobar
I know, I know. But really, does anyone know anything about Microsoft's structure? I assume they use some sort of content/people management system, and while they're *certainly* not perfect, I bet it scales better than the one man, one kernel approach. Any thoughts?
Perhaps this is a good time for a fork for those who are frustrated with the scaling issue. Linus can focus on his preferred method of maintaining the kernel and those with the larger scale in mind can implement theirs on a separate kernel. The beauty of the open source is that it is open source. If the new fork proves to work better, then parts of it or all of it can be imported back into Linux.
I am going through the comments, and I am confused as to where CVS is coming into this? Not using CVS or any other control management system is rather ridiculous. Controlling access to it, to Linus himself, or whoever else is approved to is another story. Using CVS does NOT cause 'bad code' to enter if you are not allowing everyone and their dogs to commit code to the tree.
;)
Linus is too arrogant for my taste, but as others have pointed out, it's his baby. I may not like his attitude in general, and may even disagree with his decisions.. but, hey, it's his final say. If you don't like it, use something else. FreeBSD doesn't seem to have half the _bad_ code the linux kernel does
Now I'm no kernel hacker, but I do think the current system could use some improvement.
So, you have no knowledge or experience with the subject at hand, yet you are eager to offer direction and implement changes. I see a bright future for you as a clueless PHB at any major corporation.
If LT left the planet, who would step into his role?
A lot of people have said CVS could not work, agreeing with Linus. Yet FreeBSD uses a CVS tree with multiple committers, and has had no serious problems that I am aware of. Infact, I would say they have had less problems than linux has had in the last few years.
cjk
Toothpaste likes you
You will forget this sig before you next see it
then {I should sue him for custody}
I almost don't believe what I'm hearing. How do you manage development branches? How do you roll back your code to undo an enhancement you thought would work? How do know which bug fixes are tied to a particular instance of code? Wimp? More like "anyone who ISN'T using source code maintenance is a fool."
You speak the truth.
Linus created what of the most significant pieces of software ever. However, as time has gone by, Linux's place in the world is becoming far more prominent. Billions of dollars are being spent worldwide, in some way related to Linux. As such, does it make sense to rely upon one man? I don't think the attention needs to be on Linus's shortcomings as a person; how about his shortcomings as a human? Humans get sick; humans die. If Linus was in a car wreck, what happens? If he developed a mentally debilitating disease, what happens? If Microsoft dropped $1B in his lap to start placing crap in the kernel, what happens? (I doubt this'd happen, but the ease of espionage and blackmail is far simpler when you have a single source) I think Linux is analagous to the early United States - yes, the "forefathers" are the ones who led and fought the battles, but it wasn't their country - the US was for the people, and as such, no one man could (or had the right to) control it.
The best thing about a boolean is even if you are wrong, you are only off by a bit.
This is a basic principle of leadership/management that the Army calls "span of control".
It has been proven (through all kinds of research) that any one person has difficulty controlling much more than 10 individuals, with 8 being a practical maximum.
This is why military units are organized in strict tree structures - at no point does any one leader exceed his span of control.
So an 8-man infantry section is controlled by a Section Commander (which can be further broken down to 2 4-man fire teams, but rarely). 4 sections report to a Platoon Commander. 4 Platoons report to a Company Commander. 4 Companies report to a Battalion Commander, and so on through Regiments, Brigades, Divsions, and so forth.
In this manner, the several thousand men in a large formation like a Division can be commanded by one man.
Further aiding the General in charge of the Division is that each sub-unit is granted a certain amount of autonomy within certain boundries. As you go up the chain, orders become more general (2 Battalion is to attack objective Oscar) and as you go down the chain, orders become more specific (Bob, you're carrying the machine gun)
While Linux development does not require this level of structure (and indeed, would probably suffer if this many authority-resistant cats were forced into such a regimented structure) the basic principle of "span of control" is still applicable.
The obvious correct solution is to modularize the kernel into subsections with clearly defined areas of responsibility, with a "mini-Linus" (who Linus trusts) granted control over each module.
Not suprisingly, this is what Linus has suggested.
The trick (and the catch) is two-fold. Firstly, you have to find people who are both responsible enough to be able to act as a "mini-Linus" without dropping the ball (which means Linus has to trust them too) and secondly, the kernel has to be modular enough so that changes in Module A do not step on or otherwise negatively impact code in Module B.
That's a hard row to hoe.
What I find a little distressing is that there appears to be a whiff of revolution in the air; of people talking about overthrowing Linus (and Alan Cox seems to be among them) This will not solve the problem. It is not that **Linus** doesn't scale, but rather that any single maintainer doesn't scale. Any revolution will just be "same shit, different name"
CVS doesn't solve the problem either, as anyone with commit privilages can jsut dump anything they want in there, and it becomes canon. Linus' function as a shit filter is very very important. every patch *must* be audited by someone with very high standards before it goes in.
I hope the crew rallies around Linus - as usual, he's right.
DG
Want to learn about race cars? Read my Book
I am tremendously impressed at the amount of kernel developers posting their opinions here today. It is truely heart warming to know that all of you are working so hard and so passionately on the kernel.
Just for the record. I have been very impressed by Mr. Torvalds work thus far. I feel that he is definitely on to something as *his* system seems to be working exceptionally well so far. I, regretably, am not capable of contributing to his work but, I do very much enjoy and benefit from the fruits of his labour. Feel free to fork, if you wish. But, for now I will continue to follow Mr. Torvalds> I feel that quality takes time and I am willing to wait.
Thank you, all.
If the kernel development situation gets any worse (or seems to be getting worse) it will only give MS more fuel to generate fud. Their claims about kernel forking and 'more than one linux, how can you support it' will begin to sound real. The kernel IS already forked with different distros applying different patches (Redhat does NOT use the standard kernel versions from kernel.org, hope they at least label their stuff to make this clear).
Linus better come up with a good answer to all this noise, or Bill Gates and company will!
Some 20 years ago, another open source operating system development group[*] had the same problem. At that point, several people had access to the source tree, each one supervising a certain area, reviewing and accepting patches for his area.
When that wasn't enough any more, several people were brought aboard to handle one area.
That's how things still work today, with a core team doing architectural guidance, developers who have write access to the source tree and who can make modifications on their own, of sent in by contributors and reviewed by the developers.
- Hubert
[*] The Computer Science Research Group, working on the Berkeley System Distribution's Unix variant.
What Linux needs is a five-year plan.
The coders and maintaners that meet thier five-year plan will get a silk banner with the logos of all the Linux Distributions.
No. In all seriousness, I don't know what Linux needs to solve this problem. But I know what it doesn't need. And that is a committee.
> So you wouldn't be able to call it Linux?
LEWNIX
LOONIX
LIENUX
LENNOX
But NOT LUNIX. Nice try.
WAREZ MY BROWN PANTS LOONIX ?!
How did you manage to disable the link helper???
Sorry but Linus Does Not Scale is a false statement. Who could say that (s)he could do better than Linus does.
It is an organizational problem. I think a system like bugzilla or another colaborative framework could be the solution.
The only matter is to find someone who as time and capalbilities to do and deploy it.
its easy to see why there will be no consolidated cvs tree for linux. that would make it too bsdish in developmental terms. shock horror gasp! we cant go against the gnu dogma! having subsystem maintainers (aka 'core') commit patches, well we cant move from a 'bazaar' to a 'cathedral' can we? that'd be sleeping with the enemy.
no sig for you
How about we set up a fund so that Linus can work on Linux full-time, instead of needing a day job? That's not a permanent fix, but it would help for a while.
I don't give a rats ass how long it takes linus to apply a patch. Linus does a wonderful job and I know he has my best interest in mind when doing that job. It is only a kernel for god sakes and it does just about everything it needs to do today and does it well. I care about stability nothing more nothing less. You can't just go yanking around with a stable codebase with a bunch of poorly tested patches and hope for the best, it just does not work like that.
Got Code?
I removed the bloom from my girlfriend's rose the other night.
Here's how it went down. We went to a party. I was tired of her not putting out (we've been going out for a whole week already), so I made up a special batch of punch for her and took it over to the apartment earlier that day. My friends were only too happy to go along. The punch was an extra-strong version of the vodka punch they were already serving, but with some sugar and lemon juice added to hide the gin and everclear combination (ahhh, gin and everclear - it's never failed me, not even once). Every time I got a new cup for her, I used my "special" punch. She normally doesn't drink more than three cups, but I told her it was pretty week, so she had five. Man, was she toasted!
So I took her home to her apartment. Her roommates were still out, so I took her up to her room and put her on the bed and unbottoned her shirt. She even laughed while I did it! I unbuttoned her jeans and pulled them down. Her panties were pink. I pulled them off too and spread her legs. Her pubes were light brown and not too think. Her lips were pink. She put her legs back together, but I spread them again and sat between them while I took my pants off. Man, was I ready. I laid down on my side, grabbed by dick, and rolled on top of her. I had a little trouble at first finding the right spot because the end of my dick was a little numb from all the beer I drank. But then I found the hole and forced my dick in.
I can't believe how tight she was! She didn't say anything, she just laid there. Here eyes looked a little glassy. I could tell the gin and everclear was really doing its trick because she didn't even flinch when I really had to get violent to pop her cherry. Finally I was in, and I got what I needed.
I fucked her three more times that night before I left. She was all sprawled out on the bed. I haven't seen her, and she hasn't even called me. All in all, I would say it was a successful relationship.
The problem is that people send him patches of bad quality, pushing a lot of work on to him which they should be doing themselves.
For example really big patches with only short descriptions.
Considering the amount of patches that he has to wade through daily people should try to make it as easy as possible for him. For example split the patch into more easilly handled chunks and write good descriptions for each part. This is not the case right now.
As "president" of FreeBSD. Then he had the courage to step down and become a "normal" member of the "core-group", a collective in which every member has the main responsability for a part of the FreeBSD code. Apart from the core group there are other committers but the core group decides who these are and can revoke commit-rights in cases of abuse.
This is a nice distributed system that continues to work very well when the load gets higher; also noone is indispensible, noone has to be afraid what would happen to FreeBSD if a certain person would somehow drop out.
Of course Linus has every right in the world to remain the status quo, even if it damages Linux. After all Linux is his baby and he can do with it what he likes. Whether it is a good idea to rely on an OS with this kind of a leadership structure is another matter however. But noone can force Linus to change, since he doesn't force anyone to use Linux (take it or leave it).
Imagine the terror of a 50 foot tall Finnish programmer wandering the streets.
Now let's just hope RMS doesn't scale either.
"rediculous"
Can anyone spell these days?
There is always the Hurd. If you think Linux gets bloated...
Assuming the kernal can get to the point where it can be successfully modularized to the point where changes in a given module are localized to the scope of that module (and let's be honest, that's a Mighty Big "If") then Linus doesn't have to give up the level of fine-grained control he likes. He can focus his attention on individual trouble spots, secure in the knowledge that the "mini-Linusen" are holding the fort while his attention is elsewhere.
Successful Generals lead from the front. Really successful Generals (Patton!) are not only at the front, but have the ability to select the portion of the front which most needs them at that particular instant.
WWI taught that lesson. Generals who sit behind the front lines waiting for information to reach them are too far away in both distance and TIME to be able to affect the outcome of the battle.
But I agree that the sticky part is getting this structure set up. Once in place, it works, and it offers the best chance of success from all points of view (quality control for Linus, patch responsiveness for individual coders)
I think the first step is for everyone working on the kernel to - on their own - determine who their subsection maintainer is, and only submit patches to them: this is another principle of leadership called "chain of command" and frees up Linus to do more "battalion" orders and less "Bob" orders.
But it has to be done SOON. I think it's clear that Linus IS losing control of the kernel - no WAY should that bogus "preemptable kernel patch" that keeps circulating have the life that it does - and Linus' control has been key to the quality control that has worked so well to date. The less influence Linus has, the more willing people are to put up with bogus and wrong code in the kernel, and the more quality suffers.
DG
Want to learn about race cars? Read my Book
If people submit crap into CVS (or Subversion, or Aegis, or SCCS, or CSSC, or RCS, or whatever fabled system may be out there), what you've got is crap in the kernel.
Automated tools have merits, but one demerit is that they make it easier for people to submit a thousand bad
patches per day
The wonderful relevant quote, from Mitch Radcliffe:
Computers
let you make more mistakes faster than any other
invention in human history, with the possible exception of handguns
and tequila.
Any would-be fork has to put a lot more thought into the political processes than into the technicalities of which version management software to use, otherwise you're arming the teeming masses with tequila and handguns, and that's hardly going to lead to reliable kernels :-).
If you're not part of the solution, you're part of the precipitate.
No source control for the Linux kernel? What the hell is going on here? C'mon, Linus, get a clue: source control is FOR YOUR BENEFIT. I've used SCCS, a little bit of RCS, and now I'm using ClearCase and can't imagine doing development without source control. The very idea just horrifies me and I simply can't imagine you're not using it! ARRRGGGGHHH!
Anonymous Kev
Proudly posting as AC since 1997
Linus and team are architects of technology, the distributions are architects of product. This same scenario goes on in the large Unix system development houses too.
Often there is conflict between the two in terms of goals/objectives, key values, processes, tools, practices, timelines, etc...
Understanding the key values of each team is critical in developing the correct practices, tools, and processes for the teams.
The challenge, I think, for the Open Source Community is to develop tools that will respond to different team values and practices, which results in providing support for the individuals to achieve their objective.
Regards,
Kramer
Amazing how many jealous little twits pop out of the woodwork when articles like these come along (including the author, it seems). You know the kind - they go on and on about how "Linux is bigger than Linus", or that "democracy is better than autocracy", or some such rot. None of these 'arguments' are more than nebulous, poorly-defined horseshit without so much as a smidgeon of hard evidence to back them up, but that doesn't stop the fools from spouting page after page of useless rhetoric.
What does it really boil down to? The complainers aren't Linus - that's the sum total of the argument. Linus is famous, Linus is respected, Linus approaches the status of a demigod in the eyes of a few - and the complainers are nobodies who'll never reach anything like this stature during the course of their lifetime. Envy galls them, so they do their best to try to pull down the guy who's exceeded everything they might ever hope to accomplish, all before the age of 40. Same shit, different venue.
What really points out these losers as vicious, jealous little maggots is Linux itself - they aren't in any way required to use it so they can, if they're so dissatisfied with the way Linus runs things, go off and use another OS. Or fork Linux. It's all good. And if they were serious about their unrest they would.
But that's not the *real* point, eh? The actual goal is to pull down Linus based on the age-old preschool argument "if I can't be Linus, then neither can Linus".
Transparent, pathetic assholes.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
"Hell, even a lot of BSD people see it this way"
Yea cause they are not a bunch of snobs who are jealous of how popular linux is. Next time why not use M$'s point of view on linux?
(Grammmatical errors on purpose)
One thing most people fail do undestand is that Linux is Linus's Project. He own the copyright.
Yes, I know it's opensource/free software, which only means that if someone does not agree the way Linus does thing, he can fork the project and do whatever he wants with it.
Actualy, this is was most distrubutions have been doing for as long as I can remember.
Okey, if you disagree, you can talk to Linus. But it's his call.
Ranting about it is just childish.
morcego
I think there is a possible solution, if we look
closely at what Linus was saying. He talks about
evolution. He talks about him not being
indispensable. He likes module maintainers. This
is all a part of the solution. The only problem is
that people percieve multiple competing kernels as
a big problem.
The perfect solution would be to have each module
maintainer release their own kernels, maybe not
naming it like -ac but -scsi or -net. These kernels
should only have only those module patches and must
be synced with Linus's kernel. Anybody developing
a patch needs to look into which kernel suits his
work most and sends it to the maintainer. The
maintainer adds it if it fits his kernel, other
wise the guy needs to try a different maintainer.
Once a patch is accepted into one of kernels its
the maintainers headache to sync with Linus. Linus
will be happy and everybody knows that their
changes have been included.
Because these same stupid questions have been asked over and over again over the years. That one about him dying is especially lame since its been answered so many times. Do yourself a favor and do some research for the answers. And no I'm not going to point you in the right direction.
Sure I'm all for OSX!! Just make all of it open source, free, and make it run on X86. Otherwise sit on it Potsy.
Three responses.
1) Why did you stay with a system you hated for 5 years? Plently of other free OS's around like BSD.
2)I guess your too fucking stupid to use RedHat Network or Apt-get.
3)Yea, we all know a windows install from three years ago only needs the occasional windows update to be secure and fixed. Do me a favor and send me your IP so I can rape your box. Honestly if you think that is all it take to admin a doze box I hope you get fired and have to sell your asshole on the street.
Jackass
Arrghh! I've seen this too many times on Slashdot. "He has a loose * tooth; he may lose * it soon." * Definitions courtesy of dictionary.com.
Badgeez?! We don' need no steenking badgeez!
Coding what? I bet your projects are a complete mess. Programming problems are solved by coding, but code management problems are solved by using effective process.
I remember that guy from the Bible, he was overburdened, just forgot the name now (yeah, I suck, I was supposed to be a good catholic).
Well, that guy went and asked his father-in-law who said, take 100 men you trust and make your lieutenants and make them choose their own 100 men of trust as their respective lieutenants...
Well, you get the picture (it's a tree).
We could do the same. But, be warned, companies are discovering that such a tree-like organogram bears trouble, so we would probably need some assistance in devising a lean organisation.
That is, if it is not already informally happening.
Linus is excellent and maybe the best of us but, as Ray Kroc once said, "none of us is as good as all of us".
Have a nice day!
PS: Now that I'm on the religion topic, a question (message) to muslims and jews: What would a FATHER think about HIS children killing one another?
I wish we can attain peace.
Says some no-name slashdot poster who's never even come close to submitting their own kernel patch? Look, numbnut, unless you are one of the people involved in the process, you "opinion" on the matter is 100% worthless. Join the fray and then comment, but talking out of ignorance is a waste of everyone's time.
In many of the posts (yes I read the whole thread) people state things like this:
"I perceive this to be true. Any objections? Now, since we've agreed this is a global constraint, here is a consequence of the aformentioned thing that I believe to be obvious and thus not requiring any objective support"
Then the other kernel hackers argue about the conclusions (which are typically quite logical) rather than the premises.
Here's an example from Linus: Now, I personally have worked with well over a hundred people, and I know that there are other humans who can do it (granted, it's a somewhat rare ability - like programming or musical talent). But nobody bothers to point out that Linus is committing the fundamental logical fallacy of ascribing his own attributes to all other humans.
More from the same post:and again:
Linus, I have tremendous respect for you (and I still regret the conversation we had at LinuxWorld that I'm sure you don't remember) but I think that these "obvious truths" are not obvious at all, and that more "thinking things through" may be required on your part. You do not have the same social or organizational abilities as all other humans.
Alan is one of the very few people on the LKML (as far as I can see) with the balls to say that important stuff is being dropped because the authors don't have name-recognition with Linus. Ingo has that name-recognition, so his patches get respect, and consequently he finds ways to excuse the (mis)handling of others' patches. Sorry, Ingo, but that's what I see.
--Charlie
Here's the Linux version:
-- @rjamestaylor on Ello
If you bothered to read the entire kernel thread, you'd realize that no one was "bickering": it's called discussing ways to improve the kernel patching process. Linus and Alan are hardly "playing king", and only an outsider wouldn't understand that.
Why would we want another quickly developed, but a shitty, broken OS? It's a frickin' hobby OS. People take it way too commercially seriously and that will probably ruin the good quality of it.
I think Professor Tanenbaum is laughing.
Its a lot easier to controll religious sheepeople than to control cats. If the typical religious person differed in perspective from the 'flock' as much as kernel developers differed from Linus, we'd have about 1000x more religions, or, at least a lot less religious thought. Both good things.
For me, I prefer cats.. They're so busy diagreeing with each other that they don't have time to fuck over my life.
I think some of you are forgetting that Linux is open source. If you want a version of Linux that has a different style of upgrading features and providing patches than what Linus does, then start your own version of Linux so you can do it the way you see fit. Isn't this one reason it's open source?
Its sloppy, yes, if you keep up with the bleeding edge. But, the bleeding edge is always sloppy. Linux, because it has the number of developers and a well known mailing list exposes that slop to the public.
I wonder, how sloppy would freeBSD development be if you synced your kernel hourly with the dev kernels? How buggy would it be? What does the interdeveloper mail look like in the freebad world?
I run kernels over a year old. There's no slop. I'm (mostly) happy. In about 6 months, I'll switch to 2.4.
If you want less slop, stick with a distribution kernel. They've chosen and tested it out to be stable and reliable.
IMHO (very humble in this case as far al kernel hacking goes, but I have been writing software for a decade, using various source control systems for half of that) the fact that Linus doesn't use any kind of source control/version tracking system is immature, stupid, counterproductive and just plain wrong on his part. It's shortsighted that a project of that size and importance depends on the buddy-system (ie Alan Cox has the source as well, etc..) for backups and revision tracking. When I write a few 100's of lines of utility code that i intend to keep, you bet it's in CVS!
No, CVS or other source control is not a magic bullet, you have to use it right. But if you don't have one, you don't even have a gun.
I'm not saying he should have a CVS tree with every joe haxor and their dog allowed to write to it. But no version history and change tracking capability at all! Gibber!
My Karma: ran over your Dogma
StrawberryFrog
Did the guy hit a nerve with you? Can you honestly say he's wrong?
Mac OS X and Windows XP working side by side to fight back the night.
it seems to me that it would be a Bad Thing(TM) if too many developers had free reign to add shit into the kernel... it would quickly become a completely unmanagable overbloated kernel. I think that there really needs to be a unified site to keep track of all kernel patches, so that you have easy access to the hard work these people are putting out, but without the need to clutter the kernel with tons of stuff most people may not need or even want. Then the decisions as to what gets merged into the main trunk of the kernel tree can be left up to Linus (it's his project after all... trust his judgement on this stuff!) but nobody's work gets shuffled under the karpet.
I thought the major distros (RH, SuSe, Mandrake) used modified AC kernels. I don't know about Debian, but I think they patch their kernels too. Slackware is the only distro that uses "raw" Linus kernels, and even they included a patch for the broken 2.4.5 kernel, though it was up to the user to apply it.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean.
I believe Linux 1.0 came out in 1991. Any new OS has a 11 year gap to close (except BSD which isn't new).
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
First of, Linus is Right. There, I said it. Why?
Because 10 is the practical limit to the number of people any project manager can be expected to directly deal with. And five is 'almost perfect'. Now, I will agree that, from a technical standpoint, Linus might need a second, not just for the "Bus Factor", but also for sanity-checking sake, to help smooth out issues where others might complain that Linus is playing napoleon. "Well, Alan agrees with me, so suck it"
I also think that we need to start thinking of development along honest PM guidelines. And Linus is right, here again. The maintainers for the various modules should be accepting and testing packages. OR, we need a set of people who will be responsible for various functional units of kernel design, a Portability Penguin, a Process Penguin, a Memory Subsystem Penguin, a Filesystem Penguin, a Networking Penguin, &c, who collect patches from the various maintainers. An org. chart where any single node has more than ten connections is useless, just as Linus suggests. These various, and God Help me, Project Managers, would be responsible for accepting patches and making sure they worked with the more core systems, and that things should be checked from whatever the most central modules are to the rest. And it all needs to be documented. There needs to be a Documentation Penguin, too. Dear god, people. Maybe we should all go read the Mythical Man-Month or something.
But then, I'm a freak. You can't build a car in a Bazaar.
see subject
(How many down-mods do I get for a catchy title like that??)
I think the problem is that the developers are arranged in the reverse of how they need to be. Linus has chosen the role of point man for advanced development. All very well, it's his baby. But lots of people, like me, need a stable kernel. We want the ultimate sign-off to come from quality control. The problem is that QC is subordinate to Linus. The patch penguin proposal doesn't do anything to fix the problem.
Ala Cox did a fine job on 2.2 as QC manager. Linus was off putting in new stuff. Trouble was, a lot of those neat new things never made it up to the quality needed for inclusion into a stable kernel. As a result, 2.2 stagnated somewhat, and when Linus decided 2.4's time had come, there was a major hiccup.
Will the same thing happen to 2.4/2.5? I wouldn't bet against it, unfortunately. It looks like cleaning up the mess that Linus left (like the VM issues) is going to take a while. By that time, 2.5 may be too far ahead to incorporate new stuff while maintaining quality.
If my thesis is right, what is needed is some way to bridge the gap between the development and the stable branches. Perhaps the "group of developers" can fill this, with the equivalent of a perl pump-king doing the final QC, with the final say as to what gets in and what doesn't. This would reduce the discontinuities when Linus says, "OK, now we're ready to start doing 2.6 or 3.0."
Maybe it's a revolt, but isn't this a revolution?
An on-topic first post is redundant? Twice???!!!
He may not have read the article but it's a valid point. I never understood moderator crack until now, and no I did not author the post.
Nobody is stopping anyone from writing a kernel patch management system. Perhaps, after a dozen or attempts, somebody will write a system that is simple enough, fast enough and good enough by various other criteria so that enough people will gradually start using it in large numbers, just like sourceforge, slashcode, cvs or diff and patch.
The likelihood that anyone will get it right on the first attempt is low. So, I think it would be courting disaster for the Linux kernel development community to commit to such a system in advance.
Did ANYBODY on /. actually read the ML Thread on this problem the kernelpeople have?
/.ers should read the actual thread before they post every instant and absurd mindfart that comes to them. Be it about jelousy amongst kernelhackers or Linus supposedly bossing around or whatever other sorts of utter bullshit.
Rob Landley and Linux Torwalds aren't bashing their heads in on one another nor is ANYBODY of the Kernel Team about to 'dethrone' Linus. Whatever that may be.
In fact Landley suggest a "Patch Penguin' to actually EMPOWER Linus in his actuall job as an arcitect of Linux.
Linus in turn says that officially shifting patchin jobs to somebody else (the said Patch Penguin) won't save the problem of, for instance, people being to lazy to clean up their code dependencies.
Linus wants to see a sort of 'web of maintainers' where everyone knows and works with a overseeable amount of others (just like he does) rather than a big patcheritis boiling around a main single/pair/group of developers.
It may, IMHO of a absolute non-kernel savy guy, kinda boil down to the monolitic/modular kernel discussion that comes up every know and then.
Then again, on the other hand I gather the impression that Rob Langley and Linus Torwals aren't that far apart in seeing the issue that needs to be addresses rather than seeing different ways of aproaching a solution to it.
Anyhow,
We suffer more in our imagination than in reality. - Seneca
for software precisely because the "general to specific" heiearchy breaks down.
It's not enough for Linus to wave his hands and say "we need a new VM", and then Joe hacker writes one.
Joe hacker, on the bottom, is fixing typos and writing documentation. Actually, Joe Hacker is probably working on apps.
The brigade commander, in your analogy, is writing the VM in bits and pieces. Linus has to go through it carefully and apply the diffs or not. Software is all about details. There are ways (e.g. modularity and interfaces) of splitting up the work, but only to a certain extent.
Imagine a war fought almost entirely by the general staff, with their subordinates serving as assistants and sopport staff -- it's the reverse of your analogy: A small group of people at the very top write most of the code.
When in doubt, have a man come through a door with a gun in his hand.
OpenOffice and KOffice
Linus' Linux and
So there is now talk of forking Linux.... I believe that almost everyone would be better off with a single open-source system. Sorry to those whose egos might be offended: Linux/KDE+OpenOffice. The rest waste OSS resources.
Please think. Dividing weakens. Uniting strengthens.
This does nothing to help those that take on the task of seeing which "bits of crap" should stick, and which should be dropped on the floor.
I don't see that SCM automation does too much more than accelerate the rate at which crap gets thrown at the kernel.
As for the JVM-like thing, it seems unlikely to me that this would be fundamentally helpful. You would see performance really sucking, because DSP-like stuff (like image processing, audio processing, GUI rendering) massively benefits from being compiled for a specific architecture.
If you're not part of the solution, you're part of the precipitate.
Seems to me that Linus needs to decide whether Linux is his pet hobby project, or a community effort.
This is basically CS202: Learning that in computer science, a lot of projects quickly grow so large, you can't do it all yourself. You need to cooperate with and trust other people. A hard lesson to typically anti-social CS types who likes to do it all themselves.
After all, not everything that's (+1, interesting) has to be a good idea. ;)
Anyway, you aren't actually accopmlishing anything but attaining buzzword compliance by slapping the
"CVS" label on what is already occuring.
Think about it. At any point in time, you are still going to have your patch synched against only one 'tag' of the CVS tree. Multiple patches are going to arrive with the same 'tag', none of the patches are going to be commited to the CVS tree (and trigger a tag increment) until they satisfy Linus. If multiple patches are submitted that conflict with each other -- well, you've done nothing to change that.
In fact, there is no functional difference between what you describe and just downloading the lates kernel source and syncing your patch against that. Except it's called "CVS" instead of "kernel.org", and if the tags get incremented faster than kernel revisions then you've actually -increased- the amount of re-synching and re-submitting that needs to be done.
The enemies of Democracy are
This is plain and simple ignorance.
Every bit of code I write goes into CVS. My CVS repository is not open to the public, it's to help me track my own code. It gives me the freedom to make arbitrary experimental changes, toss them into a branch (or just throw them away and roll back my code), examine the difference between any two arbitrary dates for any two files, etc... It gives me an excellent history of development, per file, so I can know what I've done, when I did it, etc...
What it does *not* do, however, is encourage anyone to submit patches any more than they otherwise would. It's not voodoo. People don't hear that someone's using proper development tools and start spewing code generators at them.
If some guy allowed lots of people to dump code directly into his source tree, then, yeah, it's going to have as much crap as exists with the incoming patches nowadays, possible more. The solution isn't to avoid CVS, it's to not use it in really stupid ways. That's roughly the equivalent of saying, ``Linux development shouldn't happen under Linux because it's a multi-user OS and just anyone could be logged in changing the code at any given moment!'' Yep.
Now granted, that won't solve the immediate problem much like inflating your tires won't give you enough gas to start your car...but when you have two problems, why not solve them both?
Yes, it's true that it's not easy to revert bad stuff with CVS. It's not any easier without it. It's most certainly possible, though, especially if you were to tag every patch import.
Don't take development tool advice from someone who won't use the tools because they cause problems when you use them incorrectly.
-- The world is watching America, and America is watching TV.
The high-tech "telepresence" stuff is great - when it is working. The US Army has had the luxury of fighting against opponents that have not had either the equipment or the desire (or perhaps failed to see the need to) disrupt the communications networks.
:)
Had Iraq been capable of jamming communications, locating and targeting transmitters, or throwing up a better deception plan, the Yanks might have had a tougher time.
Not to mention that sometimes the damned stuff just breaks down. Radios will do funky things out in the bush.
In my armoured recce troup, we used to practice communicating with hand signals and lights all the time. We assumed that any radio transmission longer than about a second would give away your exact position, and that any transmission _at all_ would give away that you were there, somewhere.
The high-tech stuff is really, really nice when you can use it, but don't assume that it will always be availible to you.
A few years ago, there used to be this NATO-wide tank gunnery competition called the Canadian Army Trophy. Part of it involved a move-and-shoot range where pop-up targets were shot at.
When the Yanks first brought out the M1 Abrams, its thermal sight was better than anything anybody had fielded before. It was so good that it picked up the heat from the motors that lifted the pop-up targets - and the Yanks cleaned house.
The next year, the motors on the targets were insulated, and a large number of fake-motor-heat-sources were seeded on the range. Suddenly, the fancy-shamcy thermal sights were feeding _disinformation_ - and the American performance dropped off considerably.
The bottom line is that technology is no substitute for sound procedures. It may augment them, but it cannot replace them.
DG
Want to learn about race cars? Read my Book
But we have to also obtain or evolve the techniques neccessary to make a clone one-eighth Linus' size!
(Sorry, sorry, I'm just trying to see how quickly I can burn up 50 karma. :-) I agree with your analysis, by the way. It's very well put.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Linux is great nowadays but I think that OSes with a more modern and "decentralized" design
will wipe it out. It is the case of the Hurd
(www.gnu.org/software/hurd/).
And so the end begins. Finally the whole Linux mess will come to a deserving halt and crash to pieces. 2.4 was and still is a disaster. And seeing that nobody are wimpy enough to use source control it is to be expected. Do you people really expect a normal run of the mill user to try Linux? Intall XP or even W2K, and see what users want. They do not care about holly OS wars and ESR's ranting's nor do they want to care if Linus will fix the next kernel. The user want's to play his DVD, record his MiniDV videos on CD using firewire or USB 2.0. He/She can do all that and more with Apple or Microsoft. And you, the "hollier than though " kernel geeks can fight on how to do source control. Linux will never be a major on the desktop nor the server if this is how dev is done. The more growth the higher the demands on the kernel will be. Can Linux handle that? It does not look like it.
Moderation Totals: Flamebait=1, Insightful=2, Interesting=1, Overrated=2, Total=6.
Total of positive and negative mods: 0
Total effect on my karma: -2
Hey, that Karma Cap was sure a great idea, huh? And the implementation - now that's just fucking flawless.
Hey Taco, now that you lost all your money that was tied up in VA Burgers stock, maybe you can use some of your leisure time to fix the convoluted abortion that is Slashcode. Just a thought.
--saint
I've never been a a Linux developer - I use Macs and I can't figure out where (besides sourceforge) I'd look to help. From this thread I've seen that Linus is mainly afraid of introducing bad code and thinks a versioning system won't help. I'm prone to disagree with this as it's certainly helped my coworkers and myself. One thing I wonder though is aren't bug patches or other code submissions made with accompanying unit tests to help Linus verify them? If not, why not? I realize many problems are with drivers and other things which would make some functions hard to test (or hardware dependent) but still, units tests should be possible for a large amount of the code changes and providing them to Linus could help make it easier to approve the changes. Just a thought.
The model that Linus is advocating is in fact a peer to peer network with maintaines acting as super peers. This seems to be a sound way to scalability for me !
We put a HUGE dildo up his ass and make him look like the http://www.goatse.cx/ guy.
He'll be scaled up NICE and BIG after that. Maybe then he'll get the clue about having the kernel be a bit more robust, like support for things such as stackable drivers....
Linus, you're not a jerk. You're a bitch.. and a lousy one at that.
my little sister, the Lynnette you mention, barely knows which side of the keyboard to use . .
So why don't whe go for a mini-Alan instead. Someone must know a couple of Alena's . . .
:_)
hawk
Linux isn't anyone's toy choo choo train but Linus's. Sure, you can take the time to program something for it, you can rant and rave like a bearded maniac about how it should be called GNU/Linux..
In the end, Linus is the man on top. Good for him.
The day Linus stops working on Linux is the day I stop using it. I can see it now, can't you? The angry developers, intent on 'crushing' Microsoft - bastardizing all that Linux is.
Besides - it's not as if Linus isn't sharing. If you really don't like the way he does things, well, then, grab a kitchen utensil and start prodding away with it. Or write your own kernel.
Seriously, how many here complaining about how slow and inefficient Linus is could do the same?
...I thought so.
I think I'll go buy Linus some beer and send it to him.
This is not a suggestion I have heard yet (except indirectly in some people's mention of the FreeBSD maintenance system), and I expect it to be an unpopular one, but perhaps those in charge should be thinking not about "How do we decentralize or otherwise modify the process so that we can maintain the current rate of development?", but rather, "Would it be wise to reduce the current rate of development?" Such a reduction would (some may disagree) result in an overall increase in the quality of code getting into the kernel. And arguably, a modicum of new development work would suffice to keep Linux running on new, common hardware; is it really necessary to support every new ethernet or graphics chipset that comes out? This would at least allow for a favorable marketing argument about the "stability" (not necessarily synonymous with "reliability") of Linux. There is perhaps a connection with the "Worse is Better" philosophy which has worked well for Unix in the past. It would also free up developers to work on other aspects of the overall Linux system, such as applications, desktop issues, perhaps ease of installation, and so on. Maybe I'm rambling, or off base, but this seems reasonable to consider.
Maybe the problem is with, as it works right now anyway, the open source development model and large projects. As Linus has said some people check in shit and you can't get them to fix it. If that code is allowed to sit in there for a while and people start building on that code it becomes a very difficult thing to remove or fix. If it was the software for money world you can say fix it or your fired, sort of. I guess major offenders could be kicked off the project, but open source projects, especially Linux, requires a lot of warm bodies to crunch enough code to meet goals. I am not saying that open source development is shit, but like the for profit world there are good programmer and poor programmers and how you deal with them and keep the good ones focused is always going to be a problem.
Look at what has happend to Mono and The switch from LGPL to XFree. Since both licences address the issue of using classes in closed source software, the real reason they change was to get access to more resources. In some ways it isn't the much different than the commercial world it is just the resources for the most part are unpaid for.
There are drugs to fix that.
- undoware.ca
I agree. The Linux kernel has reached a critical mass of sorts. It's time to Linus to give up the micromanagement of the project and start delegating. He is a human being after all, and he can't be expected to be an expert in everything. So let him find those experts and give them the reins over their area of expertise. No other project of this size has this level of control by a single person. Even Theo delegates.
A Government Is a Body of People, Usually Notably Ungoverned
the Bazaar is getting crowded. To put it mildly.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
...or one that would lead to a better answer, is thus: Why is Linus rejecting so many patches? Does he mail the contributer with a little message saying, "Hey, this would be great, except you need to clean up this, this, and this, and just resubmit it," or is there any response at all?
If the case is the former, then I'm willing to bet that so many of these patches are 'rejected' because they're never resubmitted. If it's the latter, then the problem might just be the threshold of what can be handled.
So what's the solution? Well, there's always the possibility of thinking along the lines of a community. If a group of people come up with a lot of patches, which together work towards a goal, e.g. making RtCW run better, then they could spend the time auditing each others' code, and submit it as one, larger, and certainly more worthwhile whole.
After all, if there was a patch that managed to get an extra 3 FPS out of RtCW, not many would bother. If there was a group of patches, or rather, one large patch, which resulted in an extra 30 FPS, with a step up in resolution, and a faster network throughput (damn you, high ping times!) then it would most certainly be worth while.
RtCW is just a hypothetical example, but I'm sure it can be applied to many other subjects... even the idea of collecting a slew of previously rejected bug-fixes, which still exist, would be more worthwhile than just fixing one, rare-to-occur bug. Right? Right. Glad we agree.
Jake
Dating: while( 1 ){ call_girl(); get_rejected(); drink_40(); } return 0;
Aside from a lack of basic text formatting, he is dead on accurate. Hell, even on something as simple as the compiler that we all had to write back in college, CVS can help track down changes that introduced bugs, and that is without anyone except your sketchy partner being allowed to checkin.
...although I concede that trust comes from competence. But what does this have to do with anything?
If you're going to overhaul (or in this case, overthrow) an established system, you need to do it with much fear & trembling. Look, I see this all the time as a manager. A new project is given to a manager. That manager hires someone competent and works with that person to build something from nothing. If the project takes off, you can end up hiring a lot of people to help support that project. It is possible for all those new hires to be more competent than the original, lead developer. But that original, lead developer now has management's trust. That lead developer, who got the damn thing off the ground in the first place, has an opinion that -- like it or not -- counts for more than the other developers. You can call that unfair, but certain people are just better rounded than others -- they have social skills, they can explain things well, they understand the market pressures, or whatever. Not to mention that it's their baby and you don't fuck around with stuff like that. As a manager, if I stomp all over the lead developer's project, that lead developer may not want to lead the next project! Sure, I can call on one of the other people brought in to help, but those other people may not be leaders.
I'm not saying that such an effort is doomed. But I am suggesting that, if you want to propose that Linus relinquish some authority, you damn well better have a value proposition for him. Shouting "this needs to be a democracy" is what you want, not what Linus wants. He's looking at that as a management nightmare, a removal of a power structure that is in place because, whatever it's faults, it was the structure that worked. If it doesn't work well anymore, you either have to convince Linus, or you have to convince everyone else to stop trusting the person in authority. That is a massive undertaking.
My Greasemonkey scripts for Digg &
I am not the original AC but here I go. No nerves, I just love Linux and Linus and think he has done a great job. I love him like a Saint. I am not sure if you can understand it. This is not your world of marketing smoke, mirrors, hipe and trash talk. This is a world where everything is real, time is *really* expensive and freedom is *really* valued. If you want, install your own CVS and do your own kernel. I am sure nobody will care if you have a CVS or an SUV over there. See, the projects have priorities. You cannot just rip apart the patch system when there are so many and so important other things to do.
Now, do it yourself and prove it!
Not really. Just because Linux took this long to mature to it's present state, doesn't mean every other kernel/OS needs this much time. See AtheOS for an example. The guy has worked on this system for only 5 years, and in some ways it's already more advanced than Linux.
Furthermore, the user land apps have significantly improved since '91, so much of the important infrastructure needed for widespread adoption is already done.
Higher Logics: where programming meets science.
*My* world of marketing smoke, mirrors, hipe (hype would be the correct spelling) and trash talk? What the hell do you know about me that would give you a stance to say such things? You are a troll and have approrpiately posted as an AC to further demonstrate your own idiocy!
What the FUCK does suggesting he use a CVS have to do with any of the garbage you are spewing on about? What does using a CVS have to do with freedom or liberty? Or do you just like to grandstand for no reason at all?
Mac OS X and Windows XP working side by side to fight back the night.
Yes, it's true that it's not easy to revert bad stuff with CVS.
Here that was the main point of Linus. He is not working with the next door guy to resolve the problems fast. Do you work with tens of people eager to put their stuff in the kernel after a sleepless night before going to their *other* job. You do not know what you are talking about. Even if there is way to make CVS work for that environment finding it and the trnasition to it are sure to *kill* the kernel. So Linus is right. The only way to prove yourself right is to put the kernel in CVS, rally hundred something developers, smooth out the edges and produce a better kernel. I am *sure* Linus will come to work for you.
That's no attitude to take. What we need is cooperation and competition, ..blah
Well, take that cooperating attitude yourself son... Stop trying to make others to take it. See If you took that attitude you would do your own kernel. But since you want others to cooperate in building the life the way you like it, you just bark around.
Linus doesn't use CVS or any source control system because he doesn't have a clue about how it works, and how cooperative software development should be done. Please stop giving him points for his ignorance. Period.
BSD people have been doing very productive and cooperative software for years being based on CVS. It's interesting how they have created more stable and better quality code than the Linux community have achieved, even using the impossible-to-imagine decentralized structure.
I really wonder why someone in the Linux community who actually have a clue on software management don't setup a CVS tree, give the right permissions to the maintainers and deprecate the dumb Linus centralized model. May it happen that guys as Alan Cox and Marcelo Tosatti are clueless about CVS as well?
(sorry for the flamebait, it's just that this whole situation is too disgusting)
If this rain of complaints and mishaps carries through and people realize more and more that a better solution is /badly/ needed, two things can happen:
1) Someone clones Linux and turns it into a better system by including all the features that people want and Linus drops.
2) Linus is forced to turn Linux into a pure microkernel, so subsystems are clearly defined, and he can still dictate over it.
These are Linus' two worst nightmares. (Think Minix and Hurd.)
This has been done before Linux was even conceived in the BSDs communities. It simply doesn't need to be proven. On the other hand, the way Linus has chosen has shown unacceptable weakenesses.
In other words, if you are a serious kernel developer with some software engineering knowledge, you should never consider Linux.
It's not surprising, though, the BSDs communities have understood that a long time ago. Most interesting is that they have achieved overall better quality over Linux.
before Linux was even conceived...
Can't you see that?
Haven't you ever noticed that?
For those of you who want to know why Linus pursues a monolithic kernel, have a read of the archived usenet debate between Andrew Tanenbaum and Linus from 1992:
0 st ar.cs.vu.nl
http://groups.google.com/groups?threadm=12595%4
DD.
"You can justify anything by putting it in quotes, adding a famous name and making it a sig" - Albert Einstein
Unfortunately, many (the majority?) likes to show their trash talk not code :(
What is increasingly apparent, is that any operating system, once it reaches a level of sophistication, is going to get out of control if the proper management systems are not put in place.
MVS did not have have 'kernel panic' and other totally uninformative messages that just left you scratching your head. Every piece of IBM software put out one of the infamous 'IKJEFT01 99965I' type messages. Other people laughed at them, but the fact was, every message with a reference number could be looked up in a manual, and the problem database searched on those messages.
Even more, the patch system became increasingly sophisticated, and was a whole system of it's own, much like a much more powerful 'apt get'. All patches had the prerequisites and corequisites explicitly named. If a patch did not go on, you could find out exactly why. If you wanted to put a patch on, it would tell you what else was needed. If you wanted to create your own patch, subsequent external patches that clashed with yours would be identified for you to resolve. And when you applied the patches, they were automatically applied for you. Just select the patch, and they were all applied with one simple command. Then if you wanted to back out a patch, that could be done too. Then if you wanted to apply a new version to a certain level, that was all automated. The banks use systems such as MVS not just because they are locked in, ( which they are to a certain degree, but because they get certainty and predictability with MVS, Zos now, I believe).
Microsoft - Where would you like to go today, Maybe Jail?
The notion of trust seems central to this debate -- who can be trusted to apply patches that will make the kernel better? And it reminds me of structures for establishing trust in the world of cryptography -- who do I trust to tell me that this public key really belongs to the person to whom it's supposed to belong?
The ideas about kernel patches being discussed remind me of the distinction between a "web of trust" and "certification authorities" in the world of cryptography. Certification authorities are the conventional means, which are used by the most popular web browsers. Some authority, like Verisign or Thawte, is universally accepted as trustworty, and if they sign a key, then it can be trusted. The web of trust was advocated by Phil Zimmermann and built into PGP, and AFAIK, PGP is the only context in which it's ever been applied (or even proposed). It's an attempt to reflect our everyday notion of trust -- I decide who I trust, on whatever basis I choose, and if someone I trust has signed a key, then I trust it. I can also decide if I trust people I don't know, if they are trusted by people I trust. There's no need for a central authority in a web of trust (although I might choose to include CAs in my web and trust them).
Rob Landley is suggesting that we entrust the patch penguin with the job of filtering patches towards Linus, but Linus sees the PP as a kind of central authority, and prefers to have a web of individuals around hom who he can trust.
Like Phil Zimmermann, Linus is arguing that his model is much more similar to the way that people decide to trust each other in real life. In the world of crypto, certification authorities have always been regarded with suspicion for reasons just like this -- why should I trust Verisign more than my friends? In the kernel world, Linus is saying, isn't it better and more intuitive to trust a group of people I know well, who can distribute the work amongst each other?
The analogy breaks here a bit. CAs in the crypto world are suspicious because we don't if they're corrupt -- maybe they're full of Enron managers. In the kernel world, we need to trust maintainers with their skill and above all, ability to handle the workload. Corruption is not the problem (I hope not, anyway.)
But, to take the analogy further, one should also note that PGP web of trust never really worked well as a practical matter. Most people using PGP had an island of people around them whom they trusted, with few connections outside of their immediate clique. I don't recall *ever* receiving a key from a stranger that was evaluated as trustworthy because of its position in the web topology.
So I'd say that Linus has a point in saying that the web model fits our common-sense intuitions about trust. But if Rob Landley says that it's not functioning well, the experience of PGP gives some support to his argument.
Always keep a sapphire in your mind
http://www.lib.uaa.alaska.edu/linux-kernel/archive /2002-Week-04/0568.html
> > Viro, David Miller, Greg KH, Andrew Morton etc. They've shown what I call
> > "good taste" for a long time. But it's not always a long process - some
> > of you may remember Bill Hawes, for example, who came out of nowhere
> > rather quickly.
>
> So listed "maintainers" may need to forward patches to these people, and get
> them to sign off on them, in order to get their patches at least reviewed for
> inclusion into your tree?
Count me out of that job. If you want something in 2.5 don't bug me. I
simply don't care
Alan
From what I know, the only way Theo eats, pays rent, or goes to the movies, is if he breaks his ass working on OpenBSD. I.e. it is his full time job and he takes it seriously. And the quality shows the the history of OpenBSD's security and reliability. Linus on the other hand has stated many times that he has a life outside of Linux and many other things to do. Fine. Linus, you are a better man than most, and we all owe you a great deal of gratitude. But now that people are using Linux in banks, hospitals, billion dollar companies, etc, maybe Linus should pass his hobby onto some people that will treat it like a profession.
Sorry if I'm out of line.
-... ---
WARNING! The parent contains a goatsex redirect! DO NOT CLICK! Mod down the parent post!
Frankly, I don't see there being much done. And hell, even when they make a desicion in congress, they send it off to some department that'll actually handle it. Guess what? You don't got any department to command around.
Oh and democracy, for living in a democracy (and elsewhere) you usually pay *taxes* that fund that society. How do you support the Linux kernel? How many patches have you written? The reason you get the vote is because you go no choice accepting the government backed by the people, but you're free to not use linux even if you were the last one on earth not using it.
And if you seriously believe people will fork the kernel here and there, I'd want something of what you're smoking. Quite simply the kernel needs a simultanious effort, one man patching it will realize the 100 other patches in another kernel branch makes that one much better.
Kjella
Live today, because you never know what tomorrow brings
Slash kids just aren't up on the classics.
Anyway: Larry Wall isn't stupid. There are reasons they use a pumpking in the perl world. Note: the pumpking is indeed expected to burn out, that's why they rotate the responsibility. The subtext of the dispute between Linus and Landley seems to be that Landley thinks Linus's job can be neatly split into a creative and a routine function, and Linus seems to think that this isn't so easy.
Or maybe he likes doing the "routine" stuff too, and doesn't want to off load it.
To me this looks to be the first true test of open source. Can a large scale project (do they get bigger the Linux?) survive while staying completely open for everyone to play with?
./ it seems that everyone has an opinion (much like a certain unable body part). I for one am in no way close enough to the situation to make those decision but I can say I hope it gets worked out, because as one poster stated: " ... people are using Linux in banks, hospitals, billion dollar companies ..."
...
After reviewing the posts on linux-kernal and here on good-ol
If this turns into bad publicity for linux who knows what will happen to those customers. Maybe Sun and MS try to get back in selling their respective os's to the same customers touting their ability to control how it all works in a "corporate environment", because we all know how much at least MS would love to discredit linux and those that use it. And don't think this can't get bad because just a few minutes ago on "The Screen Savers" on "Tech T.V." (a very lame show By The Way) the host gave a little run down of this entire situation (a bad run down, but enough to make it look bad in the eyes of many managers I am sure).
Ok rant over, I hope it all makes sense
man
No manual entry for
I think it is ridiculous just imagine the amount of work needed to get the tremendous amount of kernel patches into the kernel source tree is done by one man. No matter how prudential the process should be, handled by one man is just impractical.
Well, Linus, Linux is at the age when she starts dating now ...
I am gonna shut up and read the rest ...
Linux is killed in a crashing plain hijacked by terrorists.
The Linux kernel is branched into 1000 other branches of the kernel, and after a year it dies.
hmm, wait a minute - there are already 1000 other branches of the kernel
Correct plural is Linii (pronounced "line-eye")
just thought you should know.
ANIX. For AnyNIX. That's the solution. Remember that Linux is just the kernel, and since under the terms that Linux floats around with, the fact is, anyone can take what Linus Torvalds (dontcha love how everyone refers to Mr. Torvalds as "Linus"... like they know him personally...) wrote and change it, release the changes, and then make a killing on docs & support... or not.
If your group of hackers wants to see a different system used to maintain Linux, if say... LT decides he doesn't want to do something with his OS, or just quits maintaining it altogether, I believe you can make your own derivative kernel, as long as you keep the copyright notice intact, and call it something else. This is the fix you'll have to use when LT does eventually stop maintaining Linux, and he'll have to, eventually, just as CP/M outlived Mr. Kildall, Linux use will continue even if only in little isolated pockets, for as long as 115 (+/- 5) V, 50/60Hz AC flows from the outlets, and there are computers to use it.
So change the name, (call it HackNIX, if you like,) hack the crap out of the kernel and make it to your liking. Then have a coke (TM) and a smile, and shut the fuck up.
8-)
AC!!!
Surely he can't, if all the free software advocates are to be believed?
Reading the advocacy on /. and elsewhere, there are two points that come up again and again in favour of free software/open source ideas. Firstly, because you can see the source, you know you're not being screwed behind your back. Secondly, because you can develop from the source yourself, you can't be cut out of the loop; there's no "vendor lock-in".
This is going to be a fantastic test of whether the FS/OS movement is for real, or just a hype machine driven by wannabe code wizards. If it's as solid a development methodology as people so often claim, if it's as robust a platform to depend on as people so often say, then no one individual -- not even Linus Torvalds -- can stop the movement.
Linux lives or dies by the contributions of volunteers. If they don't like what they see, one day enough volunteers will get together to start work on an alternative, with organisation they do like at the top. They'll branch the code base, leave Linus behind, and go their own way. Linux will stagnate, and NewDifferentlyNamedFreeOS will replace it.
Of course, whether that would be in the interests of the Linux community, or of Linus, remains to be seen.
And of course, whether the concept above is even realistically possible, also remains to be seen. I guess this is where we find out if the much-evangelised benefits of FS/OS make the cut.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
HAHAHAH!!! Mod parent up (at least +1 funny...) people are actually using this term. Whoever wrote this first Linii reference should have signed in to get the cred for thinking of it... what a shame...