Rubénerd!

I love the Links text web browser and have been using it on FreeBSD, Linux and OS X shells, terminals and whatnot for years but I've never once felt the need to customise any builds because it Just Works® so gosh darn well. Checking out the variants (-v) for the Links port in MacPorts on a whim I noticed something interesting:

links has the variants:
   universal: Build for multiple architectures
   gcs: Grilled cheese sandwich headers
   x11: Include X11 interface

Aside from the one obviously fabricated option (universal), the thing that caught my eye was X11. Being a curses application (I think) it didn't strike me as intuitively obvious how an X11 interface would work, but it piqued my interest and it was a Saturday night so anything goes!

Entering links (then cursing, entering rehash and entering links again, one downside to tcsh!) I got the bog standard curses links interface I was used to, but consulting the man page there is a flag for graphical mode:

-g
Run Links in graphics mode. If not given, Links will run in text mode. Running in graphics mode means that Links will probe all compiled-in graphics devices and run on the first found. If none found, links will not run in text mode. This option works only if --enable-graphics was given to ./configure.

-no-g
Run in text mode (overrides previous -g).

And it works!

And it works! I just said that. Of course if you'd been to their home page or Wikipedia recently you'd know this, but as I said at the beginning I'd never felt the need to.

What's really amazing is Links 2.0 with it's new graphics stack can (depending on the system) even display graphics on terminals without X! The layout of pages is a bit iffy, but I've got to admit that's gosh darn impressive.

I'll be sticking to using links in it's capacity as a lightning fast, easy to use text based browser, but it's been a fun experience, especially with this half pint glass of Kilkenny poured from one of those cans with the widgets. As I say, I have wild Saturday nights.

---> Installing links @2.2_2+x11+gcs
---> Activating links @2.2_2+x11+gcs
---> Cleaning links
---> Removing build directory for links

Why not Lynx or eLinks?

Because links is a delicious pun, having one big cat on my Mac is enough, and elinks imposes its own colour scheme over my carefully chosen Terminal colours of which I'm rather partial.

Perhaps my internet connection has been a bit spotty, but building the latest version of Ruby 1.9 from MacPorts has been failing on me with a checksum error all afternoon.

--->  Verifying checksum(s) for ruby19
--->  Checksumming ruby-1.9.1-p376.tar.bz2
Error: Checksum (md5) mismatch for ruby-1.9.1-p376.tar.bz2

Portfile checksum: \
ruby-1.9.1-p376.tar.bz2 md5 e019ae9c643c5efe91be49e29781fb94
Distfile checksum: \
ruby-1.9.1-p376.tar.bz2 md5 3e4ea40c2639880bfe5355c17cf91363

The correct checksum line may be:
checksums \
md5 3e4ea40c2639880bfe5355c17cf91363 \
sha1 5178cb0e1007ee839316206ee3aaeed49059cf0d \
rmd160 191e2be8c7817f9efab9f72ebb692ca33375d14a

Error: Target org.macports.checksum returned: \
Unable to verify file checksums

Might need to download the file manually, or if worst comes to worst build it manually. Package managers spoil me :).

In other news, as you can see from the screenshot above I haven't been able to access Matz's blog either, though Guido van Rossum's comes up just fine. I'm starting to think there's a Ruby conspiracy going on.

Update!

Well there's the problem Sherlock! Despite improvements in efficiency with the Ruby 1.9 stream, I doubt they've managed to fit the entire language runtime in 12 kilobytes ;).

There are plenty of more thorough lists online, but I thought I'd keep my own too. So far I've been using this software without problems:

• Adobe Air 1.5.2
• Simone's Gimp 2.6.7
• iMovie HD 6 from iLife 06
• MacPorts 1.8.0 Snow Leopard release (guess that goes without saying!)
• Mozilla Firefox 3.0.13
• Mozilla Firefox 3.5.2
• OpenOffice.org 3.1.1
• TextMate 1.5.8
• TweetDeck 0.26.6

Software I've been having problems with:

• Skype 2.8.0.659 works as long as you do not thin the universal binary with ditto as I described in December 2007.

• QuickTime 10 with Perian currently doesn't support the MKV media container because of a registration incompatibility problem.

• The Intel build of VLC 1.0 works, but for some reason takes upwards of 30 seconds on my machine to load and start playing MKV files. This wasn't an issue on regular Leopard on the same machine.

• XQuartz 2.4.0 returns an error saying "This update is designed for OSX Leopard Only.".

I've been able to compile the following ports from MacPorts without problems:

• lame 3.98.2_1
• ncurses 5.7_0
• ncursesw 5.7_0

I was having trouble compiling Gnumeric from MacPorts and Pan this evening. Turns out gtk2 was failing to build because of a problem with the tiff port.

root# port -v install gtk2
–––> Extracting tiff
On Mac OS X 10.5, tiff 3.8.2 requires Xcode 3.1 or later but you have Xcode 3.0.
Error: Target org.macports.extract returned: incompatible Xcode version
Warning: the following items did not execute (for tiff): org.macports.activate org.macports.extract org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install
[...]
Error: Status 1 encountered during processing.

If you're being given this error message too, as the error suggests you need to grab yourself a newer version of Xcode. Since I only just reinstalled Mac OS X Leopard on my MacBook Pro I installed the Xcode that came on the 10.5.6 DVD which as the error above shows is only Xcode 3.0.

What's curious is the Apple Software Update has never told me about a newer Xcode. Is it because you need to login as a ADC member first perhaps?

Anyway, lesson learned: make sure you have the latest Xcode before attempting to compile software or built ports on your Mac! It's not that it's darn obvious you should, but that we need reminding sometimes :).

As I said previously, I tend to wipe and reinstall the operating systems on my computers at least once a year, then I go about reinstalling software. Here's a cloud showing my current Mac software, current as of this post. I would discuss software from the future, but that would be in violation of the Temporal Prime Directive.

Cyberduck

Slick little (S)FTP client

Gimp

Photoshop replacement for editing pictures

Inkscape

Vector graphics editor

iStat Pro

For monitoring temperature, memory etc from the Dashboard

MacFuse

For easily mounting tons of file systems, and for TrueCrypt

MacPorts

OS X free software package manager

MacVim

Beautiful Aqua-native Gvim text editor

Mozilla Firefox

With these mostly-security extensions because I'm paranoid

Perian

QuickTime codec library, so Finder can create video thumbnails

TrueCrypt

Encrypted volume creator and manager

TweetDeck

Full screen Twitter client with interchangable columns

VLC (Intel)

For actually playing most of my video!

From MacPorts I build copies of:

ImageMagick

Easy command line image converting

LAME

For encoding podcasts

Midnight Commander

Still my primary file manager!

Music on Console

For listening to online radio, smaller than iTunes

Python 2.6

A kind of snake, also a British comedy troupe

It still doesn't work... it still doesn't work... it still doesn't work...

I've heard it said by many programmers I respect that you spend 10% of your time coding, 90% debugging. I would argue it's closer to 5% coding, 95% debugging, but the point stands. It also stands true that the more tired you get, the less obvious basic mistakes appear to be.

Case in point, this evening I decided to update my MacPorts collection on my iBook and install Gnumeric (I've so far only switched to pkgsrc on my MacBook Pro). For the life of me I couldn't figure out why this single line wasn't working:

% sudo port -v selfupdate && port -v install gnumeric

If you've worked in UNIX for more than 5 seconds you'd be able to tell me in an instant what I did wrong, but for the last 10 minutes I just couldn't figure it out. It was driving me crazy! When I did I promptly hit my forehead on the table causing a glass of cold water I had placed on it to jiggle its way off the table and with an almighty crash land in a million pieces on the floor.

ASIDE: That glass thing didn't really happen, but doesn't it sound like something that could?

Lesson learned, don't do any programming, scripting or shell work when you're half asleep or not feeling well. You just don't get much done!

As for the mistake, I only used one sudo command. Using && doesn't carry over the higher user privileges! Simple, obvious, glaring mistake that was staring me in the face the entire time and I couldn't see it.

Mikuru tried to compress my files too using her superpower energy. Rzip still worked better.

After reading an old post on Jeremy Zawodny's weblog and installing it myself, I have to say Rzip is my new favourite compression algorithm!

From the developer's website:

rzip is a compression program, similar in functionality to gzip or bzip2, but able to take advantage long distance redundancies in files, which can sometimes allow rzip to produce much better compression ratios than other programs. The original idea behind rzip is described in my PhD thesis.

For a bit of real world testing, I decided to try compressing the www folder in my home directory on my MacBook Pro. I thought this folder would be a useful test because it's relatively large and contains a few large files mixed in with hundreds of smaller ones. From what I understand of compression algorithms, they each tend to favour compressing certain types of files and in certain quantities so I figured this way it would show a more balanced result.

The original folder size was 436.0 MiB with 312 files. The Tape Archive is the control because it's needed for all but ZIP to archive the files before they can be compressed. For convenience the names also redirect to their associated Wikipedia pages.

What's curious is that Gzip was more efficient than Bzip2, in almost every other circumstance I've come across the reverse was true. I'm not sure how much that affected the results of the other formats. The final result is clear though, Rzip was able to squash like nobody else!

Image © Jan Mehlich, from Wikimedia Commons. As with the image above, I thought it was mildly amusing given the subject matter. I hate dry weblog posts without pictures you see.

From what I can make out reading the developer's website; and with help from dadaist in real-time on Twitter; is that Rzip isn't an entirely new compression algorithm per-se, it essentially just uses larger chunks of data over much longer distances, and then uses existing algorithms to process it all.

I theorise from reading up on this that only in the last decade have computers had enough processing power, and more importantly memory, to be able to pull this off. 900MiB of looking space is great for compression, but can suck up all your resources pretty fast if you don't have much. This is why we haven't seen this level of compression until recently.

In any case, I know what I'll be using to compress all my large files and folders with now :).

Everyone knows that vi and vim are better than emacs right? Well personally I prefer nano even over vi. It was the first text editor I ever learned (okay it was actually pico, the editor it was cloned from) on UNIX and even now I use it for almost everything: Ruby, Perl, HTML, XML, KitchenSink... even these weblog posts. It's a small world, so why not use a small editor? Hey, that's catchy.

The problem though if you install Nano from MacPorts is that it's not enabled with a number of what I would consider critical features. Aside from syntax highlighting support probably the most noticeable of which is the lack of UTF-8 support which means it spits out a series of question marks whenever you're editing files with katakana, kanji and kitchen-sink in it for example. Bummer.

A cursory glance over at the DarwinPorts website shows that in fact it's possible to enable UTF-8:

Variant: utf8 {
configure.args-append --enable-utf8
configure.args-delete --disable-utf8
depends_lib-append port:ncursesw
depends_lib-delete port:ncurses
}

The key is simply to add +utf8 when you initially build the port, along with any other conditions you think are spiffy:

sudo port -v install nano +utf8 +color +no_wrap

There's really little point using MacPorts if you don't keep it up to date. After all, that's the whole point of a package management system, right? ^^

To keep MacPorts / DarwinPorts up to date, you just need to issue the selfupdate command. The problem I always saw with it though was it seemed as if it wasn't doing anything:

$ sudo port -v selfupdate
Downloaded MacPorts base version 1.442
The MacPorts installation is not outdated and so was not updated
selfupdate done!

In fact what I later discovered was that it was doing something. The selfupdate command actually does two tasks: it issues the sync command to update your ports tree (vis a vis portsnap on FreeBSD) and then updates the framework itself. The not updated message is referring to is the framework, it still updated your ports.