Hooray for Bluecurve
Immediately after its release and apart from the usual rough edges of every .0 version, Red Hat 8.0 generated a lot of heat. Much of it came from the Bluecurve desktop and from the changes RH made to standard KDE (for those who care, a good, though partial, summary of what Red Hat actually did is available here).
Red Hat had good reasons to create such an interface, apart from the unavoidable implementation errors. Even before the release, however, KDE developer Bernhard “Bero” Rosenkraenzer left Red Hat, claiming that KDE, as shipped in that distribution, is crippled. Since it's release, many GNOME and KDE fans are screaming because of this unrecognizable, offending, hybrid GUI. An excerpt from this posting sums up their feelings pretty well:
What you see is neither Gnome nor KDE in RH 8! Kind of comical actually.... I think...Redhat did [us] all a huge disservice with RH 8.
Personally, I am happy Red Hat melted the two environments together. If nothing else, this could be an excellent opportunity to realize that decently functional, good-looking desktop interfaces can be built on the assumption that KDE and GNOME themselves aren't really necessary and important in the first place.
In the rest of this article, I'll refer to them simply as K/G.
Back in 1996 and 1997, as a free desktop user I missed a few basic things—I'm still missing them today.
Making the cut-and-paste option always work between windows.
System-wide Unicode, instead of n different solutions for the Euro symbol.
One standard, centralized, font management system, for both display and printing.
A method for easy definition of the same hot keys across different applications.
Documentation written for end users, not people debugging a program.
Of course, K/G have slowly added come of these options. But I can't help but ask myself if these changes happened by mistake, while they were doing something sillier and (at least initially) throwing performances out the window (pun intended).
I would have liked to see, and here comes the real issue, programmers working to provide a path along which all existing applications could independently evolve in such a way that programmers could work less and end users could choose any combination of programs that maintain performance, integration and the userspace features listed above.
Instead, what K/G have said and done [during their development] sounds an awful lot like “let's throw existing applications away, even when they are perfectly good, and make everybody start using our programs”. One world, one Net, one (set of) windows—it's déjà vu.
I agree that without K/G Linux screenshots look like a mix of many different things—things that don't really want to stay close to each other. This point is made in this message and expanded in the related thread.
Beginners may indeed have an easier time if, for instance, the File Open dialog and other components were always the same in any application. In spite of this, however, I keep thinking that the whole “one look and feel” mantra is seriously overrated. I further believe that advancing toward desktop integration starting from the windows is the wrong way to go.
First of all, free software is successful because it started doing the “best of breed” thing decades before consultants created the slogan so they could overprice enterprise-level, process-oriented, Dilbert-R-Us, business “solutions”. Now some KDE-centric distributions are proposing that Mozilla be the standard default browser. Good, keep going: I might not personally agree, but I like open, pragmatic minds.
KOffice is trying to become a free FrameMaker with fully integrated spreadsheet and presentation capabilities. Being the ultimate solution to my idea of desktop/WYSIWIG publishing is why I'd use it, side by side with mutt and The GIMP—not because it browses local folders looking just like Konqueror.
What about developing effort? Mike Harris recently pointed out the huge amount of energy Red Hat is still forced to spend to make OpenOffice, K/G, Mozilla, X and fonts coexist, and I can't see why other distributions should be different in these respects. Speaking of fonts in general, Mike helps us understand why complaining about Bluecurve themes, in and by itself, is pointless:
The GNOME and KDE releases in Red Hat Linux 8.0, both are using Keith Packard's Xft2 and fontconfig, both of which are a core part of XFree86 now, and will be _the_ way fonts are done from now on period, in _all_ Linux distributions that are using X at all.
Keith has done a fantastic job at creating this technology, and we are very glad to be using it in Red Hat Linux 8.0, and to take X11 out of the 1980's finally.
For years I have made it a point not to lose sleep over any K/G, and now Bluecurve, crusade, on the assumption that the only meaningful road to really useful and flexible desktop integration is what I call a “path” above. A few weeks ago, I found the same concept in a message by Havoc Pennington. As he clearly expressed the idea in software engineering terms, and because it makes me really happy to see real gurus agree with the actual needs of the poor users, I'll quote Havoc directly:
Interactions between applications and the runtime environment really need to take place via documented, toolkit-independent protocols and file formats.... Documented, long-term-supportable protocols are the way to go from an engineering standpoint, vs. more ad hoc and implementation-dependent solutions.
The last and more important reason to stop bothering with K/G, Bluecurve and what-not is what I call the “migration mistake”. Please let's end this desktop environment tantrum and realize how futile it is to think Windows users will be freed from slavery by somebody saying, “Here, take this, it looks and feels just like Windows.” This last point has been thrown around too much, in too many places.
The question “How do I replace Microsoft Access” appears on the mail OpenOffice.org list every other week. Every time it reappears a bunch of solutions, usually MySQL-based, are kindly suggested. Almost always, though, nobody—starting from the original poster—understands what is really being asked. They're not looking for a “a stable, powerful and license-free DBMS which also has more or less the same buttons as Access” as much as they are looking for “whatever, even text-based, as long as it reads perfectly ten years worth of customer orders”.
Windows users (especially corporate ones) don't stick with Windows because they can't stand different interfaces, but because they have a really hard time converting terabytes of documents in proprietary formats. This is the real problem.
With respect to those Microsoft users not chained by data compatibility but only by mouse and start panel addiction, give them (and yourselves) a break. They couldn't care less about K/G. They want to see windows, any windows, so they can point-and-click all the way through. Everything that helps them to leave closed platforms and formats is fine. After the first thirty minutes, they won't even notice if their fingers are single- or double-clicking. Why should you?
Marco Fioretti is a hardware systems engineer interested in free software both as an EDA platform and (as the current leader of the RULE project) as an efficient desktop. Marco lives with his family in Rome, Italy.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide