Debian Developers - [RFC] User Accesable Filesystem Hierarchy Standard

Author

[RFC] User Accesable Filesystem Hierarchy Standard

Gary L Greene Jr

2004-03-27, 5:35 pm

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a proposal for a standard to accommodate the accessibility of the=20
filesystem by end-users. We request discussion on this as a new standard. T=
he=20
URL to get to the document is:

http://www.csis.gvsu.edu/~abreschm/uafhs/

I am a member of the Ark Linux team, who is interested in seeing the Linux=
=20
desktop become a viable option. I apologize for the cross-posting.

=2D --=20
Gary L. Greene, Jr.
Sent from uriel.gvsu.edu
5:23pm up 4:38, 5 users, load average: 0.16, 0.16, 0.11
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=46ounder and president of the Grand Valley Linux Users Group
check out http://www.gvlug.org/ for more info.

PHONE : (616) 331-0849
EMAIL : greeneg@arklinux.org (my Ark Linux account)
EMAIL : greeneg@student.gvsu.edu (my student account)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZgFjrTQE7CqFxs8RAngWAJ4mxppz+w+a
0bR28qPtTJDPmz0KNQCfYmdM
bd9jwfGCKvg+KApS5h1BsoE=3D
=3DPsPI
=2D----END PGP SIGNATURE-----

Nicolas Mailhot

2004-03-27, 6:34 pm

Le sam, 27/03/2004 Ã_ 17:34 -0500, Gary L Greene Jr a Ã©crit :

> This is a proposal for a standard to accommodate the accessibility of the
> filesystem by end-users. We request discussion on this as a new standard.The
> URL to get to the document is:
>
> http://www.csis.gvsu.edu/~abreschm/uafhs/

From a usability POW hidden files (and directories) are very bad.
I must admit I'm a bit horrified by the number of new hidden roots
you're suggesting to create (not only you duplicate classic / topdirs
but you also enshrine stuff like fonts that doesnt exist on the system
root).

My proposal would be simple :
1. use a single or at most two-three top-level dirs in ~ (etc and the
rest)
2. at this point you can probably not hide them since they won't result
in too much clutter
3. do not try to keep current dotfiles/dotdirs in your spec but move
them to your clean file layout

As far as I know current $HOME clutter is what's keeping some people
from using it as their desktop (even though that the natural unix way).
Cleaning up the mess would certainly help there.

A good point is the way you follow / FHS layout instead of reinventing
yet another convention.

Anyway - I'm pleased to see someone working on this ! Most people seem
to have given up on ever cleaning up the home legacy dotfile mess.

Regards,

--
Nicolas Mailhot

Henning Makholm

2004-03-28, 12:34 am

Scripsit Nicolas Mailhot <Nicolas.Mailhot@laPoste.net>
> Le sam, 27/03/2004 Ã_ 17:34 -0500, Gary L Greene Jr a ecrit :

[color=darkred]
> From a usability POW hidden files (and directories) are very bad.
> I must admit I'm a bit horrified by the number of new hidden roots
> you're suggesting to create

I concur. Apart from the problem that there are many of them, it is a
significant technical problem that the way they are formed is not
compatible with the --prefix interface of legacy configure
scripts. Thus, even if there is a ~/.bin and a ~/.share, it is not
easy for a user to download a tarball and easily get something to
*install* in them. (Well, perhaps the problem is for the one who
packages some software for others to install in home dirs, but it is a
problem nevertheless).

Something like ~/$FOO/{etc,bin,lib,share,include} for some value of
$FOO, would have a better chance of taking flight.

> 2. at this point you can probably not hide them since they won't result
> in too much clutter

I'd tend to think that even one name that is not dotted is too much
clutter. There's a strong unix tradition that *any* name in ~ that
does not begin with a dot should belong to the user alone.

Perhaps FOO="..."?

> 3. do not try to keep current dotfiles/dotdirs in your spec but move
> them to your clean file layout

By the way, the draft's distinction between .etc and .config is
strange and un-FHS-like. In FHS, /etc is for the system administrator
to change; sets of defaults that are never meant to be changed by the
sysadm (resp. user) belong in [/usr]/share rather than /etc.

The /home/shared part of the proposal is at once too general and not
general enough. Most computers who have more than one user to share
data between tend to have *many* users, so one would quickly want a
way to share software between smaller sets of users (I may trust that
software installed by Tom and Jennifer is not intentionally trojaned,
but there is no way that I will put into my $PATH a directory where
Charles from accounting has write rights).

--
Henning Makholm "Kurt er den eneste jeg kender der er
*dum* nok til at gå i *ring* på et jernbanespor."

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Barth

2004-03-28, 3:33 am

* Nicolas Mailhot (Nicolas.Mailhot@laPoste.net) [040327 23:25]:
> From a usability POW hidden files (and directories) are very bad.

I disagree with you, if it's about directories normally not directly
used, but e.g. searched as a part of the path. I really prefer if I
don't normally see them with e.g. ls. (Well, I _have_ ~/.bin on my
systems for more than 5 years now.)

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Adrian 'Dagurashibanipal' von Bidder

2004-03-28, 6:34 am

Henning Makholm

2004-03-28, 8:35 pm

Scripsit Gary L Greene Jr <greeneg@student.gvsu.edu>

> URL to get to the document is:

> http://www.csis.gvsu.edu/~abreschm/uafhs/

Another problem is that any standard that just says ~/.bin or
something like that (~/$FOO/bin) will be inherently broken on sites
where NFS-mounted home directories are shared between machines of
different architectures. That may not be a problem for living-room
home machines (yet!), but as soon as one looks at at-work setups, it
is possibility that needs to be considered.

In order for a standard to be robust enough to deserve widespread
adoptance it needs a more complex system, perhaps something like

~/.debian/i386/bin
~/.debian/i386/lib
~/.debian/alpha/bin
~/.debian/alpha/lib
~/.debian/share
~/.solaris/sparc/bin
~/.solaris/sparc/lib
~/.solaris/share
...

in a fairly diverse hypothetical environment.

One needs different .../share for each vendor, because FHS /usr/share
is only sharable between different architectures of the *same*
OS. (This is not widely known; I only learned it when I tried having
my own equivalent ot /usr/share/terminfo on a NFS $HOME, and watched
it malfunction once I logged into one of the HP-UX boxen we ran then).

Still, one probably wants ~/.debian/share/texmf and
~/.solaris/share/texmf to symlinked to each other, nevertheless...

--
Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at
følge den vej kun bliver gennemsnitligt ca. 48 år gammel,
og at man sætter sin sociale situation ganske overstyr og, så
vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed."

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-03-28, 8:35 pm

Scripsit Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch>
> On Sunday 28 March 2004 06.17, Henning Makholm wrote:

[color=darkred]
> There could be group home direcories, aligned along unix groups. Anything
> else, I guess, is pretty much unsolvable, users would just have to massage
> their $PATH manually, I guess with a proper configuration tool this should
> not be a problem even for novice users.

One might reasonably hope that OSes and software authors could agree
on providing a standard way for users to set up themselves as users of
such tertiary roots.

When I was at the university of Copenhagen, I maintaned a "local root"
tree for our research group. It turned out that there are many more
environment variables than just PATH to deal with. We needed to set
MANPATH, INFOPATH, LD_LIBRARY_PATH, C_INCLUDE_PATH, XFILESEARCHPATH,
EMACSLOADPATH, ... for each user.

Perhaps the best forward-looking solution would be to invent a new
catch-all variable, say $ROOTS, and encourage every other package that
interprets a ${FOOPATH} variable to support a common syntax meaning,
"try $X/share/foo for every X in $ROOTS".

--
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Alexander Larsson

2004-03-29, 3:34 am

On Sat, 2004-03-27 at 23:34, Gary L Greene Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> This is a proposal for a standard to accommodate the accessibility of the
> filesystem by end-users. We request discussion on this as a new standard. The
> URL to get to the document is:
>
> http://www.csis.gvsu.edu/~abreschm/uafhs/
>
> I am a member of the Ark Linux team, who is interested in seeing the Linux
> desktop become a viable option. I apologize for the cross-posting.

Seems similar to:
http://freedesktop.org/Standards/basedir-spec

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@redhat.com alla@lysator.liu.se
He's a suicidal guerilla paramedic trapped in a world he never made. She's a
provocative nymphomaniac archaeologist with an evil twin sister. They fight
crime!

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tollef Fog Heen

2004-03-29, 7:38 am

* Gary L Greene Jr

| This is a proposal for a standard to accommodate the accessibility of the
| filesystem by end-users. We request discussion on this as a new standard. The
| URL to get to the document is:
|
| http://www.csis.gvsu.edu/~abreschm/uafhs/

Home directories are often shared across distributions, architectures
and operating systems. (Personally, at one site, I have my home
directory across nine architectures, ten operating systems and three
linux distributions, without even starting to look at version
numbers.)

This means that bin, lib and include have to be at least per arch-OS,
maybe also with a distribution component in the path. This also
removes the need for the ugly lib64, so you can use ~/.system/$(gcc
-dumpmachine)/{lib,include}.

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Zackary Deems

2004-03-29, 11:35 am

The private install portion does.. the rest of it is sane. I'm still of
the opinion that installing anything to ~/ is a bad idea: /home
typically is not created with enough space to support application
installs, for one; two, the average desktop user is not going to know
enough to watch the available space, potentially creating a DoS for
himself and everyone else on that machine when /home fills up (this is
not quite as much of an issue for distributions which use flat partition
structures). Administering a machine with software installed in ~/
would also be far more difficult and would require much larger changes
to the package managers currently in use.. or it would require keeping
multiple package databases.. which would be even uglier for administration.

Also, this sort of functionality should be an add-on package which can
be removed, rather than a completely new install type.. so the cleanup
must be simple in the event the box administrator decides to stop
supporting this.

Just my thoughts so far

Zackary D. Deems
Ark Linux

Alexander Larsson wrote:

>On Sat, 2004-03-27 at 23:34, Gary L Greene Jr wrote:
>
>
>
>Seems similar to:
>http://freedesktop.org/Standards/basedir-spec
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson Red Hat, Inc
> alexl@redhat.com alla@lysator.liu.se
>He's a suicidal guerilla paramedic trapped in a world he never made. She's a
>provocative nymphomaniac archaeologist with an evil twin sister. They fight
>crime!
>
>
>
>
>

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Adrian 'Dagurashibanipal' von Bidder

2004-03-29, 2:35 pm

Zackary Deems

2004-03-29, 4:35 pm

Adrian 'Dagurashibanipal' von Bidder wrote:

> Then the admin is to blame. Set up disk quotas.

And disk quotas would prevent a user from installing something like OO.o
or most linux games.. or their own implementation of KDE.. defeating the
purpose of this RFC.

>Isn't the whole idea that the admin has got nothing to do with all that. It's
>the users' home directories, and the idea is exactly that users can install
>software without bothering the admin.
>
>So the only thing the admin will have to care about is changing libraries the
>software installed in ~/... uses. But this is already the case, sophisticated
>users already have local stuff installed.
>

The idea (as I understand it) is not so much to circumvent the Admin, as
it is to make life easier for the vanilla user. Making life easier for
the user doesn't necessarily have to be done in a way that makes
monitoring software installs difficult for the admin. A centralized
'userland root' as suggested in this RFC would accomplish the goal that
the freedesktop guys have, without scattering installs all over the
filesystem, and requiring multiple or heavily modified package db's. It
also reduces the likelihood of the exact same package being installed 10
times because 10 different users didn't know the other 9 had it
installed. Obviously you could have the package manager refuse to
install the second copy because one was already installed, but since
it's installed in that user's home directory, it's completely
inaccessible to the 2nd user.. so now you either get a user who can't
install the program he wanted, or you get a new copy of the same thing
on the system. OR you blindly allow each user to install whatever
he/she wants, and just accept that multiple copies/versions will be
installed. (which, as a solution, is simply too ugly to live, imho)

Maybe the better approach would be to install the package to the central
'userland root', update the installing user's menus accordingly, then
add the package to a list of programs other users can add to their menus
if they so choose. That way they have a choice.

The idea of 'private installs' would probably work better as a
distribution add-on instead of being part of a much more broad based RFC
like this. As an example.. maybe your distribution decides to give the
user the ability to install the program into 'userland root' and NOT put
it on the list for other people to add to their menus. (For most
inexperienced desktop users (redundant?) that would be as good as not
having it installed.)

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jamethiel Knorth

2004-04-03, 12:34 pm

After the previous suggestions on this topic, I have revised the proposed
standard somewhat. It is still posted in a variety of formats at:

http://www.csis.gvsu.edu/~abreschm/uafhs/

I added the suggestion of using .<distribution>/<architecture>/ for a
directory structure, rather than my first change to simply putting it into a
hidden umbrella directory of a standard name. However, I still have several
questions regarding this which I could not find an immediate answer to:

Should there be a standard naming scheme for architectures, or should that
be left completely to the devices of the distribution? I'm tending towards
leaving it to the distribution, but would like some comments.

What about architecture independent systems, like Java? Should each distro
include a 'java' architecture, or something of that sort? There is no
particular reason for such files to be in every architecture's folder when
they work fairly widely.

I also liked the idea of having group directories similar to the shared
directory. In a larger work environment, such directories could solve many
difficult problems. The standard doesn't say much about them, however,
besides that they can be named arbitrarily and should have an internal
structure identical to /home/shared/ and should be located somewhere in
/home/. I don't see what else is needed to be defined on that topic, but
would like any suggestions.

I see no reason to unhide the program folders. They are still perfectly
accessible when they need to be accessed, but they can at least be kept out
of sight. This is even more important when using a naming scheme based on
the distribution which could result in very many folders.

Due to the fact that I merely added to and edited the old document, rather
than going through and actually rewriting it, or at least checking it, the
wording is clunky on several occasions. I'm not too concerned, as this is
still a draft, and will work more on clarity when the ideas to be conveyed
are better decided.

As always, thank you for your commentary and criticism.

Micah Abresch
jamethknorth@hotmail.com

P.S. In case anyone was wondering why this was sent to the lists it was:
those are the groups which have easily accessible public lists and to which
this proposed standard seemed relevant.

P.P.S. Many people have contributed ideas in discussions but aren't added to
the contributors section. Luckily, everything is in a public archive so I
can go back and see who suggested what, but it would be easier if anyone who
wanted to be credited would just e-mail me about it.

________________________________________
_________________________
Persistent heartburn? Check out Digestive Health & Wellness for information
and advice. http://gerd.msn.com/default.asp

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org