rudd-o@karen: ~ $
history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
76 cd
38 mv
36 svn
34 python
31 rm
30 ls
19 git
14 dpkg
14 aptitude
13 find

Please note: I have history set up so it doesn’t record repeated commands. So this count is a count of unique, different commands each.

Want the graphwatch version? Here it is:

cd 70 #################################################
      mv 36 #########################
  python 34 #######################
     svn 32 ######################
      rm 29 ####################
      ls 29 ####################
     git 16 ###########
    dpkg 14 #########
aptitude 14 #########
    nano 13 #########

Here’s what I did to generate that graph:

1. history > x
2. graphwatch 'cat x | awk '\''{a[$2]++}END{for(i in a){print a[i] ” ” i}}’\” | sort -rn | head | awk ‘\” { print $2 ” ” $1 } ‘\”’ ” “

graphwatch is a nice Python script that takes a properly quoted shell pipeline that will be run through bash and a field separator (in this case, a sngle empty space). My extra awk invocation there swaps the first and second fields so the first column is the label, and the second column is the value — graphwatch plots a nice set of proportional horizontal bars.

But that’s not it. The command is run once every second, so if the contents of the file x (or the output of the supplied command) change, the graph is re-plotted. Very nifty to watch tabular numeric output in graphical form, in real-time — imagine using it with iostat and you’ll get the idea.

Here’s the code. I will release it as a proper package with enhancements (it’s a quick hack right now) later on:

#!/usr/bin/env python

from time import sleep from subprocess import PIPE,Popen from sys import argv,exit,stdout import os

try: cmd = argv[1] sep = argv[2] except IndexError, e: print "usage: graphwatch 'shell pipeline' 'separator'" exit(os.EX_USAGE) print "Running this command in a shell:" print ">", cmd

def getstdout(cmdline): p = Popen(["bash","-c",cmdline],stdout=PIPE) output = p.communicate()[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output

try: while True:

    output = getstdout(cmd).strip()
    stdout.write(getstdout("clear"))

    labels = []
    values = []
    for l in output.splitlines():
        try:
            label,value= l.strip().split(sep,1)
            label,value = label.strip(),value.strip()
        except ValueError, e: label,value = None,l.strip()
        labels.append(label)
        try: values.append(float(value))
        except ValueError, e: values.append(0.0)

    try:
        maximum_value = max(values + [maximum_value] )
    except NameError, e:
        maximum_value = max(values)

    try:
        longest_label = max( [len(l) for l in labels if l is not None ] )
        label_fmt = "%" + str(longest_label) + "s"
    except ValueError, e:
        longest_label = -1 # to compensate for the extra -2 below
        pass # nothing will happen later

    longest_number = max( [ len(str(int(i))) for i in values if type(i) is float ] )
    number_fmt = "%" + str(longest_number) + ".0f"

    column_width = 61
    leftover_for_plot = column_width - longest_label - longest_number - 2


    for value,label in zip(values,labels):
        if label is not None:
            print label_fmt%label,
        print number_fmt%value,
        print "#"*int(value/maximum_value*leftover_for_plot)

    sleep(1)

except KeyboardInterrupt, e: exit(0)

The script

Stash it in /usr/lib/nagios/plugins of the Dirvish backup machine, naming it check_dirvish. This script assumes that your Dirvish vaults are in /mnt/backup, so tune it if that isn’t true in your case:

#!/bin/bash

for a in /mnt/backup/* ; do if [ -f ls -d "$a/"* 2> /dev/null | grep -v /dirvish | sort -g | tail -1/rsync_error ] ; then echo "CRITICAL: latest backup in vault $a failed" exit 2 else /bin/true fi done echo "OK: All backups OK"

The security setup

Create a nagios user on your Dirvish backup machine, and set up SSH passwordless authentication.

Now, if your Dirvish vaults are accessible only to root, set up sudo to allow Nagios to run this script as root:

nagios ALL = NOPASSWD: /usr/lib/nagios/plugins/check_dirvish

The Nagios setup

Finally, set Nagios up:

define command{
        command_name    ssh_dirvish_sudo
        command_line    /usr/lib/nagios/plugins/check_by_ssh -t 29 -H $HOSTADDRESS$ -C 'sudo /usr/lib/nagios/plugins/check_dirvish'
        }
define service{
        use                             generic-service
        host_name                       gabriela
        service_description             Backups
        check_command                   ssh_dirvish_sudo
        }

Of course, the sudo call is only needed if the Dirvish vaults are restricted for the nagios user.

These packages are built from the source code of the next release of Ubuntu, Hardy. They work flawlessly on my home machines (yes, plural). I built these packages myself for my usage:

• libpulse-browse0_0.9.8-1ubuntu3_i386.deb
• libpulse-mainloop-glib0_0.9.8-1ubuntu3_i386.deb
• libpulse0_0.9.8-1ubuntu3_i386.deb
• libpulsecore5_0.9.8-1ubuntu3_i386.deb
• pulseaudio-esound-compat_0.9.8-1ubuntu3_i386.deb
• pulseaudio-module-gconf_0.9.8-1ubuntu3_i386.deb
• pulseaudio-module-hal_0.9.8-1ubuntu3_i386.deb
• pulseaudio-module-lirc_0.9.8-1ubuntu3_i386.deb
• pulseaudio-module-x11_0.9.8-1ubuntu3_i386.deb
• pulseaudio-module-zeroconf_0.9.8-1ubuntu3_i386.deb
• pulseaudio-utils_0.9.8-1ubuntu3_i386.deb
• pulseaudio_0.9.8-1ubuntu3_i386.deb

Download them all in a folder, then just open a terminal window there and type:

sudo dpkg -i *deb

That should upgrade you to the latest PulseAudio. I was gonna write a tutorial, but then you would have had to download hundreds of megabytes of development packages.

sudo sed -i 's/feisty/gutsy/g' /etc/apt/sources.list && sudo apt-get update && sudo apt-get dist-upgrade

If at some point any of those processes fail, you will be returned back to the console. dist-upgrade will require your confirmation, so don’t just take off before the confirmation question.

• Real speed
• Guaranteed bandwidth
• Unfiltered, unthrottled service
• Reliability and quality of service
• Access from the outside world
• Privacy, neutrality and censorship

Each and every one of these aspects can make or break the honeymoon with your ISP. Each matter independently, and once you’ve done a little research on what your ISP of choice is doing to grant (or deny) them to you, you’ll be in a position to make a much more informed decision.

Bandwidth is not speed. Latency is.

If you are anything like the next person, by now you’ve been led to believe that your Internet experience is determined by bandwidth. That’s bullshit. Bandwidth is hoy many bytes you can download per second — and nothing more.

Anything above 500 kbits per second guarantees enough speed to make Web surfing snappy — if, and only if, the latency of your connection is low enough. Becaus, you see, latency is key — it’s the time your computer takes to initially communications with Web (or other types of Internet) servers.

What happens when you click on a link

After you click on a hyperlink, your Web browser (more or less) goes through the following steps:

1. It connects your computer to a Web server and requests a Web page.
2. It receives the response, starts processing it and (in parallel) starts other requests — to get the images, videos, styles and scripts that actually form the page. But only four of those at a time.

If each of those steps can be started in, say, 50 milliseconds, you’re golden — the page more or less snaps in front of your eyes. But if they take over a second each… well, let’s say you have a problem because, for the average Web page, you will never see it settle down before ten or so seconds since your last click.

What happens when you play games over the Internet

Let’s imagine for a moment that you’re playing Unreal Tournament, or any other fast-paced first person shooter kinda game. Just blink once — boom, you’re dead. That’s how long it takes for someone to shoot your neck and rip your head off.

A blink of an eye is, literally, 25 milliseconds. Not a problem for wireless or wired local networks — because the bullets traveling through the network take less than two milliseconds to get eaten by your enemies. But if you’re gaming through an Internet connection and your enemy is sitting just 200 milliseconds “away”, you’re going to have real trouble making any kills.

Sure, modern games incorporate mechanisms that attempt to compensate for that latency problem. But they only go so far.

What determines latency

Latency is determined by two factors:

1. The physical distance of the route that information takes through the Internet. Not a really big hurdle, since information travels at a rather close factor to the speed of light.
2. The time each “hop” (Internet router) takes to process and forward that information to the next hop.

You can verify this yourself. Open a command line (cmd.exe on Windows, konsole or gnome-terminal on Linux) and type (on Windows) tracert google.com (on Linux, substitute tracert for traceroute). You’ll see a table grow: each row is a hop, and the three columns on the right side are the times, in milliseconds, that information took to reach that hop. The last row will contain the final destination’s latency measurement. You can substitute google.com for your favorite Web site’s address or your gaming friend’s IP address.

So latency is key — now you know that.  Next up: how much bandwidth you’re really getting?

1. Open the VMware .vmx / .cfg file of your VM.
   1. Find the config entries labeled sound. Kill them all.
   2. Put the following instead:

      sound.present = "TRUE"
      sound.autodetect = "TRUE"
      sound.fileName = "-1"
      sound.directSound = "false"
      sound.highPriority = "TRUE"
      sound.maxLength = 2048
      sound.smallBlockSize = 1024

2. If you are using Steinberg Nuendo in your VM:
   1. Go to Devices -> Device configuration…
   2. Select VST Multitrack on the left panel.
   3. Change the ASIO controller to ASIO DirectX Full Duplex

Let’s hope this works for you as well as it worked for me. Here’s the obligatory screenshot:

See that? It’s Steinberg Nuendo performing a mix down under Windows XP, running under a VMware machine in a headless Linux computer, displaying to a virtual Xrealvnc screen, displayed on my desktop computer using KRDC (my favorite VNC client). KRDC is set to resize the desktop — that’s why Windows looks a bit blurry. For kicks, XMMS is playing the mix down as it’s being generated, from a shared folder in the Windows virtual machine.

Refer to my previous “cluster computing” audio hack to understand why I went to such lengths.

It’s a 3-hour mix, so the mix down will take a while. I’l just sit and chill.

• It’s Safari.
• There’s no exposed filesystem anywhere.
• Heed sanctioned Web development best practices.
• In contrast to a PC, you may not have the full attention of your users.
• Build apps to provide quick, easy access to things user need.
• iPhone is different. People expect a different user experience. People will benchmark your Web site against the included apps.
• Make fast Web pages. People may be browsing using EDGE networks.
• Cookies are available.
• No Flash. No Java.
• No scrollbars. Finger gestures are to manipulate how the content is viewed (pan, zoom in/out).
• The tap is equivalent to a mouse click.
• Present your text in narrow columns to let the user avoid zooming in/out.
• People fatfinger. Design UI elements accordingly.
• There are pages compatible with iPhone, pages optimized for iPhone and iPhone Web applications.
• Shoehorn your content into single-purpose views. You can redesign centering your site around that, or you can build iPhone Web applications (mimicking the iPhone UI) for each specific type of view.
• iPhone applications should integrate with iPhone services.
• Make it obvious how to use your content.
• Minimize user input.
• Remove decorative crap.
• User-centric terminology.
• Provide dynamic feedback.
• Be consistent in your UI.
• Aim for instant display in the responsiveness department.
• Make your page/app resilient to network service interruptions.
• Avoid absolute positioning.

Here’s the set of guidelines. And here’s a set of metrics, layout guidelines and tips which don’t work well as a summary.

My personal tip: you can, and should, use CSS to make your page work differently in Safari. Do so; avoid falling in the trap of different markup for the iPhone.

Maybe I was at a loss for words. Maybe not. But today I found the most amazing, concise and compelling explanation — I just couldn’t have said it better:

Visitors want to have control over everything what happens in their browser. If they’d like to open a link in a new window they will. If they don’t want to, they won’t. If your links open in a new window you make the decision which is not your decision to make.

Thanks to these guys for the explanation. I will burn it in my memory for future projects — there will never be a shortage of bozos attempting these shenanigans.

I could of course rant at length about style, but it’s pretty open-ended: people constantly find clever new ways to be unclever. So I will restrict my stylistic remarks to the use of the word “utilize”. “Utilize” has been scientifically demonstrated to be used only by stupid people, so if you use it you could easily be mistaken for one. A stupid person, that is, not a scientist. “Utilize” is one of the all-time classic Stupidity Indicators, right up there with saying “choo-choo-choo” out loud when you’re thinking. Ever notice how only stupid people make train noises when they’re thinking? “Oh gosh, lemme think, chsh chsh chsh… hmmm, choo choo choo…”I could of course rant at length about style, but it’s pretty open-ended: people constantly find clever new ways to be unclever. So I will restrict my stylistic remarks to the use of the word “utilize”. “Utilize” has been scientifically demonstrated to be used only by stupid people, so if you use it you could easily be mistaken for one. A stupid person, that is, not a scientist. “Utilize” is one of the all-time classic Stupidity Indicators, right up there with saying “choo-choo-choo” out loud when you’re thinking. Ever notice how only stupid people make train noises when they’re thinking? “Oh gosh, lemme think, chsh chsh chsh… hmmm, choo choo choo…”

The article’s got great tips for aspiring young people who want to make their résumés look great too!. I wonder if the author will pick this post up and as a consequence, read my own résumé.

Put this on a script, and run it with the offending process ID as the first argument, and the destination directory as the second one:

#!/bin/bash

pid="$1" # get the PID cwd="$2" # first argument is the CWD, there is a quoting bug below but I really couldn't care less

now let's command the GNU debugger

gdb -q >> EOF attach $pid call (int) chdir("$cwd") detach quit EOF

Inspired by Behdad. Took me one minute to write it, two to look up how it’s done. Thank Google.

Things to notice:

1. Yes, there’s a quoting bug in the here-document fed to GDB. I couldn’t care less; post the fix as a comment if you want to.
2. Caveat luser: when you sweep the rug off of bash’s feet using this trick, the bash prompt will continue to have the wrong idea of the current directory, but every other command (not using the $PWD variable, of course) will operate correctly.
3. Processes holding files open on a volume to be mounted could conceivably get their files closed using GDB as well. Trivial and left as an exercise for the reader.
4. bash is my bitch, I rule, then you die.

People who actively chose to be poor. These people are those who chose not to live a competitive lifestyle. Just down the road from where I grew up lived a person with a Ph.D. from Berkeley who basically checked out of mainstream life in the mid-’70s. He bought a small piece of land, built a log cabin out of the wood on that land, and spent all of his time fishing, hunting, and reading. He chose to be poor as a lifestyle choice. There were others like this as well who made their living quietly.

People who inactively chose to be poor. These people were the ones that played the lottery every week, followed celebrity gossip, and rambled on about how they were going to have big money someday, but just kept going to work in the same old factory doing the same old thing. They basically refuse to make choices that would raise them up from poverty for whatever reason. It is people from this group who you often see winning the lottery - then blowing it all in a few months.

People who choose to get out. The third group mostly is filled with younger people who see that this is a fool’s game and then try to get out of the situation. They do whatever it takes to go to college, get an education, and find work. What I often noticed is that these people managed to make the step to the upper middle class, but it was their children that did amazing things, as these people instilled some serious values in their kids and also gave them appropriate support.

Keep reading that article, and then subscribe to The Simple Dollar. Whether you subscribe to their ideas or not, at the least I can guarantee you a steady source of food for thought.

• It resets out of the blue. Even with no applications installed, the bundled VersaMail and Blazer Web browser tends to reset spontaneously. Some VersaMail mail messages are undeletable (unless you manually nuke its databaes, in which case you need to reconfigure the app from zero again).
• Blazer, the Web browser, is slow and bad. It won’t load big Web pages either.
• When an SD card is in the expansion slot, the Palm takes 8 seconds to power up (resume from standby). Imagine wanting to take a quick note and having to wait every time you turn the device on.
• It’s slow and unresponsive. Lots of applications block. There are tons of corners in the little TX’s world where you can’t do anything but wait.
• Networking sucks. It fails out of the blue, and when it fails, the device hangs until the application times out — no way to cancel network operations.
• It has extremely poor audio quality. There’s a horrible hiss coming out of the headphone jack constantly. If you want to listen to music, you better listen at max volume and brace yourself for hearing loss, because listening at low volumes is impossible given the hiss.
• Every media player available for the Palm (even the bundled one) rescans the expansion card every time you launch it. This means that you have to wait up to 15 seconds in order to select a song to play.
• Music on the go? Forget about it. Although Pocket Tunes can turn the screen off while listening to music, if you put your Palm T|X in your pocket, the 5-way navigation keys will be depressed constantly, randomly activating functions in your Palm and turning the screen on — effectively, it’s a music player with no Hold function. The only workaround, an app (aptly) named Hold On, takes a while to launch, shows an annoying dialog box, and needs two extra taps on the screen in order to activate. In effect, to put the Palm on hold, you need to start the app, wait 5 seconds, tap the screen twice, then hit the (hard to depress) Power button. If I want to change a song, I have to hit the Power button again, tap the screen again, then hit the a hard key mapped to Pocket Tunes, and endure its interface, awkward to use with a thumb. Compare to an iPod: slide a slider, scroll a wheel, and you’re done.
• Did I say Power button? My Power button is already damaged.
• Battery life: bad. Don’t get me wrong, for a PDA, it’s quite good. But for a music player… come on, if the CPU scaled back when listening to music, it’d last so much more! I’m forced to use WarpSpeed to manually set the speed to 70 MHz when the Hold On app is active.
• Zero support. The forums about Palm on the Web are helpful, but you ain’t getting to talk to Palm customer representatives that easily. After extensive talk to reps, all they could suggest is that I erase everything from my Palm and see if problems continue to exist.

For me, the Palm T|X was the hopeful answer to carrying both a PDA and an iPod in my already crowded pockets. In reality, the Palm T|X has the potential to be everything you need, if you can hack the hardware to replace the poor DAC and amplifier, add an extra battery rucksack, and hack the software to work around all the limitations and bugs.

I suspect the LifeDrive is also plagued with the same issues (the Tungstens did have these issues, for the record).

Steer clear of Palm — they’re dead and I wish they were even deader.

Update: the problem I experienced with my SD card is circumscribed to my SD card and only it. Others don’t make the Palm T|X exhibit the issue. However, there’s no guarantee that spending another $100 in a new 4GB SD card will solve the issue, so I’m stuck with it. Sucks to be me, doesn’t it?

Most Python packages fail to build using the traditional python setup.py bdist_rpm process with an Installed (but unpackaged) files found error message, and a list with a bunch of .pyc and .pyo files.

If this is the problem, I know why it arises, and how to solve it.

Why?

First, let me assure you: you are not doing anything wrong. It’s a Fedora 6 issue.

Because there’s a post-process script that Fedora runs named /usr/lib/rpm/brp-python-bytecompile. This fucks up the RPM buid process because it compiles byte-optimized versions of the Python files to be installed. Of course, bdist_rpm is not aware of this, so it can’t inform RPM that those files will also be added to the package. What does this mean? It means that RPM finds those files and says Oh, damn, these files don’t belong here, I better bomb out.

The script is a complete fuckup, and it contains at least two bugs.

How I solved it

I opened it in my favorite text editor, located these two lines:

# Generate normal (.pyc) byte-compiled files.
$python    -c 'import compileall; .... (something irrelevant)

Generate optimized (.pyo) byte-compiled files.

$python -O -c 'import compileall; (something equally irrelevant)

and commented those two lines beginning with $python, like this:

# Generate normal (.pyc) byte-compiled files.
#$python    -c 'import compileall; .... (something irrelevant)

Generate optimized (.pyo) byte-compiled files.

#$python -O -c 'import compileall; (something equally irrelevant)

You should do so too.

And once Fedora 7 comes out, if this fuckup persists, you bet you’ll be able to do this again.

Here are his top ten no-no’s:

1. Enforced immediate registration.
2. The long URL.
3. Windows that don’t generate URLs.
4. The unsearchable web site.
5. Sites without Digg, del.icio.us, and Fark bookmarks.
6. Limiting contact to email.
7. Lack of feeds and email lists.
8. Requirement to re-type email addresses.
9. User names cannot contain the “@” character.
10. Case sensitive user names and passwords.
11. Friction-full commenting.
12. Unreadable confirmation codes.
13. Emails without signatures.
14. Supporting only Windows Internet Explorer.

Yes, I know Kawasaki said 10 and delivered 14. But he’s right, on all counts. Read his article if you want to understand exactly why these things are bad for your readers and you.

And don’t just wave your hands and say “I don’t understand that much about tech to be fixin’ these things”: get the fark off your comfort zone and do whatever it takes to start learning how to fix what’s wrong. Which is usually no more than a clever reading list of information that already exists on the Web. Just fucking Google it.

Oh, if you’re blogging, then you better pay attention to one more thing: you need to link. I’ve always said so — it’s self evident — and now Scoble is voicing his support for linking as well. Oh, and linking to outside blog posts is a great way to gain pingback links, in case you didn’t know.

]]> http://rudd-o.com/archives/2007/01/29/have-a-blog-or-a-web-site-you-better-not-do-these-things/feed/ http://rudd-o.com/archives/2007/01/29/cocomment-awesome/ http://rudd-o.com/archives/2007/01/29/cocomment-awesome/#comments Mon, 29 Jan 2007 12:28:33 +0000 Rudd-O http://rudd-o.com/archives/2007/01/29/cocomment-awesome/ Do you comment on blogs? If you do, you’ll love CoComment.

Imagine a conversation. A distributed one. Someone posts in his blog. You reply in the comments box of that blog. A couple of people respond to your comment: some in the same page, and some directly in their blogs (seamlessly tied into the original page through pingbacks).

How do you keep track of whoever responded to you afterwards?

If the answer to that question is by checking the Web site I commented on every so often, smack yourself in the head.

CoComment promises to do away with that. It’s a new Web service that keeps track of the conversations you’ve engaged in blogs and news sites.

How does it work? It’s practically like magic. On CoComment-enabled Web sites and blogs, a small, unobtrusive CoComment status bar attaches to the comment form on the Web page. Simply comment there, and CoComment will track that conversation. You just log in to CoComment to see a nimble, expandable, AJAX-powered overview of your conversations:

You can clearly see the conversations you’re currently involved into. These boxes expand as you click on them.

CoComment also works as a plugin in your browser. If you have it installed, you can automatically track all of your conversations, even if the Web site doesn’t support CoComment.

Evidently, social features are featured throughout the site. Just like last.fm’s neighbour functionality, you automatically get commenting neighbors. You can peek on others’ conversations, be them heated or cozy. You can easily get hypnotized by the service.

Give it a spin. Registration’s free, and the service is a real time saver. And, of course, it’s ideal for highly effective trolling.