Andrey Rahmatullin <w...@wrar.name> 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 > different. 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 them. 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 it.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nl6bc69....@windlord.stanford.edu
