[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gentoo guys starting a fork of udev



On 11/14/2012 09:04 AM, John Paul Adrian Glaubitz wrote:

On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote:

But anyway, we're getting tired of their ADHD-driven changes just to change
things

TBH, I'm getting tired of people who are constantly shooting against them
because these people are unwilling to accept changes. We're not bringing
Linux forward if we stick to 30-year-old concepts.

While I think I recognize the idea behind this, and it's one I don't necessarily
entirely disagree with, this sentiment just seems wrong to me.

True, if people are unwilling to accept change for the simple reason that it
*is* change, that's a bad thing.

But why is a 30-year-old concept necessarily worse than a new one? Or to put it
another way, why is it necessary to "bring Linux forward", in cases where what
is already present is good and works well? (And, taken further: in cases where
what is already there *isn't* good and/or *doesn't* work well, why is it
necessary to accept change *in a particular direction*, if that direction has
problems of its own?)

I've run across a few software projects where it has seemed as if the developers
were adding new features and removing old ones and changing UIs not because
there was something wrong with the old, but apparently just because "we're the
developers, we have to make changes or we're not developing it" - because they
seemed to think that letting a program sit unchanged is automatically a bad
thing, no matter how close to perfect-for-its-purpose the program may already
have been.

Change is not always bad; in fact, it's very often good. But change isn't always
good either, and refusal of change isn't always simple obstinacy or stagnation.

--
      The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


Reply to: