The HP Stream as a cheap open-source Chromebook

I really like Chromebooks but I must admit there are times when I’m travelling and I’d like a more conventional offline setup.

Also one of the attractions of the original wave of Chromebooks were their price and I feel that the more recent editions have been price comparable to mid-range laptops.

Finally I read a few pieces warning against slipping into a monopoly of convenience around the Chrome browser so I thought it would be great to have a Chromebook that essentially ran Firefox.

I chose the HP Stream as the cheapest laptop that people mentioned that had Linux running on. It’s plastic and it’s proud of it, I bought one in an aquamarine blue. Trying one out in a store it has a good sized keyboard with only one quirk around the enter key which a bit smaller than the typical UK keyboard and has a hash key right above it.

That plastic shell means it is light but it is durable to have been shoved in a few travel bags and transported round. It has a custom power adaptor which is a pain when you’re travelling. USB-based charging would have been much better.

Installing Linux

I chose Elementary as my distribution, partly out of curiosity but also because people mentioned that it was an opinionated take on what a user-friendly operating system might be.

I had to read how to enter the Stream’s BIOS on the internet and set it to boot from a USB but after that it was pretty plain sailing to get the Elementary ISO onto the USB and for the Stream to load it.

Everything worked first time and I had the new OS completely replace pre-installed Windows and also encrypt the drive, which seems important if you are going to be travelling with the laptop and thus more likely to lose it or have it stolen.

Connecting to Wifi was painless as was the upgrade process.


Elementary takes a very different approach to all the other Linux distributions with the UI essentially hiding all the normal Linux details. It has its own app store and upgrades of managed packages are seamless and mostly seem to complete without the need for restarts.

You can get to the terminal and install packages via Debian-style packages if you want to but Elementary mostly shines when you stick to the GUI and the apps.

For the kind of consumer electronic experience I wanted Elementary was an excellent choice. The only real problem I encountered was the classic issue of the OS not suspending when the laptop lid was closed, instead I had to manual suspend and then close the lid. This has subsequently been fixed in a subsequent update and currently the whole OS feels like what you’d expect from a modern system.


I am an absolute tab monster when it comes to browsers. I rarely have less than 40 tabs open in each browser and I have been known to use multiple windows on top of this.

My Chromebooks have struggled in the past and I’ve had to use the Task Manager to figure out where the CPU and memory are going in terms of the sites I use.

The situation was similar with the Stream. When I run Chrome and Firefox the system struggled and the battery ran flat quickly. I’ve since stuck to just Firefox and tried to limit myself to a set of about 15 to 20 tabs. This has been stable and has given me a few days worth of web browsing per charge.


When I started experimenting it would have been hard to say that I really had a better experience using my setup compared to a Chromebook. As we head towards Christmas, almost a year into the experiment, I’m now starting to think that I’d prefer to take the machine that would allow me to use git and my choice of text editor if I wanted. Firefox is a great choice for most of my daily websites and both of the machines have encrypted drives.

Elementary isn’t quite consumer electronics and the Stream is probably the wrong side of the price/quality divide but its actually the flexible machine I want to talk as I visit family and friends over the holidays.


The Doxie handheld scanner

Doxie makes handheld scanners, which seemed the perfect replacement for my flatbed scanner that is currently without working drivers for any modern OS.

I opted for the DoxieOne even though my scanning is primarily for Linux and there it wasn’t going to use all the integration and software the device comes with.

Doxie’s failure to integrate with Linux is a bit baffling but the basic behaviour is absolutely acceptable. It connects as a standard storage device by USB and you can just use all your usual tools against the device’s drive.

The scans produced are good quality and unlike a flatbed it will scan any length of document as long as it is roughly A4 or less in width. Of course you can’t use it to scan books (although there is a mini-flatbed version) if that matters to you.

The only real difficulty in using the Doxie is that an slight misalignment when you first engage the roller can get very pronounced by the end of the scan and the result is a picture at an angle that is hard to fix up in an image editor. If I realise that something is feeding incorrectly I tend to rescan as it is easier.

I was looking for a portable scanner that is easy to store and interact with and the Doxie meets the bill in an elegant way.


Using Linux and WD’s My Box Live

For a while I’ve had a hankering to be able to share content (mostly music) between my various laptops via a network drive, mostly to avoid having to either attach a drive or waste laptop SSD space. A cursory look through Amazon gave me Western Digital’s My Book Live, which seemed compatible with Ubuntu while mostly being presented as an OSX/Windows product. However the official line is actually “if it works with Linux great, if not we don’t support it”.

Actually getting things working was harder than I had anticipated, if I had a Ethernet connected computer switched on then the drive appeared normally however as soon as I switched off the computer then the drive disappeared as well, presumably meaning that the drive was being shared via mesh networking rather than being available to the Wifi devices as a first-class network citizen.

Some online comments suggested that the issue was that the device was not using a static IP, so I went into the settings and changed that. While in Static IP mode the drive started to give a warning it wasn’t connected to the internet, which presumably is something to do with port forwarding for the WD2GO service which also requires some router config. Despite this the drive was available once the static IP binding was done. However any music player (Rhythmbox and Banshee) that tried to connect to the drive failed to connect and there didn’t seem to be a way to provide the required anonymous login.

The final stretch was helped by this post about mounting network drives, on mounting the drive manually it was possible to access the new drive and generate playlists for the new drive. I didn’t want to edit fstab for this so I’m think of creating aliases for the mounting and unmounting operations.

I am now able to share my music collection to my Ubuntu laptop but it has not been a simple experience and I do think WD are short-sighted in not making the operation smoother. Linux may not be a massive market but it doesn’t seem that complex to support it better, if nothing else in the FAQ for the product.


Running Virtual Ubuntu

So at work I need to be able to have access to a personal UNIX playground and the form that you have to fill in to get a licensed VMFusion instance is a nightmare so I decided to look at the alternatives. I already had Parallels installed on my MacBook Pro but I had not done anything with it. I also decided to try and get Ubuntu running on my Windows Vista machine using the free (to download) VMWare Player.

VMWare Player requires a special image (I used this one) however once the software and the image was downloaded (the images are sensibly torrented although the player software itself does not seem to be), getting the system running was extremely easy. You just click on the image, it loads up and you update within Ubuntu as normal.

Getting Parallels working was not as as easy. I tried a standard DVD from a Linux Magazine, that failed with an X error where the X window could not be started. So I downloaded a text based installer and ran through that. It had the same problem and after reading this item in the Parallels Knowledge Base I took a guess at the problem and set the resolution during the text installation to be 1024 by 768. That sorted the issue and after that the major problem was networking. The Parallels installation did not seem able to share my wireless connection. Once I connected my Ethernet cable then the instance updated fine. Oddly once I set the VM to use Shared networking I could use the Wireless connection but counter-intuitively setting the Ubuntu instance to use the Wired connection. I guess at that point Parallels was able to weave a little magic and make the connection available and the issue of whether the physical hardware was Ethernet or Wireless was completely irrelevant.

Both systems run their virtual machines very quickly but VM Player seems to be the better suited to rapidly stopping and starting the machine. It works pretty much like a normal application, you fire it up and close the window when you are done. The Parallels application is much less seamless. Both applications use a similar amount of space to save their state, VM Player perhaps runs a bit fatter from my experience.

VM Player is pretty amazing for a product that is offered for free and is definitely a well-done teaser product. If you have never run a virtual machine before I would definitely recommend giving it a spin. Parallels is a slick and excellent program but its focus on running Windows under OS X seems to have led it to not being able to create a trouble-free installation experience for the leading desktop Linux distribution of today. That is a big mistake and even Parallels’ relatively low price tag of £50 to £60 does not excuse it. Some things should just work. After all at some point you are going to appreciate having the flexibility to install a OS how you like and at that point you may be more tempted to upgrade your existing solution than switch to a new application altogether.

Java, Software

Setting up a Derby Database

Okay so I currently I am setting up a number of databases on my own V-Server and I thought it would be helpful to make a few notes about the current Java databases and how easy they are to run in Server mode. The two biggest databases are Derby and HSQLDB, this post is about Derby. Both databases are really geared towards the embedded space and generally focus their documentation and tasks around this. In their default setups they are both pretty insecure for running on a public network, neither for example defaults to using passwords to authenticate logins.

All the databases are getting setup in the same basic way. Each database is going to be run in the userspace of a dedicated UNIX user and that user is meant to be accessed via SSH and SSH Keys. All the datafiles will reside within the user’s space. I’m not going to go into that as it is fairly straightforward and is probably better covered by the various UNIX admin guides you can find around the internet.

So Derby first then, well I have played around with Derby before so I hoped this would be the easiest. One thing that you need to know about Derby is that its documentation is good but it is organised into several different documents… by a madman. There is no apparent logic, rhyme or reason to the way information is included in one document or another. When setting up the server I had to jump between the Developer’s Guide, the Tuning Guide, the Server Guide and more unusually the Tool Guide. If you have the same experience then don’t worry, you’re probably doing it right.

Having downloaded the Derby package unpack it to the root directory. I find it helps with upgrades to create a symbolic link ~/derby to the actual installation directory. You can also create a profile environment variable DERBY_HOME that points to $HOME/derby.

With that all setup you can simply run ~/derby/startNetworkServer and you should be in the basic network server business. This is where it gets a bit more complicated. Derby will look for its configuration in the directory where you start it not in DERBY_HOME. So you need to create a file in $HOME to configure the behaviour of the server.

To require authorisation you need to properties created in the properties file. Remember that the format of this file is a standard Java properties file. The two properties are:

  • derby.connection.requireAuthentication=true
  • derby.authentication.provider=BUILTIN

You should now restart the server. Now when you want to interact with the database you should need to provide a username and password. You have to check this though to make sure it works.

Run the ij tool from the command line: try to create a new database with something like the following

connect 'jdbc:derby:test;create=true';

You should get a message saying something like ‘Invalid authentication’. If the database is actually created then the database is probably not picking up your properties file, which in turn is likely to be an installation issue.

All being well we can now add a user to the properties file. User information is also a property so to make the file manageable you probably want to use comments to divide up the file into relevant sections and try and keep all the user setup in the same place. The format of the user entry is derby.user.USERNAME=PASSWORD. So for example


Okay now restart the server and login via ij again. This time use a connection URL like the one below.

connect 'jdbc:derby:test;create=true;user=test;password=changeme';

This should now create a new database under HOME and give you access to it normally. Drop out of ij and confirm that the test directory has been created.

That is pretty much that now, from here on in you can connect to your server database instance as you would any other database server.

Written like this the setup must seem very basic and quick to perform, which is good. However when I was finding my way with it, it took over an hour and most of that time was taken up with looking for things in the documentation. Nothing is logically organised with Derby, for example the configuration properties are all described in the Tuning Guide. Except the network control properties which are described in the Admin’s Guide.

Unlike code DRY is not a good idea unless you are going to very rigorously modularise the documentation. Even then why not repeat something if it means that all the information relevant to task is one place?

Derby has a great feature list but I wonder how many users are ignorant of what it can do because of the poor documentation?