I think that comment is shortsighted and unfair. I also think I would be hard pressed to come up with a better example of the barrier I'm talking about.
From my personal experience - a Winx user sat in front of a Mac will generally be productive within a day. Same user in front of a Linux desktop will typically give up.
What's needed here and apparently absent from your comment is an ability to listen to the problems I raised and address them constructively. All too often what I find are comments like yours which belittle the user and serve to squelch the kind of insights that are necessary before Linux will succeed on the desktop.
This is precisely the barrier I was talking about. A glowing example in fact.
To address your first point on horror stories, and hopefully leave out the un-needed emotional heat, the point is not a numerical comparison of how many Winx horror stories there are compared with how many *nix horror stories there are. That is immaterial.
What is important is that there are any Linux horror stories and what to do about reducing that number.
I for one am not content to have Linux be "just as good" or "better than" Winx in any case by case comparison. I feel that Linux is far too powerful to settle for that.
Rather, my goal would be to have Linux serve as the basis for a near revolution in computing - one that finally makes reliable, scalable, and powerful computing capabilities accessible in a way that computing has never been. As simple as a toaster for the novice, yet as powerful as the largest super-computer ever concieved for the expert, with no large bumps in-between on the learning curve. An environment that encourages wide and constant innovation while preserving reliability and stability. If a goal must be picked, that would be mine.
No FUD here. Linux is good. But, it's not good enough yet. With open eyes - let's solve that issue.
I can't agree with your experiences on stability. In fact, I trust my Linux boxes more than anything with Winx on it. In my experience, the only reason our Winx boxes don't crash once or more per month is that we've adopted a strategy of rebooting them once per week so they don't "eat themselves". (A hard learned lesson. Maybe exagerated _a little_.)
That only addresses the server side of things though.
I agree on software installation - there are a lot of problems, mostly stemming from the lack of a strong, unified configuration. That is, everybody seems to have their own version of how a Linux (or unix in general) box should go together - and so the configuration options are too broad for a strong standard to emerge. MHO. Even Red Hat's RPM fails to solve the problem a lot of the time (my experience)...
I recently launched a RH7.3 server for MySQL & Resin (JSP Application Developmet).
Everything from the CD went well - and then I needed to add Java. Got the RPM from Sun, and wouldn't you know it - the install went great.
(The other shoe drops here)
...but the program (java) wouldn't run - let alone the fact that I have to manually hack all of the environment varialbes. I thought that maybe this was ahead of the curve (using 1.4 instead of 1.3 on the CDs). I Turned back to the 1.3 version on the CD's - that failed too in precisely the same way.
As it turns out Java needed another package installed before it would work - a dependency - precisely what RPM is supposed to solve. After 3 days w/ tech support (sometimes it just doesn't go well) I got the answer on the package that needed to be there - I found it on the CD, installed it manually, and that problem was solved.
This is an example of something that should have been very simple, but became extraordinarly complex - from cryptic error messages and difficult technical support calls to locating installation packages to manual environment configuration etc... A less technical user would have been in real trouble.
An executive comparing that to the one-button install on a Winx machine doesn't take long to decide it's a better business decision to "stick with what works".
On the point of a user environment/desktop. There again, I have to agree. Every couple of months I pull out the latest RH version, wipe a machine, and try to build a user workstation that I could throw at my user base for business, software development, or even webware work... Every time so far it's a disaster - there are too many tools missing and the tools that do exist have steep learning curves.
On the point of learning curves, there's another core problem here I think - a cultural one. The *nix crowd in general seems to have a built in right of passage. You either know all of the right buzzwords, techniques, tools, and utilities, or it's your own fault that you haven't figured it out yet. (RTFM!)
It's difficult to describe - but I'll bet anyone who's tried to use *nix has had the experience:
You find yourself staring at a problem that should be simple to solve, but everything about it is inpenetrable - you don't even know what questions to ask... - or when abruptly reminded RTFM - which FM to F' READ...
...then, if you're lucky, you will stumble across some *nix guru who will press a few obscure keys and solve the problem instantly (thus is the power of *nix) - Even if they were nice about it and tried to teach you, and even if you took copious notes - this little tid-bit is probably not much more help than wrote instructions - and if you loose them, or forget them some day, you're just as lost as if you'd never had the help.
Even the simple things are maddening. Take the vi / emacs debate - then, prompty forget about it because it completely misses the point. For the typical computer user, in a world where every editor you can find works just about like Notepad (even edit on a DOS prompt works this way for the most part) - vi and emacs are useless and inaccessible.
The newbie can't begin to gain access to a *nix system. What we (people who want Linux to succeed) have to do is realize that in it's most profound terms.
In most of the companies in the world using computers, the guy that has to make it all work isn't a well trained technician or engineer, or even a hobbiest. He's the poor schmuck who figured out how to modify autoexec.bat with his trusty text editor - the token computer geek in the office - and through his continuing experiences he may eventually become a well trained technician... but today he can get by with a few simple tweaks and keep the wheels moving. This is just not so in the Linux world right now.
Show of hands: How many of you know why the following expression is a bad idea:
[/] rm -rf *
The short of it is that I think *nix in general, and by extension Linux, is structured so that the learning curve is far too high for casual entry.
Once you get past the learning curve enough to be somewhat effective, you no longer have the time or energy it would take to bring the next fellow along - and so they will struggle as you have, or they won't "join the club".
I think it likley that until the Linux community solves this entry problem the barriers to solving usability, installation, and integration problems will remain unsolved.
What's needed is a workable environment that doesn't require a deep knowlegde, but does not preclude the benefits of that deep knowledge. A way for the novice to get their work done on their way to becoming a whiz...
Typically those in the open source development community that have the skills to solve these problems are busy with other things - and in any case there's little strong direction as to what the details of such an environment should be...
The challenge is going to be defining that goal and motivating the developer community to achieve it.
The first part is hard because the very people who can help to define that goal are kept out of the community by the entry barriers - and therefore don't get into the conversation.
The second part is hard because it is the nature of the development community (generally) to solve local problems and then share those solutions - rather than coming together to collectively solve a central problem they don't personally have. (Is that where RTFM comes from?!)
Think of it this way... If I have to make my mail server or database work properly, and I can fix the open source code to solve that problem - then I can do that and keep my job - it's all part of the work I've got to do. When I'm done, that work is now available for everyone. By extension, the most common problems will be solved and overall the open source software will be extremely reliable for the majority of people most of the time.
Try to apply that to this problem: Basic users need a unified desktop and operating system with integrated applciations and a shallow learning curve. Now tell your boss that you're working on a suite of productivity apps and a one CD linux distribution that will slickly install and interoperate with the majority of the business world running Windows. I'll bet he will ask: "How's that going to get our database up?"
The boss in this case might be the developer themselves. Best intentions, altruism, and grand visions not withstanding, it is not the open source developer's job to make everyone's desktop work and their installs go without a hitch - This is an advantage that the Microsoft developer has - it is their job and they get paid to do it. Similarly for the ISV/ISD - the potential for conflicts of interest are reduced significantly.
The short way of saying this might be that the open source community, left to it's own devices, probably can't solve this problem.
What's needed is an economically viable project that can focus the community on a unified vision, and specifically one that is strong enough, and compelling enough that the majority of the community will wish to participate.
To work, this project would have to encoumpass a wide range - not only the operating system and it's environment, but also the applications that make that environment powerful - IDEs for all programming languages, Word processing and document publishing, Spreadsheet, Database, Presentation, Mulitimedia, Web & Email access, all of those applications will have to work together in a seamless way - and had better coexist nicely with Microsoft's products which, like it or not, set the standard due to market share.
To date, I've seen some methodologies get close to supporting this kind of effort (a few good tries) - but nothing seems to have captured the critical mass necessary to generate this kind of focus.
It's a thorny problem.
I think we'ev seen some glimpses of what it _might_ be in the likes of MySQL, RedHat, Sun(java)... where there is a blend of open source and commercial licensing - sort of the best of both worlds. None of these seem to be perfected yet.
Slashdot Mirror
I think that comment is shortsighted and unfair. I also think I would be hard pressed to come up with a better example of the barrier I'm talking about.
From my personal experience - a Winx user sat in front of a Mac will generally be productive within a day. Same user in front of a Linux desktop will typically give up.
What's needed here and apparently absent from your comment is an ability to listen to the problems I raised and address them constructively. All too often what I find are comments like yours which belittle the user and serve to squelch the kind of insights that are necessary before Linux will succeed on the desktop.
This is precisely the barrier I was talking about. A glowing example in fact.
To address your first point on horror stories, and hopefully leave out the un-needed emotional heat, the point is not a numerical comparison of how many Winx horror stories there are compared with how many *nix horror stories there are. That is immaterial.
What is important is that there are any Linux horror stories and what to do about reducing that number.
I for one am not content to have Linux be "just as good" or "better than" Winx in any case by case comparison. I feel that Linux is far too powerful to settle for that.
Rather, my goal would be to have Linux serve as the basis for a near revolution in computing - one that finally makes reliable, scalable, and powerful computing capabilities accessible in a way that computing has never been. As simple as a toaster for the novice, yet as powerful as the largest super-computer ever concieved for the expert, with no large bumps in-between on the learning curve. An environment that encourages wide and constant innovation while preserving reliability and stability. If a goal must be picked, that would be mine. No FUD here. Linux is good. But, it's not good enough yet. With open eyes - let's solve that issue.
I can't agree with your experiences on stability. In fact, I trust my Linux boxes more than anything with Winx on it. In my experience, the only reason our Winx boxes don't crash once or more per month is that we've adopted a strategy of rebooting them once per week so they don't "eat themselves". (A hard learned lesson. Maybe exagerated _a little_.)
That only addresses the server side of things though.
I agree on software installation - there are a lot of problems, mostly stemming from the lack of a strong, unified configuration. That is, everybody seems to have their own version of how a Linux (or unix in general) box should go together - and so the configuration options are too broad for a strong standard to emerge. MHO. Even Red Hat's RPM fails to solve the problem a lot of the time (my experience)...
I recently launched a RH7.3 server for MySQL & Resin (JSP Application Developmet). Everything from the CD went well - and then I needed to add Java. Got the RPM from Sun, and wouldn't you know it - the install went great.
(The other shoe drops here)
...but the program (java) wouldn't run - let alone the fact that I have to manually hack all of the environment varialbes. I thought that maybe this was ahead of the curve (using 1.4 instead of 1.3 on the CDs). I Turned back to the 1.3 version on the CD's - that failed too in precisely the same way.
As it turns out Java needed another package installed before it would work - a dependency - precisely what RPM is supposed to solve. After 3 days w/ tech support (sometimes it just doesn't go well) I got the answer on the package that needed to be there - I found it on the CD, installed it manually, and that problem was solved.
This is an example of something that should have been very simple, but became extraordinarly complex - from cryptic error messages and difficult technical support calls to locating installation packages to manual environment configuration etc... A less technical user would have been in real trouble.
An executive comparing that to the one-button install on a Winx machine doesn't take long to decide it's a better business decision to "stick with what works".
On the point of a user environment/desktop. There again, I have to agree. Every couple of months I pull out the latest RH version, wipe a machine, and try to build a user workstation that I could throw at my user base for business, software development, or even webware work... Every time so far it's a disaster - there are too many tools missing and the tools that do exist have steep learning curves.
On the point of learning curves, there's another core problem here I think - a cultural one. The *nix crowd in general seems to have a built in right of passage. You either know all of the right buzzwords, techniques, tools, and utilities, or it's your own fault that you haven't figured it out yet. (RTFM!)
It's difficult to describe - but I'll bet anyone who's tried to use *nix has had the experience:
You find yourself staring at a problem that should be simple to solve, but everything about it is inpenetrable - you don't even know what questions to ask... - or when abruptly reminded RTFM - which FM to F' READ...
...then, if you're lucky, you will stumble across some *nix guru who will press a few obscure keys and solve the problem instantly (thus is the power of *nix) - Even if they were nice about it and tried to teach you, and even if you took copious notes - this little tid-bit is probably not much more help than wrote instructions - and if you loose them, or forget them some day, you're just as lost as if you'd never had the help.
Even the simple things are maddening. Take the vi / emacs debate - then, prompty forget about it because it completely misses the point. For the typical computer user, in a world where every editor you can find works just about like Notepad (even edit on a DOS prompt works this way for the most part) - vi and emacs are useless and inaccessible.
The newbie can't begin to gain access to a *nix system. What we (people who want Linux to succeed) have to do is realize that in it's most profound terms.
In most of the companies in the world using computers, the guy that has to make it all work isn't a well trained technician or engineer, or even a hobbiest. He's the poor schmuck who figured out how to modify autoexec.bat with his trusty text editor - the token computer geek in the office - and through his continuing experiences he may eventually become a well trained technician... but today he can get by with a few simple tweaks and keep the wheels moving. This is just not so in the Linux world right now.
Show of hands: How many of you know why the following expression is a bad idea:
[ /] rm -rf *
The short of it is that I think *nix in general, and by extension Linux, is structured so that the learning curve is far too high for casual entry.
Once you get past the learning curve enough to be somewhat effective, you no longer have the time or energy it would take to bring the next fellow along - and so they will struggle as you have, or they won't "join the club".
I think it likley that until the Linux community solves this entry problem the barriers to solving usability, installation, and integration problems will remain unsolved.
What's needed is a workable environment that doesn't require a deep knowlegde, but does not preclude the benefits of that deep knowledge. A way for the novice to get their work done on their way to becoming a whiz...
Typically those in the open source development community that have the skills to solve these problems are busy with other things - and in any case there's little strong direction as to what the details of such an environment should be...
The challenge is going to be defining that goal and motivating the developer community to achieve it.
The first part is hard because the very people who can help to define that goal are kept out of the community by the entry barriers - and therefore don't get into the conversation.
The second part is hard because it is the nature of the development community (generally) to solve local problems and then share those solutions - rather than coming together to collectively solve a central problem they don't personally have. (Is that where RTFM comes from?!)
Think of it this way... If I have to make my mail server or database work properly, and I can fix the open source code to solve that problem - then I can do that and keep my job - it's all part of the work I've got to do. When I'm done, that work is now available for everyone. By extension, the most common problems will be solved and overall the open source software will be extremely reliable for the majority of people most of the time.
Try to apply that to this problem: Basic users need a unified desktop and operating system with integrated applciations and a shallow learning curve. Now tell your boss that you're working on a suite of productivity apps and a one CD linux distribution that will slickly install and interoperate with the majority of the business world running Windows. I'll bet he will ask: "How's that going to get our database up?"
The boss in this case might be the developer themselves. Best intentions, altruism, and grand visions not withstanding, it is not the open source developer's job to make everyone's desktop work and their installs go without a hitch - This is an advantage that the Microsoft developer has - it is their job and they get paid to do it. Similarly for the ISV/ISD - the potential for conflicts of interest are reduced significantly.
The short way of saying this might be that the open source community, left to it's own devices, probably can't solve this problem.
What's needed is an economically viable project that can focus the community on a unified vision, and specifically one that is strong enough, and compelling enough that the majority of the community will wish to participate.
To work, this project would have to encoumpass a wide range - not only the operating system and it's environment, but also the applications that make that environment powerful - IDEs for all programming languages, Word processing and document publishing, Spreadsheet, Database, Presentation, Mulitimedia, Web & Email access, all of those applications will have to work together in a seamless way - and had better coexist nicely with Microsoft's products which, like it or not, set the standard due to market share.
To date, I've seen some methodologies get close to supporting this kind of effort (a few good tries) - but nothing seems to have captured the critical mass necessary to generate this kind of focus.
It's a thorny problem.
I think we'ev seen some glimpses of what it _might_ be in the likes of MySQL, RedHat, Sun(java)... where there is a blend of open source and commercial licensing - sort of the best of both worlds. None of these seem to be perfected yet.
Anybody have a solution?