SuSe CEO: 'Linux Still Not Ready for the Desktop'

A lot of people have been submitting the interview with SuSe CEO Roland Dyroff, in which he states the Linux is not ready for the desktop. Sounds bad, right? Well, if you read the interview, it makes much more sense - he talks about company adoptions of Linux, but also addreses issues of hardware drivers and such. But with the upcoming release of the GUI Managers and the rising number of pre-installed Linux boxen, I think we're getting closer.

Comments

Welcome to 2000...

[emerson]

That's right, folks, welcome to 2000: The Third Annual Year Linux Will Really Be Ready For The Desktop.

Highlighted events include:
-- presentations by two more vendors with GPLed hardware drivers.
-- discussion of why StarOffice is, in fact, a perfect and complete replacement for Microsoft Office.
-- announcements from the Gnome and KDE teams about further slavish aping of existing WIMP interfaces.
-- side seminar from old-school devotees: "Why Dumbing Down Linux for the Desktop User is a Bad Thing."
-- hundreds of anecdotes about Linux-using grandmothers and girlfriends.

...and, to close out the year, we have the standard recap planned: "What Linux still needs in order to be a desktop OS."

Be there early to make your reservations for our next event, "2001: The Fourth Annual Year Linux Will Really Be Ready For The Desktop."

--

Re:Umm

[cpt kangarooski]

Excuse me for just a moment.

Bwa ha ha ha ha

Okay, now that that's out of my system, please allow me to explain about the GIMPs #1 and 2 shortcomings.

1. Color

There are two common ways in which we can create color. The first is Additive. This basically means that you are adding different types of light (that's what color is, after all) and you can eventually arrive at white by combining all colors. The three primary additive colors are Red, Green and Blue. Sunlight is additive, and so are computer monitors - they actually emit light.

The other method is subtractive. This means that instead of emitting, say, red light, you have an object which absorbs all light _except_ red. No light is created in this process. Instead, light is absorbed. If you combine the subtractive colors, you get black (ideally). Because of imperfections in the substances used to absorb color, it tends to get all muddy, and so the primary subtractive colors are Cyan, Yellow, Magenta and Black (which is denoted as K). (Cyan ~= Blue; Magenta ~= Red)

You'll surely have noticed that your color printer has either 4 ink cartridges/toners (CYMK) or 2 (CYM and K). NOT RGB. Besides, RGB can't create Black, so you'd need black paper and a whole lot more ink.

Clearly we haven't got paper yet that emits its own light. This means that while displayed pictures are additive, printed pictures are subtractive. A conversion has to be made between the two colorspaces (there are others, the most well-known being L*a*b). Furthermore, it is very important that the conversion process be highly accurate, and that the colors that are on screen closely match the color when it's printed (which ranges from impossible to really hard) so that you don't screw something up and only discover it when it's printed out.

Worse yet, the gamut of colors that we can see is bigger than the gamut of colors that can be generated by either one of these processes (try duplicating Day-Glo orange on your screen - it just won't ever look right, because that particular shade is out of your monitor's gamut)

At any rate, GIMP has absolutely no CYMK support at all. And since virtually all color printed material relies on CYMK, and accurate color matching and conversion, the GIMP is simply not going to make inroads. Why bother using the GIMP _and_ Photoshop, when you can just use Photoshop, and probably have better results to boot?

Plus, professionals in the printing world use a lot of esoteric hardware (you'd get a kick out of an imagesetter, i can tell) which all screw up ideal color in their own way, and need to communicate with your software to compensate for this. Scanners, monitors, printers - they all have to be calibrated carefully just depending local lighting conditions if nothing else. And there's always something else.

2. Pantones

The other common method is to use spot colors. You see, for each color you use, the price of printing it will go up - more ink will be needed, each color requires a seperate lithographic plate, more drying time may be needed, material may have to go through a press twice in order to get all of the colors (presses typically have 1-6 plates, so too many plates requires a 2nd pass all the way through again), more work has to be done to make the plates align properly so that colors don't look weird, etc.

One solution to this problem is to use spot colors. Say you want green and black. You could create green with C & Y, making it a 3 plate job (CYK), or you could just use a special green ink instead. Additionally, if there's a color that you can't reproduce with CYMK, or you want colors to be solid instead of halftoned (combining CYMK requires halftoning - the colors are not really overlapping solid regions, but lots of little dots side by side - you can see them with a magnifying glass), you might specify certain spot colors.

The Pantone system basically consists of *many* specific, standard inks. These inks have very specific colors, and behaviors, and you will want to know precisely which one you have. Most people in printing have a swatch book that can be used to compare colors, and Photoshop has a big Pantone color palette in it. But when someone wants you to print with Pantone 072 (a very commonplace blue) you have to be able to model it properly in the computer.

There's no Pantone support in GIMP either.

Besides all this, don't get me started on the finer, but essential details of printing (trapping, overprinting, having to manually adjust line screen angles - a giant pain in the ass if there ever was one) where there is a lot of support for Photoshop and the Mac, but not for GIMP or Linux.

Putting stuff on paper is hard. The GIMP might be good for web graphics, but it will not do the job if you need to deal with anyone else.

Maybe Linux *Shouldn't Be* for the Desktop.

[Lord Kano]

What I like about Linux is it's it's speed ,stability and flexibility. I don't care as much about ease of use. It's people like us who drove the linux revolution. Grandmothers and uncles didn't and WON'T. It's those people who will continue to use Windows and MacOS for everything.

It irks me that on mandrake's homepage all of their reviews center around how easy Mandrake is for the linux newcomer. I don't CARE about that. I want to know about stability, speed and new features.

I didn't mind a text menu based installer, I didn't need X to install. I'm sure that many of you feel the same way.

Linux developers should be more worred about SERVERS! When you get server quality stability and speed, then you can trickle down to the desktop market.

Look at M$, WinNT was for servers only. Now Win2K is using that base (with several thousand bugs added) to bring many of the features of NT to the desktop. THAT's what Debian, Redhat, Caldera, SuSE and Mandrake should be doing.

LK

Re:So true

[be-fan]

Are you kidding? GDI+ (the windows graphics interface) is a stinking piece of shit, and probably not much faster than X. Kernel graphics in general is not the best of ideas, but user spaces graphics can be just as fast. Take a look at beos. The graphics server is extremely responsive and the whole graphics system is really fast. Its entirly a function of design, though. The app has a direct connection through a very fast messaging system to the app server. (which handles graphics.) The app server implements most of the graphics driver; the kernel just implements a small part that deals with interupts and whatnot. Its a really beautiful desgin, because it incurs very little overhead, but is still very stable. I call an accelerated line draw, it sends a message to the app server, which uses the driver (in the form of a dynamic library) to acceleratadly draw the line. The app server, (or the user space driver for that matter) can't crash the system, so only bugs in the minscule kernel driver can cause problems.

So true

[Bryan Ischo]

I am a hardcore Linux guy but I think this is definitely true.

I am the only full-on Linux user where I work. We have had several new employees start who were enthusiastic about trying Linux; each time they tried it for a while and gave up on it, and I can't blame them. I gave them all the help I could but the Linux graphical "shells" (KDE, Gnome) are sooooo buggy it is ridiculous.

Seems to me that the people who make these graphical shells should focus on reducing the bugs rather than coming up with even more bells and whistles and eye candy. Also someone really needs to sit down and organize the released desktop; the default RedHat desktop install is so disorganized and impossible to find anything in, it's ridiculous. And did I mention that it's incredibly buggy?

I think that the very first thing that a Linux desktop needs to be able to do and able to do absolutely flawlessly is, download a RPM or similar package, install it with a few simple clicks, create a "shortcut" to run it on the desktop or in some program menu somewhere, and then run the program. This is what 90% of computer users do 90% of the time (with the running of software happening much more often than the installing, of course), and right now the graphical shells just plain SUCK at this.

I place the blame pretty much squarely with RedHat these days. They've got the money to make it right, but instead they are just going further and further off on a Linux fragmentation path. RedHat seems to think nothing of introducing more and more non-standard system configurations with each release. Surely they must realize that this will fragment Linux just as badly as Unix has traditionally have been fragmented, if not worse.

I love Linux but to be honest I don't see a very bright future for it unless those with the money and power to pull it all together start doing so.

Either way, I will stick with Linux, because even if its popularity faded and we ended up with just as many users as we had back in '94 when I started using Linux, I will still enjoy working on Linux and developing on Linux.

Of course, I'll probably still be using my ancient twm with my 8-year-old .twmrc, and doing everything from an xterm instead of Gnome or KDE or whatever. I would like to see Linux succeed in a desktop sense, simpy because as a software developer I'd rather work in an option, Unixish environment than a closed Windows environment. But since Linux is all open source it can never be taken away from me so I'm not too worried either ...

Voice of a Heretic

[banky]

Preface: I am typing this on my Frankenstein Intel-architecture Red Hat 6.1 machine, running the latest GNOME stuff. Its my main line machine: other than my laptop, a junky Toshiba running Corel Linux. All my servers run Debian or Red Hat.

I don't think Linux is ready for the desktop. In fact, I am going to buy a Mac to supplement my desktop needs.

Why? Well, first, I can't stomach buying a supplemental Windows machine. Second, the state of the Linux desktop art is lagging behind in areas that I need it, right now and today. Not things where I can donate my time (which I do), not things that I can contribute code to (which I want to), but things I need, right now, this minute, in order to get my work done and get paid.

The sad thing about this is my machine - this here Linux box - is the best computer I have had, both in terms of hardware and software, I think. I play Quake3, I do network administration, web design, programming, and I have a killer MP3 collection. I talk to my friends on ICQ - at least, when they aren't busy rebooting their Windows machines.

In other words, I get 98% of my work tasks done, and no one cares, no one complains, and they're quite happy with my performance and could care less about what my machine is running.

That other 2%, is when they send me a proposal in Word to review: and not a grocery list, but a huge document with lots of Word cruft. When I can't read it properly, I get yelled at. I have filed bug reports and Abiword, stressed Star Office to its wits end, and run Applix ragged. If I can't get 100% accuracy, I have to work that much harder (fiddling with VMWare, for instance). I have to be able to do EVERYHING that my co-workers do (except reboot/reinstall!) and if that means "straying from the flock" for a while, then I will have to do that.

Don't get my wrong: I love fiddling with VMWare as much as I love Quake3. I love hacking away happily on my machine, optimizing it as much as I can, I love Linux and support it every chance I get. Its the best thing to come along and I consider my self a good supporter of free software, open source, and Linux. Its a time of serious cognitive dissonance in my life.

So anyway, I need something for the simple things: Word/Excel (Lord how I hate it), scheduling, calendar, PIM, etc. I don't want it to require a single minute of fiddling, I don't want it to work at it. I want it to work for me. So I seriously see a little tranlucent blue potty in my future.

I still intend to support Linux, and strive to improve the things that are lacking. I would never have NT, not for all the tea in China. But I think there are certain facts of life that we ignore.

Note: No, no dual booting. I can't close down the 900 things on my desktop to look up a phone number. Why ruin good uptime, anyway?

Reasons Linux is not ready for the desktop

[be-fan]

I happen to agree with the CEO of this company that Linux is not ready for the desktop. It is a great system, and for a UNIX the infrastructure underneath it is quite solid, at least much better than windows, and it has good developers behind it. The main problems, however, are.
A) Linux does not have enough fit and finish, its not very polished. Say what you will about Windows, but it is very polished. The stuff underneath may suck, but the outside is nice and shiny. People like shiny things. Point about me: I'll generally use Redhat for examples because I feel that it strikes the best balance between ease of use and included features. Plus, most non techs think Redhat==Linux. (they don't even do the == thing to express equality, they say =) Redhat is generally pretty polished but there are quite a few problems. X still needs to be configured from Xconfigurator because the one in the installer is inept. Second, sound is left entirely to the user, one has to start up sndconfig and enter settings from there. Resolution changes all have to be done from the X config file, blah blah blah. These are all little things and don't have that much to do with the OS, but when a person first uses Linux, it makes a bad impression.
B) Linux has a weird sense of configuration in that it doesn't really have a good driver model. Most users I know are comfortable with the concept of a driver. They don't understand what it does but they know that to install a device, they have to put in the driver disc. DevFS is great, except in UNIX it doesn't define a driver model, just a communications model. In BeOS, a user can just copy a driver into the directory and the device magically starts working. Linux should be that simple. (ie. no requiring kernel patches to install ANY device.) All config files are stored in /etc, which is okay for people who know UNIX, but face it, its a good idea implemented very badly. What there should be is a straight list of configuration files terminal, sound, network, startup, shutdown, discs, etc. Yet you have a horrible mess with multiple directories and not all config files having the same format. Its fine to keep that, but Linuxconf needs to be expanded to the point where editing a text file is never necessary.
C) Software installation has to get a clue. People don't think of their installation as a set of files. They think of it as a directory. Thus there should be something analogous to a program files directory. RPM would ask you for the destination directory, and the app would install there. Tell me what you want about the flexibility of having /usr /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt and all that, but face it. Its a dumb idea implemented incorrectly. At least in windows program droppings (the files a program leaves on you system) is kept in scope to the \windows\system directory! In linux they install themselves all over the place. The ideal install structure would look like this. There is an apps folder, /apps. RPM installs everything into this folder, letting the user choose the name of the folder. Thus if the user wants to go into the folder for some reason, to make a shortcut or whatever, they know where it is. Adding and removing of programs would be done through RPM, so the frontend will be the same, and the back end will be more sane.
D) Linux lacks hardware support. Not only in the case of OpenGL, which is getting better, but in sound and video and input, etc. Even when a driver works, it doesn't take full advantage of the hardware on the system. A sound blaster live! is awesome under windows, but not anything special under Linux because it doesn't support EAX. There is a reason for that. Manufacturers don't like hacks. Sure Aureal is porting A3D to linux, but in what form? Some sort of obscure dll wrapped hack. Linux and other UNIXes desperatly need multimedia APIs and driver models. Just as important this driver model has to be similar to directX. Not for any love of directX, mind you, but because thats what most hardware today accelerates and we want writing drivers to a UNIX media API to be easy as possible.
WIndows users have gotten increadibly used to pampering. Windows is a much friendlier environment to use, even if the UI sucks. People understand it, and it has a lot of features to make life easier. Pervasive right click menus being one thing, context sensitive help, etc. No matter how good GNOME gets, thats not the whole of the system. The linux directory structure needs to be reworked and the concepts of administration need to be rethought. Now don't think you'll sacrifice flexibility in doing this. All this nice GUI config stuff can be done through text files, so if you like CLI, you can edit it directly. And somehow I doubt that you'll miss /usr/local/sbin (at least on the desktop.)

Ugly Linux

[gargle]

Linux is ugly. I'm not just talking about the prettiness of the GUI, but the general ugliness of the fonts and text.

I've already copied and installed the true type fonts from Windows (following the font deuglification faq), and now it's merely ugly - a step up from hideous I guess. But text still turns out uglier and more unreadable than in Windows, and it makes long term use a strain on the eyes. The system fonts used in KDE and Gnome also tend to be extremely ugly - they should note that good, readable text != fonts made out of thin straight lines.

Dumb

[uebernewby]

Frankly, the average joe is too dumb to use something like linux.

Let's turn this around: frankly, the average linux-programmer lacks the skill to make joe use linux.

It takes skill to be able to create an interface that people can use whose lives revolve around other things besides computers. Not everyone has that skill. There's a lot of talented linux programmers out there who are very good at creating a stable, flexible core-operating system. There's not a whole lot of skilled interface designers. My guess is that this is due to the fact that being a good interface-designer requires having to be exceptionally good at programming, graphic design and psychology, all at the same time. It's hardly surprising there's not a whole lot of these uebergeniuses around. The alternative is to get a group of people whose combined skills approach the ideal. For its time, I think the Apple Lisa/Mac team was such a group. And if you'll recall, large numbers of people recognized their skills and went out to buy Macs, even though they were then, as now, ridiculously expensive.

We can only hope that such a team will form in the linux community and come up with a new and usable interface paradigm suitable for today's computing power. Most likely, however, as soon as someone does manage to assemble a team like that, it will be bought up by some large corporation. The company that manages to achieve a truly new, workable interface will dominate the market for the next ten years, at least. Betcha Bill Gates would gladly offer half his assets to such a team.

The reason why this is so important is not because the average joe is "dumb", but because the average joe thinks it's a waste of time to fumble with config files and xservers. Only a very small group people actually enjoy this. Most mortals just want to get their work done, go home and look at porn on the Internet.