What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin?

There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.

FreeBSD installs all packages in /usr/local/bin and /usr/local/sbin

You can blow away your /usr/local and start from a new ports tree and build it all back up without adversely affecting the system.

Everything system related is in /bin, /sbin, /usr/bin, /usr/sbin depending on whether it needs to be accessible when the system has just / mounted or when /usr is mounted as well.

So in single user mode with just / mounted you have access to various different utilities. Mount /usr and you can expand upon that.

Back in the old days when FreeBSD required perl in its base system switching to a newer version didn't break any of the base system tools (or maybe I just never noticed).

There is something nice about a layout that is properly documented and makes sense: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...

Well exactly. People who never learnt the old-skool ways always reinvent the wheel in an over-complex way. /usr/local/bin is stuff for the users, but which the sysadmin installs. So /usr/bin/python for the OS and /usr/local/bin/python for your users.

> What about stuff that belongs to me (the sysadmin) but runnable by all users?

If you're writing quick ad-hoc scripts and don't have time to package, /usr/local/bin.

Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. We can't and probably don't want to change that, so we'll need to live with it.

Use virtualenv. if you need to to, install a quick Python 2.6 package that slots alongside your OS package rather than removing it - using RHEL 5 as an example, you'd install 'python26' alongside your existing 'python' package.

Not to nitpick here, but I want to clarify something you said.

> Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it.

The OS doesn't need python. It is some package you have installed that needs python, like Gnome(py-gtk2) or KDE(py-qt), for your desktop environment or some application you decided you needed. If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server. Having large numbers of language interpreters and compilers on a server can be considered a security risk, since after someone gains access, that provides him or her a large number of options of what kind of code he or she can run. Even having a C compiler is a risk, since code can then be compiled into programs already present on the system. Security should be first in mind when developing an application server.

On the other hand for a development environment, there should be nothing stopping any distribution from installing multiple language interpreter versions. The default `/usr/bin/python` or `/usr/local/bin/python` can be a symlink to python25, python26 or python27, and when the user needs to run a different version, they explicitly call the binary with the version number. This whole virtualenv method just to parse a configuration file of a program not written in python seemed a little excessive.

> The OS doesn't need python. It is some package you have installed that needs python

No. The installer and packaging system need Python. Anaconda and Yum depend on it. Try removing it and see. You cannot install a minimal RHEL or Fedora system without Python. I am fairly sure this applies to other distros too.

Whats to stop you from patching and compiling programs yourself to get rid of the python dependancies of your package manager?

If the Linux distro you choose doesn't meet your needs, why would you continue to use it? If your Fedora install requires it to be one way, but that doesn't fit the need of the server, it would like one should reconsider why they are using that distro.

If you're just running Linux on your PC in your dorm room, go for it.

If you're running 10,000 machines you don't make changes that you haven't regression tested and aren't committed to supporting. Effectively, you'd need to write your own package manager, maintain your own repository and deal with upstream yourself... You'd be Red Hat.

Not true. In some Linux distros Python is used for system scripts, instead of sh.

If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server

Quite.

You answered your own question - /usr/local/bin. I don't know about MacOSX but on Linux, this is the solution to your problem - "stuff that belongs to me (the sysadmin) but runnable by all users".

People who don't do Python won't/can't use virtualenv. Also, you don't think that's a nasty workaround for something that should just be a non-issue? That's like you telling me to use NetBSD pkgsrc just to get around some ancient linux (which I have done).

Hi Zed. For the specific case of needing Python 2.6 on RHEL, ask your user to install the 'python26' package from EPEL. It's a semi official source of packages for RHEL including newer versions of OS tools that slot alongside those versions.

Or, just rewrite in C and everyone except Python people will quit bitching. :-)

It seems nobody liked having a full language for default config file format anyway, so ditching it for something simpler may make people happier.

The problem with requiring an update to something like Python may break other programs. Not everything in Python (or Perl) is backward compatible.

Installing the 'python26' package doesn't update or change the installed Python in any way. That's why it was created.

* 'python' remains installed, at version 2.4

* 'python26' is now installed, into separate folders.