News
Features
Guest Essay
Technicalia
Security
Community
Commentary
Home
ymmv
The View from the Desktop
The April Fool's joke that oughtabe
It's funny, the reaction to this year's bumper
crop of April Fool's jokes and stories, that
so many people didn't find them funny at
all.
Some were truly state of the art in their cleverness and sophistication -- Qt-Console is very funny, but then there are the screenshots! Some were just wonderful -- Slashdot moderating a first-post post to "+5, Insightful" is the kind of thing that you simply don't expect. Some people found them all funny; some people thought they were all just awful.
One of them made me kind of sad. It was Qt-Console. A lot of people actually believed in it. I actually believed in it for a few minutes, a belief I thereafter realized was born of wishful thinking.
Imagine: a small, easily compiled package the result of which would be a ready-made suite of console applications employing the same configuration files and document formats and storage structures that we already use under XFree86 and KDE, but running much faster and making far better use of system resources than our X-based desktops do. A set of applications which are CUA-compliant, meaning that they have menus, menu contents, and key bindings that are consistent from application to application.
You know: the kind of thing that allowed applications to run under DOS on an 8088 15 years ago as quickly and as easily as our modern desktops and apps do today on a 1-gig machine with 512 megs of memory. One drools at the possibility.
Or the impossibility, if one is looking at Qt-Console. I mean, I suppose it's not unreasonable to think of grabbing huge pieces of the Qt API and redirecting them to run things in the console -- I believe that SuSE does something very like this with YaST2, which comes up as a text application if you don't have X running; I doubt they rewrote everything, but I also doubt that the front end is the same, merely hitting the API differently based on the status of XFree86.
Let's imagine that it were true, that a console subset of Qt which dealt neatly and efficiently with all the things a behemoth like KDE does, throwing away -- early on -- the stuff that now didn't matter. What would it give us?
Let's look at what KDE brings to the table. A big desktop with a lot of nice features -- these would all pretty much get routed to /dev/null, though it would be possible to replicate Kicker, to some extent, by the iconic equivalent of the "alt=" html command, which substitutes words describing what you would be seeing had the graphic that didn't had loaded properly. You could even do this for desktop icons. It would require some extra code and probably wouldn't be that attractive or desirable, and it wouldn't bring the user value for resources spent, but it probably could be done.
Now let's consider the applications. The games would be out, because they are pretty much graphical by definition. Likewise the graphics and drawing tools. A text-based konqueror would be good, perhaps for Web browsing but certainly for file management and ftp client purposes -- Midnight Commander with a CUA menubar. KDENetwork ought to work pretty well, because there's nothing it does that isn't done more efficiently from the console anyway. Likewise the KDE PIM, which might actually become more attractive for having shed a few pounds. Some of the multimedia stuff would be fine; some, such as mpeg players, obviously wouldn't. The various little editors and even the KDE IDE ought to make the jump just fine, as should the administrative tools. The word processor and spreadsheet in KOffice would be fine, somewhat resembling, say, Microsoft Works 2.0.
There would be disadvantages -- there's no reason to have Qt or anything like it in the loop at all. No such toolkit is needed to write console applications. We're talking a degree of complication the sole purpose of which would be to allow the use of KDE applications. I do not know the extent to which there's anything useful in the KDE code for anyone seeking to make a console port, but it's probably true anyway that starting from scratch and simply writing a suite of console applications would be as easy as trying to shoehorn KDE in.
All of which is fanciful imagining. What isn't is the fact that the Linux console is the most underutilized resource in computing.
As Linux and Main columnist Ron Landley will explain in detail in the coming weeks, file formats matter more than the applications which write to them. What matters to the KDE (or GNOME) user is the idea that file formats and at least some configurations remain constant, both from version to version and in our imagined console suite. There is, of course, no reason why a text-based KMail couldn't use the same configuration (within reason -- font selections, for instance, would have little analog in a console application, though font colors would be useful), maibox, folders, and index files. A console KWord could write the same formats, such as they are, as the graphical application. Fact is, file formats are more important to Linux than are KDE, GNOME, and all the rest put together.
Because once file formats are settled upon, the destination is determined with an endless number of routes to get there. But I'll leave that to Rob, who has done more work on it and given it more thought than I have. I'll stick with the lesser consideration, the applications, and my belief that the console is tremendously underutilized.
Any longtime Linux or UNIX hand will argue that there are loads of console applications, and strictly speaking that's true. But look at them! There is talk about the "holy war" between advocates of emacs and advocates of vi, and bringing religion into it is probably pretty sensible, because starting out with either one is an act of faith. They are not applications, they are clubs, and they have very rigorous rites of initiation. They are unconscionably unintuitive. Knowledge of anything else is of little use with either of them. They are the poster children of the widely heralded "steep learning curve" of Linux.
The community's response has been to churn out these huge -- or in some cases not huge, but you seldom hear about those -- graphical arrangements, where everything from boot to shutdown takes place with XFree86 running. And to what end?
Whole classes of applications are singularly ill-suited for a graphical user interface; indeed, to the extent that high-quality content comes from them it is because the person using them was able to overcome the GUI rather than benefit from it.
Word processing, for instance. It's nice, sure, to know how a document will look overall, but when the document is being composed, its appearance oughtn't enter into it -- its content should be the sole concern. It can be prettified later, when that, rather than the content, is the object. Trying to do both at the same time is as silly as trying to paint a boat as you build it.
Text-based applications are faster than even the fastest GUI application. They have to be. They require less of the system. They require less system, period. GUIs are a tremendous waste of system resources unless the task at hand is something graphical. You'll note that Linux system administrators seldom even install XFree86 on their machines. This isn't all machismo at the command prompt.
What's so sad about there never having been developed good, consistent, text-based applications for Linux is that Linux is perfectly suited for useful work with that kind of app. There are all sorts of multi-tasking tricks -- multiple applications on the same screen, of course, but also the multiple virtual desktops that we all have. Console mouse support is good. All that's needed is a suite of nice, CUA-compliant applications writing to sensible configuration and data formats.
Moreover -- ugh, here he goes again -- a world of relatively low-powered machines that stagger and fall under the weight of the graphical overhead heaped upon them would hum along productively with good console applications. March into a small or medium-sized enterprise and announce that you have a system that's easy to use, runs faster on their existing hardware, is highly reliable and fully connective, offers all the modern conveniences of email, file sharing, and the like (and makes Web surfing during work time less attractive), and business owners will snap it up. So will lots of people who would like to do something useful with that old computer that is otherwise headed for the dump. Instant jump in the Linux user base and, yes, the Linux desktop user base.
Nor do console applications need to be unattractive. Most of the ones for Linux are, but that's because they were designed by hackers for hackers. In terms of appearance, the console is nearly as configurable as a graphical desktop is. No, there wouldn't be any tricky wallpapers or animated icons, or 3-D screensavers. But the experience needn't be unpleasant.
It's all so obvious, it's a mystery why it has never happened. We have hundreds of people working on each of two big GUI projects which, no matter how you cut it, are fundamentally redundant. There are hundreds more spread out over smaller GUI projects. Which are in many ways also redundant. There are scads of people hacking away at Mozilla and OpenOffice. And in all of it there is no project to produce a simple collection of good, easy-to-use console applications.
Which is why some people, myself among them, so very much wanted to believe in something like Qt-Console. It would not have utterly embraced sanity, but it would at least have been a nod toward it.
How sad that the one day that the subject is raised is also the one day set aside for foolishness and tricks. The rest of the year we can argue over KDE vs. GNOME. I can never remember which is the pot and which is the kettle.
And all the while, one area in which Linux has real, demonstrable advantages over the products out of Redmond goes untapped. That's the real fool's joke, and it lasts all year long.
Comment on this article
Posted 3 April 2002