Link: Classic Mistakes Enumerated
Classic Mistakes Enumerated is an exerpt from the book Rapid Development by Steve McConnell; it runs through 36 familiar classic development mistakes that people make over and over again. Brooks's Law makes an appearance, of course.
(From Bill de hÓra.)
I found out about Linux
-p' option from comments on a a
previous entry. The option is also known as
--preserve-environment; the manpage describes it tersely as 'do
not reset environment variables', but the info document tells the full
Do not change the environment variables `HOME', `USER', `LOGNAME', or `SHELL'. Run the shell given in the environment variable `SHELL' instead of the shell from USER's passwd entry, unless the user running `su' is not the superuser and USER's shell is restricted. A "restricted shell" is one that is not listed in the file `/etc/shells', or in a compiled-in list if that file does not exist. Parts of what this option does can be overridden by `--login' and `--shell'.
I'm used to old-fashioned
su's that always run the target user's
login shell, no matter what. Being able to override the login shell is a
bit alarming; although there are safeguards, it does make what you put
/etc/shells somewhat more dangerous. (Clearly you never want to put
/bin/false or the like in there, in order to get something else to
At the same time, being able to run alternate shells for 'restricted'
accounts as root is a useful trick (whether done through
--shell). I'll have to remember it for the next
time I want to fiddle with an environment owned by such an account; it
certainly beats trying to do it as root and then
chown'ing the setup
SCGI is a form of caching
This is perhaps an obvious observation, but I've recently consciously realized that persistent SCGI and FastCGI daemons are a form of caching of regular CGI programs; rather than caching data, they're caching code and often configurations. Thinking about them this way has made several things clearer to me.
As caches, they have all of the usual concerns with detecting and dealing with cache invalidation, complicated by the fact that few environments have really good support for loading new versions of your program's code on the fly. Even fewer can cope with data structure changes.
While I have my reasons for disliking resorting to caching, I don't wind up feeling that using persistent daemons is giving in in the same way. I think the reason is because the speed problems that prompt persistent daemons are beyond my control; how fast CGI processes start is mostly up to the operating system and the language interpreters. (Some of it is how fast my program parses its configuration files, but this is usually a small portion of the time.)
This doesn't mean that I like SCGI daemons et al, but I dislike them for different reasons: they're harder to manage, partly because of the caching issues, and I often feel that they shouldn't be necessary. Just running CGI programs directly means that I am always using the latest code and configuration and so on, and if something goes wrong it goes wrong very directly and immediately. (And if it works it's going to keep working.)