Now you can browse in complete full-screen without having to rely on context menus.
I'm curious. What's wrong with context menus? Unlike mouse gestures, their commands are highly discoverable, once you know the basic trick of right-clicking or control-clicking. Mouse gestures seem to be a reversion to the old "memorize a manual before using the program" paradigm.
I saw a study in a magazine a few years back comparing application speeds between Windows and the Mac. It turned out that all applications they tested were virtually indistinguishable between the two platforms, megahertz for megahertz, except, that is, for Microsoft applications.
Microsoft applications were two to three times slower on the Mac, although Adobe and other vendors' applications were just as fast.
Of course, this is just a coincidence. It's not as if Microsoft would have any commercial interest in making the Mac platform seem inferior to Windows.
For example, the software will make the user deal with a database's unique identifier, or forcing the user to restart windows in order to install a driver.
Exactly. If you start with programming concepts and then slap an interface on top of it, you find that the underlying layers won't support the interface you need. For instance, in a network application framework, there are serious issues about timeout. If they're approached from a traditional programming perspective, you'll be left with a system that drops connections out from under the user and loses their work in progress.
This kind of issue is pervasive throughout any software system. You've mentioned a few other good examples; I'd add things like timeout management (as above), exception handling, module installation, and refresh timing. Engineers looking at these problems will generally take paths of least resistance which wind up hurting the user. The only way to prevent these problems is to start with the user and work back to the system. If you try to fix them after the foundation is already laid, engineering will always report that it's too late to tear up the foundation.
Considering that they are currently working on the compiler, the language runtime and base class libraries for Mono I fail to see what user interfaces have to do with anything at this stage in the development process.
That's exactly the problem. It's called "user-centered system design" for a reason. User experience is upstream from engineering in a user-centered project. You don't bring designers in late in the game to slap some icons on the system. Instead, you have a set of designs that engineers work towards implementing.
On the other hand if this was an interview about GNOME, which it isn't then I assume he would have mentioned the user interface issues.
I believe your assumption is in error. I have seen de Icaza discuss GNOME in exactly the same way -- naming lots of libraries and implementation strategies, but saying almost nothing about user-facing issues. That's why I noted the continuing pattern in my message.
every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full.NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way.NET services work.
Does any contributor's goal include a focus on usability issues and user experience design? If so, they weren't apparently worth listing.
As in many other interviews, de Icaza's comments are focused almost entirely on technical issues, and not on design issues. Component architectures may be fascinating for engineers, but they don't deliver an enhanced experience for the user by themselves.
To really improve the Linux user experience will require the kind of passionate engagement with the user that Apple has had, but instead we seem to be seeing a very programmer-centered set of interests and preoccupations at Ximian.
Is there any plans for improving pgp's ability to incorporate itself into email programs and other forms of internet communications that will make it easier for companies and end users to use?
Take a look at this usability study on PGP. The design hasn't moved forward much since the study was done. PGP is so difficult to use that it may have created a new category: "insecurity through obscurity."
The Key Largo installation is using commercial software on their servers, including WordPerfect, MS Office and Citrix. That's not factored into your cost estimates.
I don't know what you mean by "immediately intuitive" -- that's not a usability principle used in the field. But you've nicked me on the fact that this wasn't a comparative study.
I was reasoning from the fact that the problems noted were problems not present on Windows and Mac OS, and that the proposed solutions moved the designs more toward those used on the other platforms. It doesn't demonstrate that equally bad unique problems don't exist on the other platforms -- that's my personal judgment call.
I haven't seen any TCO studies that compare StarOffice with Mozilla on GNOME to MS Office with IE on Windows and Mac OS, but I would be interested in any references.
less tangible items like how much time do the secretaries spend changing fonts in Outlook or fidgeting with Word documents to get them to look right.
Exactly. The design of software -- its "user-friendliness" to employ an overused term -- is a major factor in total cost of ownership. That can't be answered by a once-over-lightly review by a system administrator mostly concerned with ease of installation, which is what the article amounts to. Evaluation of costs created by usability factors requires extensive user testing, both in the field through ethnographic methods and in controlled situations in usability labs.
Instead, what we got in the review was a lot of unsupported superlatives like "excellent," "great," etc. The personal opinion of a system administrator does not have a great deal of relevance to the costs that the software will create in an actual user environment.
The recently discussed GNOME Usability Study showed that even at the current fairly advanced level of development, GNOME is significantly harder to use for most people than Windows or the Mac. That's a cost that impacts overall productivity of the users.
And GNOME is considerably more usable than most of the applications available for Linux. Granted this is not an opinion I am able to support empirically, since the studies have not yet been done, but it seems obvious that, for instance, Microsoft Office is more usable than StarOffice at their current stages of development, and that the continued reliance on the command line for routine tasks presents a very steep obstacle for the average user.
So it seems to me quite inaccurate to describe this software as free. Low up-front costs are being traded for persistent usability costs. This may be an equation that makes sense in some offices but as a general rule, it would be a money-losing proposition.
Still, I do not expect this large loss will make the slightest impression on all the people who keep telling me that "Red Hat makes tons of money selling open source." It happens here on/. and on other open source boards as well, and demonstrates a "reality distortion field" that would make Steve Jobs proud.
Open source has not yet found a viable business model. The reason open source has seemed to move forward in the last few years is because investors have poured large amounts of money into it without getting anything in return.
Most software engineers would prefer to code rather than to document, even though documentation is equally necessary to the success and maintainability of a project. They document even less in open source, though, and the reason is that they're not managed as closely.
In any job, management needs to "encourage" people to do the unpleasant tasks which left to themselves they would prefer to ignore. In the open source volunteer model, no one is cracking that whip, and so the equally necessary but not equally pleasant parts of the job often don't get done.
(I mean, Python has been around for years, and parts of the manual still say "I don't feel like writing this yet -- maybe someday.")
I wonder if the book has any insight on how to deal with the problem.
The one quibble the reviewer has with the book seems to me likely to be one of its strongest points. Open source has not delivered good end-user applications so far; its strength has been in developer-facing products such as the kernel and the Apache web server. Open source does not meet the challenges of end-user-facing software very well because it requires non-programmer skills like interaction design and graphic design, and does not appeal much to people with those skills. In addition, good user experience design depends on extensive user testing, which requires cash outlays. Open source may produce good software by and for programmers but it falters when it comes to delivering software suitable for the average user. This suggests a hybrid model in which commercial developers create proprietary applications on top of free back-end software.
If he's made something worth a restrictive licence then the GPL is not in his way to sell it as a separate plug-in / module / application or whatever.
It is a common misconception about the GPL that it allows this kind of plugin extension. In fact, however, the GNU GPL FAQ expressly forbids this for any code that runs as an integrated part of a program.
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
People often claim that there is prior art for any patent they don't like. However, they are usually short on the details of what that prior art was, just as the FSF and yourself are short in this case. If you are correct, congratulations, you can defeat the patent. But you'll need more than a bare assertion of prior art to do that.
Here is a significant innovation which was created in hopes that it would be protectable and thus profitable. That is the traditional rationale for patents: by allowing intellectual property to be protected for a limited period, they create an incentive for innovation.
Now we see that the GPL's anti-patent stance appears to be trying to stifle this innovation unless the inventor consents to its terms, which would deprive the inventor of profit.
A clearer example of the anti-innovative tendency of the free software movement could not be imagined.
The law doesn't say anything about banning free software or open source. Here's what LWN adds to try to construe this as a law against free software:
The "security standards" mentioned are to be developed in the future; one can, without too much trouble, imagine that these standards to not specify "source available so that the security systems can be changed." [errors in original]
Good imagination, guys, especially given that the consensus in the security community is that open systems are more secure rather than less. This bizarre, paranoid speculation is as much FUD as anything that Microsoft has promulgated.
A machine custom built for computing mortgages would be cheaper than a general-purpose computer, right?
It's an interesting counterargument. The fact is that a special-purpose computer is faster than a general-pupose computer for any real-world algorithm which turns out to be computational expensive. That is one of the main reasons why we have ASICs. However, an ASIC is not necessarily cheaper, since many algorithms run fast enough on the general-purpose processor, and the separate chip would not pay for itself given the lack of demand.
It might be that a general-purpose fabricator would prove to be fast and cheap enough for some common goods, and so undercut the need for mass manufacturing of those goods. However, I think this remains entirely speculative given that we don't have anything like a general-purpose fabricator today, and don't know what its characteristics would be. It probably wouldn't work anyway -- see the current Scientific American, in which the world's only nanotech Nobelist explains why there will never be a nanoassembler
Of course, there is a wide range of possible special-purpose fabrication techniques well short of the dream of general-purpose fabricators, and some of these might be useful for distributed manufacturing. Food and clothing come to mind. Reprogrammable cell cultures together with a robotic chef might be able to make reasonable biological simulacra of most possible foodstuffs, while a robotic loom/sewing machine could produce a great deal of high quality clothing. I submit that in either case, the specialization would allow for faster and cheaper production of the goods than attempting to build them molecule by molecule -- if that were even possible.
I list specific sources of cost in something that someone else is saying is free, and then the responses to my message don't address any of the cost issues I've raised. In this discussion, I raised:
equipment
energy
time
waste
distribution
raw materials
I'd add to that two more:
research and development
design
Your message ostensibly in response discusses none of these costs, except to say that:
"raw materials are relatively cheap" -- Are they? What form do raw materials have to be rendered into to be suitable for input to a general-purpose assembler?
goods distribution as opposed to raw materials distribution is "inefficient from an energy perspective" -- Why would shipping the specific goods someone wanted be more expensive in terms of energy than shipping them raw materials for things they may or may not want? And why is non-centralized assembly assumed to be cheap in terms of energy? Is this a magical appliance that doesn't use energy?
"think about the recycling applications" -- Waste is intrinsic to all energetic processes. Processing resources out of waste is intrinsically costly and also creates a buildup of unprocessable waste in the system (or more technically, leads to a point of diminishing returns in which the reprocessing of remainder waste becomes economically unfeasible).
You also decline to discuss the issue of economies of scale in mass production. If general-purpose assemblers become cheap, then don't specialized assemblers become even cheaper? At the very least, you can use general-purpose assemblers to create special-purpose ones. The special-purpose ones will then produce the particular goods faster and cheaper.
This would be great for mankind, as the cost of production would be driven down dramatically, and you could literally have whatever you wanted for the cost of the raw materials to build it.
You're repeating something that's also been said elsewhere in the thread, as well as being a standard doctrine of nanotechnology, which is that this kind of fabrication would be cheaper than current mass production techniques. What is the basis for that assertion? The equipment itself is currently quite expensive even in the limited forms which are now available, and there is a floor to the cost (unless you know somewhere I can buy a good refrigerator for $10?) Then there is energy, time, and waste, as well as distribution of raw materials and raw materials cost itself.
I haven't seen any basis for the assumption that all of these can be driven to near zero. If they can be driven way down, then so can the costs of mass production, which could be driven down even further due to economies of scale. A machine that only builds one thing is going to produce that one thing faster and cheaper than a machine that can build anything. That's true even of theoretical nanoassembly systems.
>i>IBM is by far the largest OS company in terms of $$ spent on OS projects ($1,000,000,000, or so they say) and they seem to be doing pretty well. Everyone cries "Who will make a succesful service business that supports open source?" The answer: IBM.
It may be. It isn't now. They are spending money on open source, not making money on it. It may work out for them, but it's way too early to cite IBM as an open source success story. They could just as easily become one of the cautionary tales.
Ralph Nader's consumer advocacy has always been first and foremost about quality, of which safety is a subset. Given that the commercial operating systems (MacOS and Windows) are much more user-friendly than the current slate of Linux offerings, and that even many Linux advocates have now come around to admitting that fact, how does Linux advocacy benefit the consumer? Isn't it strange for a consumer advocacy organization to be advocating a lower-quality product over a higher-quality one?
why not look at the several threads on mozillazine.org which document the distortions of fact and pure speculation on the part of mozilla quest? Various errors include misinterpretation of bug statistics,
I've read all of them carefully. So far, not one has documented an objective error. The responses are always along the lines of, "so what that we didn't fix a lot of the bugs for this milestone that were marked to be fixed? What does that matter? The project is still getting better, isn't it? How can he say it's buggy? Mike Angelo is such an idiot!"
misconstruing the meaning of projected release dates,
Very similar issue. He points out that a new milestone means a slip in the 1.0 release date, and the responses all say "so what that 1.0 will be a few months later? We're not a commercial project! We don't have a schedule! Who cares when we ship? Mike Angelo is such an idiot!" Again, no factual errors in his analysis are demonstrated. He's reporting things that are true, but taboo on the advocacy site.
and a uniformly unequivically negative opinion of everything mozilla.
Yes, but I was asking for examples of objective factual errors on the site. You don't like his opinions, fine, but that doesn't make him an unreliable source. He broke this story. People at MozillaZine knew about the story for a week and a half and tried to keep it secret. Who's the better news source on this story? MozillaQuest 1, MozillaZine 0. Sorry, but it's a fact.
For all the flaming of MozillaQuest by the Mozilla faithful, I have yet to see the flamers document a single objective inaccuracy. Most of the responses consist of personal attacks devoid of content. In this case, we have to look at the fact that MozillaQuest broke the layoff story -- accurately -- while the advocacy site, MozillaZine, was still in denial about the prospect of the AOL layoffs hitting the project.
As far as I can tell, MozillaQuest's only crime is in pointing out facts about the late, buggy, and ugly Mozilla project that its small remaining core of advocates would rather see suppressed.
Slashdot Mirror
Now you can browse in complete full-screen without having to rely on context menus.
I'm curious. What's wrong with context menus? Unlike mouse gestures, their commands are highly discoverable, once you know the basic trick of right-clicking or control-clicking. Mouse gestures seem to be a reversion to the old "memorize a manual before using the program" paradigm.
Tim
I saw a study in a magazine a few years back comparing application speeds between Windows and the Mac. It turned out that all applications they tested were virtually indistinguishable between the two platforms, megahertz for megahertz, except, that is, for Microsoft applications.
Microsoft applications were two to three times slower on the Mac, although Adobe and other vendors' applications were just as fast.
Of course, this is just a coincidence. It's not as if Microsoft would have any commercial interest in making the Mac platform seem inferior to Windows.
Tim
For example, the software will make the user deal with a database's unique identifier, or forcing the user to restart windows in order to install a driver.
Exactly. If you start with programming concepts and then slap an interface on top of it, you find that the underlying layers won't support the interface you need. For instance, in a network application framework, there are serious issues about timeout. If they're approached from a traditional programming perspective, you'll be left with a system that drops connections out from under the user and loses their work in progress.
This kind of issue is pervasive throughout any software system. You've mentioned a few other good examples; I'd add things like timeout management (as above), exception handling, module installation, and refresh timing. Engineers looking at these problems will generally take paths of least resistance which wind up hurting the user. The only way to prevent these problems is to start with the user and work back to the system. If you try to fix them after the foundation is already laid, engineering will always report that it's too late to tear up the foundation.
Tim
Considering that they are currently working on the compiler, the language runtime and base class libraries for Mono I fail to see what user interfaces have to do with anything at this stage in the development process.
That's exactly the problem. It's called "user-centered system design" for a reason. User experience is upstream from engineering in a user-centered project. You don't bring designers in late in the game to slap some icons on the system. Instead, you have a set of designs that engineers work towards implementing.
On the other hand if this was an interview about GNOME, which it isn't then I assume he would have mentioned the user interface issues.
I believe your assumption is in error. I have seen de Icaza discuss GNOME in exactly the same way -- naming lots of libraries and implementation strategies, but saying almost nothing about user-facing issues. That's why I noted the continuing pattern in my message.
Tim
every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.
Does any contributor's goal include a focus on usability issues and user experience design? If so, they weren't apparently worth listing.
As in many other interviews, de Icaza's comments are focused almost entirely on technical issues, and not on design issues. Component architectures may be fascinating for engineers, but they don't deliver an enhanced experience for the user by themselves.
To really improve the Linux user experience will require the kind of passionate engagement with the user that Apple has had, but instead we seem to be seeing a very programmer-centered set of interests and preoccupations at Ximian.
Tim
Is there any plans for improving pgp's ability to incorporate itself into email programs and other forms of internet communications that will make it easier for companies and end users to use?
Take a look at this usability study on PGP. The design hasn't moved forward much since the study was done. PGP is so difficult to use that it may have created a new category: "insecurity through obscurity."
Tim
The Key Largo installation is using commercial software on their servers, including WordPerfect, MS Office and Citrix. That's not factored into your cost estimates.
Tim
I don't know what you mean by "immediately intuitive" -- that's not a usability principle used in the field. But you've nicked me on the fact that this wasn't a comparative study.
I was reasoning from the fact that the problems noted were problems not present on Windows and Mac OS, and that the proposed solutions moved the designs more toward those used on the other platforms. It doesn't demonstrate that equally bad unique problems don't exist on the other platforms -- that's my personal judgment call.
I haven't seen any TCO studies that compare StarOffice with Mozilla on GNOME to MS Office with IE on Windows and Mac OS, but I would be interested in any references.
Tim
less tangible items like how much time do the secretaries spend changing fonts in Outlook or fidgeting with Word documents to get them to look right.
Exactly. The design of software -- its "user-friendliness" to employ an overused term -- is a major factor in total cost of ownership. That can't be answered by a once-over-lightly review by a system administrator mostly concerned with ease of installation, which is what the article amounts to. Evaluation of costs created by usability factors requires extensive user testing, both in the field through ethnographic methods and in controlled situations in usability labs.
Instead, what we got in the review was a lot of unsupported superlatives like "excellent," "great," etc. The personal opinion of a system administrator does not have a great deal of relevance to the costs that the software will create in an actual user environment.
The recently discussed GNOME Usability Study showed that even at the current fairly advanced level of development, GNOME is significantly harder to use for most people than Windows or the Mac. That's a cost that impacts overall productivity of the users.
And GNOME is considerably more usable than most of the applications available for Linux. Granted this is not an opinion I am able to support empirically, since the studies have not yet been done, but it seems obvious that, for instance, Microsoft Office is more usable than StarOffice at their current stages of development, and that the continued reliance on the command line for routine tasks presents a very steep obstacle for the average user.
So it seems to me quite inaccurate to describe this software as free. Low up-front costs are being traded for persistent usability costs. This may be an equation that makes sense in some offices but as a general rule, it would be a money-losing proposition.
Tim
Still, I do not expect this large loss will make the slightest impression on all the people who keep telling me that "Red Hat makes tons of money selling open source." It happens here on /. and on other open source boards as well, and demonstrates a "reality distortion field" that would make Steve Jobs proud.
Open source has not yet found a viable business model. The reason open source has seemed to move forward in the last few years is because investors have poured large amounts of money into it without getting anything in return.
Tim
Most software engineers would prefer to code rather than to document, even though documentation is equally necessary to the success and maintainability of a project. They document even less in open source, though, and the reason is that they're not managed as closely.
In any job, management needs to "encourage" people to do the unpleasant tasks which left to themselves they would prefer to ignore. In the open source volunteer model, no one is cracking that whip, and so the equally necessary but not equally pleasant parts of the job often don't get done.
(I mean, Python has been around for years, and parts of the manual still say "I don't feel like writing this yet -- maybe someday.")
I wonder if the book has any insight on how to deal with the problem.
Tim
The one quibble the reviewer has with the book seems to me likely to be one of its strongest points. Open source has not delivered good end-user applications so far; its strength has been in developer-facing products such as the kernel and the Apache web server. Open source does not meet the challenges of end-user-facing software very well because it requires non-programmer skills like interaction design and graphic design, and does not appeal much to people with those skills. In addition, good user experience design depends on extensive user testing, which requires cash outlays. Open source may produce good software by and for programmers but it falters when it comes to delivering software suitable for the average user. This suggests a hybrid model in which commercial developers create proprietary applications on top of free back-end software.
Tim
It is a common misconception about the GPL that it allows this kind of plugin extension. In fact, however, the GNU GPL FAQ expressly forbids this for any code that runs as an integrated part of a program.
Tim
There is significant prior art for this.
People often claim that there is prior art for any patent they don't like. However, they are usually short on the details of what that prior art was, just as the FSF and yourself are short in this case. If you are correct, congratulations, you can defeat the patent. But you'll need more than a bare assertion of prior art to do that.
Tim
yeah right. The GPL stifled the development of linux too.
Linux isn't an innovation. Linux is a clone of aging technology.
Tim
Here is a significant innovation which was created in hopes that it would be protectable and thus profitable. That is the traditional rationale for patents: by allowing intellectual property to be protected for a limited period, they create an incentive for innovation.
Now we see that the GPL's anti-patent stance appears to be trying to stifle this innovation unless the inventor consents to its terms, which would deprive the inventor of profit.
A clearer example of the anti-innovative tendency of the free software movement could not be imagined.
Tim
Good imagination, guys, especially given that the consensus in the security community is that open systems are more secure rather than less. This bizarre, paranoid speculation is as much FUD as anything that Microsoft has promulgated.
Tim
Seven pages of installation instructions and a bunch of keyboard commands to memorize, and it's "simple"?
Man, some people just will never get it.
Tim
A machine custom built for computing mortgages would be cheaper than a general-purpose computer, right?
It's an interesting counterargument. The fact is that a special-purpose computer is faster than a general-pupose computer for any real-world algorithm which turns out to be computational expensive. That is one of the main reasons why we have ASICs. However, an ASIC is not necessarily cheaper, since many algorithms run fast enough on the general-purpose processor, and the separate chip would not pay for itself given the lack of demand.
It might be that a general-purpose fabricator would prove to be fast and cheap enough for some common goods, and so undercut the need for mass manufacturing of those goods. However, I think this remains entirely speculative given that we don't have anything like a general-purpose fabricator today, and don't know what its characteristics would be. It probably wouldn't work anyway -- see the current Scientific American, in which the world's only nanotech Nobelist explains why there will never be a nanoassembler
Of course, there is a wide range of possible special-purpose fabrication techniques well short of the dream of general-purpose fabricators, and some of these might be useful for distributed manufacturing. Food and clothing come to mind. Reprogrammable cell cultures together with a robotic chef might be able to make reasonable biological simulacra of most possible foodstuffs, while a robotic loom/sewing machine could produce a great deal of high quality clothing. I submit that in either case, the specialization would allow for faster and cheaper production of the goods than attempting to build them molecule by molecule -- if that were even possible.
Tim
I list specific sources of cost in something that someone else is saying is free, and then the responses to my message don't address any of the cost issues I've raised. In this discussion, I raised:
I'd add to that two more:
Your message ostensibly in response discusses none of these costs, except to say that:
You also decline to discuss the issue of economies of scale in mass production. If general-purpose assemblers become cheap, then don't specialized assemblers become even cheaper? At the very least, you can use general-purpose assemblers to create special-purpose ones. The special-purpose ones will then produce the particular goods faster and cheaper.
Tim
This would be great for mankind, as the cost of production would be driven down dramatically, and you could literally have whatever you wanted for the cost of the raw materials to build it.
You're repeating something that's also been said elsewhere in the thread, as well as being a standard doctrine of nanotechnology, which is that this kind of fabrication would be cheaper than current mass production techniques. What is the basis for that assertion? The equipment itself is currently quite expensive even in the limited forms which are now available, and there is a floor to the cost (unless you know somewhere I can buy a good refrigerator for $10?) Then there is energy, time, and waste, as well as distribution of raw materials and raw materials cost itself.
I haven't seen any basis for the assumption that all of these can be driven to near zero. If they can be driven way down, then so can the costs of mass production, which could be driven down even further due to economies of scale. A machine that only builds one thing is going to produce that one thing faster and cheaper than a machine that can build anything. That's true even of theoretical nanoassembly systems.
Tim
>i>IBM is by far the largest OS company in terms of $$ spent on OS projects ($1,000,000,000, or so they say) and they seem to be doing pretty well. Everyone cries "Who will make a succesful service business that supports open source?" The answer: IBM.
It may be. It isn't now. They are spending money on open source, not making money on it. It may work out for them, but it's way too early to cite IBM as an open source success story. They could just as easily become one of the cautionary tales.
Tim
Ralph Nader's consumer advocacy has always been first and foremost about quality, of which safety is a subset. Given that the commercial operating systems (MacOS and Windows) are much more user-friendly than the current slate of Linux offerings, and that even many Linux advocates have now come around to admitting that fact, how does Linux advocacy benefit the consumer? Isn't it strange for a consumer advocacy organization to be advocating a lower-quality product over a higher-quality one?
Tim
why not look at the several threads on mozillazine.org which document the distortions of fact and pure speculation on the part of mozilla quest? Various errors include misinterpretation of bug statistics,
I've read all of them carefully. So far, not one has documented an objective error. The responses are always along the lines of, "so what that we didn't fix a lot of the bugs for this milestone that were marked to be fixed? What does that matter? The project is still getting better, isn't it? How can he say it's buggy? Mike Angelo is such an idiot!"
misconstruing the meaning of projected release dates,
Very similar issue. He points out that a new milestone means a slip in the 1.0 release date, and the responses all say "so what that 1.0 will be a few months later? We're not a commercial project! We don't have a schedule! Who cares when we ship? Mike Angelo is such an idiot!" Again, no factual errors in his analysis are demonstrated. He's reporting things that are true, but taboo on the advocacy site.
and a uniformly unequivically negative opinion of everything mozilla.
Yes, but I was asking for examples of objective factual errors on the site. You don't like his opinions, fine, but that doesn't make him an unreliable source. He broke this story. People at MozillaZine knew about the story for a week and a half and tried to keep it secret. Who's the better news source on this story? MozillaQuest 1, MozillaZine 0. Sorry, but it's a fact.
Tim
For all the flaming of MozillaQuest by the Mozilla faithful, I have yet to see the flamers document a single objective inaccuracy. Most of the responses consist of personal attacks devoid of content. In this case, we have to look at the fact that MozillaQuest broke the layoff story -- accurately -- while the advocacy site, MozillaZine, was still in denial about the prospect of the AOL layoffs hitting the project.
As far as I can tell, MozillaQuest's only crime is in pointing out facts about the late, buggy, and ugly Mozilla project that its small remaining core of advocates would rather see suppressed.
Tim