Directory structures in the future and other things I want.

Casey Dahlin cjdahlin at ncsu.edu
Fri Mar 28 07:11:35 UTC 2008


Stephen John Smoogen wrote:
> 2008/3/27 Martin Sourada <martin.sourada at gmail.com>:
>   
>>  On Thu, 2008-03-27 at 15:57 -0600, Stephen John Smoogen wrote:
>>  > I dont know if this is a thread hijack, but I felt this was a better
>>  > name than the previous threads subject. If it is.. my apologies..
>>  >
>>  > My main 2 things I would like:
>>  >
>>  > 1) If we were to say get rid of /usr/bin, /bin, or /sbin etc.. Heck I
>>  > wouldn't mind if it wasn't named something people could understand
>>  > like: /SystemPrograms/ . I justwould like to see it come from a joint
>>  > Linux taskforce so that it's not just yet another OS weirdness. I say
>>  > this because I am currently having to rewrite my .profile to deal with
>>  > our growing HP-UX, AIX, SuSE, Red Hat, Solaris, and CygWin
>>  > environment. Everyone but Linux seems to stick things in weird spots
>>  > or you are expected to know that you can't use /opt/bin/blah all the
>>  > time because its a symlink and it breaks on this blah blah blah.
>>  >
>>  Hm.. I'd keep the standard unix structure... I think it's quite well
>>  thought through and proved working... /SystemPrograms/ would suck a lot,
>>  first it uses capital letters, second it's too long and third it is less
>>  understandable than /bin (or /sbin or /usr/lib or /usr/share is supposed
>>  to be it?)...
>>     
>
> It was meant to be a ludicrous example..  My main aim is that if it
> were to be all reorganized to be simpler and more understandable by
> 'humans' versus geeks-with-too-much-Unix that such decisions are done
> outside of one small cabal unless thats their SIG/SpecialGroup etc..
> but more done by something where other distros have a say in it.
>
> [But on the other hand.. is /system/programs, /system/documents,
> /system/configurations (or some shorter version config) more
> understandable to a human new to computers or is /usr/etc ]
>
>   
>>  > 2) One thing that Jesse and Seth brought up was the one major RPM
>>  > breakage that comes up every other release about why we can't do
>>  > something really cool. And that is the problem with symlinks and I
>>  > think directories. I would rather us do something really really
>>  > radical like going to a package system that deals with that than
>>  > moving items from /sbin, /usr/sbin/, /usr/myosrocks/sbin etc.
>>  >
>>  +1, but rather than going to another packaging system, it would be
>>  better to fix the current one...
>>
>>
>>  > 3) I think I will +1 Bills very clear fix: Just add /sbin:/usr/sbin to
>>  > everyone's path. Deal with 1 and 2 after 9 is out the door, and
>>  > probably shoot for it to be 11 earliest (or if we never go to 10 or
>>  > 11.. whatever the next series is called :)).
>>  >
>>  -10. In /sbin and /usr/sbin aren't binaries supposed to be run by
>>  average user and some of them even does not work with insufficient
>>  privileges. If you insist on using them you should be proficient enough
>>  to be able to add it to your path yourself.
>>
>>     
>
> I guess this the real issue. What is a normal user these days? Why can
> a user get the equivalent of lsusb/lspci via Gnome/KDE but not
> normally as a user. Should those have been put in some 'protected'
> area so that their .desktop and executables are only available if you
> are root.
>
>   

The approach you're using to the filesystem is wrong. We don't need to 
make it more accessible. We need to do the opposite. The user that can't 
handle unix file paths doesn't need to have the system changed to 
accomodate him. He needs to be kept inside his home folder where he 
can't break anything.

It seems strange that the majority of the folder structure is the OS's 
business alone, but raw space is still very much in the user's domain.

--CJD




More information about the fedora-devel-list mailing list