Ubuntu should move all binaries to /usr/bin/

[Dane Mutters]

I accidentally hit reply instead of reply-to-all.  My message is below the
quote.

On Tue, Dec 6, 2011 at 11:23 PM, Dane Mutters <dmutters at gmail.com> wrote:

>
> If you really care about end users and you think this is something that
>> need fixing, then the proper way to do it is to:
>>
>> 1. create a fake /usr/bin/ where all binaries are available without
>> breaking anything else. (this could be done by having a virtual filesystem
>> of some sort that automatically finds things for you, think autofs /etc/
>> auto.net
>>
>> . So if you say: which bash it shows as /bin/bash if it hasn't been used
>> from /usr/bin/bash. and which bash will be /bin/bash and /usr/bin/bash if
>> somebody or some command called /usr/bin/bash as it would "mount" this for
>> you there). This would mean that all packages that install things to
>> /usr/bin would need to be installed elsewhere... which is really bad
>> 2. write GUI tools that find binaries properly, think gnome-open but for
>> binaries. I guess similar to command-not-found in Ubuntu
>> 3. hide the whole filesystem from end-users GUI programs (MacOS X does
>> this beautifully, if you open a terminal you can cd / and it takes you to
>> some /private hidden directory)
>>
>> If it was me, I would do this actually:
>>
>> 1. hide all from users
>> 2. install all packages to /opt/app/version/{bin,share,
>> lib}
>> 3. symlink stuff from /opt/app/version/bin/* to /usr/bin/ if not already
>> there
>>
>> And write a really good update-alternatives to manage /usr/bin/* symlinks
>>
>
> I'm glad you mentioned this, Luis.  I know you weren't exactly advocating
> such changes, but I think the implications of this bear discussing.
>
> Another issue to mention, that I dearly hope has some positive hold in
> minds of the Ubuntu community, already, is the hell of actually editing
> configurations, hand-linking files, installing 3rd-party/manually-compiled
> apps, etc. when you have a system that makes you deal with a "shells game"
> of where things actually are.  I, personally, HATE that.  It's exactly why
> I decided (years ago) that, despite the usefulness of YAST, and the
> easiness of the GUI, I couldn't tolerate using Suse in the least.  Whenever
> I wanted to edit a configuration file by hand, I found that it was being
> created by several other files--that themselves were created by some binary
> GUI tool that I couldn't see into the guts of.
>
> Making a semi-knowledgeable "power user" of Linux/Unix (such as I consider
> myself to be) sort out a spaghetti of links and virtual filesystem junk
> just to figure out where some file is, or where it's safe to "make install"
> something into would be entirely unreasonable.  One of the things I like
> about most Linux distros is that you can look at the filesystem directly
> and tweak things to your liking, so long as you've read some basic
> documentation on what you intend to change.  Yes, Mac OS X does a great job
> of obscuring the filesystem hierarchy from typical users (which makes it
> easier for the really computer-illiterate ones), but it's a pain to
> actually get into the "guts" of.  Heaven forbid you have to use a command
> line to fix something...
>
> I've seen a bit of this obscuring mentality creep into modern Linux
> (including Ubuntu), in the form of auto-generated /etc/ stuff--which isn't
> necessarily a bad thing, except when you can't easily change what's getting
> generated (GRUB 2, anyone?  I don't want to learn another dialect of a
> scripting language to remove a single word from my boot-up screen...)--and
> I truly cringe at the thought of dealing with this on a system-wide scale,
> instead of just in a few spots in /etc/ and similar.
>
> Yes, by dumping everything into /usr/bin, you might make binaries easier
> to find for basically Linux-illiterate users who probably wouldn't know
> what to do with the binaries once they found them.  You would, however,
> make things very difficult for any sysadmin, power-user, or person trying
> to learn Linux's guts, as well as anybody else (who didn't design the
> system or spend days/weeks reading about it...) who might actually have a
> good reason to be mucking around in those areas (i.e. not be on his way to
> screwing it all up through ignorance or recklessness)--that is, if things
> are linked or otherwise obscured.  Dumping all binaries into one place
> poses its own problems, as are being discussed already; so I'll forbear
> repeating what's already been said.
>
> So, if the Ubuntu developers really do want to simplify the filesystem
> structure, please do it TRANSPARENTLY, so that those people who really want
> to see the insides of their installation can do so sensibly, without having
> to sort out where things ACTUALLY are, independent of where they LOOK like
> they are.  I honestly don't know whether putting everything into /usr/bin
> is a good idea (that's something for those more knowledgeable than myself
> to work out--though I'm inclined to be against it).  I just hope that
> whatever is decided upon won't make my life tougher by obscuring,
> autogenerating, and/or autoconfiguring such basic things as where files are
> located.
>
> Thanks for reading.
>
> --Dane
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20111206/bf386bc7/attachment.html>