Building software yourself? Don’t forget about GNU make’s ability to build in parallel, taking advantage of all those fancy CPUs you have: make -jX where X is the number of processes you want to spawn in parallel. For me it’s an old habit to make X the number of CPUs + 1. Not all software is set up for this, though. I usually try it, and if I get compilation errors I issue a “make clean” then a normal “make” command to see if it’ll build that way.
If a picture is worth a thousand words then getting to see something for yourself is worth an entire library. Especially when it comes to troubleshooting. We’ve been having problems with our list server lately. Our monitoring system sends email through it at regular intervals to check the service, and if the round trip time is too long it sends an alarm. Standard stuff, built to handle the case where the list manager software spontaneously dies once every quarter or so. The problem lately has been that we get the alarm much more frequently: once a day or more. Since this thing is a production service our operations staff have procedures on how to restart it. They get the alarm, …
The Emergency Power Off (EPO) switch in a data center I was in last week. Appropriately labeled, in my opinion. My favorite is actually the old-school pushbutton light switches, though. The lamp next to the switch glows red when they’re off, which makes it easy to find the switch in the dark.
There’s a lot of discussion going on lately about memory overcommitment in virtual environments. All I have to say is that memory overcommitment is great when you have to treat a VM like you’re buying a physical server. When I buy a physical server (or twenty) I often look for the “sweet spots” in pricing. I might know that the app that will run on a server will need 4 GB of RAM, but for $100 more I can get 8 GB and not have to worry about being short on RAM when something changes two years later. Worth it? Yes, and my customers think so, too, because the cost of me adding RAM later is much more than $100. …
I don’t know about all you developer types out there that got the iPhone rejection letters but I got my iPhone Enterprise Beta invite today. w00t! I’d say “In yo face developers!” except it isn’t the same. Plus I’m a nice guy and would never say something like that.[0] It should be interesting. I normally dislike NDAs, and now I’m under one, but then many of the details are already public. Means I have to stop letting people play with my phone, which might be a good thing. Not for Apple, though — most people who play with my phone for more than five minutes end up buying one. I’d say I’d keep you posted, but, well, um, yeah. Frickin’ …
In reading the multiple monitor posts over at Jeff Atwood’s “Coding Horror” I was reminded of a conversation I had a couple weeks ago: “Hey, I just wanted to let you know that your web site doesn’t look right on an 800×600 screen.” “You should get a bigger screen,” I reply. “I have a 30″ monitor, I just limit my browser windows to 800×600 to optimize the web stuff I do. You should really redesign your site to fit in 800 pixels, for compatibility.” “I see. Similarly, I have a 50″ TV at home but I only watch stuff in the picture-in-picture window.” “You do?” “Actually, no, I don’t, because that’s dumb.” Even my mother’s computer is capable of 1280×1024 …
Today has been a day of meetings. Lots of them. I got to my desk for the first time around noon. Since I was meeting someone for lunch I hustled to unlock my workstation, print something, and take off. I routinely unlock my workstation before my monitors wake up, one big swoosh as I sit down. The problem was that my workstation apparently didn’t lock itself[0]. So when I typed my password I typed it into a window… …an instant message chat window… …which was open to a fellow in my Security group. *sigh* This is right up there with the time I typed my password in the wrong field while doing a presentation. [0] Don’t know why. Most people …
As a guy who spent a few hours last week figuring out what was changing the permissions on / and /tmp on two of my servers, I offer this advice: always use absolute paths in scripts. You can’t count on the path or current working directory to be what you want, especially if your script runs from cron. And if you can’t count on that you run the risk of changing the wrong permissions, filling the wrong filesystem, or just generally doing the wrong thing. In my case a script changed the permissions of /tmp, using code very similar to: cd /opt/application; chmod 700 tmp What if the ‘cd’ fails? What will the chmod change? A better way to do …
“What do you mean he doesn’t know how to do that?” I ask. “He just doesn’t. Matt had to show him. Twice.” “Twice? Well, we’ll have to show him a third, fourth, and fifth time then, too.” “Don’t we have written procedures for these things?” “We all know how to do this stuff. We’ve all known for years. We hire folks that know this stuff. I guess there’s just been little need for these basic procedures.” “How do you know everybody does it the same way? What if I had to do it in an emergency?” It’s fun to hear my own questions being asked by others. “In this case there’s only one way to do it successfully. Plus you …
To me, it seems that a system administrator’s knowledge of a system, application, or technology follows a curve similar to the 80/20 rule. 80% of what you need to know comes in the first 20% of the time you spend on the problem: “So what?” you ask. Well, I think about this when I see folks spend hundreds of hours to design the perfect system. Or when they absolutely must tune a server to its peak performance. Or lay out LUNs on storage arrays. The list of examples is enormous, but I only ever have one question: was all that time best spent on that one system, that one task, that one goal? The inverse of this is when I …
