tech.fromagique

In case you've tried out the new Ubuntu 11.10 and have started to go mad trying to turn off the stupid login sound, here's your solution:  editing a text file as root.  Yeah, those UI geniuses at Ubuntu have deemed that the unwashed masses do not need to mute their wonderful fanfare, and have therefore removed the GUI option entirely.  (Their reprehensible taste in color is another question entirely, which I shall not rant about in this post.)

Anyway, what you need to do is to edit /usr/share/gnome/autostart/libcanberra-login-sound.desktop as root, and change the line that reads:

NoDisplay=true

to

NoDisplay=false

This is usually the last line in the file.  Now, go to the Startup Applications section of the System Settings, and you should see an entry in the list for "Gnome login sound".  Uncheck the box, or better still, simply remove the item entirely.  Wasn't that easy? Grr....

I suppose you might be able to just remove the file and not bother editing it, but I don't know if some other part of the overprotective Gnome desktop regime might throw a fit if you do something so heinous as that.

Or you could just use Debian, where all the options are available for you to choose for yourself.

This is one of those annoying things that come along with the conflict between a friendly GUI interface and a handy, powerful command line interface.  People from the GUI world tend to use filenames with spaces in them, because, well, they look better.  And that's fine.  But when one tries to use command line tools that assume that lists of filenames are delimited by spaces, one has trouble brewing.  Fortunately the fix is usually pretty easy, if not immediately obvious.  I found a few different solutions at Greg Miller's blog, and I present here his #3 solution for reference.

Basically what it does is to feed the output of a find command into a while loop which reads the filenames line by line.  This gets around the spaces problem by properly breaking up the output into lines:

$ find /home/peter -name '*.jpg' | while read filename
> do mv "$filename" /home/peter/Pictures
> done

This finds all the JPEG files anywhere in my home directory (even hidden in folders somewhere) and moves them all into my Pictures folder. Note that any files with duplicated names will cause all but one of the duplicates to be lost (overwritten, actually), depending on the order in which find does its search and the order the filenames sort in. So be careful with this if you do anything that could be lossy with it.

I just found a cool new service provider: PiCloud.  They allow you to run Python code on their EC2 clusters with no server overhead.  If that sounds interesting, take a look at their site.  That is all.

I've been fooling around with the idea of a base-36 calendar for a while.  I know, it's really geeky.  Oh well.  It's based on the Julian Day Number, which basically gives us a nice positive integer for any date we're probably ever going to want to represent, and it does it in a short, compact text format.

The Julian Day Number is (since you probably didn't read the article I painstakingly linked above) the number of days since an arbitrary date very long ago.  January 1, 4713 BC, to be exact.  Now, you might think that this is going to produce a very large number of days, and this number will be unwieldy to work with.  Yes, you're right.  In base 10, it does tend to be unwieldy, just as (for example) 2011 is unwieldy in base 2, being represented as 11111011011.  But in base 36, 2011 becomes 1JV, and 2455834 (being the Julian day number for today, 9/29/2011) becomes 1GMXM, which is pretty easy to handle.

It becomes even easier when you consider that the base-36 "century" 1G000 began on 5/15/1930, and will last until 1GZZZ on 2/7/2058.  In other words, for a lot of people, one can in informal usage just drop the 1G and use the three characters such as MXM for today.  Or, if you're more conservative, just drop the initial 1, since the base 36 date 10000 was on July 13, 114 BC and 20000 will be February 28, 4485 AD.  By then all of the Twinkies will have almost reached their expiration dates, so it won't be worth the effort of keeping track of time anyway.

So here's some sample code in Python to show how to do this.  Basically you give the tojdn function your year, month, and day (in that order, unless you use keyword parameters) and it gives you back a Julian day number as an integer.  The fromjdn function does the reverse.  The base36encode and base36decode functions do pretty much what you would expect.  So all you have to do to get a base 36 date is something like: base36encode(tojdn((2011,9,29)) and you'll get back '1GMXM'.

Enjoy.  The JDN calculations and base 36 conversion code were lifted from a couple different places.  I doubt very much they're patented, God help us.

import datetime

def base36encode(number, alphabet='0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'):
    """Convert positive integer to a base36 string."""
    if not isinstance(number, (int, long)):
        raise TypeError('number must be an integer')
 
    # Special case for zero
    if number == 0:
        return alphabet[0]
 
    base36 = ''
 
    sign = ''
    if number < 0:
        sign = '-'
        number = - number
 
    while number != 0:
        number, i = divmod(number, len(alphabet))
        base36 = alphabet[i] + base36
 
    return sign + base36
 
def base36decode(number):
    return int(number, 36)
    
def tojdn(year, month, day):
    """Returns the Julian day number of a date."""
    a = (14 - month)//12
    y = year + 4800 - a
    m = month + 12*a - 3
    return day + ((153*m + 2)//5) + 365*y + y//4 - y//100 + y//400 - 32045

def fromjdn(thejdn):
    """Returns a date corresponding to the given Julian day number."""
    if not isinstance(thejdn, int):
        raise TypeError, "%s is not an integer." % str(thejdn)

    a = thejdn + 32044
    b = (4*a + 3)//146097
    c = a - (146097*b)//4
    d = (4*c + 3)//1461
    e = c - (1461*d)//4
    m = (5*e + 2)//153

    year=(100*b + d - 4800 + m/10)
    month=(m + 3 - 12*(m//10))
    day=(e + 1 - (153*m + 2)//5)
    return (year, month, day)        

 
if __name__ == '__main__':
    print base36encode(2455834)
    print base36decode('1GMXM')
    print fromjdn(base36decode('1GMXM'))
    print base36encode(tojdn(2455834))

I'm currently attempting to write iOS applications, and one thing that I've noticed is that people tend to not upgrade their iOS devices (iPhone, iPod Touch, iPad) to the latest versions of iOS. So there's an awful lot of devices out there still running versions like 3.1.3 (the last iPhone version before the jump to 4.x).

I got into the iDevice universe with an iPhone 3G back in 2008, and have since upgraded to an iPhone 4. I have the old phone still hanging around, and so I thought it would be good to use as a testing device, to make sure my apps work for people with similarly old devices.

It had been upgraded to iOS 4.2.1, but I wanted to see if I could roll it back to 3.1.3 for testing. I was pretty easily able to find a copy of the 3.1.3 software image (.ipsw) for my device (and every other device) at hackint0sh.org. And so I proceeded to reflash the iPhone 3G with that image. Unfortunately Xcode hit a speed bump at the very end, declaring that the cellular baseband could not be rolled back. And the phone just sat there, with its progress bar filled up, probably just waiting for Xcode to give it the OK to reboot once it had been cleared as legal or something.

So I looked around, and there's this tool called RecBoot, which is specifically designed to get around this problem. All one needs to do is uncompress it, make sure Xcode and iTunes are shut down and the device is plugged in, showing the "plug me into iTunes please, because I'm lost in the mall and can't find my mommy" screen that indicates it's hanging out in DFU mode.

At this point, fire up RecBoot and click the button that says "Exit recovery mode". RecBoot will yell at the device to reboot, and it will. It will then happily start up with the software you just flashed to it. Very nice.

Now, I don't know if the device will function as an actual phone, since the cellular baseband bits are much later than the old OS expects, but in my case, it doesn't matter because this device isn't provisioned for cellular phone/data service anyway (and won't be, since I already have a newer device handling that end of things.) But if you are experimenting with a device that you actually want to use as a phone, I have no assurances that it will work, so consider yourself warned.

Enjoy. That is all.

If you've ever had to use certain Debian-based Linux distributions within a Virtualbox instance, you are probably familiar with the maddeningly slow and tiny VGA framebuffer console that they inflict upon you. (The 10.04 LTS release of Ubuntu is the specific perpetrator that prompted this post.)

Well, here's the solution for you. This will make your Virtualbox instance much faster and give you control over its console resolution.

Step 1: Blacklist the VGA16 framebuffer

In the file /etc/modprobe.d/blacklist-framebuffer.conf, add a line that reads blacklist vga16fb

Also, comment out the line that reads blacklist vesafb. In other words, put a "#" (hashmark, pound sign, octothorpe, whatever you want to call it) at the beginning of that line.

Step 2: Put your desired resolution in grub's configuration file

In the file /etc/default/grub, there should be a line that by default reads GRUB_GFXMODE=640x480. Change that 640x480 to whatever resolution floats your boat and you know works on your monitor. (I like 1024x768 personally.) I would also suggest removing the word "quiet" from the GRUB_CMDLINE_LINUX_DEFAULT line (just leave the quotes empty) but that's up to you. I like to see the messages scrolling by.

Step 3: Hack the grub scripts to make it set the resolution you want

In the file /etc/grub.d/00_header, search for the line which reads set gfxmode=${GRUB_GFXMODE}. Add a line below this which reads set gfxpayload=keep.

Step 4: Run update-grub

Run update-grub so that everything gets updated and grub actually reads your changes at the next boot.

You're done.

You should now have a fast, high-resolution console. Congratulations.

If you have some spare memory, and you have a disk-bound task you need to speed up on OS X, perhaps you should try a RAM disk.  These were an indispensable tool back in the days of floppy disks, since the floppies were so slow.  But they still work pretty nicely.  Here's the command line necessary (for 10.5+):

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://<size in 512-byte sectors>`

Note carefully those little backticks just before "hdiutil" and after the number of sectors...

I found this handy tip here: http://osxdaily.com/2007/03/23/create-a-ram-disk-in-mac-os-x/

To get rid of the volume and reclaim the RAM, just drop the volume like any other removable disk or mounted disk image, in the Finder.

If you’ve ever wondered how to work with times and dates in Python that also include timezones and possibly DST, you’ve probably run screaming at all the complexity.  Since the domain of timezones and DST are not governed by any rational science, but rather by political intrigue and posturing, it will always be so. But fortunately there are people that kindly maintain the pytz package, which soothes a lot of this pain. Here is a short script which demonstrates how to get a local time in a given zone, from a given UTC timestamp.

(Hint:  to avoid a lot of pain, store all your datetimes in UTC, no matter what timezone they belong in.)

Update: I simplified the code considerably—I was trying to be too clever the first time.

zones.py

from datetime import datetime
import pytz
import time

zones = [
    'UTC',
    'America/Los_Angeles',
    'America/New_York',
    'Pacific/Auckland'
]

ZONE_UTC = pytz.timezone('UTC')
DATE_FMT = '%Y-%m-%d %H:%M:%S %Z%z'


timestamp = time.time()
UTCnaiveDatetime = datetime.utcfromtimestamp(timestamp)
UTCsmartDatetime = ZONE_UTC.localize(UTCnaiveDatetime)
for x in zones:
    localzone = pytz.timezone(x)
    localSmartDatetime = localzone.normalize(UTCsmartDatetime.astimezone(localzone))
    print 'Location: %s, Local time: %s' % (x, localSmartDatetime.strftime(DATE_FMT))

I know, this is yet another obscure corner case, but if you run into this problem, you'll be truly glad to find the solution.  Here's the problem:  you are running 64-bit Linux, have a mounted volume (probably external), formatted as HFS+ (probably because you share data with OS X), which has a media file that you want to play, with the ever-talented and wonderful VLC.  But when you open the file, nothing happens.  If you copy the file to a native ext2/3/4 or fat volume, it plays just fine.  You're tearing your hair out, trying to figure out what in the world is going on.  Well, here's the answer.

I'm going to assume you're running a Debian-based Linux distribution, such as Debian itself or Ubuntu.  If you have one of those distributions that uses RPM and its tools, then you'll have to figure out the equivalent commands, which shouldn't be too hard.  I have no idea about RPM, sorry.

OK, so here's the problem summarized by someone who knows more than me: "Apparently, hfsplus has some nasty problems and isn’t actually POSIX compliant when it comes to opening directories. Due to how VLC handles “files” that it is asked to play (it accepts both directories and files as playlist arguments and VLC chooses to try to open the playlist element as a directory first, and this doesn’t fail with hfsplus the way it should in POSIX-compliant filesystems) VLC is unable to play anything that’s on an hfsplus partition."

So there needs to be a patch applied so VLC can play nicely with non-standard HFS+.  Fortunately, someone has figured this out and made a patch.  It was written for VLC 1.0.4, but it worked for me on VLC 1.0.6 (once I got by the problem that is described below).  You can download the patch from its author's site:  http://launchpadlibrarian.net/37707309/vlchfs-1.0.4.tar.gz

(If the above link fails, here's an alternate: http://postaux.fromagique.com/vlchfs-1.0.4.tar.gz)

What this patch does is make a new version of a library plugin that VLC uses to open files and directories, and this new version knows how to talk to HFS+ properly.  I'm very glad VLC uses a plugin architecture like this, because it saves us from having to recompile the whole program, which would require us to install all the development headers and libraries for all the vast array of formats that VLC supports.  And of course that would be a major pain in an inconvenient body part.

So let's get to fixing, shall we?  You need to install the development headers for VLC, which are available via a quick "apt-get install libvlc-dev" command (as root, of course, whichever way you prefer to do that.)  You also need gcc, of course, and also pkg-config, so if you don't already have it installed, grab all the right bits with "apt-get install build-essential pkg-config".

Now, unpack the vlchfs-1.0.4.tar.gz file, and descend into the resulting directory.  If you were running on a 32-bit system, all you'd have to do is a quick "make && sudo make install" and you'd be done.  But on a 64-bit system there are a few differences that make the process fail with a nasty message: "/usr/bin/ld: libaccess_directory_plugin.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC".  Ugh.

What this means is that the 64-bit system needs to have the file compiled as position-independent code (thus the "-fPIC" at the end.)  This, (to greatly simplify) enables the system to be able to relocate this code anywhere it needs to--it's not tied to any particular memory address.  So, fire up your favorite editor and look at line 10 of the Makefile.  Right before the bit that says -D__PLUGIN__, add in -fPIC.  So the line should look like this when you're done:

    sed "1i #define _(str) (str)\n#define N_(str) (str)\n#include <sys/stat.h>\n" $< | gcc -xc -c - -std=gnu99 `pkg-config  --cflags vlc-plugin` -fPIC -D__PLUGIN__  -DMODULE_STRING=\"access_directory\" -o $@


Make sure that whole awful chunk stays on one line; some editors have an annoying habit of trying to helpfully wrap long lines for you.  Save the file, and now run the "make && sudo make install" command.  Enter your password when prompted.  You should now be able to play your HFS+ hosted files.  Enjoy.

Note: when VLC gets updated via your normal package upgrade mechanism, this patch will probably get removed.  So you may have to do this again--be sure to keep the patch file around.