Linked by Adam S on Wed 30th Apr 2003 07:26 UTC
Linux Lately, we've all read a lot of articles about desktop Linux - so many that it's getting hard to tell them apart. One says "Why Linux Sucks," the next "My Success With Linux." Even Michael Robertson of Lindows.com joined the fun with his "Why Desktop Linux Sucks, Today." But very few people have proposed anything radical, and I believe that's what's needed to take GNU/Linux to the next level.
Permalink for comment
To read all comments associated with this story, please click here.
Including all known libraries? NO!
by Jason on Tue 29th Apr 2003 19:04 UTC

I think that including all known libraries is a stupid and counterproductive way of going about things. Look at Windows DL-HELL for an example.

I think there should be 3 levels of libraries in a system:

1 - System - A subset of libraries that only the OS Distributor should be able to modify (unless specifically allowed by the system administrator). This would be things like the KDE or GNOME Libraries, GCC, etc.

2 - Application - A subset of libraries that applications can change if they are explicitly given permission to by the user. For example, I want to install the latest version of Someemailapp 2, which requires LibBC92-3 to work properly. The software package will ask me if A.) I want to download and install that package myself, B.) If I want it to download and install the latest version from it's last known good location, which is set by the programmers, or C.) If I want to install the software using the embedded (or optionally downloaded) version of the library. I picture a system in which we could choose do download from each software website which package we want, Minimal, Standard, and Kitchen Sink, which would determine which libraries are included, with all libraries typically used included with the standard package.

This would be the most common library style. See number 3 for added idea.

3 - One-time - Say I want to run a program that I will use to generate a result and then I would uninstall it. There's no reason for me to spend a ton of time hunting down libraries for a one-time use application. Thus, when I install the software, I can specify whether or not I want to delete libraryx after I'm done running the program. The library would be kept in a binary archive which I would use to reinstall that library when it's needed, only if it's needed. This would keep my /system/libraries dir clean, and prevent conflicts.

The one flaw in my plan is conflicts of libraries. There are three ways of handling libraries. One dir (/system/libraries), the libraries being in the program dir (/programs/program/libraries) or a dir based on which level the library is (for level 1, it would be in /system/os/libraries, for 2, /system/shared/libraries, and for 3, /programs/program/libraries)

I dunno, this is off the top of my head, but I think it would be a much better way than bundling a ton of libraries with the os that would be out of date in 3 weeks.