Responses to reader comments regarding some older posts
This is a batch of updates to older posts and responses to reader questions.
One question is about my scanner project: am I motivated by profit or is this a hobby? That one is a little hard to answer, but I can definitely remove one angle from it: there is no profit in this kind of work. Nobody wants to pay for it. They don't want to pay for the hardware, the software, or the development time.
Back when you had to pay $800 or more to get into this field with a $500 USRP1 and a $300 daughterboard, hardly anyone did it. It took the existence of the $20 RTLSDR sticks to get more people to pay attention.
So I guess that leaves the "hobby" angle. I don't listen nearly as often as before, but other people have found it useful on occasion, so it's worth keeping up. I got a few mails from someone who was concerned for a friend out this way when something scary happened involving some criminals, and my site was able to help them out.
If I don't want that to go away, then I have to adapt my site to the new TDMA-based system somehow. There's just no way around it.
...
In regards to a post from 2012 about working tech support, there was a question as to how big the day shift was. To be honest, I don't remember exact numbers any more. I think the Linux side of the house had 3 teams back then just for the non-high-end customers. Each team probably had three or four "level 2" techs and one or two "level 3" techs, plus however many "level 1" phone firewalls they could cram in.
So... maybe 12-15 people? That number seems low. I'm trying to visualize the area which held their desks now and it seemed to go on forever.
I know that's not much of an answer. Sorry. It's the best I can do.
...
Finally, I got a couple of questions about my RPM cleanup project, and whether I'd make it available. Well, I'm sorry to say that it's not mine to give away. Someone paid for the development of those tools, and they own them a result.
Fortunately, we're not talking about rocket science here. Any of these tools could be re-created by anyone so inclined. Run "ps" with the right flags to select things like yum and rpm and have it return the pid and wchan. If it's in the futex state, poke it with ptrace as previously described. Try a few times and then punt if you must.
That's one tool. Another one just tries to do the equivalent of "rpm -qa" using the librpm calls, and if it gets stuck or fails, it kicks off db_recover. It's basically a bit of paranoia to keep from running the recovery tool every single time, since I'm not sure exactly what that would do to a concurrent RPM operation which is otherwise fine. The only magic here is that it happens in a child process to avoid getting itself stuck when things go bad in libdb.
Finally, for the NFS thing, you do the same "fork and test in child" scheme, but you're looking at entries from /proc/mounts instead. If they don't work, kick them out and remount them if at all possible. Lather, rinse, repeat.
I don't have the cycles to maintain or support something like this for the world. If you need them, write them. They aren't terribly complicated, and the wins you'd get from local customization beat any savings you might get by copying code from someone else.