Slashdot Mirror

LinuxFund.org has been kind enough to supply two of my projects (GNUpdate and Gaim for Qtopia) with funding and hardware. It may not directly relate to your question, since it sounds like you already have someone that may be giving you the money, but you can look at their policies and requirements, and request more information.

People are more than welcome to test it! Just keep in mind that it is not ready for daily use quite yet. It's almost there, but not quite. Feel free to join the listservs if you want to keep up on development, ask questions, or contribute to anything.

Talking of usability testing, do you have any data to back this up? It's true the KDE Control Centre is bizarrely designed, but in fact it's being restructured for KDE3.1

KDE lacks any functionality close to an iDisk, and you cannot configure things such as webserving with the click of a button like you can in OS X.

Incorrect. There is no centralised free disk service like the iDisk, but on the other hand remember you effectively pay for the "free" mac.com services when you buy a Mac. If you want, you can pay me and I'll give you some FTP space. You'll then find you can browse your "mikeDisk" direct from Konqueror like a normal filing system, and also all your apps will be able to load and save to it directly - you need never know it's on a remote disk. What, you want even more power? Then try InterMezzo, which is a caching, conflict resolving offlineable remote drive system. Not only do you get network transparecy, but also you can disconnect at any point and continue working.

Oh, I almost forgot, there is a KDE panel applet that includes a small webserver, that can be switched on or off with a mouseclick. I think it's included with KDE3 or if not then with 3.1

The excedingly simple directory structure of OS X is completely lacking in all Linux distros.

Switch to root and try again. The whole UNIX directory structure is there, the finder simply hides it. Fine - I can make a version of Konqueror that hides it all as well, would that make it easier to use? Perhaps. I don't know to be honest. It might be something to look into.

You're right in terms of software management, but it's being worked on. Font management is also improving.

What matters is the process - OS X is simply a way of locking you into proprietary Apple hardware and kit. All platforms have their strengths and weaknesses, and the weaknesses you mentioned in Linux are being resolved fast. I could name a lot of weaknesses in OS X too, which I believe Apple are on the verge of solving. So what? What matters is - are you the one in control 5 years from now?

I'm not entirely sure how you manage to find Linux software management easier than drag'n'drop or run-the-installer, in fact, a Mac friend of mine who recently tried Linux (OS X performance was killing his old iMac) found the software management was THE thing that switched him off. The whole: X needs Y needs Z needs X mess, the fact that he couldn't even upgrade Mozilla (mandrakes urpmi wouldn't let him uninstall the older one cos gnome needed it) really was offputting. And I share his sentiments.

Now, I've said elsewhere in this story how I think the large amount of code reuse on Linux is a good thing, and it is. But software management is one of the biggest things stopped me recommending it to my non-technical friends. Perhaps GNUpdate will help solve this dilemma?

Perhaps one implementation that might work well on Linux would integrate a folder with a package manager, such as GNUpdate, so you could drag a package into a folder, which would then be installed in the background. Drag a package out, and it'd be uninstalled. You get the benefits of the distributed FHS system currently used with the end user ease-of-use that AppFolders provides

• Standardise on XML for configuration files. No, it's not perfect for everything, but it's well known, easily manipulatable with many different tools and is an open standard. It's good enough, and the benefits of standardisation here (in terms of ease of manipulation) outweigh the disadvantages I think.
• Make a GNU Configuration Library that simply exports some DOM interfaces for documents that can be retrieved via URIs. So - an app passes a URI to the config library along with some other information (like is this system or user config data) and gets back an XML document. The idea is that each application can be identified by a URI (or perhaps guid if you're feeling windowsish), and that they don't worry about how their configuration data is stored, only that it is.

  In the background what happens here is the config library is an abstraction layer over a datastore - of any kind. The default would probably adopt the dotfile standard that is defacto at present for personal data, and /etc, /usr/etc for system configuration. However, other plugins could implement an XML:DB backend, or store the data in a binary database, or do anything you like with it. The apps don't care.

• Fantastic, so now we've got most programs reading and writing to a standardised configuration format, and that data will be managed by the system according to user/distro preferences. Storing stuff in personal dotfile(s)/dotfolders would be easiest and most common I'd imagine, after all this system is pretty easy to understand and work with for the user. Next up is how the sort of user who doesn't want to edit text files all day alters the system configuration.

  Everyone will have different preferences for this too, and as Linux is as much about choice as anything else, this must be accomodated. Webmin is great for remote administration, but when I'm sitting in front of my box I'd rather use the KDE Control Centre. Other people would rather have their settings altered in each application. How do you manage this?

  Well firstly, it seems pretty obvious that most of the time it's going to be easier to edit application configuration from within that app. Sometimes that won't be possible, for instance with server apps, but for desktop GUI apps like word processors it'd be easier to select the Configure menu option. In KDE/Gnome etc. apps already use standardised config dialogs, so it's pretty easy for the user. For servers, Control Center plugins (or whatever your favourite equivalent is) would seem the obvious way to go. This doesn't necessarily mean coding up a new control module each time: Broadway would let you embed a KDE/Gnome control center module into Webmin easily.

• So now we've got configuration sorted, or at least a lot better than it was. Next up is software installation. This is a hell of a lot better than it used to be, but one popular misconception in the *nix community seems to be that non-technical end users are willing to compile apps. People who say "but it only takes 3 commands!" are glossing over the problem - often you need developer packages and reams of source code and header files for a program to compile. It can take a long time for even simple programs, and if there's an error during compilation/linking then non-programmers are screwed.

  That's why we have binary packages. Unfortunately there are two competing package systems, and this isn't a great system. Don't get me wrong, I'm all for competition, but sometimes competition is good, and sometimes it's harmful. This is one area where it's harmful, and it means I can't always get programs working on my distro simply because nobody has packaged it for me. But - nobody can seem to decide between Debian and Red Hat package managers! LSB says RedHat, Debian people say Debian, and in the meantime end users are caught in the middle. What's needed is a technically advanced solution that is distribution neutral - like for instance, GNUpdate If I was designing the LSB, this is what I'd use. It's not finished yet, but when it is it will give us backwards compatability with a distro-independant packaging solution. For those who can and want to build from the source, it will even be able to pull programs direct from CVS!

So there you go. Simple things, not a giant leap coding wise, but simply agreeing on some things with a smart architecture would go a long way towards propelling Linux into the kind of ease-of-use that only MacOS and perhaps Windows enjoys.

thanks -mike

I think that this project might be the solution to the above-mentionned 'shared libraries hell' problem. http://www.gnupdate.org/