Stephen John Smoogen wrote:
2008/3/27 Martin Sourada <martin.sourada@xxxxxxxxx>:
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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
