alsuren (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} alsuren) wrote, |
Re: Response from Philosophicles
I think a little clarification is in order:
In unix, the 4 locations mentioned are the folders in which you should find *all* executable binaries (yes, this might stretch to 6 or 8 for some vendors).
/usr/kde/3.5/bin --KDE apps. Should strictly go in /usr/bin, but I have 2 versions of KDE installed, and it's nice to be able to switch between them.
/usr/local/bin --user compiled apps (using ./configure and pals.)
/usr/bin --Package managed binaries. Often large optional binaries like GUI apps
/bin --required apps that everyone expects to find on a unix system
/opt/bin --the traditional location for optional locally installed binaries
I can link you to a manual page which tells you *exactly* what's supposed to go in each of those folders. Also, if you replace 'bin' with 'lib', you will find the locations of SharedObjects (.so ~= .dll) and LibraryArchives (.la) in a similar manner.
Compare this with the locations of executables in windows: %PROGRAMFILES%/*, where * globs many hundreds of folders, each containing all of the supporting libraries for each program as well as the binary executables, and none of them having a recognisable folder structure (and many of them containing folder structures going far deeper than you would like). I'm sorry, but I see no contradiction when I say that %PROGRAMFILES% is an ambiguous dumping ground compared to $PATH.
And don't get me onto executable installers. .msi installers for intels and .cab installers for mobiles are a sign that MS is catching up with the rest of the world, but it seems like 3rd party vendors still don't know what's going on. Quite depressing really.
I do like how MS is gently pushing the software vendors to be sensible, by requiring admin rights to execute anything that looks vaguely like it might be an exe installer (but allowing .msi installers to get quite a long way before nagging for admin rights), and following ubuntu's example of explicitly requiring a password, even if the user in question is in the admin group. It would be interesting to see whether it's possible to make a .msi installer that doesn't require admin rights at all, if you install into your user's home directory. It would also be interesting to see if someone could make a command line .msi installer, or an apt-get equivalent.
I think a little clarification is in order:
In unix, the 4 locations mentioned are the folders in which you should find *all* executable binaries (yes, this might stretch to 6 or 8 for some vendors).
/usr/kde/3.5/bin --KDE apps. Should strictly go in /usr/bin, but I have 2 versions of KDE installed, and it's nice to be able to switch between them.
/usr/local/bin --user compiled apps (using ./configure and pals.)
/usr/bin --Package managed binaries. Often large optional binaries like GUI apps
/bin --required apps that everyone expects to find on a unix system
/opt/bin --the traditional location for optional locally installed binaries
I can link you to a manual page which tells you *exactly* what's supposed to go in each of those folders. Also, if you replace 'bin' with 'lib', you will find the locations of SharedObjects (.so ~= .dll) and LibraryArchives (.la) in a similar manner.
Compare this with the locations of executables in windows: %PROGRAMFILES%/*, where * globs many hundreds of folders, each containing all of the supporting libraries for each program as well as the binary executables, and none of them having a recognisable folder structure (and many of them containing folder structures going far deeper than you would like). I'm sorry, but I see no contradiction when I say that %PROGRAMFILES% is an ambiguous dumping ground compared to $PATH.
And don't get me onto executable installers. .msi installers for intels and .cab installers for mobiles are a sign that MS is catching up with the rest of the world, but it seems like 3rd party vendors still don't know what's going on. Quite depressing really.
I do like how MS is gently pushing the software vendors to be sensible, by requiring admin rights to execute anything that looks vaguely like it might be an exe installer (but allowing .msi installers to get quite a long way before nagging for admin rights), and following ubuntu's example of explicitly requiring a password, even if the user in question is in the admin group. It would be interesting to see whether it's possible to make a .msi installer that doesn't require admin rights at all, if you install into your user's home directory. It would also be interesting to see if someone could make a command line .msi installer, or an apt-get equivalent.
