Ubuntu should move all binaries to /usr/bin/

[Matt Alexander]

Sure, using find or which, etc., can be used to locate a particular app,
but that's not really the point.  Why not simplify things and put all
binaries under /usr/bin?  Then you don't have to teach users about silly
distinctions like "Oh, see, if it's an app that's meant to be used by a
System Adminstrator, then it goes into /usr/sbin".  Who cares?  Just put
everything in /usr/bin to keep things simple.


On Mon, Dec 5, 2011 at 4:24 AM, Dane Mutters <dmutters at gmail.com> wrote:

> I don't know if the original poster has since learned this, but I think
> it's worth noting several things, in case the person coming over from
> Windows hasn't figured it out.  (If this is a non-issue, please disregard
> this email.)
>
> 1) Linux/Unix executables don't have a .exe extension.  Typically, they
> don't have any extension at all, and can conceivably have every extension
> imaginable (including common ones like .sh for scripts).  If you're looking
> for an executable, forget looking for its extension.  Try using the "find"
> command to look for executable files, or if you know the one you want,
> already, use the "which" command, as above.
>
> 2) You almost certainly don't need to find that file.  As mentioned above,
> if it's not in your PATH setting, then something is broken.  This is pretty
> rare.  If you need to execute a command--from a terminal or from an "open
> with" dialogue, just type the command (in the appropriate dialogue box, as
> needed).  If you want to open a PDF, and the GUI hasn't figured out how to
> do that, type "acroread", "evince", or whatever you have installed into the
> box.
>
> 3) <rant> +1 about Windows having an absurdly hard-to-use filesystem,
> where finding binaries/executables is concerned.  Once you learn Linux,
> you'll bless its build-in filesystem, and probably find little/no need to
> mess with it.  For that matter, +1 to all the stuff about /bin, /sbin,
> /usr/local/bin, /usr/local/sbin, /opt, etc. having useful, specific
> purposes.  Sure, it bugs me when some program insists on installing
> someplace I don't think makes sense.  Usually it'll let me change it upon
> install, if it's from a script, but if not, I can still put it into the
> PATH if it's not already there, and after that it doesn't matter!  So long
> as the uninstall functionality works for a given program (which it REALLY,
> REALLY should...), and the executable structure of the program is remotely
> sensible (looking at you, OpenOffice, Mozilla, etc.), it's all gravy, so
> far as I'm concerned.  Proprietary programs are the more problematic
> culprits, anyway, and there's not much a distribution can do about them, so
> far as I'm aware.  </rant>
>
> 4) I've never liked Fedora, anyway.  :-p
>
>
> I'm sure the real gurus here know a lot more about the specifics than I
> do, so have at it!
>
> --Dane
>
>
> On Mon, Nov 7, 2011 at 3:16 AM, Colin Watson <cjwatson at ubuntu.com> wrote:
>
>> On Sat, Nov 05, 2011 at 02:40:31AM +0800, John McCabe-Dansted wrote:
>> > We could even enhance which to look in obvious places off the path
>> (perhaps
>> > locatedb?)  and print the output on stderr if we really wanted to.
>>
>> Please don't - 'which' is used in scripts and needs to preserve its
>> current behaviour.  Any extra behaviour should be added to a
>> different/new program.
>>
>> --
>> Colin Watson                                       [cjwatson at ubuntu.com]
>>
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>>
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20111205/2d5f2f08/attachment.html>