Archive for December, 2007

Instability does an angry man make…

I have a new MacBook. It’s less than a month old, and came with Leopard.

My father bought be a Mighty Mouse (wireless) to go with it.

Today, I’m getting angry to the point where I thought about the idea of taking the whole lot back for a full refund. You see, this is the most unstable system I have used since Windows 98, and that’s no exaggeration.

Leopard, is a piece of shit. Ok, that’s possibly a little harsh, but…

  • I have had two full kernel panics since I bought this laptop (i.e. in the first month)
  • I have had numerous application crashes, mostly with Mail.app and hardware interfaces (bluetooth + USB), but actually, half of the apps currently on my Dock have crashed on me.
  • I have not installed any kernel level software (which is what causes other OSes to BSOD/panic)
  • The mighty mouse crashed the bluetooth system, twice, and then stopped working completely.
  • The USB system has frozen (complete OS deadlock) the laptop, three times, coming out of, or going into standby.
  • Spaces is buggy as hell, many of the native apps (including iTunes and Mail.app) don’t Apple+Tab correctly if they’re “Zoomed”. That’s really poor, and suggests a serious lack in real user testing before launch.
  • The PGDN + PGUP and HOME + END key bindings (on the MacBook) are so inconsistent it makes me angry about once every 5 minutes.
  • The RSS screensaver prevents you from logging in when you come out of standby, and it can’t release control of the screen back to the login prompt (this is pathetic, and likely a security hole) (and it makes the screensaver completely useless for laptop users, really)
  • This is a set-top-box - There is no damned excuse for instability. At least EVERY OTHER operating system ON THE PLANET supports a great deal of hardware, and in reality, receives it’s instability through THIRD PARTY SOFTWARE. First party instability in a commercial “production ready” kernel, is pathetic.
  • “The Cult” lies about stability issues, and on becoming a mac owner, they start to open up to the truth, that this system is in fact NOT stable - For that, they are due a “Fuck you, liars” from those of us don’t follow “the religion”.

So, you arses, please sort this crap out. I’ve sent you all the bug reports for these crashes, it’s about time you live up to the lies you (and / or your users) have been spreading. And if you wouldn’t mind sorting out the security whilst you’re at it, that would be just dandy (there are plenty of exploits documented (and in my normal usage, I have found more - I’ve been too busy to do an audit, but this OS would fail))

I won’t be returning this stuff yet, at the moment, the stability issues can be worked around (by not using the respective features and devices), and the only reason I’m still here is for the performance of Ruby, Textmate and Terminal.app, and the reasonable quality of the hardware itself - At least that’s making me JUST happy enough to combat my current anger, after a rant. If it wasn’t for these things, I’d be screaming bloody murder right now.

A Quick Gem (1.0.1) Faq - Gem::Runner Name Error

There’s a “problem” with the current version of rubygems that’s causing somewhat of a FAQ, that as far as I can see, Google doesn’t index too well, so this post is for you, those people that find yourselves here via Google, at least until the problem is at least well known or the procedures change.

The relevant entry in the change log is this one:

Executable stubs can now be installed to match ruby’s name, so if ruby is installed as ‘ruby18’, foo_exec will be installed as ‘foo_exec18’

This can be found on Eric Hodels blog.

The current version of gems (1.0.1) installs the gem command as gem18 if your ruby is installed as ruby18.

For now, the fact that the upgrade via “gem update –system” is not doing anything with the old ‘gem’ command, is causing quite a few people to come into the ruby channel complaining about the following error:

gem:23: uninitialized constant Gem::Gem Runner (NameError)

You want to remove your old gem command (found at `which gem`) (i.e. rm `which gem`) and then link or copy the new gem command (likely gem18) to gem.

Anyway, this post is only this long so that it gains a high enough relevance for google to bother indexing it, with the goal of helping out a few of you folks until one of the many possible more permanent resolutions comes about.

Overall, the 1.0.1 release is a great release, seeing a lot of enhancements in rubygems that personally, I’m really happy to see. Thanks for all the hard work Eric, Chad and everyone else involved.

ttfn!

Update:

As it seems to have not been clear to some, on Debian, it may well (n.b. may well != will) be gem1.8, as your ruby may be ruby1.8.

If you need to know which it is, do the following:

ls -la `which ruby`

And this should tell you which ruby file you’re “ruby” is linked to, and where that link is located.