| |||||||||||||
what Hans is right aboutwhat Hans is right aboutPosted Jul 28, 2006 16:48 UTC (Fri) by pimlott (guest, #1535)Parent article: Quote of the week
I don't follow lkml and don't have the full context for this, but Hans does in his way point out an unfortunate aspect of Linux development. Rather like wikipedia, Linux tends to discount and even disparage expertise. As Linus himself puts it, Linux was not designed, it evolved. Linux developers are only willing to consider immediate solutions to obvious problems, and while this helps maintain focus and avoid overengineering, it leaves out those with the talent and experience to design, to look ahead and address the problems that haven't been encountered yet but will. "Show me the code" is the stifling response to design discussions that become the least bit abstract. Dare I say it, but while the core developers may not have the background and aptitude for such discussion (the numerous short-sighted decisions in Linux's history attest to this), there are those who do. If Linux could benefit from their insights, it would improve much faster.
(Log in to post comments)
what Hans is right about Posted Jul 29, 2006 19:30 UTC (Sat) by bronson (subscriber, #4806) [Link] You can babble on a mailing list about something for months or you can hack out a prototype. Which technique do you suppose will be more instructive? Which will produce a usable product faster? In my experience, most projects die of overdesign. Have you read Brooks? He speaks about much more than just project scheduling.
And, if by "disparage expertise" you mean that all developers are treated more or less equally, regardless of their experience, well, you might be right!
what Hans is right about Posted Jul 29, 2006 21:12 UTC (Sat) by pimlott (guest, #1535) [Link] You can babble on a mailing list about something for months or you can hack out a prototype.Writing kernel code, even a prototype, is quite hard and time-consuming. At the beginning of a project, this time is better spent on the design. Which technique do you suppose will be more instructive?You've given a false choice, obviously. Thoughtful design, on-paper analysis, modelling in a formal or semi-formal language are all highly instructive (and they don't require chasing down oopses!). Writing a prototype is also instructive, but bang-for-time, it may not be the best. I have known gifted designers who could write a spec much faster than they could write the code--and the spec proved implementable and solved the problem! NB: Most people can't do this. But some can. Maybe our disagreement comes down to whether such people really exist. My experience says yes. Sure, overdesign is a danger. It's critical to identify the good designers and not listen to every babbling bozo (which may be hard in and of itself). And ever then not every design will work. But there are big payoffs too. And, if by "disparage expertise" you mean that all developers are treated more or less equally, regardless of their experience, well, you might be right!Come on, that is patently false. Linus is treated very differently from most developers, and the same to a greater or lesser extent goes for the rest of the pantheon. The problem is that writing Linux code is the only way to get any respect among Linux developers, who are generally indifferent to the other accomplishments and expertise of a would-be contributer.
what Hans is right about Posted Jul 29, 2006 23:05 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] if you are willing to invest the time to readk the kernel list (and yes, it does take quite a bit of time) you will find that the kernel developers are not at all opposed to people designing things for the long-term, it's just that they are not willing to pay attention to people who say 'stop what you're doing and wait for someone to design this'
there are quite a number of very experianced people who pop up on the kernel list once in a while to weigh in on something. when they do they are listened to and things are useually adjusted to accomodate them.
the situation is something like this
code that works trumps a design that's not implemented
and in all cases evolutionary changes win over rip-out-and-replace (although there are some kernel developers who are famous for long patch series that incrementaly replace core functionality, the key is that each stop stands alone)
none of this sits especially well with a lot of the 'specify, design, then code' folks. however if they keep working rather then getting discouraged the results of their work does stand a good chance of being accepted
what Hans is right about Posted Aug 4, 2006 0:12 UTC (Fri) by efexis (guest, #26355) [Link] I haven't kept up to date with the resier4 debate (if much has changed with it) but from what I got at the time of it beginning, the reasons it was rejected were actually more to do with long term design than current implementation; the belief that chunks of his code would be better places in the VFS layer rather than in the filesystem itself, that way, other/future filesystems could use the same plugins and model. So the "long term design goals" argument doesn't really apply as much as it might seem.
(no that wasn't worded very well, but it should be clear what I mean ;-)
|
|||||||||||||