Wizard Boot Camp, Part Six: Daemons & Subshells | Linux Magazine

Let’s continue our discussion of Linux processes with a look at two unrelated concepts that are both good to understand. First we’ll write a simple daemon process and send signals to it. Then we’ll see how to suspend a child shell — which gives some insight into how shells cope with signals sent to them.

Here is a good article on processes and signals on a Unix/Linux system. This also shows why sending a ‘kill -9′ to terminate a normal process is a bad idea. It doesn’t give the process a chance to clean up after itself.

Wizard Boot Camp, Part Five: Control Processes Using Signals | Linux Magazine

This month we’ll dig into process control: signals sent to processes and how a shell handles processes, including some details on job control.

The Wetware Crisis: the Dead Sea effect : Bruce F. Webster

Many large corporate/government IT shops — and not a few small ones — work like the Dead Sea. New hires are brought in as management deems it necessary. Their qualifications talent, education, professionalism, experience, skills — TEPES will tend to vary quite a bit, depending upon current needs, employee departure, the personnel budget, and the general hiring ability of those doing the hiring. All things being equal, the general competency of the IT department should have roughly the same distribution as the incoming hires.

But in my experience, that’s not what happens. Instead, what happens is that the more talented and effective IT engineers are the ones most likely to leave — to evaporate, if you will. They are the ones least likely to put up with the frequent stupidities and workplace problems that plague large organizations; they are also the ones most likely to have other opportunities that they can readily move to.

What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.

I’m painting with pretty broad strokes here, yet I’ve seen this same effect taking place in different companies and different IT shops. Large companies tend to lose the really talented IT engineers and hold onto the less talented ones, when they should been actively seeking to do just the opposite. And the effect tends to be self-reinforcing: the worse an IT shop becomes, the harder it is to get really talented and effective IT engineers to join it and the harder it is to retain them if they do. It can reach a point that the really good talent only comes in as entry-level personnel who don’t know any better — but once they do wise up, they’re gone.