I accidentally hit reply instead of reply-to-all.  My message is below the quote.<br><br><div class="gmail_quote">On Tue, Dec 6, 2011 at 11:23 PM, Dane Mutters <span dir="ltr"><<a href="mailto:dmutters@gmail.com">dmutters@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
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:<br>
<br>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/<a href="http://auto.net/" target="_blank">auto.net</a><div style="display:inline-block;width:16px;min-height:16px"> </div>.
 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<br>
2. write GUI tools that find binaries properly, think gnome-open but for
 binaries. I guess similar to command-not-found in Ubuntu<br>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)<br>
<br>If it was me, I would do this actually:<br><br>1. hide all from users<br>2. install all packages to /opt/app/version/{bin,share,<div>lib}<br>3. symlink stuff from /opt/app/version/bin/* to /usr/bin/ if not already there<br>


<br>And write a really good update-alternatives to manage /usr/bin/* symlinks</div></blockquote></div><div><br>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.<br>

<br>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.  <br>

<br>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...<br>

<br>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.<br>

<br>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.<br>

<br>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.<br>

<br>Thanks for reading.<span class="HOEnZb"><font color="#888888"><br><br>--Dane<br></font></span></div>
</blockquote></div><br>