Well, since people would rather hear constructive criticism. I’ve taken what I consider to be the major irritations with various Linux distributions and compiled what fixes I’d like to see for them.

Three points I’d like to address beforehand.

Firstly, I use “Linux”, not “GNU/Linux”. Firstly because I think saying “GNU/Linux” all the time sounds stupid. Secondly, as was pointed out on Slashdot, we don’t call something developed with Microsoft’s visual studio MS-###. I understand the people who made Linux possible by building GCC deserve credit and I accept that, but only to an extent.

Second, I think Linux as in the kernel is pretty much perfect. I’ve never had Linux (the kernel) crash or misbehave too badly in default configuration. I mean I’d love to see the resolution set back to 1000Hz as default, but that’s just a personal thing. The real problems are in applications, which are not as well organized or led as the kernel dev teams. Probably, I mean I can’t be sure of course but I know the kernel’s team is massive. I’d be surprised if anything but the most major projects approach that.

Thirdly, people often complain that something that doesn’t work on Linux should be returned as not fit for purpose. However would they make the same argument if the item in question doesn’t work on BSD, Solaris, Unix, Minix, ReactOS or SkyOS? In essence, it can only be the manufacturer’s problem up to a point. So if someone has a piece of hardware that doesn’t work on Linux, the proper response will never be “tough”. It’s the problem of the OS provider to make it work.

Also, one thing bears restating. Other people not into OSS have their own problems. What I mean is that there are plenty of causes to the benefit of all Humanity, OSS is just one of them. People working in those causes probably don’t have time for ours and most people have enough problems just doing their jobs. Here’s the kicker, it’s unreasonable to expect people to donate their time to your project. Giving money is different, there’s a long tradition of paying for a service but people are busy and expecting them to spend hours customizing their system, debugging or doing other things that should have been done before release is unreasonable.

In no particular order.

3D Issues

A great many distributions check for the graphics card and then run an OSS driver for it. That’s the obvious thing to do. The problem is that the nv drivers have an issue with various Nvidia cards, well the issue is they don’t work. This has been a problem for ages. Well there’s two solutions, one you can just use vesa for everything unless you know that card/driver combination is good. Otherwise you could use a script to check the dmesg output and if it finds the string of a known bad card it edits xorg.conf to use vesa before it fires up whatever graphical installer that distro uses.

On the subject of the GPL and video drivers; I’m personally surprised that nobody’s written a user-space driver plug-in. I would accept something like a 25% performance loss if people would stop complaining about binary drivers. It’s not as if the various manufacturing companies don’t have very good reasons for keeping the code and specifications closed. They all infringe on each other’s patents, however none of this can be proved without the various plans. Releasing anything is a big risk, not necessarily a certain one, since they could countersue for whatever the opponent infringes, but a possible problem nevertheless.

Of course one could always ask, why don’t you just use intel integrated graphics. Well because they’re not good enough for anything except desktop work. I’ll grant, the stuff that makes use of high powered graphics generally doesn’t work on Linux anyway, but if I have a 7600GT card, it’s generally because I intend to use a 7600GT.

One personal irritation is the difference between X.org and Window’s method of resolution change. X.org forgets the window positions while Windows doesn’t. Now that might seem like a small thing but I feel it’s fairly important, if you pull the resolution down and have something open in the background, it’ll stretch from one side of the screen to the other when you put the resolution back to its original level. It would be immeasurably helpful if X.org would remember where the windows were before it went full-screen with one application and reset them when it switches back. The effect of the current method is that it discourages using games on Linux, if you do there’s a chance that the desktop will be messed up when you quit.

Also, the compiz effects are nice and all. But the assumption that people switch OS based on eye candy is probably faulty. Not even the most computer illiterate users think like that. But that’s not what annoys me, what annoys me is the “overkill”. All I want is for windows not to tear when dragging and not to white out when dragging if the application goes unresponsive. Really, that’s it and I would love to see there be an easy option for it; even Ubuntu doesn’t allow that except on “Extreme” mode and everything else requires too much reconfiguring. I hate it when video performance shoots through the floor while using compiz; the same thing doesn’t happen on Vista. However, more to the point, if you use applications that require 3D power then you probably won’t activate compiz as long as it makes a big performance hit. Since it interferes with work. While I’m on the subject, the bouncing window effect sometimes bounces windows outside the desktop, some distributions stop this by decreasing the bounce but there really should be a check to prevent it from occurring.

General

Custom keyboard keys work on some distributions and not others. Not just custom keys but also custom laptop buttons. Now that Vaio’s come out with their Laptop/Desktop hybrid it’s especially irritating knowing that their cleverly engineered design won’t work as expected. I’d love to see a project that pools all the aliased commands for these buttons and put out a package for distributions to install. That will ease the work needing to be done for each distribution to be compatible and standardize the best work between distributions.

Speaking of things that work intermittently, the wine project’s been around for ages and still experiences difficulties with old software, new bugs and problems with practically every recent game. On the contrast the biggest argument against writing a good 3D driver for a VM is that it’s too complicated. The thought occurs that a couple of wine programmers could get together and work on it, insuring nearly 100% compatibility with software. Of course you’d still need a copy of Windows to make use of this, so it’s not a perfect suggestion. On the other hand, Windows XP licenses are going to drop in price as time goes on and I still prefer this solution to doing what is essentially reverse-engineering Windows. By the way, the Parallels people are something like 6 months overdue on their Linux version, no point in depending on them.

One thing that could stand some improvement is the “klik” installer format. Instead of working with program and dependency packages. The idea was for a format that would incorporate the application and its libraries, similarly to the way Windows games are packaged. One advantage to upgrading libraries is that you fix security issues for all your applications at once, so the current method does have some advantages. On the other hand, there’s a great deal to be said for simply dragging an application into your “Applications” folder, then clicking on it to run. I don’t believe that it’s anything world shattering compared to .deb and .rpm, however it’s definitely a concept that seemed cool when I heard about it and still does. The biggest problem with Klik at this point is that it doesn’t have enough applications packaged for it, or enough popular distributions that support it. It, essentially, needs a leg up. Of course that’s a pretty narrow focus, there’s also Zero-Install that works somewhat differently and a few others besides that.

I’d have to mention my main reason for suggesting something like this is the fact that one application will work perfectly on one distro, but due to an error in packaging fail utterly in another. In order to actually use a computer, they ALL have to work. A universal, self-contained package format would help iron out these inconsistencies. It would also make it considerably easier to package software for distributions, take the latest “app-run” file from the projects homepage and put it in the “install” folder on your disk. A script to pull the install folders onto the /app/ or whatever folder based on install options would then complete the process. The flaw with this idea is that the start menu would still need work, maybe a series of prefixes on the package names can set their point in the menu.

It’s one unfortunate fact that applications are still riddled with bugs. One fun one was that opening a pdf in the kde pdf reader produced a result where the rendered image would not match the page. No matter, what, the most irritating bug I have EVER encountered. This brings up the question of dtrace. Certainly one of the biggest improvements in Solaris 10. Dtrace allows you to set markers, either through tested scripts or by writing your own, inside the kernel without affecting its speed or stability. Then these markers write out a log as you run the applications, this lets you rapidly diagnose even obscure errors. Well, it’s not the be-all end all, it doesn’t help with everything but it’s very useful. So, what happened to the Linux version. Well, it’s being worked on.

Brilliant concept that bombed; dynamic re-linking of libraries based on the desktop in use. In theory it would change the skin of your app to match the desktop, in practice it dropped the speed by about 3 times and if you use gnome, the menus take several minutes to appear. The OpenOffice in OpenSUSE did something like this. Other thing that failed, the application selection menu takes 3 seconds to start up.

Usability

One thing that strikes me is the mount command doesn’t support enough formats. That doesn’t explain anything. There are many different image formats in use, depending on what one does, they would meet all of them. Someone uses Alcohol120% to image a self-booting presentation disc and e-mails you the result so you can check through it. It’s too irritating to have to convert mds to iso and try to mount it. Probably getting a corruption error as a result. A gnome and kde patch for right click mount with fuse would help immeasurably.

However, the biggest problem with usability is BUGS. I’ve mentioned this repeatedly but it’s important. All the applications a person needs need to work with their distribution of choice or the distro is unusable. There always seems to be one or two applications that for whatever reason don’t work at all on any chosen distro. There simply must be a way around this. If nothing else, it might help to designate some people to go through each major application and just make sure that all the menu options do what they’re supposed to. This might seem obvious but I’d swear that it gets ignored.

On the subject of stuff working. There should be a driver hack to get Windows printer and scanner drivers working on Linux. As I mentioned in point 4, it’s not the manufacturer’s problem if something doesn’t work in system x. Well, depending on its popularity it might be. However there are too many systems to write drivers for everything. Still, people need their stuff to work.

One thing I like about Office 2007. Yeah, it’s the one where if anything added up to 65535, it would print as 10,000. What unholy programming errors cause THAT bug I’ll never know. However, the Ribbon idea is a brilliant concept, I’ve used it and I love it. Rather than having massive menus where you have to hunt through them for your options; The ribbon idea has a row of tabs that reveal buttons with a graphic of what they do. If you hover your mouse over them, the text in your document changes to reflect what would happen if you click. It’s a more aesthetically pleasing way of editing text, but it also solves the problem of customers not being able to use the application to its fullest extent because the needed commands are hidden too deep. In essence, I’d like to see more applications take this theory of interface design.

Of course, I’d love to see more graphical interfaces overall. Command-line and text files are good for rapidly entering complex data. However I’ve begun to suspect that the real advantage is that you don’t need to bother with complex graphical interfaces. The downside however is that people need to know the manual. If you rapidly need to set something up one time or efficiently get several projects done quickly; graphical interfaces would be more efficient. I’d point to OSX-Server as being a good example of this. It can handle an impressive array of tasks, but more importantly, it can configure all of them from a central interface. The only Linux Distribution to match this so far is OpenSUSE. The flaw with that is that OpenSUSE has other irritating bugs that need to be dealt with, that and it’s interface is slow, really slow. I don’t know what they did but I could probably build a faster one in java. On the plus side, it runs in ncurses too. So you can graphically configure your server over an ssh command line, very impressive. It should be duplicated more often.

It’s not that I seek to discredit the ability and skills of experienced IT staff. I do believe that more efficiency is always better. Especially for me, who doesn’t do IT. Another analogy is that lowering the bar for entry means that experienced jumpers clear it farther.

Conclusion

There’s plenty of things we do well. There’s also plenty of things we could be doing better. I didn’t talk about desktop gadgets because I don’t care about them, but there are people who do. Likewise I didn’t mention wireless networking because I only seldom use it. Feel free to comment.