[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: A radical idea
From:       Seth Nickell <snickell () stanford ! edu>
Date:       2001-11-13 1:54:50
[Download RAW message or body]

> Sorry, but your idea is really not a good idea.
> Yes, the unix directory structure  makes sense.  The unix directory 
> strutcture is one of the best things from unix. You should remember linux is 
> made for many users and networking. If you think in a computer made just for 
> one user who doesn't use internet or similar services, then maybe you are 
> right.

I can devise many multi-user suitable directory structures that are not
so bloody archane. The view that the unix directory structure is perfect
and/or excellent is in my opinion indicative of too great a familiarity
with it ;-) First of all the naming conventions leave much to be
desired. A simple renaming of directories *with no substantial change in
structure* would be a big improvement. Off the top of my head, here's on
possible renaming of /usr (this is completely not thought through,
obviously there are better names)

doc     ->    Documentation
bin     ->    Programs
games   ->    Games (wow! a sensible name!)
info    ->    (eliminate? my /usr/info has like 3 items in it)
local   ->    <no good ideas...."custom" maybe?>
sbin    ->    Administration Tools
src     ->    Source Code
etc     ->    Settings
include ->    Development Headers
lib     ->    Libraries
man     ->    Program Manuals (better put in Documentation)
share   ->    Program Resources
var     ->    Storage (not a good name really)

This is just a literal renaming. With minor restructuring all the
advantages of the multi-user system could be preserved with far far
better naming from a user perspective. For reasons besides "graphical
clients" systems such as HURD have proposed removing /usr and
/usr/X11R6, semi-arbitrary sub-directories. One system with radical
renaming could be:

/Applications  <- (GUI apps *with icons, and descriptive names*)
/Applications/Games
/Applications/Internet
/Applications/Office
/Applications/...etc...
/Development/
/Development/Headers
/Development/Source Code
/Development/Tools
/Devices <- "mnt"
/Documentation <- (Documentation for GUI apps)
/Documentation/Manuals
/Home <- (a lot of other possible names, but Home is fine)
/Storage
/Storage/Music <- (an example, a music archive for all users)
/Storage/System
/Storage/System/Cache
/Storage/System/Incoming Mail
/Storage/System/...etc...
/Storage/Web Pages
/Storage/...etc...
/System
/System/Documentation
/System/Documentation/Manuals
/System/Kernel/ <- "boot"
/System/Kernel/Information <- "proc"
/System/Libraries <- "lib"
/System/Programs <- "bin"
/System/Programs/Admin Tools <- "sbin"
/System/Program Resources <- "share"
/System/Settings <- "etc"
/System/Settings/Web Server
/System/Settings/KDE
/System/Settings/GNOME
/System/Settings/Networking
/System/Settings/...etc...

So a user browsing the root node would see:

Applications    Development   Devices    Documentation   
Home            Storage       System

Still not perfect, but a *LOT* better than the existing state. And it
works just as well for multi-user purposes: same seperation of data, and
the same ability to mount different things in from different devices at
different times. For example, there's no reason "/boot" has to be at the
root heirarchy, its silly because its hardly ever used. Putting it in a
system directory actually makes more sense, even from a non-usability
perspective.

> The unix directory structrure is a must.

No its not. Look at MacOS/X for an example of a multi-user system that
has done something like this.

> What I  think should be done is: programs should be smarters and programs 
> should use this unix directory structure wisely. 

I can't find any content in that statement. What should they do smarter
that would help the problem of having a complex (and more problematic
*archane* directory structure?

-Seth

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]