Installing Ubuntu on a Dell M3800

For a while I was having problems with my laptop having too little memory. It was a Dell XPS13 developer edition. A system I was very happy with, but the 8GB RAM was proving to be too little in some cases. So I wanted something more powerful. I chose the Dell M3800 because it has a recent i7, has 16GB RAM and a HiDpi screen with a 3200×1800 resolution. No “developer edition” though but (being a full-time Ubuntu Linux user) I went bought it anyway.

I installed Ubuntu 14.10 on it. and encountered a few issues.

  • The system was a bit slower to compile than my previous one even though it has more memory and a faster processor. Looking into this, it seems this was caused by overly aggressive settings to keep the temperature down. I tweaked the termald settings to kick in at 75 instead of 45 degrees and this halved the compile time! For details look at “Thermal Issues” and “Powerclamp”.
  • Parcellite (a tool which keeps clipboard memory) does not seem to work. I replaced this with diodon which seems to be a better tool anyway.
  • The system needs to be rebooted a lot more than my previous one. There are two problems which sometimes occur which need a reboot to fix. One is that the screen turns black – as if I am not doing anything except it kicks in after a second or two instead of five minutes. I turns back on when I move the mouse but gets annoying quickly. The other is that the wifi sometimes gets very disfunctinal, hardly being able to connect to the local network and when it does only has very limited bandwidth.
  • Sometimes the keyboard becomes quite unresponsive. This may be application related. I have encountered this most in pgAdmin and Inkscape. Inkscape also seems to crash very easily.

The HiDpi screen is a challenge in itself.

  • Ubuntu itself (or Unity) looks great. The trick is to set the “Scale for menu and title bars” setting in the display menu. I used “2” as setting so the screen looks as if I have a resolution of 1600×900 but with more detailed rendering.

  • Firefox also works fine. You just have to set “layout.css.devPixelsPerPx” to 2 in about:config.
  • The same trick works for thunderbird. To access about:config, go to Edit → Preferences → Advanced → Config editor.
  • Chromium only half works. Many windows and pop-up boxes are positioned and scaled wrong.
  • Unfortunately many application don’t (or only half) support the scale setting. For example pgAdminIII is mostly ok, but all rows in query results are only half the size of the text displayed in them.
  • Java applications also don’t respect the scale. In some cases this can be fixed by configuring the text size (for example in IntelliJ IDEA), but the menus and icons stay too small. For the many, installing jayatana (Unity global menu integration) really helps.

In short, the linux support for HiDpi displays is clearly a work in progress.

Database migrations using Flyway, multiple modules for one schema

In our project we selected Flyway to handle out database migrations.

This is a great library which can easily be configured to do the database migrations for you. For example using Spring all you need is:

<bean class="org.flywaydb.core.Flyway" init-method="migrate">
    <property name="dataSource" ref="dataSource" />
    <property name="locations" value="scripts" />
</bean>

Basically you point it to the data source and the package where the migration scripts can be found (or migration classes).

In our setup, the migrations script have names like the following (conforming to the default conventions):

  • V001__initial_schema.sql
  • V002__initial_data.sql
  • V003__additional_script.sql

Flyway will check if the selected database schema (default is “public”) is empty. If it is, the table which stores information about the database migrations is created and the found migrations are run. If the schema exists, it will use the table to figure out which migrations need to be performed. As a sanity check it verifies whether there are any conflicts between previous migrations and currently available migrations.

Unfortunately this does not work in our setup.

  • The project has multiple modules which all have their own migration scripts but share the public schema.
  • We also use Activiti which manages its database structure itself, creating the tables before Flyway kicks in. This causes Flyway to stop as the migrations table does not exit and the schema is non-empty.

Fortunately Flyway allows for this case using the following configuration (shown here for two modules).

<bean class="org.flywaydb.core.Flyway" init-method="migrate">
    <property name="dataSource" ref="dataSource" />
    <property name="table" value="module1_schema_version" />
    <property name="locations" value="scripts/module1" />
    <property name="initOnMigrate" value="true" />
    <property name="initVersion">
        <bean class="org.flywaydb.core.api.MigrationVersion">
            <constructor-arg index="0" value="000" />
        </bean>
    </property>
</bean>
<bean class="org.flywaydb.core.Flyway" init-method="migrate">
    <property name="dataSource" ref="dataSource" />
    <property name="table" value="module2_schema_version" />
    <property name="locations" value="scripts/module2" />
    <property name="initOnMigrate" value="true" />
    <property name="initVersion">
        <bean class="org.flywaydb.core.api.MigrationVersion">
            <constructor-arg index="0" value="000" />
        </bean>
    </property>
</bean>

There are a couple of tricks.

  • We use different tables for the migration info for each of the modules (using “table”).
  • We use a different classpath location for the migration script for each of the modules (using “locations”).
  • We assure Flyway always initialises itself (using “initOnMigrate”). This assures the migrations table is always created if it does not exist.
  • Assure all out scripts are run using “initVersion” setting it to “000”. When initOnMigrate is true, a record is written in the migratinos table to indicate that Flyway init was run. By default this is marked as version “1” which would then means that our first migration script (“V001__initial_schema.sql” in the example above) is not run as it is also version “1”.