|| ||Russ Allbery <rra-AT-debian.org> |
|| ||debian-devel-AT-lists.debian.org |
|| ||Re: major linux problems summary 2012 |
|| ||Sat, 03 Nov 2012 14:37:34 -0700|
|| ||Article, Thread
Andrey Rahmatullin <email@example.com> writes:
> On Sat, Nov 03, 2012 at 08:53:24PM +0000, Ben Hutchings wrote:
>> And if he doesn't like the answers, there are plenty of other operating
>> systems to choose from.
> This is dangerously close to "if you think these are problems, just use
> a different OS, we are fine with that". I hope you mean something
These sorts of articles seem to always be written as if the author
honestly expects the list to be some sort of profound revelation. That no
one even realizes these problems exist, and that now that they've been
identified and put into a list, this will somehow be helpful in solving
Then, they're usually baffled by the extremely negative reaction that
people working on Linux distributions have to a list that, in their eyes,
is an unactionable and uninteresting merger of old, already fixed bugs,
personal preferences, bare outlines of actual bugs without enough
information to fix them, grand sweeping statements of vision with no
resources attached, and misunderstandings.
The resulting conversation is almost never useful.
This is another variation on the constant question of "why isn't this bug
fixed yet?" Authors of these articles seem to think, or at least come
across as thinking, that these bugs are not fixed yet because no one knows
about them, and if they just bring them to the world's attention, that
will somehow solve the problem. That's sometimes true, but "sometimes" is
probably closer to 5% of the time than 50% of the time. Most of the time,
the bug isn't fixed yet for the very simple reason that no one has fixed
it. If the bug is a long-standing one, usually no one has fixed it
because fixing it is a lot of work.
None of those statements are unique to open source software. They apply
equally well to proprietary software.
With the exception of bespoke software internal to a particular
organization of which one is also a member, which for some reason is
almost never the situation these sorts of articles are written about, one
rarely has standing to tell someone else to work on a bug that they
already know about, haven't fixed, and which is bothering you. This too
is not unique to open source software; in fact, it's even *more* true of
proprietary software than open source software. Unless you're the
president of a multinational corporation talking to the CEO of the
software development company, the chances that you're going to be able to
reorder someone else's development priorities *even if you're a paying
customer* is actually quite low. I say this as someone who also regularly
deals with purchased commercial software in may day job.
At least with open source software, a third path (besides working around
the bug or switching to some other software) also exists: you can help.
That's not always practical, but at least it's *possible*.
(Of course, a separate reason for writing such articles is to simply
review a technology for the benefit of other prospective users or
customers. That's a fine reason for writing a list of issues. But one
generally doesn't send a review of something to the author of that
something for a whole host of good reasons, one of which being that
they're not at all the target audience and probably know everything in the
review already, even if they might put a different spin on some parts of
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>
to post comments)