Archive for October, 2007

Leopard

Wednesday, October 31st, 2007

My leopard upgrade experience was extremely positive. Thankfully, I didn’t experience any of the difficulties some have had – this account by the veritable Wincent Colaiuta filled me with dread, but thankfully none of his woes were visited upon me. I was cautious about upgrading, and waited a couple of days so that early bugs could be found by early adopters, I’m glad that I did, since I did have APE installed (although by what, I have no idea) and I made sure to run disk utility’s repair function on the install disk before attempting the upgrade.

That said, there are a few observations I’ve made:

Mail 3.0

I decided to do a clean install of Mail, since most of my “archive” mail is still sitting on a machine in Japan, and all messages in the local instance of Mail were kept on the server. I also decided to use this opportunity to switch to IMAP exclusively.

The IMAP imports went well, though took an awfully long time, during which Mail.app refused to quit.

I imported my RSS bookmarks from Safari, since I’d prefer to not be distracted by them during web usage. The import went well, though updates of the feeds seem unreliable and it sometimes takes a couple of restarts to “force” an update. Another unexpected behaviour of RSS in Mail.app is its desire to automatically download all attachments in an RSS feed – leading to quite a surprise as it proceeded to start downloading every single railscast from the entire railscast feed, well over a gig of movies, and refused to quit while in process. I had to force quit mail and delete the Railscast archive to avoid the massive, and slow, download.

MacPorts and custom compiled software

I switched to MacPorts some time ago, reducing the need to custom compile software and, more importantly, eliminating (in theory) the dependency hell that custom compilations can sometimes launch you into. I decided to take the opportunity to nuke /opt and reinstall from scratch – the old repository was, well, old, and I was getting the occasional weird error from the still very much in development macports software.

But now – I have a problem. Apple’s taken the laudable step of upgrading the version of ruby installed with the OS. They’ve got a new build of subversion in there too, and even included rubygems – and Rails! What to do? For example, there are two good ways to install MySQL on this system – port install mysql-server, or download and install the binary. Because I wanted to go with Apple’s pre-install of ruby and rubygems/rails, I thought it maybe better if I installed the binary version. But then gem install mysql, for the native ruby mysql bindings, bombs out. Great, dependencies – exact what I’m trying to avoid, and so early in the customisation process, too!

Anyway, for now I am using the Apple installs, mindful of the possible need in the future to just go ahead and port install duplicates over the top of the bundled software. Furthermore, Ruby 1.9 is supposedly around the corner. What will be the recommended upgrade path then?

I can’t really work out why Apple isn’t going with MacPorts officially here. The project is amateur, but it’s certainly “blessed” by Apple – so why not build it into the OS? There are now 3 ways to go installing a lot of open source software on MacOSX – use the included but rapidly outdating and dependency-locked installs, install manually from source, or use the supposedly official MacPorts package management system. All three leave software in different places. Which one gets used will come down to your $PATH. It’s not exactly elegant, and seems like a recipe for hard-to-troubleshoot problems in the future.

That said, I got everything up and running with no real problems, although postgresql refuses to build in the current Port incarnation.

Interface

A lot of what I think about the interface has already been written in the unbelievably long ArsTechnica review of Leopard, but I’ll save you the 2 hours reading that and list my general thoughts:

  • I don’t like the unpredictable, uncustomisable, ugly icons of the new “collection” folders in the dock.
  • I don’t like the loss of the “drill down” folder browsing mode
  • The new dock wastes space and is gratuitous in its eye candy – eye candy which is, if anything, functionally inferior to the preview incarnation
  • I don’t mind the new translucent menubar

Favourite App updates

Safari, Terminal and Mail are hugely improved, and I think this will make most of the positive difference in my daily work with the OS. I like Spaces, too. Spotlight is also much, much better – basically, Spotlight in Leopard is what it should have been all along, which allows me to jettison QuickSilver.

to be continued ..

Tags: , ,
Posted in mac | 3 Comments »

Words & Phrases I fucking hate

Wednesday, October 24th, 2007
  • “a ways to go”
  • folks
  • lil
  • ol’

More as I am reminded of them by web pages. Note I’m not even starting on Web 2.0 bullshit like “folksonomy” (althought it’s partially covered by item 1 in my list there).

Posted in rant | No Comments »

oink.cd shut down

Wednesday, October 24th, 2007

This is a very sad day – the best filesharing site in history shut down, the admin arrested. For anyone who knows the site, you’ll know it’s an incalculable loss for anyone who loves music. There was simply no better place to find rare, obscure music, with a great community, high quality standards and always fast speed.

Apparently there was 180,000 users. It’d be a fair guess that those were a good portion of the top hundred thousand or so technically competent, quality aware, and passionate music lovers in the world – all of whom are now presumably furious at the record companies responsible for the takedown. This feels exactly like Napster, where the idiot record companies, instead of making a deal and legitimising a better service than they can possibly offer, just shut it down – pissing off hundreds of thousands of what should be their best customers.

Anyway. Let’s hope a recent copy of the database exists, and the site can be reconstituted in Sweden or Russia – the only free countries left, it seems.

Posted in music | No Comments »

Installing couchdb on RHEL4

Tuesday, October 23rd, 2007

1. Install erlang

Ignore the instructions here which are misleading and outdated.

cd ~/src
mkdir erlang
cd erlang
wget http://www.erlang.org/download/otp_src_R11B-5.tar.gz
tar xzvf otp_src_R11B-5.tar.gz
cd otp_src_R11B-5
./configure && make && sudo make install
## ignore warnings about jinterface and odbc

2. Solve dependencies. You’ll need EPEL

yum install icu libicu-devel

3. install couchdb

cd ~/src
svn checkout http://couchdb.googlecode.com/svn/trunk/ couchdb
cd couchdb
./bootstrap && ./configure && make && sudo make install

You may need to change one line in configure.ac: You don’t need to do this in latest builds (last tested 0.73a)

38
39

--FLAGS="-I${ERLANG_HEADERS_DIRECTORY} -I/opt/local/lib/erlang/usr/include/"
++FLAGS="-I${ERLANG_HEADERS_DIRECTORY} -I/usr/local/lib/erlang/usr/include/"

or if you don’t want to do that, this nasty hack will paper over the problem: (unnecessary in recent builds)

ln -s /usr/local /opt/local

4. start couchdb

sudo couchdb
couch 0.7.0a548 (LogLevel=info)
CouchDB is starting.
CouchDB has started. Time to relax.

UPDATED to cover recent builds.

Tags: ,
Posted in development | 7 Comments »

Ruby: quotes are different

Tuesday, October 23rd, 2007

I cannot tell you how many times this has tripped me up.

1
2
3
4
5
6

>> str = 'fuka'
=> "fuka"
>> str2 = '#{str}machi'
=> "\#{str}machi"
>> str2 = "#{str}machi"
=> "fukamachi"

Supposedly the ruby interpreter is faster using single quotes, because it doesn’t have to read the string first looking for possible substitutions within. But I dislike using double quotes on aesthetic & number-of-keystroke grounds so inevitably do this again, and again, and again.

I wonder if there’s a way to simply force ruby to always interpret single quotes as double. The few times I need to escape something in the string, I’ll do it manually – it’ll be worth it to reduce confusion like this:

1
2
3
4
5
6

username = 'sho'
endpoint = Net::HTTP.new("localhost", 8888)
headers = {'Content-Type' => 'text/javascript'}
response = endpoint.post("/shadow/_temp_view", 'function(doc) 
{ if (doc.username=="#{username}") { map(null, doc.username); } }',
 headers)

Quick, tell me if #{username}’s going to be substituted properly or not.

Tags:
Posted in programming | 3 Comments »

And this is why I don’t trust Google

Friday, October 12th, 2007


From the Google Groups home page.

Hm. I’ve been searching for a lot of Rails stuff. I keep track of mac news, yeah. Active Merchant? Hm, I remember finding out about that. Harry Potter? Not for a while, but I’ve searched a couple of times. Nethack? Check. Roguelike? That would be text-based computer games, like Nethack and a bunch of MUDs. I’ve been reading a lot about them. Game design? Obviously, I take an interest.

Nice to see it all spelled out. I wonder what else they’ve got?

Who the fuck wants to leave this kind of a trail?

Tags:
Posted in Uncategorized | No Comments »

Sup

Friday, October 12th, 2007

As discovered by Wincent the ruby mail console Sup is looking great. Ah, the memories .. it’s just like running elm (or pine) back in 1993! Except, way better, and it can do mbox over remote. I can see myself coming to love this.

Just a couple of small problems – the lack of unicode, and the fact that it stores your ssh passwords in plaintext in ~/.sup/sources.yaml.

Still, glorious days and as of now the most 1337 way to check your mail, bar none.

I may as well use this entry to also announce that I’m retiring my gmail accounts – and the advent of cool tools like this to access mbox-based mail only speeds my wish to migrate. I no longer trust gmail, and prefer to host my own mail servers.

My old gmail address will still work indefinitely, but replies may come from a different domain. I might also change my DNS over in the next few days so I can add SPF records, there might be some disruption but only temporarily.

Posted in Sho Fukamachi Online, cool, recommendation, technology | 7 Comments »

Best deadpan ever

Friday, October 12th, 2007

I know this is old but it gets me everytime.

Tags: funny
Posted in Uncategorized | No Comments »

couchdb: switching to experimental branch

Friday, October 12th, 2007

Current CouchDB development is progressing in an experimental branch named “interface-changes”, and it’s not in trunk yet. As the name implies, the interface is changing and it’s very useful.

To switch your svn checkout to this branch, do this:

svn sw http://couchdb.googlecode.com/svn/branches/interfacechanges/
./bootstrap && ./configure --prefix=/opt/local && make clean && make && sudo make install

You can then have a look at the “documentation” to see some of the new changes.

While still alpha, it’s still a very interesting project. The prospect of getting something like Map/Reduce capability natively in a database is almost too exciting for words, if you’re a data nerd like me. Well, figuratively speaking, Map’s there, but Reduce isn’t yet – still, it’s great to get your hands on what seems sure to become a Big Thing so early. Oh, and in case you were wondering, COUCH stands for “Cluster of Unreliable Commodity Hardware”.

Imagine GFS and Map/Reduce, baked into a single databse, with JSON in/out, pluggable query language, and native REST .. what’s not to love?

Laika’s ThingFish is a Ruby-based competitor. You might think I’d be more interested in that, since it’s in my favourite language! Not so. The very thought of a Database programmed in Ruby actually gives me an instant waking nightmare along the lines of running through treacle, gulliver in lilliputia, 80286SXs with 12MB of RAM, etc. And using mongrel server for a database!

UPDATE: it’s been merged to trunk, so just forget that interface-changes stuff.

Tags: , ,
Posted in development, technology | 10 Comments »

Why don’t the new aluminium Apple keyboards have backlighting?

Thursday, October 11th, 2007

Because I’d buy one if they did. Laptops aren’t the only computers that get used in dark rooms.

Tags:
Posted in Uncategorized | No Comments »

Installing nginx on RHEL4 x86_64

Thursday, October 11th, 2007

Want to use the new kid on the block, nginx, as a server on your old RHEL4 server? Well, guess what, it’s now available in EPEL so it’s incredibly easy.

First add EPEL as a repository on your system. They provide a package to do that:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm

now install nginx. You’ll need to specify the testing repo. I use yum but the same thing will work with up2date

yum install nginx --enablerepo=epel-testing

Done. Now go edit /etc/nginx/nginx.conf to use an IP or port that doesn’t conflict with anything, and:

service nginx start

UPDATE: Updated EPEL RPM link with new version.

Tags: , ,
Posted in development, rails | 3 Comments »

Installing CouchDB on MacOSX

Monday, October 8th, 2007

If you, like me, have been keeping an eye on the extremely interesting CouchDB Project then maybe you’ve thought about playing around with it a bit on your Mac. This turns out to be very simple.

I assume you have macports w/ subversion (and XCode, of course) installed already. Most of this comes straight from the Readme but I hate reading those, I just want someone to write what I have to do – maybe you do too, so here you are!

UPDATE: 11th October

Reinstalling after noticing 60 commits in 3 days .. now that’s active development.

(more…)

Tags: , ,
Posted in development, programming | No Comments »

Song of the Day

Monday, October 8th, 2007

Jakatta – American Dream (Joey Negro Club Mix)

Loved this song when it first came out in 2000, was reminded of it recently and dug up the single. Notice anything a little non-standard about the beat? ;-)

Posted in music | No Comments »

Monday, October 8th, 2007

Say you downloaded some software, and it’s in a hundred .zip files, which all contain a part of a RAR archive. You really wish you could extract them all to this directory, then run RAR on that .. but damn OSX wants to put every extracted file in its own directory!

No problem! Just break out terminal, go to that directory, and type

unzip \*.zip

Then just hit “A” when prompted to auto-overwrite useless things like file_id.diz and the like.

if you want them all to go into a directory “unzip” then:

mkdir unzip
unzip \*.zip -d unzip/

Simple I know, but I always forget that leading “\” and then have to look it up …

Oh, and it seems that The Unarchiver isn’t able to open the latest RAR formats. UnRARX is your friend.

Posted in mac |

Rocket Dive

Sunday, October 7th, 2007

Original hide version

TK version

When I first listened to the TK version I thought it was unbearably cheesy and lame compared to hide’s fantastic original. But now it’s really grown on me!

Posted in music | 1 Comment »

DNSstuff now pay-only

Saturday, October 6th, 2007

I was very disappointed to discover that one of the most useful websites for diagnosing DNS issues, DNSstuff.com, has decided to force people to pay for its lookup services. That really sucks, because it was always so good that no-one bothered making a competitor, and now it’s no longer free, I don’t know any other good options.

And they don’t allow you to sign up for less than a year either! Sigh. USD$36 .. I’ll have to think about that. Seems awfully expensive for a totally automated website I’m only likely to use the once or twice a year I make DNS changes. Then again, it’s fucking useful when making those changes. But I don’t like encouraging these “monetising what used to be free” trends. Sigh!

Posted in internet | 5 Comments »

Know-nothing Gruber links to know-nothing MacJournal, annoyance ensues

Saturday, October 6th, 2007

Supremely annoying John “Hans” Gruber, of Daring Fireball “fame”, has just linked to an even more annoying article, wisely anonymous, posted by some pompous asshole on MacJournal.com, taking to task AppleInsider for their very welcome recent scoop that Apple has enabled read/write access in dev builds of its ZFS implementation. The fool at MacJournal seems personally offended by the news, personally offended by ZFS in general, and in fact just very offended at everything he can think of – I’m sure you know the type. And you’ll quickly recognise the same type in Mr Gruber, a sickeningly egotistical blogger worshipped by the exact kind of self-righteous fanboy that long-time Mac users like me can’t stand.

Anyway. Let’s cut and paste from the offending article. I’ll just pick a few quotes.

Ah. The first paragraph should have ended with the text “…by people who leak pre-release code and know nothing about ZFS.” AppleInsider apologizes for the misunderstanding.

You fucking moron, it’s a rumour site. There was no misunderstanding. AppleInsider does one thing, does it very well, and has done it since before you could drive – report rumours and leaked information about Apple products. This is another in that series, a very welcome one, and you’re a fucking idiot for not recognising it as such.

“…where by ‘destruct,’ we mean ‘destroy,’ or would if we knew anything about ZFS. Write capabilities are no big secret, since the entire file system is open source, but it sounds a lot better if we portray it as something mystical.”

You’re a nit-picking retard. And while I wouldn’t call it the best style of English, this is far from the first use of “destruct” as a verb I’ve seen. And I don’t see why choice of words has anything to do with AI’s knowledge of ZFS.

“This claim [that ZFS will eventuall replace HFS+ - Sho], by the way, is widely believed by Johnathan Schwartz, cultists who assume that Apple’s advanced file system must be bad but Sun’s must be good, and people who know so little about HFS Plus and ZFS that they can’t do more than recite Sun’s marketing propaganda. For those keeping score at home, we at AppleInsider fall into the latter group.”

It’s ardently hoped by anyone familiar with the crusty, unreliable piece of shit that is HFS+ that ZFS will replace it. Do you have any idea at all what you’re talking about? Why *wouldn’t* you want to replace HFS+? Hell, NTFS is better. Much better.

“… or, at least, that’s what Sun’s marketing department tells us, and we’re far too ignorant to figure out that using significantly more disk space and processor time to store the same data is not ‘fundamentally new.’”

Maybe using more disk and processing time isn’t “fundamentally new”, but if the adoption of ZFS as the default filesystem in MacOSX led to MacOSX being no longer highly susceptible to FS corruption, that would certainly be “fundamentally new”.

“We don’t find HFS Plus administration to be complex, and we can’t tell you what those other things mean, but they sound really cool, and therefore we want them. On the magic unlocked iPhone. For free.”

You’re an idiot. No-one mentioned iPhones.

“We like how this somehow implies that hard disks can suddenly read and write for multiple clients at once, but we apparently aren’t aware that this is not true, and you’re still limited to the speed of your bus (or RAID controller) and your devices. Plus, ZFS can be a lot slower because it imposes tons of overhead on the kind of tiny files that Mac OS X uses by the thousands, but maybe magic hard disks will fix that, as far as we know.”

I read the paragraph several times and couldn’t see any implication that ZFS somehow manages to circumvent physical hardware speed limitations. What the hell are you talking about?

And I’d love to see the data to back up your “much slower” claim about the “thousands of small files” that MacOSX is apparently creating and destroying every second of the day. Oh, no data? Guess you’re talking shit, then.

“… but can only correct them if you’re using ZFS’s RAID-like capability to store duplicate copies of information, in which case a standard RAID system could fix the error too. Oops.”

Yes, they should have perhaps mentioned that this highly useful feature is only available to someone using RAID-Z across a number of disks. But to imply that a standard RAID system is just as good is disingenuous, because RAID-Z needs no special hardware, and if ZFS support is built into the OS, no special drivers. This is a major step forward to the current state of things, especially considering the dearth of decent RAID options for Mac. Or, as some would say, the complete lack of any good RAID options for the Mac that aren’t $10,000 XRaids.

“It can only correct the error if you’re using RAID and have a good copy of the bad data, but leaving that out makes you want ZFS a lot more. So does leaving out its battery-chomping, disk-eating storage hog nature that makes it fantastic for 20TB disk arrays and entirely, completely unsuitable for a Mac OS X startup disk, now or in the foreseeable future.”

Well excuse me, Mr Mac Journals, but I’ll take a bit of extra CPU activity over a corrupt filesystem any day. Your comment that ZFS is “completely unsuitable” for MacOSX’s root filesystem is ludicrous and indefensible. One is left with the strong impression that your constant mocking of AppleInsider’s supposed lack of knowledge about ZFS is nothing but a ploy to distract readers from your own obvious ignorance of ZFS, HFS, filesystems in general, and filesystems on the Mac in particular.

“It didn’t make us understand anything, but it repeats all these same phrases so it’ll make you think we know what we’re talking about, even though we don’t.”

Funny, I was thinking the exact same thing about you. But you claim to know something, so that’s worse.

I’d call you “Jackass of the week” but, since I’m not a pretentious twerp like Gruber who’s too scared to type swear words lest he damage his worthless “reputation”, I think I’ll just call you a fuckhead.

John
Hans “Sexy” Gruber, living proof that people with curly hair are bad news

Posted in mac, rant | 2 Comments »

Thinking about Changing UNIXes

Saturday, October 6th, 2007

Traditionally, whatever version of UNIX I’m running hasn’t mattered all that much to me. I’ve used a lot of them – a number of Linuxes, FreeBSD, Solaris 7, and adapted pretty much successfully to all of them. They have their quirks, but generally they all work pretty much the same.

I’ve actually got the most experience with Debian Linux, which is funny because I’m actually qualified (a long time ago) in Solaris. Right now I’m running RHEL4, which I didn’t choose for any particular reason – didn’t have much experience with it at the time, heard it’s pretty reliable, and since the price of it was included with my dedicated server I thought I’d give it a try.

But I’ve never particularly liked RHEL – while highly reliable, it’s too conservative for me. It can be months, years or never before updates to popular software becomes available – software which is highly reliable, but which never seems to become available for Red Hat. Just recently I had a considerable amount of difficulty updating Apache to 2.2; there’s no good reason this wasn’t made available for RHEL4. Apache is pretty much the gold standard for stable, well tested OSS and I was annoyed I had to basically illegitimise my RHEL4 system to get it installed. One wonders, if you have to step outside of the supported software included with your OS to gain necessary functionality, what’s the point of using that OS in the first place?

Admittedly, my needs are pretty far removed from the “Enterprise” presumably targeted by Red Hat Enterprise Linux. My upgrade was spurred by my need to accommodate Rails applications – hardly time-proven “enterprise” software! But that’s what I’m saying here – I’m not an “enterprise”, don’t have “enterprise” priorities, and am thinking about moving away from software targeted to them. My main priority isn’t covering my ass with name-brand software. It’s having highly reliable, but cutting edge, software.

The “cutting edge” thing I want the most right now is, of course, OS-level VM support. I’m at the point where I’ll need to toss my hat into the ring with one of the major VM solutions sooner or later. That’s my reason for not just sticking with my hacked RHEL4.

With the release of RHEL5 six months ago, a number of key systems have been updated, including VM support. I could perform a full reinstall of RHEL5 on my current server, get all the new software I need, and return to the “support garden” which is the whole point of RHEL. But I’m thinking – that’s all well and good right now, but what happens when I need to upgrade again in 6 months, and Red Hat hasn’t gotten around to approving the software yet? Seems like me and Red Hat just have fundamentally differing needs in an OS. I wonder whether I’m not better served just choosing something else.

As always, what the “something else” should be is far from clear. RHEL5, as mentioned, has VM support but I don’t like its backporting philosophy, which could be summed up as “no backports that aren’t security necessities!”. Sun Solaris has some nice things like ZFS, VM support (“zones”) and java nicely built in (seems the best solutions for hosting Rails could well be Java-based soon) but lacks a good package manager. Debian has the best package management system around but is a bit .. weird, in the “this OS is stuck together with gaffer tape and chewing gum” kind of way. Ubuntu Server has apparently made a lot of progress but I can’t see any reason it’s better than Debian if you don’t need the GUI, which of course I don’t. FreeBSD is of little interest to me at this point, same with Gentoo or any of the portage-style time-wasters. I don’t have any experience whatsoever with SUSE, Mandrake, Slackware, or any of them, and don’t plan to get any without a very good reason.

Right now I’m basically thinking it should be RHEL5 or Solaris.

RHEL5 Pros:

  1. Well known, easy to find documentation, software is targeted to this platform
  2. I know how to set it up and use it, and mostly trust it
  3. Decent package management system (yum in RHEL5)
  4. Mostly up to date, for now

RHEL5 Cons:

  1. update strategy incompatible with my own, as detailed above. I don’t care if the OS is still supported in 15 years’ time, I want the new shit, within reason
  2. I do not like or trust EXT3 and want to move away from it
  3. I do not have strong confidence in Xen (RH’s favoured VM system) – witness the emergency security update from just a couple of days ago – doesn’t smell mature to me
  4. Costs money, which may matter if I start buying more servers and leasing them privately. Could always use CentOS I guess.
  5. Packages available extremely limited compared to other unixes – can only be solved by compiling from source, removing the point of using RH in the first place, or using 3rd party repositories, again removing the point

Solaris Pros:

  1. I kind of remember how to use it, mostly. I can add users, anyway
  2. Heaps of good tech, active development. Specifically ZFS, Sun’s LDAP server, java preinstalled, Zones (Solaris VM) are supposedly excellent, dtrace
  3. Free
  4. Good hardware options in the future
  5. Solaris seems like it’s on a good progressive track right now, whereas Linux is, as always, bogged down. Witness Sun’s ability to ram through the changes necessary for ZFS. Sometimes it’s good to have a strong leader in OS development, and Sun seems to be doing a good job of progressing the state of server OSs right now. This is a fuzzy point, I know, but that’s the feeling I get.

Solaris Cons:

  1. Lack of user base of RH, may be difficult to find help and/or packages targeted to the platform
  2. Weak package management compared to Linuxes
  3. Possible lack of support for the things I want to do, and lack of other people who seem to be trying, ie, a seeming community consensus AWAY from Solaris; makes me uneasy
  4. A general weird feeling I get since I’m really a Linux-on-the-server guy and I just don’t know Solaris that well, not for over 8 years
  5. Weak support from hosting companies

Hm. Well, there’s only one thing I can do faced with this choice. Try them out! Well, I don’t feel I need to try out RHEL5 – it’s mostly the same as 4, just newer, and most of the new stuff I’ve managed to get running on 4 anyway – even yum, which is seriously better than up2date.

But I really don’t know what Solaris feels like to use and that’s the main thing. So right now I’m downloading the DVD of Solaris 10 8/07; I’ll install it in a vmware container and see what I think. Ironically when Solaris 10 first came out I got them to send me a DVD .. unfortunately I left it in Japan! Ah well.

Thank fucking god for being able to run real VMs on Macs now, btw!

UPDATE:

Downloading Solaris

Posted in development | 3 Comments »

ZFS Read/Write Developer Preview 1.1 for Leopard

Friday, October 5th, 2007

Apple has apparently released a developer preview of Read/Write ZFS for Leopard. Excellent news.

But I’m still disappointed we won’t see R/W capability in the 1.5.0 release. Typically, it’s the first release DVD that one uses for installations – having ZFS unavailable in the DVD will preclude formatting the boot volume as ZFS without resorting to prior disk-swapping tricks from a working install. Assuming that booting from ZFS is supported in a future point release, which seems reasonable, we’ll have to wait for an updated boot DVD before we can cast HFS+ out for good.

Tags:
Posted in leopard, mac, technology | No Comments »

Hosting Rails is a bitch

Friday, October 5th, 2007

No matter what anyone says, hosting Rails applications is – and is likely to remain for the foreseeable future – a cast-iron bitch. An expensive, slow one, too.

I’m no stranger to web hosting. I set up my first web server over 10 years ago – manually, of course, none of these control panels, and have done it many times since, as technology changed and languages shifted. I’ve been responsible for the production web presence of a number of companies, and along the way I’ve dabbled with a number of server-side application technologies, including ColdFusion and even Java (ugh!) but mostly PHP, since that’s what everyone uses.

And for good reason. PHP has many flaws as a language, mainly to do with security and the hideous mess most projects in PHP comprise, but it’s a joy to deploy. Here’s how it works.

PHP is actually two things. It’s a language, and a compiled executable which will interpret and act on commands issued in that language. It integrates nicely with the most popular, and largely considered best, front-end web server software, apache, so that what happens when a PHP web page is requested is as such:

  1. Apache reads the web page, typically page.php, and determines it requires action by the PHP interpretor, and creates an instance of that
  2. The commands in the page are relayed to the PHP interpretor instance
  3. The interpreter processes the commands and performs whatever action is required, typically HTML generation and/or database actions
  4. Apache receives back the data and serves it inline with the rest of the web page.

This all happens extremely quickly, and since PHP is integrated so tightly with Apache, you only have to worry about maintaining that one application. Sure, you configure PHP – via a single .ini file. Everything else is Apache all the way, and it’s a highly reliable and very fast way to serve web pages.

An especially welcome benefit from this arrangement is that you only require one Apache server running to serve any number of PHP applications. You can easily configure Apache to serve any number of domains via its VHosts system, any or all of which may contain active PHP pages. Apache simply instantiates (and destroys) PHP instances, which respond to the relevant pages, whenever required. The PHP executable doing the interpreting neither knows nor cares where the commands it’s interpreting come from. You’ve effectively created a “pool” of servers, any of which can respond to any PHP application, and Apache can balance its load amongst them as required.

The situation with a Rails application is very different, and not in a good way.

The current “best practise” for deploying a single Rails application is as follows:

1. Apache server front end, with a vhost interpreting the URL and relaying relevant requests to a cluster of mongrel servers, addressable by (local) IP
2. User then configures and maintains a seperate cluster of mongrel servers dedicated to that single Rails application and responding on configured IPs as set in Apache
3. Apache is further configured to go through mongrel for every non-static request.

This is then repeated for every Rails application on the box.

This has several disadvantages compared to the situation with PHP, to wit:

  1. Administrator becomes responsible for setting up, maintaining, and constantly monitoring a collection of independently-running applications, in addition to the core Apache server
  2. Mongrel servers not currently being used are not destroyed, but continue running, wasting memory (every instance of mongrel currently running on my server uses in excess of 100M each)
  3. Members in a cluster must be predefined and cannot be allocated on the fly according to need. For example, If you have 1GB of memory and 3 Rails apps, you are limited to distributing about 10 instances of mongrel between them. You must decide this in advance. If one of the applications suddenly receives a lot of hits, performance will suffer while the other mongrels, for the other apps, sit unused – the opposite of the “pool” you have access to in a PHP situation

And this is before even mentioning the underlying speed of mongrel, Ruby and Rails in general, which can only be described as horrible.

So, the sequence of events when a page request for your Rails app comes in is as follows:

  1. Apache receives request, determine the request is for your rails app
  2. Apache picks a server in your mongrel cluster, and sends the request (NOT commands, as in PHP) to it
  3. Mongrel, moving with the lightning speed of a slug through treacle, goes through the request page and sends the relevant parts to the ruby interpreter, itself not much of a speed demon, which, after a lengthy time out for self-reflection and “me time” reluctantly listens to, thinks about, thinks about some more, and then finally responds to the command. Repeat for every ruby command on the page
  4. The mongrel cluster receives and compiles the completed requests and, taking its sweet time, eventually manages to respond with the complete page
  5. Apache passes on the completed page to the client.

Not many more steps there, I admit. But it’s the speed of it which is the killer. PHP commands are detected, seperated from enclosing HTML and dispatched from within Apache, a lightning-fast and time-proven, highly reliable web server written in C. But in Rails, the job of going through the page to find Ruby requests and dispatch them is performed by Mongrel – itself written in Ruby. I don’t have any figures depicting how much slower it is, but it is – a lot.

Combine that with the inflexibility of distributing resources where needed, and having to independently spawn and monitor a seperate cluster of servers for every seperate application and you’ll understand that when people say hosting Rails is a nightmare, they’re right.

Rails has a lot of things going for it. It’s a joy to write in, mostly, and the development environment is great. It’s much, much more productive than the likes of Java while being much, much nicer than PHP.

But it’s slow as hell, and deployment sucks, and don’t let anyone tell you otherwise.

Tags: , ,
Posted in programming | 6 Comments »