|
Page 13 of 26
12. Hype vs. real needs
Once a business, always a business: Linux is subject to the inflation of the buzzwords and the false "needs" you encounter with anything that's marketable. As Miguel de Icaza was telling two years ago to Linux Format, «Linux used to be hip, but it's lost its hipness. The new thing is Mono - Mono is hip!» So Mono is the new kid in town.
Have you noticed how the IT industry doesn't seem to know whither to go, where to head to? The enterprise stack includes J2EE, but it also includes .NET. Expensive Oracle deployments and endless SAP implementations are still selling, but the quality of the software is not better than in times of COBOL. The more complex a software infrastructure is, the more painful it will be, but the ROI is hardly a certitude. Dozens and dozens of CRM and ERP solutions do exist, but I have never met a satisfied customer so far.
This is when buzzwords sell more. Because not everyone was happy with Java, and because the .NET technology that relies on a Common Language Infrastructure (CLI) pioneered by Microsoft is now an ECMA standard (ECMA-335, ISO/IEC 23271), someone thought that an open-source clone of .NET, namely Mono, would make the best choice for running .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix at large (Mono is a project sponsored by Novell).
Are we really depending on a Microsoft concept to save the enterprise services in Linux? Some people don't seem to be bothered by that. Sadly enough, Mono is nowhere close to replace the enterprise Java. Nowhere close to that. After all these years of fuss and increasing enthusiasm, Mono has not replaced ASP.NET in the companies that are using .NET on Windows platforms. The most prominent use of Mono in Linux is the use of C# for standalone GUI projects, namely through Gtk#.
As a matter of fact, the most important result was that GNOME got contaminated with Mono. Initially emerged because of license worries with regards to KDE (so it was about freedom!), GNOME is now tributary to a Microsoft-inspired technology! Unbelievable, yet true. So Mono has not fulfilled the initial expectations. On the contrary, it has made a lot of Linux users to be dependent of Gtk# (through Beagle, Tomboy, etc.), whereas excellent solutions for desktop tools already existed, e.g. PyGTK or PyQt.
While Mono is available under Red Hat's community distribution Fedora, the company's flagship Red Hat Enterprise Linux 5 does not include Mono! Is it because Red Hat does not venture into a "Novell business", is it for they can't go for a "Microsoft-designed business", or is it that I am not the only paranoid in town?
Another buzzword very cherished nowadays is about virtualization. This is what I call "Xen-mania". The IT press is full of reports on how Xen performs under SUSE or with Red Hat. Everybody is "just trying it", yet very few people really need it. Red Hat was initially reluctant to Xen, as it was dubbed "not ready for production use" (or maybe this was because Novell was the first to offer it), but now they just gave to the market what the market wanted.
When you will find about a decent number of companies really using Xen, drop me a note. Xen is still a buzzword meant to boost the sales, and this works very well in North America, where ingenuous CEOs and CTOs buy Red Hat because "it's corporate Linux" the same way they buy Oracle's broken Linux clone "because it's oh, Oracle", yet they don't make use of them. They were buying IBM with Microsoft in the past, so they're buying now what's trendy. While this can be seen as a commercial success, it is not what Linux needs.
What is really used in the real word, and it's not new technology: chroot jails in Linux, BSD jails, Solaris Zones. They just work, and they're cheaper in resources.
On the other hand, while Novell is supporting the Mono project, they have dropped the support for Hula, their own open source mail and calendar project. Novell was unable to manage such a simple project, while smaller companies had the skills to provide with excellent groupware solutions like Zimbra and Scalix that can successfully replace Exchange (I liked Zimbra, and I was short to install Scalix).
The crappy management at Novell can also be seen by looking at the most advanced mail client, Evolution. Advanced or not, Evolution lacks an elementary feature present for ages in all the Windows e-mail clients: a tooltip notification when new mail arrives, possibly providing you with details on the received messages.
I was suggested to use third-party programs to be notified of new mail, but this is not the point. When a MUA collects the mail, it is supposed to notify me synchronously ("hey! I have new mail for you!"). The third-party solutions are asynchronously checking for new mail, which means the moment they will notify me has nothing to do with the moment when Evolution has collected my mail.
The lack of focus on basic user needs is deplorable. We can have spinning cubes in Linux, yet Evolution is unable to provide with visual notification when new mail arrives. Even Microsoft is better at that.
The IT press features a stunning mimicry: a recent article describing how the Kubuntu-derived Pioneer Linux Basic Release 2 fails to differentiate enough to have a raison d'étre finds the "supreme argument": Automatix2 (a questionable concept in itself) doesn't misses a few packages, especially the virtualization product VirtualBox. I am positively sure that Al Bundy (part of the target group of Pioneer Linux Basic) can't live without virtualization.
Some other times, the needs might be real, but the solutions will deceive an uneducated user: I am thinking of the new Desktop Search metaphor.
The latest years have brought to the public Beagle, Strigi, Tracker, Pinot, Recoll, Doodle, and a few more Linux equivalents of the Windows counterparts Copernic Desktop Search, Blinkx, or Google Desktop. These are engines that make use of a daemon to periodically index the documents on your hard disk, so that a later search will provide with faster results than a more classic inquiry using find, grep, locate, or the desktop own "Search in Files" GUI tool.
What's wrong with the new desktop search tools?
The first wrong move was to have the corresponding daemons started by default in some distros. This would generate a "mysterious" and intensive extra disk activity in idle periods. For the worse, SUSE 10.0 has replaced GNOME's own gnome-search-tool with a Beagle search in Nautilus, thus breaking the common usage pattern.
Any user that will expect for accurate results will be deceived. The file you have just created or modified a few minutes ago, the new mail and whatever else has not been reindexed will be missing or showing the wrong contents in Beagle's result list. This is because, contrary to the "good ol' grep" that searches every possible matching file, Beagle only looks in the database with the indexed files (usually your home, plus your Evolution mails). When they get indexed!
Personally, I just cannot rely on results which depend on a database of (not yet) indexed data instead of a real search. These "approximate" searches have the advantage of the speed and they can take into account meta-data from several types of files. The "meta-search" capabilities come with a price though: the price of ruining the image of Linux as an accurately working UNIX system.
The last time when I used Beagle I couldn't persuade it to reindex a file that was modified for two weeks already, so that the search results showed a preview with non-existent contents.
All the wrong solutions to the unnecessary needs seem to come from a Windows-like approach of the computing.
|
Articles 
