I think it’s really important to have a healthy indy events culture around stuff that matters. So much good comes out of them, it’d be a shame if projects like this never got off the ground.

I hope you join me in supporting him to keep doing good work that matters. Lots of people will benefit and more importantly, it shows that it’s worth taking on the risk to do projects that matter.

One More Thing Q&A Series by Anthony Agius on Pozible.

Before you know it, behold:

The collision of sugar and segments. Packets and piping. Cisco and Cupcakes.

And now, should probably get back to CCNP prep!

The biggest take away for me from the whole process was how much easier it was to focus and study once I’d booked the exam in. It was hard work, sure, but once I’d taken away the option of doing it later, or doing some other exam first perhaps, everything happened a lot quicker.

Having said all that, it was certainly my intention to start studying for the next exam straight after I did the CCNA. Obviously not having learned from experience, I have taken until pretty much right now to actually decide what that next exam should be. Should I start my CCNP? Do CCNA Security? Knock out a couple of Sun exams? All perfectly valid options, and by having options I was thinking about them, and not getting any study done. So, as of 20 minutes ago, I’ve booked in for my CCNA Security exam for late September.

Now that I’ve got my date, I know what I need to do between now and then. Looking forward to the challenge!

After seeing a few variations on “cannot”, including “can not”, “can’t” and “could not” and “couldn’t” showing up in the logs, I thought it’d be interesting to audit some of the common unix commands we use in the scripts and see what sort of words they use to describe errors. It turned out to be quite a long list.

These are all taken from Solaris 10 10/08 clients. Where relevant I’ve kept them case sensitive.

cp/mv/ln

• failed / Failed
• cannot
• could not
• unable
• not
• can’t
• Insufficient
• exceeds
• Invalid

mkdir

• Failed
• but is not
• not permitted

touch

• bad
• cannot

chown

• can’t
• unknown
• invalid
• too large

chmod

• can’t
• could not
• invalid
• required
• not permitted
• WARNING
• ERROR

ls

• can’t

ksh

• too big
• required
• couldn’t
• prohibited
• cannot
• Bad / bad
• failure
• unknown
• invalid
• is not
• not
• denied
• too many
• corrupted
• can’t
• out of range
• exceeds
• already
• restricted
• missing
• expected
• failed
• requires

The thing about most unix commands is that they’re generally not very chatty. There’s a good chance if they’re producing any sort of output at all, it’s probably an error of some description. With that in mind, it’s quite possible there’s a much more elegant way of writing the parse scripts.

In the meantime, I’m writing up the scenario that doesn’t work in the hope that it a) provides me with a blinding flash of insight, b) lets other people know it’s not just them or c) prompts someone who knows the answer to drop it in the comments. Come on, you know you want to!

The General Idea

I’ve got a machine running Solaris 10 10/08 with several user accounts. Home directories for these accounts are in /export/home/. They are being automounted in /home. I want to share the /home/username directories using  NFS. Should be simple right?

The Setup

/etc/auto_master:

/home   auto_home   -nobrowse

/etc/auto_home:

fred box1:/export/home/fred

/etc/dfs/dfstab:

share -F nfs /home/fred

After confirming that NFS is running and online (svcs -a | grep nfs), we activate the shares:

# shareall
share_nfs: /home/fred: Operation not applicable

Sharing /export/home/fred works just fine.

The official Sun docs suggest that the “Operation not applicable” error means I should contact my vendor for an upgrade. Right. I’m fairly sure this was working in Solaris 8, but need to double check.

This means that a regular user can’t lock their workstation screen or have the screensaver come on. Typically, an error message along the lines of “XScreenSaver failed to load” pops up when the user logs in.

Pretty annoying all round.
Happily, it’s an easy fix. Edit your .profile and add /usr/openwin/bin to your $PATH variable.

Log out. When you log back in, you should see a “Lock Screen” option on your menu and screensavers should kick in.

I ordered it last Wednesday morning. I think it was the size of it, and wanting to buy something so that Mactalk got a cut that won me over so quickly. This seemed like the perfect opportunity.

iPod Shuffle TNT Package ready to open

Obviously it came well packaged…

iPod Shuffle in box

The only difference to the standard retail packaging was a bit of white plastic wrapped around the outside of the plastic box.

You could pretty much buy these in vending machines now...

iPod Shuffle in packaging, ready to crack open

Headphone plug and 3 way switch

iPod Shuffle from the back.

I got mine laser engraved. Figured if I was buying online, I may as well take advantage of the free engraving service. I won’t be getting a case for it (really not that much to protect!), so the engraving will be pretty much the only unique identifier on it. I suspect lots of people will end up with these, so easier to have it personalised. The engraving is top quality too. There is about 1cm of horizontal space to engrave on, and they’ve fitted 12 perfectly legible characters on one line. Apple really have a good machine for doing this!

iPod Shuffle sync cable

The USB sync cable is perfectly compact, just like the shuffle. I plug it into the back of my desktop keyboard and – kind of obviously – it seems made for it. It’s about 7-8cm long, so it won’t be a hassle to pack if you want to use your shuffle as removable storage.

It really is tiny.

I’ll reiterate what pretty much everyone is saying. This iPod is TINY. A miniturised Nano. About the size of a recent model USB drive, the build quality is amazing for something this small. It’s machined. Refined. Engineered. Metallic. It’s got that all metal feel that I love about my MacBook Pro. It’s all class.

The whole kit.

All of the playback controls are on the headphones. The controls work well, the voiceover thing is pretty cool. Much better than I’d expected based on the promo video on the Apple site. The sound quality is decent enough for what I plan on using this for (commuting & exercise). When I want big sound, I’ll plug my big headphones into the laptop. So, I’m happy. It’ll be interesting to see if a remote cable accessory is on the market soon to allow people who do what to use their own headphones to do so if they wish.

All in all, I’m really happy with it. I wouldn’t want it as my only iPod, but for having on hand for when you just want to listen to something and don’t hugely care what, it is perfect. Well done Apple!

Only problem is there are some rouge line ending sneeking to the database. I’m developing on Solaris 10 where the default line ending is a line feed character (LF, 0x0A). For reasons I don’t understand, Rails and/or SQLite is using an LF CR combination on all of the code that was entered through a text field and saved to the database. When it gets spat back out into the shell script text file and I try to execute it, Korn chokes. Korn expects LF line endings in text files and that’s all there is to it.

After poking around to uncover where the line ending might be being set, I decided it’d be easier to tweak the three places in the Ruby script where code was being outputted to the text file and modify the line ending there.

finalscript << assertion.snippet.code.delete("\x0D") << "\n"

Essentially we’re deleting all of the CR characters from the chunk of code, leaving just the LF which keeps Korn happy.

I’m not totally happy with it as a solution, but it works, it was fast and cheap and solves something that probably doesn’t affect too many people.

I don’t know what kind of dark magic Apple have used to make the iPhone work, but it only responds to fingers (or at least, nothing else I’ve tried tapping it with – pens, pencils, erasers – works).

It later occured to me that my hands are often quite dry. No skin crackingly dry, but they could probably do with moisturising more often than I do.  So I began a quick experiment.

Every time my screen becomes non responsive, I go moisten my hands under a tap. In a pinch, I lick my finger (yeh gross, whatever. This is *science*.)

Seems to do the trick pretty much every time.

Guess it’s off to buy some moisturiser then – for the sake of my hands and my iPhone!

So, how to setup the new box – knowing the end goal is to have a solid development workstation I can use for Ruby, Rails and Solaris development as well as general testing and hacking around… These are my notes. While the end result does work, it took a fair bit of effort getting there. It was a learning experience and ultimately I’m glad of it.

Solaris 10 10/08 Install

First up, the base Solaris install. I chose the “Developer” cluster of packages, it’s pretty much everything except drivers and OEM stuff for hardware I don’t have installed. I realised a bit later that if I wanted to use ZFS on my root disk (which I kind of did), I would have to restart the install in text mode. I didn’t do that this time, so no ZFS root disk for me. Oh well.

Once you’ve got Solaris installed and booting, log in as root. Add

/usr/sfw/bin

and

/usr/ccs/bin

to your PATH.

Fix some library incompatibilities before they become problems…

I learned this the roundabout hard way. In my notebook, this bit is right at the end, but I thought I’d save you the hassle of several extra recompile/test cycles by including it up here.

It seems the default libiconv library in Solaris doesn’t do as much as Ruby and Rails expects it to, so when you go to create a new rails app, ActiveRecord throws a tanty and gives you no joy at all. Basically you see an error along the lines of (Iconv::InvalidEncoding).

Happily, it’s fairly straightforward to fix. We just need to install a copy of the GNU libiconv library.

Grab a copy from sunfreeware.com. I got version 1.11. Extract the archive then change in to the created directory.

./configure --prefix=/usr
make
make install

If you do this at this stage of the install, chances are good that you’ll completely avoid the problems I ran into. This is generally a good thing, but it takes away visability for you of what the problem actually looked like. If you skip this step, get to the end of installing everything and go to create your new rails app and get the Iconv error from ActiveRecord, you simply need to come back to this step, install the GNU libiconv library then recompile & reinstall ruby. You won’t need to reinstall RubyGems or Rails, they’ll use the new Ruby which is using the new libiconv and all will be right in the world.

Compile & Install Ruby

Download and unpack the lastest stable Ruby source code. I went with 1.8.7. Then it’s the usual configure, make, make install routine – watch the –prefix and –exec-prefix options. By default they go to /usr/local. On Solaris it seems to work better as /usr

./configure --enable-pthread --prefix=/usr --exec-prefix=/usr
make
make install

All of the Ruby executables (ruby, irb, etc) should end up in /usr/bin.

Setup RubyGems

Download and extract the lastest RubyGems package. I got 1.3.1. Change into the directory just created and run:

ruby setup.rb

Install Rails

Possibly the easiest part of the whole process:

gem install rails

The particular machine I was installing on sits behind a HTTP proxy, so I needed to add a HTTP_PROXY variable to my environment. Once I’d done that, gem had no problems reaching the outside world.

Did it work!?

mkdir railswork
cd railswork
rails demosite
cd demosite
script/server

You should then be able to access http://localhost:3000/ in your browser and see a Rails “It worked” page. Woohoo! If you don’t, I wish you good luck on your continuing Rails on Solaris education