Monthly Archives: April 2012

Tell me what I need to know RIGHT HERE AT THE TOP

A user asks a question in 3 parts. The title, then two paragraphs.

Title: Run compiled c program without ./

At this point I’ve already formulated an answer: “You can put “.” at the end of your path. There are risks to that, but it will solve your problem.”

The user clarifies in the first paragraph:

Quick question. After compiling a program, I always have to explicitly tell it to run from the current directory by prepending ./ to the name. For example $ ./testprog -argument1

The user has again demonstrated again that what I’m answer is correct. Perfect! At this point, I’m done thinking. The user, however, continues:

Is there a way to set up some kind of alias which would allow me to call it simply by saying $ testprog -argument1 , essentially allowing me to run the program from any location?

I’ve already registered everything and the last part doesn’t contradict what I’ve got in my head, so I’m done. Now, what are the 3 most important words in that question? They are from any location. Re-iterating the most important part of a topic in a long piece of writing is good, but introducing the most important part of your question at the end of it is very bad.

Let’s beat this horse to death:

Imagine you’re calling 911 (or 000100108111112119, or 999 depending on where you live… wow). What discussion are you going to have? “I was watering my flowers and I saw a little bug, so I kneeled down, blah, blah… part of a wall fell down, my leg is broken and squirting blood.” You’re either going to tell me something like, “I’m have an exposed broken bone and arterial bleeding from the leg. I’m at 123 Any Street, Middle of Nowhere, South Pole,” or you’re going to end up passing out before you finish the call. You’ve told me what you need, how urgent it is, and where to find you. Do that with your questions, and do it in that order.

Why does would 911 ask for the nature of the emergency before the location? It allows them to prioritize your call if there’s an overflow (or know that this is the 10th call about that same car accident in 3 minutes), to select the resources that need to be sent, and then where they need to go because there’s a lag of at least 30 seconds between when you tone out a fire truck or ambulance and the time the vehicle makes it out the door.

Here’s another life experience: “Jeff. Jeff, wake up. Jeff? Jeff, help I’m hurt.” Want me to move in 3 words? Start with help I’m hurt and I’ll be on my feet before the 5th word drops. Try anything else and it might be a minute before I’m moving.

So, with all this blabbering, here’s the “how to” lesson:

How do I determine the important part?

Write whatever you feel you want to ask. Remove a sentence. Remove another. Keep pulling out sentences until you’re down to the last one. Now put them back in reverse order of what you removed and make it sound like something normal from that. Alternately, try to build a tree structure where each level is more specific than the last. Save my soul for this one, but if it’s your thing consider the Twitter Rule of Importance: can you express your thought in 140 characters? Start with that converted to normal English.

Whichever way you look at it, reducing your thoughts to a bare minimum will help with your ordering. Provide all the details, but tell me the important part first, especially if it defines the scope of your problem.

When working with a non-professional, the professional has to spend the time to ask questions helping them to determine the importance of things. When you’re a professional speaking to another, save their time because you know enough to understand which parts should be important.

When scripting is too damn slow

Israel Torres wrote a nice write-up on Google hacking to dig up some Wolfram Alpha API tags. This isn’t about that, but I thought the article was an interesting read. What this is about is something I noticed in his API generation script: it was damnably slow.

Now, before I go into my bit about this, let me emphasize: This is used only as an example to learn from; it is not a personal criticism of Israel in any way. Why put that in big bold letters? Because I’ve run into too many people who think they are smug and that writing something like this would be a way to prove personal superiority to somebody else. That’s not what this is about.

What is important is recognizing places where tight loops might need something a little lower level or faster. Israel’s code suffered a few things that can easily bite somebody: poor randomness from the shell’s $RANDOM and starting a ton of processes in a tight loop. In fact, the example scripting starts a new process (/usr/bin/printf) for every two bytes printed.

From his article:

Generating a million AppIDs takes under an hour on a modern system and validating them takes even longer (about 6 times longer). Interestingly, out of 1 million generated AppIDs only about 100K are unique; generating a true 1M unique IDs would take even longer! (See Figure 13 below)

Well, let’s check out Figure 15 from there instead as that’s the code:

That didn’t feel right to me on sight, so I tried a quick bit of coding:

The results were much more favorable when using C, and on a 3 year old MacBook laptop at that:

$ time ./a.out > /dev/null

real 0m1.337s
user 0m1.323s
sys 0m0.005s

For another 30 seconds of CPU work, I could pipe it to “sort | uniq | wc -l” and verify that I had a million unique entries.

In a first for me, I actually wrote a code snippet in C… then went back to my default go-to language for a speed comparison. Quickly cutting it into Perl, the code runs in 10 seconds.

In short, think about when your scripts might be slow on a production system, or when you’re generating a lot of data in a tight loop. It’s often best to write whatever gets the job done fastest overall. For the most part, whatever you can write quickly in works just fine, but sometimes remember performance — especially if what you wrote is going to spawn a lot of processes.

While I’m talking about “gotchas,” give yourself a pat on the back if you noticed what would be a huge mistake in anything involving cryptography: I didn’t seed my random number generator. The C code will generate the same list every time.

Valuing your own time

This is not a post about performance, or things that are fast in machine time. Without doubt, I dislike inefficient systems and software. Yet, I don’t always focus on that.

A couple week ago, somebody asked, “What’s with all the infosec people using Macs?” There’s a longer answer of mine there, but if I’m going to reduce my thoughts to a few sentences, there they are:

  • My maintenance and setup vs. use ratio is low
  • It fits into my command-line world
  • If it breaks, I can probably get it fixed by somebody else in 24 hours.

Sure, I built Linux From Scratch those years ago like I talked about in an earlier post. I watched KDE take 24 hours to compile and I did it a few times over. It’s a great thing to do, and I suggest everybody who really wants to know Linux knows that

"make menuconfig"

is all about. But, if I interview you, you better not plan on deploying that on my network. Your primary machine should be running something else. Sure, it’s a great hobby and the knowledge is fantastic, but keeping on top of every package’s software update and security issues isn’t the right way to spend your time.

Cars and motorcycles… I like to work on each of them, but I didn’t buy any of them with the focus of working on them. In fact, I want my ratio of time spent maintaining the vehicle versus using it to be as low as possible. I don’t do an oil change just because I like to change oil. I take pride in the fact that I do my own work, but I don’t do my own for the pride of it. So, in the world of motorcycles where I have to open the top of the engine and adjust my valve clearances to thousands of an inch… I look at how often I have to do that as a purchasing consideration.

My computer is the same way. I didn’t buy my primary computer to spend my time tinkering on it. Sure, I tinker with it and I launch VMs inside and build virtual networks… but I do that when I want to accomplish something, even if that’s learning.

The point is: value your time. In fact, up until now, every post I’ve made has related to this concept: value your time. Find a way to keep yourself focused on the things you can’t automate. Move closer to the office. Remember that it costs more than $3 to get something that’s across town and the shipping price might be worth it.

  • I once wrote my own blogging software in 2003 using PHP. Now I use WordPress.
  • When I ordered my latest desktop (I haven’t had one hooked to a monitor in over five years), it was cheaper for the same parts through Dell than was a beige box that I was going to assemble. Hello Dell.
  • I feel like a total badass when I write something in C. Usually I’m in Perl, though because it takes about 15 lines of C to do one line of Perl and I don’t have to think about buffers.