A modest VFS proposal (was: Re: Win vs. UNIX usability )



>> > I think it would be nice if there was a standard that packages
>in
>> > Linux by default went in a particular directory, eg
>> > /opt/<name-of-package>
	
>No, beleive me - it's bad. Things are going from a tradition:
>Standalone packages, stable, coming from .rpm, distributions goes
>into
>/usr/lib, /usr/bin etc.
>Manually build packages goes to /usr/local/bin, /usr/local/lib etc.
>And /opt/ is used for BIG multipackaged programs, f.e. /opt/gnome,
>/opt/kde
>I like this.

Hi. I'm Phil, and I'm a debian user.

("Hi Phil!")

Seriously, folks, I sort-of like the debian setup, where 
everything that's set up by a package maintainer goes in
/usr/lib or /usr/bin (or /usr/X11/bin if it goes there, or
/bin, /lib, or /sbin as appropriate for non-applications,
ie. real utilities, etc).

I use /usr/local for locally compiled stuff, or for commercial
applications, or things I want to install without contaminating
the main /usr/bin directories (I guess the way y'all are talking
about using /opt, but more on that in a second).

It's a lot easier than dealing with slackware. Slackware
is really fun for real he-man programmers without the distraction
of real full-time jobs, but I digress. The _system_ I have is
much _tidier_ than the slackware setup I was using.

Anyway, I have gnome stuff scattered through my /usr/bin
directories, but it doesn't bother me, really, because the
package management tools are sophisticated to keep everything
sorted out. The only thing that _bugs_ me is that gnome has
no apparent (AFAIK, I may be wrong) way of keeping track of
whatever icons you already have on your system, which for me
are scattered through directories for afterstep and tkdesk
and whatnot. I usually judiciously use a cp `find...` command
to copy everything to /usr/share/pixmaps, where gnome expects
them. I probably should make and refine a script to handle
different icons with identical filenames, but I guess I
haven't had time, or maybe I'm too lazy. That's one thing I
wish I could make better; another is that the icon selection
when you're making a launcher seems to take a lot of time.

Another point I'd like to bring up is that I have a mac at work.
There are little things the mac does right that no other OS seems
to do right (as well as things it does wrong - like cooperative
multitasking - that noone else does wrong); a lot of this
seems to have much to do with the structure of applications on
the OS. While it's as much (or more) of a bug than a feature,
mac applications seem to be much more monolithic than PC/Windows
or Linux applications, in that they seem to reside in a much
smaller number of files, and/or _not_ use shared libraries to
any great degree. While this may not be _better_, it looks
_tidier_, and is probably easier for a rank beginner to keep
track of. I've also never seen anything as good as the extension
manager setup; files become available for activation as extensions
simply by being in the right directory.

Again, I don't know if it's better, but it's simpler.

For the purposes of unix, this probably can't be duplicated,
although the SysV init style with separate files comes a lot
closer than earlier approaches I had seen in Linux. It's
also a lot better than the windows control panels, IMHO.
(Although it seems to do half the stuff the registery does,
and half the stuff the control panels do; it's not a perfect
analogue for either one; I know this is a gross oversimplification).

Getting on to my point: might further advances in the _filesystem_
make things easier? At one point, the linux package userfs would
let you mount or unmount a compressed tar file as a single file.
I understand gnome is meant to have this capability thanks to its
virtual file system associated with Midnight Commander.

Could this be part of the answer for allowing single files
to act as applications, if a tarfile can have both executables,
libraries, and miscellaneous files? Could all three of these
categories then by symlinked back into wherever they should be
in the path setup?

Comments, anyone?

Phil Fraering
pgf@globalreach.net





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]