Rookeries v0.16.0 – Cross-Platform Support

On Wednesday night, I released version 0.16.0 of Rookeries, my developer/designer friendly static site generator! What makes this release exciting is that I added cross-platform support for macOS and FreeBSD! Also I setup an cross-platform installer, that works on all 64-bit x86 Linux distros including Windows Subsystem for Linux (WSL) 2.0. And I plan on supporting Linux, macOS (OS X) and FreeBSD as first-class systems going forward.

Also a multitude of stability and UX improvements landed in this release.
You can download Rookeries and install it using the new cross-platform installer here.

Rookeries v0.16.0 screenshot

Now this took quite some time and effort, especially around figuring out cross-compiling and what each OS could reasonably support. Over the course of the next few weeks, I will be writing about the challenges and how I overcame them when adding cross-platform support. (Including a quick aside why I dropped native non-WSL Windows support, and took up FreeBSD instead.)

Do you know that my mailing list is the first to know about releases and developments around Rookeries? Consider subscribing to the mailing list to be among the first to know!

Packaging up a Rust Binary for Linux

Prologue

I should of written an update for quite some time. While I’ve been experimenting with marketing analytics, learning about data science, business development, doing DevOps with GitLab CI and various other things, I wanted to write up my learning when I had a chance to internalize everything. However what made me decide to write an update is this tweet from Chris Krycho. Chris runs the amazing New Rustacean podcast, which is a must listen for anyone interested in learning about programming in Rust.

How does one package a Rust app?

Chris asked about finding a good way to distribute Rust binaries across Linux distros:

Interestingly enough, I recently figured out how to package a small Rust CLI utility that I’m working on. My response was:

This post elaborates on what I meant with my reply.

Building snap packages using snapcraft

The fine folks at Canonical (the makers of Ubuntu Linux), have created something called snap packages. These packages and associated package manager help developers distribute applications (desktop, cloud, etc.) in a safe, isolated manner. I currently have slack installed this way. snaps isolate apps by having the package maintainer declare the capabilities an app requires (network access, access to system files, the GPU, home directory, etc.), and then ensuring the apps can not escape this sandbox.

Basic Setup

Getting setup with packaging a Rust crate was not too hard:

  1. Install snapcraft: sudo snap install snapcraft --classic
  2. Create a snap template inside your crate project: snap init
  3. Edit the generated snap/snapcraft.yml as per the documentation.
  4. Build the snap using snapcraft.
  5. Install the resulting snap with sudo snap install my-cool-rust-bin_x.y.z.snap --devmode --dangerous (this assuming you are experimenting with building a snap)
  6. Add you should be able to distribute your app as a snap now. (See the caveats below.)

Caveats working with snaps

Now there a bunch of caveats when working with snaps. And for my own Rust utility, I found these too taxing and I decided to go with creating a standard Debian package instead. However if I wanted to target multiple distributions and my app didn’t have a very unorthodox setup (my app relies on using the Chrome WebDriver to control a networked device managed by dd-wrt), I would probably have gone with a snap instead:

  • You need to know what capabilities your app needs: file access, network, etc. and you need to declare the appropriate interfaces in your snapcraft.yml
  • Using something other than my local system (be it a Docker based build or using a different base like base18), failed terribly at least for Rust.
  • Whether or not I’d have more success if my base system was the recommended Ubuntu 16.04 and not 18.04 is an outstanding mystery.
  • The snap confinement, even on the much more liberal devmode, works very well. No amount of coaxing on my part, let me use system paths when trying to spawn a process. This could just be me though, as not declaring network access did not block my app.
  • The docs could of been clearer about what was the latest recommended approach. (Still way clearer than the documentation for creating a DEB or RPM from scratch.)
  • Knowing which libraries (for the type of base system) your app needs takes a bit of experimentation. (e.g. I needed libssl1.0 for some builds and libssl1.1)
  • I have no idea how the classical confinement should work, and it is not recommended either way.

The end result for me was a working snap package, but an app that would not work when called from an installed snap. However I think snap packages are probably the way to go moving forward (or a similar format like flatpak). Since I only plan on targeting local Ubuntu 18.04 installs, I ended up creating a Debian package instead.

Building a Debian package with Cargo

I found a nice utility for creating a deb out of a Rust crate, called cargo-deb. After installing the crate with cargo: cargo install cargo-deb, I simply ran cargo deb and I was done. cargo-deb looked into my Cargo.toml for the metadata, ran a build and a few moments later I was the proud owner of a Debian package. Since my app relies on the chromium-browser and chromium-chromedriver packages, I added a small section in my Cargo.toml as so:

[package.metadata.deb]
depends = "$auto, chromium-browser, chromium-chromedriver"

The $auto is something that the Debian packaging mechanism needs, and that is the comma separated format that DEBs use.

Building a RPM from a DEB package

Now this the part that I didn’t do this time around. However I figured out how to create RPM packages from DEB packages a few months ago. The trick is to use the alien utility to create a RPM out of a DEB:

sudo alien --to-rpm --scripts --verbose my-cool-rust-bin.deb

For the record, I did not try to improve or debug the resulting RPM. (This entire effort was for a product that failed to launch.) However as part of my tests I was able install it and run it from on CentOS VM.

Epilogue

Anyways, I would recommend the cargo-deb and alien approach, if you are not planning to distribute a Rust app across a multitude of Linux distros. I would recommend dipping into snap if you plan on distributing something more commercial and wide-spread like a slack or kubectl. And I hope that helps you on your Rust app packaging for Linux journey!

Fixing Docker on Linode (Linux v4.18.16)

This week as I had some downtime after PyCon Canada, I started working on resolving all the issues that I postponed. One of these issues involved applying security updates to my Linode server and rebooting the server. However when I did so… I noticed that the Rookeries site went down. When I logged into the server, I quickly found the problem: Docker refused to start after the kernel updates.

As this bug report on Docker for Linux says, there is an issue with the latest Linode kernel when it comes to OverlayFS.

This causes the containerdservice that docker-ce is dependent on to not start. When looking at the logs (using sudo journalctl -xe), you’ll see an error along the lines of:

modprobe: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open builtin file '/lib/modules/4.18.16-x86_64-linode118/modules.builtin.bin'
modprobe: FATAL: Module overlay not found in directory /lib/modules/4.18.16-x86_64-linode118)

Thankfully there is a workaround to resolve this problem. From the instructions you need to an override configuration for the containerd service:

$ mkdir -p /etc/systemd/system/containerd.service.d/
$ cat << EOF > /etc/systemd/system/containerd.service.d/override.conf [Service]
ExecStartPre=
EOF
$ systemctl reload
$ systemctl restart docker

Anyways, I hope this helps if you run into the same situation.

Command-line JSON Formatting with jq

About 2 or 3 months ago, when testing a deployment of a microservice at work
with Eric, our head Ops admin, we were looking at the JSON output of one of
the REST endpoints. Rather than looking at the raw output from curl, I
piped the output through JSON tool in the Python standard library:

$ curl -X GET -s http://rookeries.org/status | python -m json.tool
{
    "app": "rookeries",
    "version": "0.4.9"
}

(I will give you a couple of examples based on calls to Rookeries, rather than
the actual service call, since that API isn’t available publicly yet.)

Eric seeing that suggested I try out a utility that he uses: jq which is
great for formatting and querying JSON
.

Installing jq

jq is a utility in C, and fortunately there are binary packages available for
it in the latest Ubuntu LTS (14.10). Installing it via aptitude (or apt-get):

$ sudo aptitude install jq

Pretty Printing JSON

The simplest use case for jq is to simply pretty print JSON output. This is
done by piping the result of a CURL command to jq with the parameter ‘.’:

$ curl -X GET -s http://status.bitbucket.org/api/v2/status.json | jq .
{
  "status": {
    "description": "All Systems Operational",
    "indicator": "none"
  },
  "page": {
    "updated_at": "2015-09-03T08:03:55.275Z",
    "url": "http://status.bitbucket.org",
    "name": "Atlassian Bitbucket",
    "id": "bqlf8qjztdtr"
  }
}

Formatting JSON in jq

It is also possible to format the output of the JSON to display only relevant
information. For instance if I want to find out the status of the components
that make up Bitbucket I can do the following:

$ curl -X GET -s http://status.bitbucket.org/api/v2/components.json | jq .

That however will give me a whole lot of extra data that I might not want. So
instead I might to narrow down and re-format the JSON data to something more
manageable with some jq magic:

$ curl -X GET -s http://status.bitbucket.org/api/v2/components.json | \ 
jq '{src: .page, components: [.components[] | \
    {id: .id, name: .name, status: .status}]}'

{
  "components": [
    {
      "status": "operational",
      "name": "Website",
      "id": "g0lfj4sv2fhf"
    },
    {
      "status": "operational",
      "name": "API",
      "id": "k0x2yw1435v7"
    },
    {
      "status": "operational",
      "name": "SSH",
      "id": "qmh4tj8h5kbn"
    },
    {
      "status": "operational",
      "name": "Git via HTTPS",
      "id": "c1qmcrcbc5zy"
    },
    {
      "status": "operational",
      "name": "Mercurial via HTTPS",
      "id": "vmbzxbbjz05j"
    },
    {
      "status": "operational",
      "name": "Webhooks",
      "id": "rfzky0v13fbp"
    },
    {
      "status": "operational",
      "name": "Source downloads",
      "id": "28h8dvv2qfzw"
    }
  ],
  "src": {
    "updated_at": "2015-09-03T08:03:55.275Z",
    "url": "http://status.bitbucket.org",
    "name": "Atlassian Bitbucket",
    "id": "bqlf8qjztdtr"
  }
}

I won’t explain that particular string in detail. But it will basically
craft a new JSON object, and generate new filtered objects when iterating
over the old array. Overall jq is pretty neat and is extremely fast to work
with.

There is also a Python bindings library for jq. I am considering using it to
help with mapping JSON into Python objects. However I have not played around
with it long enough to know if the extra dependencies are worthwhile or
whether or not it will bring a lot of benefits to Rookeries.

Reference Links

Distro Hopping

Sorry for the much delayed update, however this year has been an hectic and busy one. (New job, new house, lots of random unexpected events along the way, like two funerals and two weddings in a single month, etc. Long story.) Plus I really hoped to change blog platforms, but that is a story for another time.

Explaining the Journey

With so many things changing in my life, I decided to change up the Linux distribution I’m running. Now I have a large set of requirements being both a developer and gamer. I need a distribution that can handle Python, Java, Android and Qt Linux development. Also I want my distro to run Steam, and handle the Nvidia Optimus graphics card in my laptop, properly.

(Sidenote: A word to the wise, avoid Optimus cards as they are a pain to setup under Linux. I got mine because I naively assumed that all Nvidia cards are easily and nicely supported under Linux. Recently I heard that Nvidia promised to help the Nouveau devs to make the Optimus experience under Linux nicer. But I would not hold my breath to wait for things to get better soon.)

Long Story Short

The shortest version of the story: After doing a fair bit of distro hopping including using some uncommon distros, I am back to using Kubuntu.

Specifically the path I took was:
Kubuntu → openSUSE → Mageia → Debian → Linux Mint → Sabayon → Kubuntu u2192

The rationale behind all this? Well read on. 🙂

Kubuntu → openSUSE

After hearing about Canonical’s plans to use their own display manager “Mir” instead of “Wayland”, and experiencing random breakage with Kubuntu I decided to change distros. When I heard that the main dev behind Kubuntu was not going to be funded by Canonical, I decided it was time to jump ship.

I decided to retrace my steps, and try new versions of distros that I used in the past. Technically before I started using Kubuntu I ran on Gentoo Linux. But I was not about to go back to compiling and configuring everything on my system. So my first stop was openSUSE.

SuSE and now its community driven variant openSUSE, always has been a very slick distro in terms of supporting KDE.  The version I was running was no different. I was also encouraged by the large number of packages available including a nice setup for both Steam and bumblebee (this being the program that adds decent support for Nvidia Optimus under Linux).

openSUSE is a gorgeous distro overall, except for one very important issue… openSUSE feels like it was built for a corporate desktop. The number of PolicyKit warnings that I received whenever I tried to suspend and resume was surreal. While I am familiar with the lingo and ideas behind SELinux, AppArmour, etc, I could not for the life of my figure out how to get my laptop to resume and suspend without some silly PolicyKit message blocking me. openSUSE was not meeting my needs.

openSUSE → Mageia

With openSUSE failing me, I decided to go further in time to my original distro Mandrake/Mandriva. I found out that some Russian firm had bought out the French made Mandriva and as part of a general restructuring effort laid off some of the maintainers. These maintainers started their own version of Mandriva called Mageia. While the distro and its infrastructure is still fairly young, I was encouraged by the fact that some experienced maintainers were behind the project.

I was amazed with the amount of polish but into a budding community driven distro. I ran against some rough edges with Python support, but those were resolved with some help and new updates. I was impressed and I took my first steps to becoming a maintainer myself. The community was very receptive and welcoming. While I ended up using Mageia for weeks, I did not stay with the distro.

Why didn’t I stay with Mageia? I could not get bumblebee running on my machine. I could of fought some more, learn how to maintain a package and help build out the distro. But after some introspection, I realized that I simply do not have time contributing as a maintainer to a distro. There is a lot of work involved, and considering everything going on in my life right now, I needed to get a distro I could rely on and work with right now.

Magiea → Debian

Debian seemed like the logical choice for a stable Linux. The distro is entirely community driven, and has been around forever. So after a bit of haggling with the network installer, I managed to get a KDE desktop running on Debian. Debian definitely run on mature, stable software, which is perfect for someone running a server or managing a desktop configuration that has been around for years. Unfortunately the Linux desktop has only become very stable and usable in past while. Also the Debian community are sticklers when it comes to open source licenses, and how distributable
the software is legally. Unfortunately again, closed source firmware and other software makes things much more difficult. Getting my Broadcom wireless network card, and my Nvidia graphics chip working was just not happening.

Also I assumed that since Ubuntu worked so well, that Debian would be just as well setup from the get-go. I realize now how much work Canonical put into configuring their Debian base and smoothing all the wrinkles out. However I was not up for doing all that work myself, just to stay with Debian.

Debian → Linux Mint

Debian stayed installed on my laptop for a mere two days, before I got fed up with it. The next logical choice to avoid Ubuntu, but get some of the niceties of the platform was to try out Linux Mint. One of my good friends runs it and she enjoys using it thoroughly. I also watched and read some good reviews about the latest stable release of Linux Mint 15, and how much polish the devs put into the KDE desktop. I was intrigued, so I tried it out.

Linux Mint 15 definitely has a lot of polish. However nothing that spectacular that does not come standard to KDE. Except for the extra System Settings panel to handle PPAs (private Ubuntu repos), which is pretty darn cool. I did run into issues with trying to run packages originally meant for Ubuntu. There were slight and subtle incompatibilities, and I eventually gave up trying to fix things.

Linux Mint → Sabayon

By now I had run into a moment of madness. No good easy-to-use RPM based distros remained to try out. Fedora sounded too experimental for my liking. The Debian universe had been pretty much a let down. I debated using Netrunner, a KDE distro, by Blue Systems. (Blue Systems being that weird German company that somehow funds KDE development on Ubuntu, Linux Mint KDE and Netrunner. But no one has an idea how they fund themselves. Maybe by European Union funds, which seems to be the popular way to fund nebulous entities and projects in Europe.)

So I had a moment of madness, and despair brought on by no new leads while looking at potential distros on DistroWatch (http://www.distrowatch.com/). In that moment I decided to try a system not based on the traditional package systems. That left systems in the Arch or Gentoo families. Arch itself fell into the too much maintenance category. Gentoo did as well. Manjaro looks promising, but I’ll wait until it matures or fades way due to its small team. I tried Sabayon Linux, something I did not expect to do.

Sabayon Linux is definitely much nicer than Gentoo to maintain. Everything worked out of the box too. Except Sabayon felt very much like an early adopters hobbyist distro. An update or a new package installation, downloaded half the universe. My laptop ran faster… and ate its battery so quickly that it would just shutdown… randomly while running on battery. I could run Steam and my development environments, just never without worrying about my laptop suddenly powering off.

I realized I could not continue on like this…

Return to Kubuntu

Now I am back to running on Kubuntu, and everything just works well enough. I could of gone back to Mageia, and hoped that the upcoming release of Mageia 4 would of resolved most of my issues. Ultimately I went back to Kubuntu, since for right now it works well enough and meets my needs.

I work with Ubuntu at my new workplace, plus I support a couple of other Kubuntu machines running at home. I no longer use the tools that caused me grief when some libraries changed in Ubuntu. For better or worse, support for new applications or hardware is targeted at Ubuntu. Also it is a bit of a relief that Blue Systems stepped in and now funds development of Kubuntu. Canonical’s plans for transitioning to Mir, still do not affect me at least on my current version. Also this might change in the upcoming release, and I maybe stuck on this version of Kubuntu for a while.

Or things maybe change, maybe Canonical will change its mind and work with the Wayland community. Maybe Nvidia will fix up their terrible driver support due to market pressures. Or maybe I will have to move off to Mageia or Manjaro eventually. In the meantime I can be productive, and once things will calm down again, maybe I’ll go on another round of distro hopping.

Update (2013 October 18): Just upgraded to Kubuntu 13.10 yesterday!  I am encouraged by the news that the Kubuntu devs will push forward on using Wayland and support Kubuntu into the future.  So it looks like I will continue using and enjoying Kubuntu well into the future.  Now I’ll just need to learn how to package DEBs, and I’ll be able to help out occasionally too. 🙂

Linux SATA HDD Issues with Samsung RF-711

OK, this is a quick post for anyone who is running into issues with using Linux on a Samsung RF-711.  Specifically this applies to Ubuntu Linux 12.04 64-bit.

Essentially what was happening, was that periodically my entire machine would freeze with the exception of anything currently running.  This kept on happening all the time, until I wasn’t able to even use the machine for minutes at a time.  Which is a real shame since this is a very powerful and nice laptop.  Essentially my SATA hardware kept on hiccing up and failing to handle DMA write requests:

> dmesg

… (output abbrevated for display purposes) …

[ 485.289702] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 485.289712] ata1.00: irq_stat 0x40000001
[ 485.289720] ata1.00: failed command: READ DMA EXT
[ 485.289742] ata1.00: cmd 25/00:08:c0:c6:a7/00:00:1c:00:00/e0 tag 0 dma 4096 in
[ 485.289744] res 51/40:08:c0:c6:a7/00:00:1c:00:00/e0 Emask 0x9 (media error)
[ 485.289747] ata1.00: status: { DRDY ERR }
[ 485.289750] ata1.00: error: { UNC }
[ 485.432598] ata1.00: configured for UDMA/133
[ 485.432629] ata1: EH complete
[ 490.745427] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 490.745437] ata1.00: irq_stat 0x40000001
[ 490.745444] ata1.00: failed command: READ DMA EXT
[ 490.745458] ata1.00: cmd 25/00:08:c0:c6:a7/00:00:1c:00:00/e0 tag 0 dma 4096 in
[ 490.745460] res 51/40:08:c0:c6:a7/00:00:1c:00:00/e0 Emask 0x9 (media error)
[ 490.745467] ata1.00: status: { DRDY ERR }
[ 490.745472] ata1.00: error: { UNC }
[ 490.887945] ata1.00: configured for UDMA/133
[ 490.887980] ata1: EH complete
[ 496.201083] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 496.201093] ata1.00: irq_stat 0x40000001
[ 496.201100] ata1.00: failed command: READ DMA EXT
[ 496.201113] ata1.00: cmd 25/00:08:c0:c6:a7/00:00:1c:00:00/e0 tag 0 dma 4096 in
[ 496.201116] res 51/40:08:c0:c6:a7/00:00:1c:00:00/e0 Emask 0x9 (media error)
[ 496.201122] ata1.00: status: { DRDY ERR }
[ 496.201134] ata1.00: error: { UNC }
[ 496.354593] ata1.00: configured for UDMA/133
[ 496.354618] ata1: EH complete
[ 501.667841] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 501.667850] ata1.00: irq_stat 0x40000001
[ 501.667857] ata1.00: failed command: READ DMA EXT
[ 501.667870] ata1.00: cmd 25/00:08:c0:c6:a7/00:00:1c:00:00/e0 tag 0 dma 4096 in
[ 501.667873] res 51/40:08:c0:c6:a7/00:00:1c:00:00/e0 Emask 0x9 (media error)
[ 501.667880] ata1.00: status: { DRDY ERR }
[ 501.667885] ata1.00: error: { UNC }
[ 501.810534] ata1.00: configured for UDMA/133
[ 501.810566] sd 0:0:0:0: [sda] Unhandled sense code
[ 501.810571] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 501.810588] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 501.810593] Descriptor sense data with sense descriptors (in hex):
[ 501.810596] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 501.810606] 1c a7 c6 c0 
[ 501.810611] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 501.810616] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 1c a7 c6 c0 00 00 08 00
[ 501.810627] end_request: I/O error, dev sda, sector 480757440
[ 501.810655] ata1: EH complete
[ 508.210222] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 508.210228] ata1.00: irq_stat 0x40000001
[ 508.210232] ata1.00: failed command: READ DMA EXT
[ 508.210240] ata1.00: cmd 25/00:08:c0:c6:a7/00:00:1c:00:00/e0 tag 0 dma 4096 in
[ 508.210241] res 51/40:08:c0:c6:a7/00:00:1c:00:00/e0 Emask 0x9 (media error)
[ 508.210245] ata1.00: status: { DRDY ERR }
[ 508.210248] ata1.00: error: { UNC }

So every save, every time something needed to get loaded into memory was terribly slow.  After a fair bit of searching I found that the issue related to the parameters being passed to the SATA drive where my Linux partition lives:

> sudo lshw

… (output abbrevated for display purposes) …

*-storage
 description: SATA controller
 product: 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller
 vendor: Intel Corporation
 physical id: 1f.2
 bus info: pci@0000:00:1f.2
 logical name: scsi0
 logical name: scsi2
 version: 04
 width: 32 bits
 clock: 66MHz
 capabilities: storage msi pm ahci_1.0 bus_master cap_list emulated
 configuration: driver=ahci latency=0
 resources: irq:41 ioport:e0b0(size=8) ioport:e0a0(size=4) ioport:e090(size=8) ioport:e080(size=4) ioport:e060(size=32) memory:f7606000-f76067ff
 *-disk
 description: ATA Disk
 product: SAMSUNG HN-M101M
 physical id: 0
 bus info: scsi@0:0.0.0
 logical name: /dev/sda
 version: 2AR1
 size: 931GiB (1TB)
 capabilities: partitioned partitioned:dos
 configuration: ansiversion=5

The nearest bug report that I can point to on Launchpad is: Bug #550559 – hdd problems, failed command: READ FPDMA QUEUED

The solution that worked for me, and seems to be holding is to:
  • Turn off SATA GEN3 support in the BIOS.
  • Set the AHCI to manual and then disable it.
  • Add the following kernel parameter to your grub config: libata.force=X:noncq You will need to edit your /etc/default/grub file as I have below. Copy the /etc/default/grub.original file if you don’t have the a grub file already.
  • Rebuild your GRUB and initramfs with: sudo update-initramfs && sudo update-grub2
Sample grub configuration file:

# If you change this file, run ‘update-grub’ afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n ‘Simple configuration’

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash libata.force=1:noncq”
GRUB_CMDLINE_LINUX=”libata.force=1:noncq”

Anyways, this took me a while to fix.  So I’m posting in hopes that it’ll be help out someone else.

The Next Big Thing

I am really excited that I am currently working on my next big project.  I won’t spill any details until everything is setup and ready.  This new project I hope not only will give me the opportunity to work on the technologies I love to work with.  But will also benefit the Linux and open source community as well.  More details will follow soon.

As part of this project, I will be doing some major changes to this site.  One of the major things will be the expansion of my portfolio.  It has been something I wanted to do for a long time.   Now I finally have the opportunity to do so. 🙂

Experiments with Wine Gaming

While I was working last month (and last year), I had the need and opportunity to setup Linux properly on my laptop.  Windows simply did not cut it for remote development.  After a bit of fighting with some graphics issues (yes, I got bitten by the switching between the Intel and Nvidia GPUs) I managed to setup my Linux system fairly well.  Yes, I am missing out on some of the nice, new hardware features on my laptop like the fingerprint reader.  Nor can I get a nice boot experience due to the combination of a strange widescreen resolution, using the proprietary Nvidia drivers and the plymouth splash screen.  Running full-blast with the Nvidia graphics card does not help my battery much.  But I can live with that.

The experience with using modern Linux and KDE can not be understated.  Not having to fight with your system when setting up development environments helps too.  The icing on the cake, was my most recent experimentation with Wine.  Back in the day when I started using Linux, getting any Windows program running nicely under Wine was a minor miracle.  An update could change that in a hurry.  Getting a 3D game running smoothly under Wine… just did not happen.

Now imagine my surprise when I tried to use Wine on my most current install.  After using winetricks a few times, and a tiny bit of experimenting I managed to run nearly all my Windows games under Linux without too much difficulty.  Nearly all my Steam powered games worked, including Deus Ex, Half Life, and Myst.  Even Microsoft games like Freelancer and Halo ran with very little work.  So did Risk and the original Homeworld with very little effort.  And yes Uru Online which is my favourite of the Myst series runs really well as well.  What makes this great–beside not having to reboot to play a game–is that old games will run with little extra effort without keeping some ancient version of Windows lying around.  Also important to note is that none of the games lagged under Wine, just some minor sound stuttering and weird cursor grabbing.  So one can enjoy most of one’s Windows games under Linux without needed to reboot necessarily.

Migrating to openSUSE

If you’ve followed my dents on identi.ca, you may have noticed that I asked people for their recommendations for a good KDE4 Linux distribution.  Well after a bit of thought I decided that I would move away from Kubuntu to openSUSE.  Why the change?

  • KDE4 is the desktop environment that gets all the attention and polish.  Kubuntu is great and valiant effort by the community to bring the Ubuntu experience to KDE4.  However, there is a lot of polish and integration missing that openSUSE provides.
  • A system that supports my hardware. From some weird reason, the Ubuntu kernel maintainers removed a flag that cause my DVD burner not to see CDs.  This is not the case in openSUSE.  I actually tried to burn something off a LiveUSB before installing openSUSE.  Yes, I could of recompiled my kernel with the right flags.  But if I wanted to do that, I wouldn’t have moved off Gentoo to Kubuntu.
  • A system with lots of packages and community repositories. This is why I didn’t choose some of the lesser known distributions.  openSUSE (and Fedora) do a good job at this.
  • A stable system. Fedora does not do that.  The upcoming release of Kubuntu LTS et al, seems to break things.  openSUSE is extremely conservative in this manner.
  • Something I am familiar with. This was not a hyper-important point, but I do like the fact that I’ve used SuSE in the past.  So installing openSUSE is a bit like going back to an old and comfortable place.

And so far I am pleased.  The desktop looks polished, quick and a great KDE4 experience.  All that said there are somethings I don’t like:

  • Configuration is weird. I am not a huge fan of YaST.  It is good, but somehow my brain has gotten used to thinking either configuration files or KDE’s System Settings.
  • Leaving Upstart. Upstart is really, really neat way of dealing with services.  Now I’m forced to think in terms of rc.d runlevels and I’m not a happy bodkin.
  • NXServer installation breaks things. Oh yes it does.  I fought for quite a while with getting my OpenSSH server starting at boot.  It looks like the bootscript for nxsensor (nxserver’s statistics gathering engine) screws up runlevels.  Never ever had this issue in Ubuntu.
  • No DEBs. I miss DEBs,  aptitude and various DEB tool.  I’m hoping that zypper and yast manage RPM dependencies in a saner manner than what I remember from 2004-2006ish.

Somethings I look forward to trying out:

  • How easy updates work. openSUSE 11.3 is in the works, and I can hardly wait until it comes out in July.  I got a taste of KDE 4.4 via a backport  PPA in Kubuntu.  And I want that that goodness, without my system acting weirdish after the update.
  • Easy to do backups. I could not for the life of me setup a decent backup scheme under Kubuntu.  openSUSE provides a backup module right into YaST.
  • Better performance. So far openSUSE feels snappier than Kubuntu.  We’ll see what will happen once I restore all data from a backup.
  • Developing and distributing KDE and Qt with ease. This is a huge one.  I want to get into programming in Qt and enhancing the KDE experience.  I’m hoping that the tools and build system in openSUSE makes this braindead easy.

Nokia N900 – The Penguin Has Landed

You may have noticed that I’ve dropped off the side of the Internet somewhat. Life can get busy at times, especially for someone who sometimes gets muddled up with time management and priorities. Another compelling reason for this is that I recently bought a Nokia N900. And I’m still getting used to incorporating it into my day to day activities.

Getting It Home

Unfortunately, Nokia does not sell the N900 in Canada. In theory it might eventually. But I wasn’t going until the Canadian duopoly of Rogers and Bell along with the CRTC got around to doing so. So much for Canada being a leader in telecommunications technology. Instead I bought my N900 through Amazon and used Shipito to forward my parcel. Later I found out that buying from Dell may have been a cheaper and faster alternative. It took about three weeks but I eventually got my toy.

Hardware

I must congratulate the engineers at Nokia for coming up with solid feel to the N900. I would of preferred a metal body like my old N810. But the N900 is definitely not as flimsy and plasticky like my Nokia 5800 XpressMusic phone. The touchscreen is quite sensitive and responsive much like the iPhone’s. The sliding keyboard also feels great. Each key nicely rounded, depresses in a solid quiet manner and gets illuminated in low light conditions. The 5 Megapixel Carl Zeiss camera takes great pictures with good resolution and great colour balance. My 5800 in comparison took decent photos but everything was a shade of grainy grey. The auto-focus on the camera leaves much to desire. But it might be a case of my not knowing how to use the software. The N900 takes MicroSD cards, which helped with migration away from my old phone. The internal memory is a massive 32 GB. Sound quality of the speakers is excellent. Great feeling stylus as well.

I loved the large full kickstand on my N810. Apparently the preproduction units of the N900 also had this design. However the production N900s have a small kickstand built into the lower frame of the camera. It took my quite some time to find it. And since the kickstand is off-center the whole device wobbles on its kickstand. Not cool. The real scary thing is the micro-USB connector. The power adapter for the N900 recharges the device using the micro-USB. And the port itself is surface mounted to the circuitry. I’ve read quite a few horror stories involved where the port detached from the device! So I’m paranoid, and extra careful with plugging in the micro-USB cables to the N900.

Software

The UI on the N900 screams wow. The Compiz-like 3D views and effects win everyone who sees the device in action. A phone should not be able to look and act so sexy. The UI is intuitive and very finger friendly. Web browsing is where the N900 excels. The swirl zoom in and zoom out, smooth scrolling and fast rendering makes web browsing fun. The browser fully supports Javascript and Flash, so the experience is comparable to using a full desktop browser like Mozilla Firefox. The N900 also has a great PIM/contact management. Combine it with the Hermes app from Maemo extras, and you have an awesome contact management that integrates your contacts on various messaging, microblogging and social network services. Amazing. There are a few nice apps available through the repos and the Ovi store. Including the fun games of Bounce Evolution and Angry Birds.

It is not all roses in the software realm. The N900 while a mobile computer and all that jazz is still a mobile device. Space and energy constraints plague every mobile device out there. So there is a limit to how much multi-tasking one can do. Fair enough. But sometimes the device grinds to a slow halt with just a few apps on. Why? I get it why it happened when I copied my 6GB music collection off my MicroSD onto main memory. Maybe I need to restart the device once in a while? But why two browser windows, two instant messaging apps and a music player can stall the device… Also the Maemo5 platform used on the N900 is new, so there will not be the number of apps that Symbian S60, Apple’s iPhone and the Android app stores enjoy. Nokia has Ovi working for the N900, except payments are still missing. Hence my hesitation to say the N900 will work well for non-enthusiasts. It looks like Nokia also has similar feelings. Then again Nokia has said that Maemo6 will be the mainstream platform, with multi-touch support, app stores and all that jazz.

Thoughts, Ideas and Dreams

This review is reaching epic proportions now. In short, I love my little N900 mobile computer/Internet tablet/cellphone. It is definitely something I looked forward too. And I’ve owned a number of mobile computing devices already: Palm Tungsten E, Nokia N810 & Nokia 5800 XM. A great thing is that the device and platform has the potential of getting way better with time.

Related Links