blogging with blosedit

finally got around to installing some slightly more appealing frontend to my blosxom weblog than bxr. mainly because there doesn't seem to exist any good blog editor like ecto that works well with the metablog engine and doesn't cost a fortune. I guess that's because there aren't many engines besides wordpress and serendipity out there anymore ... ah, yes movable type, almost forgot about what this blog had started on.

at last I can blog from everywhere with wifi and soon it's going to be wifi or any given cellphone standard.

Faulbaer (so exciting)

ipad, iphone and the pre

I'm really looking forward to the ipad. not only that but actually signing up to become an iphone/ipad developer again - although it didn't get me too far last time I believe this time it's going to be different. there are things missing from the ipad - things I need ^_^

the only downside there is to longing for the ipad right now would be to be european as there neither is an official release-date for even the entry-level ipad nor is there a price. also there is no official word about the 3g version not to be sim- or netlocked - so let's hope for the best.

for some days or so I considered to buy the basic ipad although I'd rather be completely mobile and independent from tethering - not that my uk-based jailbroken blacksnowed iphone would tether properly anyway - for that I can only use my palm pre. no - it's going to be the 3g version. I have a 'spare' o2 data-flatrate sim that I got with my little asus eee pc netbook that the ipad is going to replace.

a propos palm pre - apparently they're broke - again. this is a major disappointment but not so much of a surprise to be honest. it's not that the pre didn't have potential or that the marketing was all wrong. even (at least in germany) they picked the perfect partner for the pre. but there were some major issues that added up had to lead into disaster:

- the device had been oversold, the pre never really came close to the iphone in terms of hardware or software and it couldn't really do what had been advertised

- promises were broken when the pre didn't connect to itunes - it's not as if there wasn't a way to get information out of itunes, the palm people just didn't get it done. why the hell didn't they supply their mac-users with a proper sync-app for the pre?

- communication issues and jobs only partially done - they shipped far too early but didn't really fix the device afterwards. I still can't properly backup my pre to my mac or to the network or to anywhere. the touch-stone charger is a great idea but without wireless synchronization it becomes an annoyance. even bluetooth protocals only have been implemented half-way. I still can't browse my pre's filesystem via bluetooth - why not?

- quality has been a big issue with the device as my battery is almost always dead after less than a day and the device has been replaced two times after dying on me - within the first month as I recall. also the device doesn't feel properly built, the keyboard-layout could be much better and the responsiveness as well as the precision of the touch-screen are less than mediocre

- the software did introduce some good ideas but since most of those great features hadn't been implemented properly the device couldn't be a success. both - iphone os as well as android have caught on with web-os. there isn't much left only the palm can do - and whatever challenges the competitors solved they did a better job at it than palm did.

actually I think the whole approach might have been flawed. it's easy to conclude that afterwards, I know that, but I think what palm should have done to compete against the iphone as well as against android would have been a much more open policy. they should have aimed applications at communication like sip-telephony, skype, jabber and maybe even some clients for the major blog-platforms. also they should have marketed tethering earlier and the quality should have been on par with at least their past products like the palm Vx or the palm tungsten or even better the ones of their competitors, the iphone or the ipod touch.

they should have opened their store right from the beginning and there shouldn't have been delays in shipping os-updates to outside the united states. why palm closed down their us-store to european customers is also an unsolved riddle to me. making developers pay for submitting applications to the store still doesn't seem right to me.

I'm very interested into who is going to buy the pre and what the next owner is going to do with web-os, the pre and how they are going to try to compete with apple and google. traditionally palm is a closed platform like apple has been. their attempts of licensing the palm platform didn't work out too well. palm might have missed their window of opportunity to become a strong competitor to apple on their locked-in turf but they still might have a shot at the open market where google is king of the hill right now - in the open market it's ok to just be good enough for a lower price as linux and windows have shown us over and over again - there nobody needs to be perfect.

Faulbaer (cheap but acceptable is the new perfect)

os-jihad: which flavor of linux for my next server?

my server is getting old - not only the hardware is way beyond due but also the operating system needs to be at least upgraded to the next major version. as always in this situation I'm pondering my operating system options - what has happened since my last major upgrade? what are my current options and what flavor of unix or linux do I want to use - and why?

I have to consider several requirements for my operating-system shootout and I have to decide between at least those competitors:

- debian lenny
- ubuntu server
- centos
- gentoo

my server currently is running xen, apache, varnish, djbdns, zimbra, ejabberd, mysql and occasionally some ftp-daemon. I could switch to lighty, I could switch to bind I even could switch to kmu or some other alternative to xen. but usually changing less works better for me.

right now I'm torn between ubuntu server which is supported by the zimbra folks and gentoo which I really like to work with because it's cutting edge and the package maintainers really keep their shit together most of the time. debian lenny would be my first choice if it worked with zimbra right out of the box and without any hackery involved. centos is just not my flavor of linux but still a sane choice in regard of stability, long-time-support etc. ... well - I'm not always a sane person I guess.

since I know so many great sytem administrators with their own perfectly good reasons for favoring one flavor of linux over the other I'm convinced I'd better just pass the ball to you my dear friends and let you recommend your very favorite linux to me.

please try and keep the signal/noise ratio in check and just suggest operating systems that really make sense to me. I can't afford vmware infrastructure nor do I own hardware that is certified to be used for vmware esx. if you really feel the urge to correct any commentor or me for that matter, please do this in a civilized manner.

at least state the three big "w":

- what? (which os would you suggest?)
- why? (why whould you suggest this?)
- when? (is a major change expected that's worth waiting for?)

please help me find the right operating system for my next server and leave a comment.

Faulbaer (guess I'm better gonna twitter this, too)

gulp stinkt mir

seit anfang des jahres bin ich bei gulp dabei und waehrend ich es schon fuer eine frechheit halte, nach einer sehr kurzen und nutzlosen testzeit, in ein abo gezwungen zu werden, bin ich als kunde des auftragsportals auch noch in anderer hinsicht unzufrieden. gulp stinkt mir - bis hier hin!

die seite kostet jene, die projekte suchen geld, ebenso wie solche, die projekte einstellen. ob 25 euro monatlich angemessen sind oder nicht, darueber laesst sich sicher streiten - ich finde es gemessen an der geringen menge eingehender projektvorschlaege zu teuer - auch liegen die vorgeschlagenen projekte zumeist so weit daneben, dass ich ernste zweifel an den faehigkeiten der entwicklern hinter den matching-algoritmen habe.

hinzu kommt, dass ich meine firma dort nicht angemessen repraesentieren darf, denn alles, was auf meine identitaet schliessen laesst, ist mir per vertrag verboten bekanntzugeben. damit soll ausgeschlossen werden, dass mich etwaige auftraggeber direkt ansprechen, ohne gulp dafuer ein angemessenes vermittlungsentgelt zu leisten. als vermittler kann man gulp natuerlich auch sofort vergessen, weil gulp ja selbst als vermittler auftritt und somit im pitch immer die nase vorn hat - dadurch suchen natuerlich vermittler auch nicht auf der plattform nach mir, dem experten.

was mich allerdings jetzt schlussendlich mehrfach genuegend veraergert hat, als dass ich mich zu einem blogeintrag genoetigt sah ist, dass mir gulp nicht nur unpassende angebote unterbreitet, sondern darauf, unter androhung der einseitigen kuendigung meiner mitgliedschaft, mir auch noch eine reaktion abnoetigt - eine reaktion, die dann postwendend mit einer projektabsage beantwortet wird. das ist gleichermassen frustrierend, wie unnoetig und ich habe ehrlich gesagt kein verstaendnis dafuer, wieso ich als kunde/mitglied/nutzer des portals mich so behandeln lassen muss.

ich zahle fuer sechs monate eine frech hohe gebuehr von 150 euro, werde dafuer schlecht vertreten, schlecht behandelt und erhalte unpassende angebote, auf die ich reagieren muss, was meine zeit kostet, um nicht von der plattform zu fliegen. davon abgesehen befindet sich das gesamte portal technisch noch in der internet-steinzeit - das kann ich mit meinem hintergrund im design und betrieb von modernen portalen wie neu.de und pkw.de ganz gut beurteilen.

fuer mich fuehlt sich das nach abzocke an. gulp hat jetzt noch knapp drei monate zeit, mir passende projekte anzubieten, dann bin ich da weg. weil es mir da so stinkt, kuendige ich aber vorsorglich gleich heute zum naechstmoeglichen zeitpunkt - kann die kuendigung ja aufheben, falls sich noch etwas aendert - wovon ich wirklich nicht ausgehe.

Faulbaer (hat hier irgendwer gute erfahrungen mit gulp gemacht - wer den ich kenne?)

palm pre app store - don't pay for nothing?!

received a mail from palm today inviting me to download some electronic arts titles for free. after palm had removed all the us titles from the german store, I hadn't spent much time in their 'app catalog'. it's full of apps again and some of them seem to be worth a look.

what strikes me as odd idea is that still everything there is for free. either palm doesn't yet have a payment-model for their platform or it's just not yet switched on. I don't get that. from my point of view this is going to annoy customers in the long run because as soon as they switch on payment, the old customers won't buy apps because they already have what they need or just don't see a point in paying for things they used to get for free. the new customers won't pay either because why should they pay for apps other got for free? when we look back into the history of radio and tv, that's what happened there - and that's what made it so very complicated for pay-tv to get their business going - at least where I live.

anyway - I'm downloading tons of apps right now, so the 'freebie' newsletter worked to get me into the app catalog again. we will see if this is going to be enough.

while I'm at it, I must admit that web os has gotten better with the latest update (1.4.0). also some of the shipped apps have improved a bit so the palm still is a valid alternative to the iphone as well as android phones. I like the new camcorder option in the camera app and all those little tweaks, fixes and features palm added to the phones's current software.

syncing over the air is still missing - I don't understand why that is. it would be easy to add some rsync-based service via samba or sftp - why doesn't palm add such a feature? it's nice to charge the palm wirelessly so there should be an option to sync it the same way, too.

the only thing I don't expect them to fix via software upgrade is the messy touch display. it just cannot compete against apple's device. but from what I know - nobody else offers a display coming even close to what apple sells.

what still doesn't seem to work is the task synchronisation between zimbra and the pre. tasks I add on the pre find their way to the zimbra desktop but what I add to the zimbra desktop sadly doesn't show up on the pre - interestingly apple's mail.app won't show zimbra's task but the one of the pre. but tasks I add in mail.app won't show up in either the pre or the zimbra desktop. besides that it's taking ages for all the tasks to sync - this is just not ready for prime-time.

what really anoys me most on the pre is that it's localization is all wrong. when I set my pre to 'english' I expect it to speak english and get all the apps in english language - but it doesn't. at least the electronic arts apps are partly in german, partly in english - this is really poor performance. oh - a propos performance - it doesn't quite make a good impression if your game stops playing music or doesn't continue loading the menues after a game of need for speed - since I dind't have to pay for the app I don't mind too much but as a paying customer I'd expect flawless game-design customized to the very abilities of the palm pre - at least my pre isn't strong enough for need for speed - not even in single-tasking mode.

I'm still considering to sell the pre but since it sells for only €250 used I guess I can just keep it and watch it to further develop into the iphone killer it set out to become ;)

Faulbaer (not really.)

model communities, forums and portals

I'm not impressed. not only that I expected far more photographers on an international portal like model mayhem, the defacto leader of the model photography portal pack, for me as a newcomer next to everything in these web-services feels wrong and yesterdayish. almost all of the user-interfaces appear to be hurried together. most of them look like they had begun as a web-shop, a forum or even a weblog-engine. there is no interconnection, no way out and no way in. there is no way to standardize your input or to update all of those portals at once. there seem to be no APIs anyone can use. there are no iphone apps to work with those sites. the only way to stay current is to keep a tab open in your web-browser.

since all of them claim they'd make our lives as photographers or models or stylists easier, I see some great opportunities ignored here. portals that look like shit, feel like shit and don't have any means to improve won't be able to survive too long.

I guess there will be one to rule them all in the near future. It's key-features will be the following:

- connections to all the important social networks like facebook, flickr, google, twitter, soup.io and so on

- a simple user-interface, streamlined to the needs of the users. models get a model view, photographers get a photographer view etc.

- import-wizards to get your information (and hopefully your contacts) from other sites

- it will be invitation-only for a time

- it will offer spam-detection as well as counter-measures

- it will offer add-words or some similar revenue-stream again for each user individually

- it will offer a recommendation-system for users who interact together in the way facebooks suggests contacts and amazon suggests stuff based on previous interactions

- a subscription will probably make advertisement go away

- with any luck there will be localized standard-contracts for tfp or other shooting-types ready to be agreed on online, printed out and filed before the shoot

- the service will be meshed with everything. images will be hosted at flickr, contracts in google-docs, mail with google, comments with disqus, locations with qype and google-maps, stuff with amazon, ebay and google, contacts with facebook and twitter, paypal for payments etc. why invent the wheel over and over again? most problems have been solved an just need to be pieced together via api-calls

- there will be an iphone-app with notifications to never miss an opportunity

- there will be filters for people with many contacts to keep their inboxes in check

- maybe there will be forums attached to the service but those need to be moderated and that seems to be overkill

I'm not yet sure where to host nude-photography properly since flickr isn't really up to the task for various reasons. maybe those images would be the only ones hosted on the portal.

anyway - I'm pretty sure there will be a new big player in the market within a year and I'll be happy to switch to their service if they even got half of what I proposed earlier.

Faulbaer (currently registered with 5 such services all of which suck plenty)

why I cannot reccomend to buy the drobo anymore

I've been having several problems with my drobo on several occasions. it's not that it's a bad idea or a bad design in general - it's just that in most cases for me it doesn't do the job as advertised and it doesn't help me with the problem that made me buy a drobo in the first place.

let's get into the details, shall we?

let's start at the beginning, while we're at it ^_^

in the beginning there were files and they got copied and changed and copied and change and their numbers and sizes grew and then space just ended and there was no more room for all those directories full of files ever growing in numbers and sizes - and the solution was to get more space, another hard-drive ... and as you might have expected the new one became too small soon again and the next and the one after that and then the first drive failed and I lost a gigabyte or two and I started backing up and keeping versioned redundant repositories on encrypted disks and/or disk-images and suddenly I needed twice the space and in some cases even more ... and I didn't know how to organize all those drives and the repositories and I actually considered deleting everything and starting all over again - not for long because that was around the time drobo launched a neat marketing campaign targeted and perfectly customized to my very needs - it promised to be the solution to all my problems and it did it with a cute girl explaining everything in a well made video on the internet where I live.

I'm not new to the business and I didn't believe everything I saw in the video right away. I did some research and read all the information data robotics provided me with. I reckoned they were cheating a little bit here and there and I expected that the important information was going to be the information they had left out in the video which by then had gone viral - not completely without my help and the help of so many others desperately searching for a solution to their storage problems.

I have a reasonable amount of experience with storage in almost every shape there is. I setup and maintained small, medium sized and large raids - even small and medium sized sans although by the time I decided to buy the drobo it had just been large raids and nas-storages.

all the information I got and all the pondering couldn't spoil my expectations of the drobo which were very high to say the least. it looked as if it was going to be the real deal and although I wasn't going for the 1.0 usb version I totally went for the firewire 800 drobo which proved to become a major disappointment after all.

broken promises

the video had shown a movie continually playing while expanding a drive or recovering a volume to a replaced drive - that is actually not a lie but they could have mentioned that a volume of the size of 4 tb was going to be recovered over days, not hours. if you wanted it to finish recovery within a week you better not touch the drobo while recovering.

the video also hadn't shown that there was actually a size limitation to a drobo - you had to decide on it's volumes' virtual size in the setup process. to date there is no way to grow the drobo beyond that. the maximum size is 16 tb in my firmware.

also there is no way of uploading a new firmware to a broken hard-drive in the drobo which is really a shame. if you are as unlucky as I was you end up with removing and upgrading your hard-drives one-by-one, always recovering and rebuilding the drobo volume.

the build-quality of the drobo is hmkay - it's loud and plasticky. I lost the cover-flap of one drive-bay by removing said drive for the mentioned firmware-upgrade. it looks rather ugly after some weeks of collecting dust. remember: the drobo wasn't meant to be used in a virtually dust-free data-center but at home or in an office where there is dust - tons of it!

I also don't like the way the sockets have been placed or that it has a separate power-supply instead of a proper 115/230 volt connector.

what drives me nuts all the time is that I can't tell the drobo to NOT shut down the drives, to not send them to sleep while not being used. the caching on the drobo seems to be shitty, too and whenever my mac wants to access data on the drobo I hear the spin-up of the drives inside taking ages and after a rather long while I can use the mac again. granted, half of that issue is apple's fault but hey - if those drives didn't sleep the other half wouldn't be such an hassle.

the overall performance of my fw-800 drobo is just poor. I haven't had any equally slow firewire drive after firewire was born. I don't actually get why that's the case. in theory there should always be at least two places to read data from, making the drobo at least double in read-speed of the slowest drive installed - but the reality is that it more like seems to be half the write-speed of the fastest drive installed for reading and a third of the write-speed of the slowest drive installed for writing data.

also accessing data in parallel proves to be problematic if not dangerous. I'm used to move data around quite a lot. I copy this and that to the drobo while reading some and more from it. the drobo sometimes responds so badly to that kind of usage that I tend to reduce all of them to just one job of either reading or writing - that is a big disappointment since I have four drives in that drobo and working with four terabytes of data involves parallel reading and writing a lot.

besides broken promises the drobo itself fails from time to time. that's when you send a mail to their very nice and very well trained support-team. and sure enough they could help me most of the time and I didn't actually lose any data but the drobo failing isn't really an option and taking recovery-times and bad performance into consideration it is kind of a deal-breaker for me, too.

I'm looking into alternatives to the drobo and deep inside me there is a feeling building up to just get rid of the drobo while there is time left - with the next major crash I'm going to switch to a proper networked storage or maybe even back to a file-server. the drobo let me down too often at too many occasions, didn't keep it's promises and can't help with the main issue: logical data-corruption.

the drobo can only fix broken drives and that it does slowly and clumsily. for it's prize-tag this is not enough and I'm not going to buy more drobos for further versioning and redundancy. the device is just not good enough for that and I lost most of the trust I put in it almost a year ago.

so - no, I can't recommend to buy a drobo for my use-cases. it's not that it isn't ready for prime-time - it's just a really bad performer and the only thing it does well, it doesn't as soon as you outgrow it's limitations.

Faulbaer (any recommendations what to buy next?)

data rescue saved the day

when I came back from london last month I noticed my mac behaving a little different from how I remembered it to. it wouldn't open disk images, it seemed to have stopped serving torrents although the internet connection was working and it wouldn't open files or applications. soon enough just about two hours later it just died on me. after a not so quick reboot I noticed the drobo wasn't coming up. I tried to check it with the disk utility but it wouldn't mount and the disk utility blabbered something about a directory being something with something blah foobar. I had been pondering to buy disk warrior on several occasions so I just went ahead and got me a copy. for $99 it turned out to be able to make the drobo accessible again but it wouldn't repair it because of some rather undefined problems that also made the scanning take ages - well today I think disk warrior is priced far to high for what it does.

next I had to buy some large usb-drives to recover as much data as I could. it took me over a week to suck all the data from the drobo and after some more crashes, reboots and several severe nightmares later my recovery work was done and I had all my encrypted sparsebundles back - just one wouldn't mount. the one that wouldn't mount had a virtual size of 4 tb and a real size of 550 gb and as it turned out it wouldn't mount because just about ten band-files worth 256 mb were missing from the band directory in the sparsebundle package.

this has happened before and would happen again - but not to me it hadn't.

after some googling around and reading this and that knowledge base discussion I was ready to give up. apples mount process just wouldn't accept a broken sparsebundle with missing band-files - it didn't matter if those were even used or necessary - it just wouldn't mount it - basta.

then I googled a little more, finding the article "repairing corrupt / damaged sparsebundle" pointing to this article "repair / rebuild damaged .sparsebundle" which finally gave me the solution: data rescue 2 which had been updated to version 3 by the time and which proved to be the helpful companion I needed to get my files back. it crashed, too but after just two more days it had recovered all the files I needed from the broken sparsebundle into a new one. the final clue suggested to mount the broken sparsebundle using the -shadow-option of the hdiutil. this then presented a readable and writable block-device for prosoft's data rescue to work with in expert mode.

although the 3d interface of the tool is a little childish and very much unnecessary the tool works great and is great value for the $99 I had to pay for it. it can't do wonders but for what it's worth it recovered all the data I needed and that's worth a lot to me.

a few final words about the sparsebundle file format: it sucks! apple should have the responsable team whipped until they get their heads out their asses and fix it.

- it's so fault intolerant it feels like it's from the eighties - all the journaling in the world can't help a sparsebundle if it's lacking band-files or if band-files and plist-file mismatch - dudes, get it fixed!

- there is no hashed directory-structure for the bands there are just millions of band-files sitting flat in the band directory waiting for accidents to happen

- there is virtually no usable documentation anywhere to be found on this sparsebundle packaging format - how open is that?

Faulbaer (and why does mac os x go insane beyond ten or more attached sparsebundles?)

my wishlist for aperture 3 ... if it's ever going to be released

I have a list of what I'd really like to see in aperture 3:

- ability to load and unload several aperture databases/libraries

- ilife and iwork integration being aware of (if not tracking) several aperture libraries/databases

- better performance in aperture itself as well as the aperture vault backup process

- ability to recover single folders, projects, albums, photos and even versions from the aperture vault backup

- non-destructive aperture library consistence check routines

- improved handling of decentral stored offline- and online-data

- ability to store files on a networked dedicated aperture server for several aperture clients to work with - I mean, it's 2010 dudes, gigabit networks are so yesterdayish, aren't they?

- ability to keep track of and maintain redundantly stored data - I want my photos to be everywhere and I want aperture to care for all the copies to stay current - that's not rocket science, just implement it!

- better web-publishing implementation tapping into services like flickr, ilife, photo-bucket, istockphoto and the like - also there should be easily accessible interfaces to publish to the common blogengines, microblogs and the like

- interfaces to easily work with the plugin-architecture in a non-destructive way. If I change colors, the size or anything in a plugin I just don't want aperture to export and reimport a tiff or psd file - I want plugins to be far deeper integrated into aperture - I'd actually like to see those plugins to dock right into the adjustment boxes, using the same mechanisms apertures adjustment panels do, being placed at a sane position in the workflow - generally before the sharpening and the vignetting steps ... am I the only one to be annoyed with the current way this is done in aperture? plugins should be just another layer to go through in the workflow!

- ability to work with huge files - I'm regularly getting 'unsupported image type' errors when I'm working with photoshop files larger than 300 mb which happens quite a lot. there is no need for aperture to act like that on a machine with over ten gigs of ram almost entirely dedicated to be used by aperture and photoshop

- make batch-processing available to keyboard users. I don't want to dive into menus and sub-menus just to add a tag to several images or to stamp adjustments to more than one photo

- get exif- and geo-data working properly - make adding and changing this data more accessible

Faulbaer (I'm going to add more in the future I guess ... )

aperture-library spring-cleaning for the brave

first of all, let me warn you: make no mistake - this is dangerous business! if you don't know what you are doing, you can and most certainly will lose some or all of your photos! read everything top to bottom before doing anything else. read everything repeatedly until you know what's going on and what I'm doing here. don't come whining to me if you lost any data - you've been warned!

now that that's off my chest let's dive right into it after a short introduction, shall we?

when apple announces aperture some years ago it seemed to be the perfect solution to all the problems I had been experiencing with iphoto. like every other apple product it wasn't perfect but it did the job much better than most competitors' products - at least after the upgrade to it's second version. unsurprisingly it was not the solution to all the problems but at least some of them had been addressed properly. what were the remaining problems then?

- it's still slow - especially with large libraries

- backups are taking ages and they break easily

- you can lose photos and projects from aperture crashing

- decentralized and distributed storage hasn't been addressed properly

there were several other small and large issues I'm not going to fix here.

most of the problems come down to one issue that can be cured: huge libraries beyond several 100 gb.
with huge libraries, backups need to take longer, going through the previews needs to take longer, aperture will consume more memory and crashes probably lead to larger chunks of data to be lost.

the solution to most of my problems was to shrink my aperture library. I could have deleted several thousand photos but as you can imagine I didn't want to delete my work. what I did was to divide my one large aperture library into many smaller libraries. for all the years until 2006 there was one new library. for the years after 2006 I had a library for each year. for 2009 I'm pondering to split the year in halves or even quarters because this library alone takes up about 550 gb. if I had reoccurring events I might have divided the library not only by date but also by topic.

the problem with the solution

the usual aperture way of doing what I was going to do can be described as the following:

a) open the source library

b) right-click the project and select "export project" from the pop-up menu

c) chose an export path and tell it to move the master-files into the project-file

d) wait and hope aperture doesn't crash

e) right-click the project and select "delete project" from the pop-up menu

f) click a bunch of silly questions away

g) close aperture to make sure the changes have been written to the library

h) wait and hope aperture doesn't crash

i) open the destination library (if it doesn't exist yet, open aperture while pressing the shift-key to make a new library)

j) import the just exported project

k) wait and hope aperture doesn't crash

l) close aperture to make sure the changes have been written to the library

m) go back to a) until all the projects are where you want them to be, shave, go outside and take a look at what the world is like in 2050 ... or whenever you've finished exporting projects one-by-one from aperture.

ok - you could have exported those projects one-by-one but then could have imported them as a folder which could have saved you time - but if you played save, the above list is pretty much what you had to do.

the hacker approach

needless to say that I wasn't going to do this the hard way but the risky hackery way. there had to be a way to get that work done much faster without repeating so many small steps and without answering the same silly questions over and over again ... and there was! It was just a bad idea ;)

as you might know apple uses so called packages for many things that need to be stored. applications, documents, sparse-disk-bundle disk-images and also the aperture libraries are stored in those packages. these packages usually are just a folder with an extension in it's name as well as a bunch of files (usually xml) and folders inside. you can take a look into a package by right-clicking it in the finder and selecting "show package contents" from the pop-up menu. if you were command-line savvy you could just navigate into the package in your preferred shell with the usual cd command.

a few words about the aperture library.aplibrary

the aperture library package isn't too exciting either. it contains some .plist and other xml-files, the main library as well as some folders with the photos organized in project-packages which again contain some xml-files, the photos, their previews and versions, some meta-data and albums as well as smart albums. albums and smart-albums also lie in those previously mentioned folders and either the main library or the .plist files link to them. I decided for saving time and agains saving rogue album data since I only had just about ten albums that were not within project package boundaries but instead in a folder somewhere else. I couldn't find an easy way to import such rogue albums and smart-albums but honestly I didn't care.

how big was it and how long did it take?

my original aperture library was just short of being 800 gb big and it contained about 754000 files. this includes the meta-data, xml files, the photos, previews and versions in different formats like jpeg, raw, psd and the like. to copy this library took me a day, partially because I hadn't invested into fast storage. to back new images up into the aperture vault never took any less than five minutes because aperture needed to check the vaults integrity first - also it had to seek through and write into huge xml main library files almost a gigabyte in size. with this many files and such a large xml library to parse through, performance had to be low.

two ways to shrink it, two days to get the job done

my first approach was to just move all the projects and folders out of the package and delete their references from the database/library by erasing the folders within aperture. I soon found out that this was taking ages and I had to repeat too many steps too often. this was the right approach in only one case - in the case there were less projects to be removed than there were folders to be imported. in the case of photographs imported from iphoto containing all the collected digital photographs I had taken between 1997 and 2006 there were hundreds of folders containing hundreds of projects containing between one and some hundred photos ... to sort through them and consolidate them into less projects with albums referring to them seemed to be far too much work. so what I did was to remove everything past 2006 first on the filesystem-level and then from within the library. all in all that included only six folders: 2007, 2008, 2009, 2010, misc and airsoft. I still had to right-click each one of them, answer some questions and wait for aperture to clean up the database, hoping it wouldn't crash. after each folder I quit aperture and fired it up again. luckily it didn't crash within this procedures - not even once! to finalize the library, I saved it into a new aperture vault of the same name.

my second approach was to open aperture while holding the option-key and by that starting aperture without a library. it then would ask me to select an existing library or instead start with a new one. I chose the latter, added some folders like 2007, 1st quarter, 2nd quarter and so on and afterwards imported the projects I had moved out the aperture library.aplibrary package into their corresponding folders. after repeating this for each of the mentioned folders I quit aperture and launched it again. aperture crashed five times which still makes me angry because after a crash I had to remove the just imported folders, quit aperture, relaunch it and import the same folders again, just to be sure the library was consistent - I've had bad experiences with corrupt aperture libraries in the past. I lost about 70 photos, some of them really nice ones because of those crashes. finally I saved the new library into an aperture vault of the same name again.

it took me two days to complete the task but now I feel much safer and the best thing is that aperture itself feels much faster and much more responsive.

why I did it - the aftermath

now that I know everything worked and still works I can say why dividing up my aperture library into smaller chunks in an ordered way was a good if not great idea.

for one, it feels faster which is not a big surprise. aperture needs to address less memory to parse through a smaller library. it needs less time to load and write into the library. there is less to be backed up if anything changes and there is less to be restored if anything goes wrong.

also the libraries are smaller and therefore much more flexible to be worked with. I could easily archive those smaller libraries to several old hard-drives that I could easily store away off-site. before any of those drives had to be at least of the size of 1 gb and it took me ages to get one backup stored away. time in which I couldn't work with aperture which proved to be annoying several times.

today it's also much easier for me to just fire up the aperture vault backup-procedure because I know it's not going to take too long in most cases. this can prove to be a life-saver in the future because I won't 'forget' about backing up crucially needed data.

it's not all good

there are some downsides I need to mention before you dive into it - it's not just all good. as it is with all the other database-oriented programs from apple, the ilife system doesn't expect you to divide your databases into many smaller ones - I mean ... well ... it's obvious apple doesn't expect you to outgrow their products faster than they make faster hardware available if not affordable to you - but in some cases that's just what happens if you use your computer professionally or . this happened to my itunes library in the past, to my iphoto libraries and now to my aperture library. in the case of itunes apple just got me faster hardware so I could reconsolidate my itnues library back into one. in case of iphoto i switched to aperture which solved the performance issue at least for some years. now in aperture I reached the borders of what I felt bearable and again I divided a library for good - let's see if apple comes up with either a better library/database format for aperture 3 or a better mac pro I can buy that can handle the load.

what are the downsides of a divided aperture library?

not so many to be honest but they are pretty annoying nevertheless.

- itunes get's all confused - it will only put photos from your current library onto your ipods, iphones and apple-tv. this is a biggie for me so I'm considering to export things I always want on my iphone into the iphoto library since I'm not working in iphoto anyway it's more or less static. I'd then fill my media-devices from this iphoto library.

- needless to say that the above is true for all the applications sharing media via the ilife hub. that includes iwork, ilife, ecto and many more. it's really a pity that apple offers to divide libraries but doesn't care for keeping track of those. there should be a way to link to those decentralized media-stores.

- it's annoying to seek through several databases by quitting and relaunching aperture. but that again is apples fault - there is not really one good reason why aperture can't handle several open libraries parallely like mail.app handles several mail-accounts and almost any app handles several open files. I sincerely hope apple is going to address this issue in it's future aperture versions.

- keeping track of several libraries and versioning several libraries could prove to be a hassle in the future. I can imagine deltas between several versions of the same library backed up to different drives in different locations but there are ways to deal with this and it's nothing really new either - it just needs for me to keep it in mind, doesn't it? ;)

a final word

back everything up, quit and relaunch aperture as often as you can. aperture is a beast with memory leaks and it's obese and heavy and stupid. I don't know any better product for the job it does and that's the only reason why I use it. keep in mind that aperture is only there to lose your photos and make your life a misery. so again: make backups before you do what I proposed - even better for you is if you don't do it at all! you are probably better off if you do it the painful slow way or not at all - maybe apple is going to supply us with much faster hardware really soon - you better wait until your new machine has arrived and keep your aperture library.aplibrary intact as it is!

also don't forget that you probably lose some albums and smart-albums not stored in any particular project but a folder or anywhere else.

don't do it and if you do it, make backups (that's plural for backup which is going to be too few - make more than one, make several backups!).

Faulbaer (you've been warned - not once, not twice but three times!)