Sometimes I forget everything I know.Take a Fedora 14 configuration issue, for instance, on one of my old machines:
Last week Nautilus was suddenly unable to access special GVFS URIs like Computer: or Trash:. Kind of annoying, but not a killer bug. I forgot about it for a few days, until I plugged in a USB drive and found that it didn't automount. Okay, more annoying, I thought, and probably related to the same GVFS error. Time for some Googling on the error message.
The first page of results revealed the problem to be my own fault: I had compiled Anjuta from source, and it required updated versions of GIO and GVFS, among many other GTK+ libraries. Unthinking, I had installed Anjuta and the new libs in /usr/local. Everything ran fine, until I rebooted. I only do that once every few months on this machine, and the error seemed disconnected from my earlier actions by that time. Once I read the post, it made sense. I renamed /usr/local/lib, lib64, etc. and rebooted, and Nautilus was fixed.
So this hiccup sparked a conversation between myself and a colleague: Why was it so easy to screw my system up, and what could or should be done about it? This, of course, led to a more philosophical discussion on the nature of an open-source OS, general UNIX principles inherent in Linux, and the ability to have one's cake and eat it too.
The basic UNIX principle that I failed to acknowledge when installing a new GIO/GVFS was the multi-user system. Users can be either remote (network) or local (physically at the console), and the system loads libraries, determines paths, and does a lot of other setup depending on what kind of user you are. This is accomplished by a simple but ingenious mechanism: directory inheritance and overriding via the PATH environment variable.
This principle extends to the individual user, where files or directories starting with "." in a home directory (~) can override system or local defaults. It is one of the features that makes Linux so infinitely customizable, meshing perfectly with the open-source philosophy. But it bit me this time; judging by the search for my simple error, this same oversight has bitten other users for years and will likely continue to do so. With root/administrative privileges, it is very easy to render any OS unstable or unbootable. I've seen more than one instance of users accidentally deleting their Windows system directories. Everything works until they reboot...
In a nutshell, the lesson learned is that almost any user installation or customization can and should be performed without root privileges. I should have installed the new libraries, and possibly Anjuta, in my home directory by specifying the prefix and libdirs during the build. So should anything be done to protect me from shooting myself in the foot again? Probably not. When one is constantly installing new development libraries and dependencies to hack and build the latest shiny version of application foo, some of them will inevitably conflict with application bar. The safest way to install, of course, is to use only the distribution's package manager and repositories. However, I can envision SELinux providing an extra layer of security by protecting distribution files.
Last week Nautilus was suddenly unable to access special GVFS URIs like Computer: or Trash:. Kind of annoying, but not a killer bug. I forgot about it for a few days, until I plugged in a USB drive and found that it didn't automount. Okay, more annoying, I thought, and probably related to the same GVFS error. Time for some Googling on the error message.
The first page of results revealed the problem to be my own fault: I had compiled Anjuta from source, and it required updated versions of GIO and GVFS, among many other GTK+ libraries. Unthinking, I had installed Anjuta and the new libs in /usr/local. Everything ran fine, until I rebooted. I only do that once every few months on this machine, and the error seemed disconnected from my earlier actions by that time. Once I read the post, it made sense. I renamed /usr/local/lib, lib64, etc. and rebooted, and Nautilus was fixed.
So this hiccup sparked a conversation between myself and a colleague: Why was it so easy to screw my system up, and what could or should be done about it? This, of course, led to a more philosophical discussion on the nature of an open-source OS, general UNIX principles inherent in Linux, and the ability to have one's cake and eat it too.
The basic UNIX principle that I failed to acknowledge when installing a new GIO/GVFS was the multi-user system. Users can be either remote (network) or local (physically at the console), and the system loads libraries, determines paths, and does a lot of other setup depending on what kind of user you are. This is accomplished by a simple but ingenious mechanism: directory inheritance and overriding via the PATH environment variable.
This principle extends to the individual user, where files or directories starting with "." in a home directory (~) can override system or local defaults. It is one of the features that makes Linux so infinitely customizable, meshing perfectly with the open-source philosophy. But it bit me this time; judging by the search for my simple error, this same oversight has bitten other users for years and will likely continue to do so. With root/administrative privileges, it is very easy to render any OS unstable or unbootable. I've seen more than one instance of users accidentally deleting their Windows system directories. Everything works until they reboot...
In a nutshell, the lesson learned is that almost any user installation or customization can and should be performed without root privileges. I should have installed the new libraries, and possibly Anjuta, in my home directory by specifying the prefix and libdirs during the build. So should anything be done to protect me from shooting myself in the foot again? Probably not. When one is constantly installing new development libraries and dependencies to hack and build the latest shiny version of application foo, some of them will inevitably conflict with application bar. The safest way to install, of course, is to use only the distribution's package manager and repositories. However, I can envision SELinux providing an extra layer of security by protecting distribution files.
No comments:
Post a Comment