|
 |
By Brian Proffitt It was kind of nice to see a little community activism on Linux Today and other media sites this past week. When we posted Eric Raymond's open letters to Sun regarding Java, it elicited a positive and more detailed response from the community in the form of a contribution to Linux Today from Ganesh Prasad. Already, Ganesh's article is the most read of 2004, and is likely to keep that status unless a Federal judge dismisses one of SCO's lawsuits and thus precipitates the electronic equivalent of dancing in the streets. Until that day, however, not a lot of issues are likely to generate this much interest. Unless, of course, ESR writes another column. Which he did. His recent rant on the lack of configurability in CUPS struck some nerves in the community--and this time he was criticized for not knowing of what he wrote. The issues he raised about CUPS, it seems, may actually be problems in Fedora, or GNOME, or something else, depending on who you ask. I am not going to debate the accuracy ESR's statements, though I personally use CUPS on Fedora for a remote printer and I have never had the problems he's described. What struck me as the talkbacks rolled in stating opinions on the article is that ESR may have accidentally given voice to a completely different weak spot in Linux and open source in general. If something goes wrong, finding the solution to fix the problem, or even finding the real cause for the problem can be a major challenge. When Raymond saw what he perceived was a problem with CUPS, he assumed it was a problem in CUPS and broadcast his opinion about it. But it could have actually been a problem with something else. The fact that there is no clear idea on what was the cause of this problem (which, ultimately, leads back to who is responsible for fixing the problem) is not a very good situation to be in. Many of us, as geeks, know how to work the system and find solutions to any problems. We Google, we hit a distro's site, we surf SourceForge, we visit JustLinux. We can, if we're very knowledgeable, find the actual developer of the application and ask them for help. And, of course, if we're really skilled, we can fix it ourselves and release a patch. I have done all of these steps, save the latter, because the only programming I ever did was BASIC on an Apple IIe in high school. And it was bad. Looking around me, if many of my friends run into a computer issue on their machines, regardless of platform, they will contact the software--oh, heck, who am I kidding? They'll call me first. Then they might contact the software maker, search the Web, check the help forums. This problem of locating where a specific problem is actually caused is not unique to open source systems, of course. In the past, I have been told that an application problem was really an issue with the OS--and then have been told that the same problem is not due to the operating system, but to the app. With Linux, though, the problem is more complex. Like the human body, Linux is a collection of cells that cooperatively work together in groups and then as a meta-group. And, like the body, it usually does its job very well. But this kind of differentiated structure can make identification of problems all that more complex. It makes me wonder if there's a future job market for Linux diagnosticians--technicians who don't specialize in any one aspect of Linux, but who can look at the Linux body as a whole and quickly diagnose application issues and help find the right solution. I don't think this a huge concern, mind you. For the corporate environment, IT departments should be able to support Linux workstations and servers just as easily as they do Windows machines. That's what they're there for. But if Linux is to ever seriously breach the home/consumer market, there will need to be über-providers of support that go beyond what the distribution companies cover. Don't get me wrong, the distro firms do a fairly good job of support--but for the non-technical home user, I think there will have to be a much more robust support system put in place. For this kind of project, I think Linux can actually succeed better than its proprietary counterparts, mostly because of its open-source nature. It could be one-stop shopping for almost all Linux issues, whether it's the kernel or the latest version of Weather Report. In the proprietary arena, you're not going to get kind of comprehensive care very often. If TurboTax breaks, you're going to call Intuit, not Microsoft... unless Intuit says it's Microsoft's fault after having you on hold for a half-hour. Can this work? I know similar attempts have been tried before, but that was in the dot-boom era, when many people were not thinking as clearly as they should. With a more cautious, reasoned approach, I think such a system would be effective and (ideally) profitable. Something to think about, if you're in the entreprenuerial mood. Related Stories:
 
|
 |
|
|
|
| All times are recorded in UTC. Linux is a trademark of Linus Torvalds. Powered by Linux, Apache and PHP
| |||||||||||||||||||||||||||||
Turbo Screen Sharing
