|
|
The other day, my EeePC's internal SSD (hard drive) decided to start rejecting writes - looks like I wore it out. Not a huge surprise, the drive has been very slow of late, making me look unfaithfully at new machines in shop windows.
The death of the drive resulted in a minor flurry of hurried nerding, here in the lovely city of Sucre, Bolivia.
First, I decided to try replacing the drive (for now) with a cheap USB thumb-drive. I wandered the streets, eventually finding a shop which sold me a nice 32GB Sony memory stick, for 50 USD. It seemed like an OK price...
Too bad it didn't work: when I tried formatting the drive as half VFAT and half Linux ext2, the ext2 partition kept turning out to be unreadable. Googling for help, I discovered that I had fallen for a common scam: selling 1GB memory sticks which have been modified to claim to have 32x more space, happily discarding data written to most of it. Very, very nasty, I consider myself lucky I caught it so soon, before losing any data.
Unfortunately, I hadn't gotten a receipt, so I ended up resorting to a slightly asshole-ish trick to be sure I would get a refund: instead of complaining, I requested a belated receipt "for work...". As soon as the friendly woman in the shop handed it to me, I apologized, explained my problem (in broken Spanish), and demanded an exchange or refund. It worked, I got my money back and the shopkeeper was still smiling afterwards. Bolivians are nice - as I left I wondered to myself whether I had been the victim of the scam, or whether she had.
My second purchase was a 16GB Kingston stick, which worked fine. Again no receipt, this time because the person selling it was avoiding tax...
After migrating my data to its new home and verifying that everything more-or-less worked, I decided to perform a basic 'mod' and install both a hub and the thumb-drive inside the EeePC chassis itself.
The mod itself was good fun, although I am limited by the fact that I have no soldering iron, only a leatherman tool and plenty of tape. A true McGuyver mod!
I stripped all the plastic from a cheap ($7) USB hub/card-reader, stripped all the plastic from a USB bluetooth adapter given to me by my brother (why I've been carrying it around S-America I cannot say...) and somehow managed to squeeze all these gadgets, including a spare 1GB MMC card into empty spaces inside the EeePC's tiny shell. A short tail of USB cable now emerges from the Eee's bottom, which I've taped to the chassis and keep plugged into one of the external slots - when I have a soldering iron I'll be able to clean that up and connect everything internally.
At one point I thought I had bricked my laptop - it wouldn't boot at all. Ewelina's working Internet connection came to my rescue though, telling me that I could hard-reset the BIOS by shorting a pair of connectors hidden underneath a sticker hidden underneath the memory. Phew!
At another point, I couldn't understand why the memory card kept showing up as read-only - until I realized that the USB hub's on-board card-reader, really was only a reader, not also a writer. Odd, but no matter, I'm just storing applications on that card so day-to-day, read-only access is all I need.
So, to sum-up, over the past 48 hours I have replaced my EeePC's worn-out, dog-slow 16GB SSD with: one 16GB USB thumb drive, one 1GB MMC card, and 1 bluetooth adaptor. Also, my laptop no longer locks up for ages when programs try to write new files...
When I find a larger thumb drive for a reasonable price, I'll be able to upgrade further, and when I find a soldering iron, I'll be able to clean up the mod and free up enough physical space for a second thumb drive or some other USB gadget.
I'm thinking an FM radio transmitter might be pretty cool...
...
That's just the hardware side though. The software side is at least as interesting.
The first trick, was to get the Ubuntu boot sequence to wait for all those USB devices to settle down before trying to run fsck or attach them to the file-system.
I solved this by adding a little script to /etc/rcS.d, which I named 'S29usbwait'. It's basically a loop which runs: dmesg |grep -c 'Attached SCSI removable disk' to count how many devices have been attached - when the number is 3, I know everything is ready.
The second problem was more subtle; I am under no illusions about the reliability of cheap USB flash drives. The more I write to the drive, the sooner it will suffer the same fate as the SSD it has replaced. So I made quite a few changes to the system to try and minimize writes.
The first change was to add the 'noatime' option to the fstab line for the memory stick. This is well documented and is pretty much standard practice. I also went with 'dirsync', which does the opposite (increases writes), but should reduce file-system corruption when the device decides to misbehave. (Comments on how dumb/clever this is, are most welcome).
But how to prevent truly unnecessary writes? Which programs are creating new files all the time, for no good reason?
Firefox is a well-known culprit, it has a disk cache, bookmarks, history and all sorts of session files. Online I found hints about how to move the disk cache to RAM (open up about: config and set browser.cache.disk.parent_directory to /dev/shm/bre or something like that).
But there's sure to be more, Firefox can't be the only bad-guy. So to figure out which files are being constantly created/changed, I turned to trusty old find: find . -mtime -1 -ls |less -S
This lists all the files in my home directory which have been created or modified within the past 24 hours. I can easily ignore the ones I'm actually working on and focus on the rest to look for things to tweak or turn off. The list was quite long.
I did find some more nasty Firefox stuff (read here about the urlclassifier bug, which sounds very bad for flash-media) and am experimenting with simply removing write access from files in the session directory (.mozilla/firefox/...). We'll see how many features I can break without noticing a difference.
However, it turns out the biggest file-writing culprit on my machine was Eclipse, which I use for Android development.
Eclipse is by default configured to automatically recompile code as it is edited, generating warnings and error-messages on the fly. This is actually quite a nice feature, which does a lot to make programming in Java less bothersome. However, it also generates dozens of files in the process, over and over and over again - pure evil from the point of view of my poor flash drive!
Looking through the Eclipse menus, I found that under Project > Properties, I could change the output path - so I changed it to a location in /var/tmp (actually a symlink from the project dir to /var/tmp), which just happens to be a RAM disk. This not only removes the write load from my flash drive, it also makes Eclipse quite a bit snappier. Score!
Eclipse also seems to like editing a whole pile of files in ~/.eclipse. History and settings, no doubt. To stop that nonsense I simply ran chmod -R -w ~/.eclipse. So far Eclipse hasn't complained.
There are also a bunch of KDE configuration files that seem to get updated quite frequently, but as I suspect they are providing useful UI features, I've left them alone for now. If I change my mind later, they also will get the chmod -w treatment.
...
Hopefully these hints will show up in search engines and help someone out.
I've seen dozens of articles mentioning individual optimization techniques, tweaks and hacks, but just running find and having a look at what is being changed, and then using chmod and symlinks to take control of the situation was nowhere mentioned - and yet I think it is a much more complete and 'sustainable' approach.
Did I just invent it, or is it just too obvious for tech journalists to mention in their articles?
It's been a while since I posted anything here. I've been writing quite a bit of code while Ewelina and I travel around, but not much of it has been put online since the photo album went live... until today.
Today I published my second-ever Android app to the Android Market: WhereBlogger
Woohoo!
The app is fully functional, and useful. I'm able to look at maps of Ewelina's and my trip to the Galapagos Islands either in my phone, in Firefox or in Google Earth.
Future plans: a non-free version which costs money and does direct publishing to online blogs and/or my own travel-blogging site. Only problem? I don't live in any of the countries where people can get Google Checkout merchant accounts.
I wonder how difficult it is for me to get a U.S. or U.K. bank account and credit card?
I am really enjoying my new coding project, and am making rapid progress building our new photo album.
Since my last post, I've implemented the following things:
I've also fixed various bugs, the most important being a bug in the image preloading code which made the site much slower than it should have been.
The next big thing I need to work on has to do with user accounts, access controls and privacy. Basically I want to have control over what I show to search engines, what I show to strangers and what I show to friends and family.
Photo albums are even worse than blogs when it comes to a weird mixture of privacy concerns and exhibitionism... :-)
What with the traveling all over the world thing, I am taking lots of photos again. And when I'm not taking photos, Ewelina is taking photos.
So I made yet another photo album thingo. It's not finished yet; it is lacking RSS feeds and some administration features, access controls and lots of little bits and pieces. But the most important things work: we can post our photos online and people look at them and comment on them. Yay!
The organization of the entire collection is done with KPhotoAlbum, which gives a much better UI for tagging and sorting and rotating and deleting than I would be able to create any time soon. To publish the photos I just upload the KPhotoAlbum database and tell my online album system which tags to publish as albums, which tags to treat as private and which tags to ignore completely.
I re-used code from Partalistinn to get this up and running so quickly, which means the whole thing is written in Perl. I'll probably switch to letting lighttpd serve up the static images later on to make things more scalable, but for now the Perl code does it all.
I also took care to write the thing in such a way that it can already handle multiple photo collections and multiple domains; the look and feel is entirely customizable and if I don't lose interest this could turn into something useful to people other than just myself.
For now though, it doesn't even have a name. What would you call yet another photo album program? How about an online photo album hosting service which allows you to use your own domain and your own look and feel? Would anyone pay for such a thing, or have Picasaweb and Flickr and all the rest already got the market cornered? So many questions...
Ewelina and I have a pair of joint blogs to document our travels around the world:
If Ewelina can keep up with writing and translating, both should end up with roughly the same content. So go there if you want to know about our trip. This blog will probably stay relatively quiet for the next few months, although when I have nerdy things to write about they will still end up here.
So here comes something nerdy about the blog itself!
When setting up the blogs, we decided we wanted to have a map. Preferably an interactive, easily updated one. It took me a while to figure out all the bits and pieces, but these are the tools I ended up using:
The trickiest part was figuring out how to get the data from My Maps in a format usable by the Maps API. Try as I might, I couldn't find any documentation on this anywhere, even though it seems like an obvious use-case to me. Oh well. Documenting is hard, let's go coding...
The trick? In My Maps, there is a RSS feed link button. If you copy the URL it references, then that can be used as an overlay source in the Maps API. Even better, if you edit the URL to replace the word 'georss' with 'kml', you get a full KML feed which includes lines, areas and custom place markers. Voila, problem solved!
Oddly enough, using the Maps API and the KML feed also loads faster in my browser than the embedding iframe solution suggested by the My Maps interface.
Today is my last day at Google.
I have submitted and approved a few code changes, the last one removing my access to submit or approve code changes. I deleted or transferred ownership of my shared documents. I've sent a good-bye e-mail to my teams and friends. I just completed my exit interview.
It's a slightly sad day, as I'll miss all these people and miss being part of a very cool company. But mostly it's a happy day, because I am excited about moving on and doing new stuff.
One of my coworkers pointed out that I've been with the company for exactly 1001 days. Pretty cool! :-)
Good-bye Google! Thanks for everything.
Next: Travel around South America for a few months. Feel free to send me job offers sometime after the New Year... :-P
In only 17 days, Ewelina and I will leave Ireland, probably for good.
We fly to Poland, then Spain, then Mexico... and then who knows! We might fly back to Europe 5 months later from Brazil, or we might change our mind and do something else entirely.
Today we got vaccinated against all sorts of diseases. We've bought most of our plane tickets, I've given notice at work, we have a nice camera and a pair of portable hard drives to store the pictures on. We have various credit cards and sums of money in various bank accounts. We have anti-malarials and prescriptions for all sorts of other fun drugs. We have been taking Spanish lessons since February, we have valid passports and according to the Internets we don't need visas for the places we want to visit.
There are still a few things to sort out, but I think we're almost ready.
We still have 17 days... :-)
Ég ætla að skreppa aftur til Íslands um þarnæstu helgi.
Ég lendi í Keflavík kl. 23:10, föstudaginn 15. maí (flug FI455) og flýg burt aftur eldsnemma á mánudagsmorgun.
Tilgangur ferðarinnar er að heimsækja afa minn, en vonandi hitti ég einhverja aðra líka. Langar einhverjum að sötra bjór á laugardagskvöldinu?
Aard
Ágúst
Anna
Annie
Árdís
Biddí
Borgar
Bragi
Diddi
Dúdda
Froskar
Gummi Jóh
Gunni Gríms
Haffi
Heiða
Helga Þórey
Helgi Hrafn
Henrý
Hrafnkell
Ingó
Jói Gunni
Jói B J
Jonni
Jósi
Kisa
Ine
Katrín
Krilli
Kristína
Logi
Marta
María Alva
Már
Mundi
Muzak
Nori
SH3
Sísí
Skrímsla
SlimJimy
Ringa
Sigga
Siggi Palli
Siggi Pönk
Sigga Sif
Siggi Sveinn
Sigurlína
Soffía
Sonja
Steinn
Tolli
Unnur
Urður
Vera