" Also, /opt is for douchebag programmers who can't be bothered to learn
which pieces of a program should go where on a unix-like system. :) It could
also be for those situations where a program should be fully stand-alone,
but those situations should be rare and far between."

I am one of those devs but I still find this hilarious and educational!!

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Benjamin Tayehanpour
Sent: 31 January 2012 15:41
To: Uganda Linux User Group
Subject: Re: [LUG] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

>From observation I arrived to the conclusion that /bin was for binaries
which would (potentially) be run before the system was fully booted and all
partitions mounted, whereas /usr/bin would be for binaries which have no
chance of being needed before the boot into user mode was completed.

Also, /opt is for douchebag programmers who can't be bothered to learn which
pieces of a program should go where on a unix-like system. :) It could also
be for those situations where a program should be fully stand-alone, but
those situations should be rare and far between.

On Tue, Jan 31, 2012 at 1:34 PM, Okalany Daniel
<[email protected]> wrote:
> From my intuition,
>
> I always thought /bin was for distro binaries, /sbin was for setuid 
> distro binaries, /usr/bin for your own package binaries, /usr/sbin for 
> your own package setuid binaries.
>
>
>
> Curious to know what you all thought.
>
>
>
> Regards,
>
> Daniel
>
>
>
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of joseph mpora
> Sent: 31 January 2012 02:47 PM
> To: Linux Users Group Uganda
> Subject: [LUG] Understanding the /bin, /sbin, /usr/bin, /usr/sbin 
> Split
>
>
>
> Finally something really interesting to talk about. If you've used 
> UNIX or any of its derivatives, you've probably wondered why there's 
> /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have 
> a rationalisation for the existence of each and every one of these 
> directories. The thing is, though - all these rationalisations were 
> thought up after these directories were created. As it turns out, the 
> real reasoning is pretty damn straightforward.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
>
> _______________________________________________
> The Uganda Linux User Group: http://linux.or.ug
>
> Send messages to this mailing list by addressing e-mails to: 
> [email protected] Mailing list archives: 
> http://www.mail-archive.com/[email protected]/
> Mailing list settings: http://kym.net/mailman/listinfo/lug
> To unsubscribe: http://kym.net/mailman/options/lug
>
> The Uganda LUG mailing list is generously hosted by INFOCOM:
> http://www.infocom.co.ug/
>
> The above comments and data are owned by whoever posted them 
> (including attachments if any). The mailing list host is not 
> responsible for them in any way.
_______________________________________________
The Uganda Linux User Group: http://linux.or.ug

Send messages to this mailing list by addressing e-mails to: [email protected]
Mailing list archives: http://www.mail-archive.com/[email protected]/
Mailing list settings: http://kym.net/mailman/listinfo/lug
To unsubscribe: http://kym.net/mailman/options/lug

The Uganda LUG mailing list is generously hosted by INFOCOM:
http://www.infocom.co.ug/

The above comments and data are owned by whoever posted them (including
attachments if any). The mailing list host is not responsible for them in
any way.

_______________________________________________
The Uganda Linux User Group: http://linux.or.ug

Send messages to this mailing list by addressing e-mails to: [email protected]
Mailing list archives: http://www.mail-archive.com/[email protected]/
Mailing list settings: http://kym.net/mailman/listinfo/lug
To unsubscribe: http://kym.net/mailman/options/lug

The Uganda LUG mailing list is generously hosted by INFOCOM: 
http://www.infocom.co.ug/

The above comments and data are owned by whoever posted them (including 
attachments if any). The mailing list host is not responsible for them in any 
way.

Reply via email to