Wifi problems with Elementary OS Freya on the ideapad 100

This week I had a problem where wifi suddenly stopped working on my Lenovo ideapad 100 15iby running Elementary OS Freya. I don't know what happened, but suddenly the machine refused to work with any access points. It would say I was connected, and I would have an IP address from DHCP... but there was no actual connection working. Chrome would just complain there was no internet, for example.

I ended up having to rebuild the Realtek rtl8723be wifi driver from the source repository here: https://github.com/lwfinger/rtlwifi_new/ but actually that was not too bad, because the instructions are quite simple. I just had to follow this post which seemed to work fine for me. But I did need to disable the sleep feature of the driver, which is mentioned as an extra step in the instructions. Otherwise the connection would keep dropping and then prompting me for my wifi password all the time.

So that was a slightly annoying problem! But I am pleased to have it sorted out. As I'm writing this I'm downloading a 750Mb file to make sure it's all OK. I'm currently at 500Mb and all is fine, so hopefully that's a job well done.

I have also noticed that Elementary OS Loki is now released, but there is no upgrade route from Freya, so I need to find some free time to do a backup and clean install. Hopefully that will be a smooth process... maybe I'll try running it 'live' first, without installing, to make sure that things work beforehand. That's a job for another day.

Vanishing mouse on my Lenovo ideapad

One problem I have found with my new Lenovo ideapad 100 15iby running Elementary OS Freya is an issue with the mouse pointer vanishing, as reported here. It seems that if you lock the machine, close the lid, or let it go to sleep, then after signing back in there is no mouse pointer. It's annoying because neither the trackpad or an external mouse seems to work.

Anyway, the solution which seems to work for me is just to replace Light-Locker with Gnome Screensaver. It means that the lock screen is not as pretty looking, but I'd rather have a mouse that works!

It's an easy fix and worth it, although it looks like future updates won't suffer from the same problem. So I look forward to trying that out when I upgrade to Elementary OS Loki. But I'm waiting for it to be released rather than using the beta.

New laptop for Linux experiments

So my trusty old Toshiba Satellite T130 has started to fail. The keyboard has started to go wrong, it seems to miss out random keystrokes, which is really annoying. It's a shame, because apart from that the machine is still working fine. But I decided that it was time for it to be replaced. I didn't want to spend very much money on a new laptop, because the old Toshiba was running Elementary OS very nicely. So I didn't need a super fast processor or anything. I ended up going for the cheapest laptop with 4GB RAM that I could find. So I am typing this on a Lenovo ideapad 100 15iby. It was less than £190, which is pretty reasonable I think. So far I am pretty happy with it.

This machine does feel cheap. It seems very plasticy and the touchpad buttons rattle a little bit as I type. I don't think that it is as robust as the Toshiba, but for the price it seems like good value. It only has a Celeron processor, but it still seems to fly along when running Elementary OS. When I first got the machine, it was running Windows and that was a slightly more painful experience. Although I only kept Windows for a few minutes - just long enough to apply the firmware updates from Lenovo so that I had the most recent BIOS. After that, I blew everything away and installed Elementary OS Freya from a DVD (the ideapad does have an internal DVD drive). I don't have anything against Windows, but I don't think that I'd be happy running Windows on this laptop - I think I would find it too slow on this hardware.

I had no problems installing Linux, everything worked right out of the box - even the special volume and brightness buttons on the keyboard.

After installing the OS, the next things I installed were:

  • Docker
  • Kate / Konsole (for coding in C)
  • Spotify
  • Chrome (and the Chromecast plugin)
  • Nim / Nimble / Aporia
  • FileZilla
  • TLP in the hope of getting more out of the battery

The ideapad version I've got does not appear to have bluetooth (I think that it's an optional extra on this machine) but I managed to find a tiny Bluetooth dongle on Amazon which seems to do the trick. So anyway, let's see how it goes!

First steps into the world of Nim

I was recently doing a bit of reading up on the Rust programming language, but a stray comment somewhere about the Nim programming language sent me off on a bit of a tangent. The thing that really got me interested in Nim was that it compiles to C, and I noticed that this brings quite some options for portability. One of the reasons why I like programming in C is that you can run the code on all kinds of machines, from tiny embedded devices to supercomputers. But that does come at a cost, because it takes longer and you often have lots more typing to do because of all that boilerpate stuff.

But it looks like Nim would allow you to be quite productive, whilst the resulting executables should still be efficient and fast. To get some ideas, I went off to Rosetta Code and found the Nim code for a simple webserver which looks like this:

import asynchttpserver, asyncdispatch
proc cb(req: Request) {.async.} =
  await req.respond(Http200, "Hello, World!")
asyncCheck newAsyncHttpServer().serve(Port(8080), cb)

Being able to create a webserver with just a few lines of code, and with the potential for the code to be portable and run on all kinds of devices seemed very tempting! By this point, I'd forgotten about Rust and wanted to explore Nim a bit further.

So whilst Nim has not reached v1.0 yet, it certainly looked very compelling. The compiler documentation made it look like cross-compilation was not that difficult, so I decided to try and cross-compile some code for a router running OpenWrt. Before going off and spendng a lot of time learning a new language, I wanted to see that I *really* can write portable code. I was very happy to see that in just a few minutes I had the example webserver code running on my TP-Link WR740N, as shown here:

To my amazement and joy, this really wasn't that hard. After installing Nim, I had to edit Nim/config/nim.cfg to point to my cross-compile toolchain, so I ended up with these lines:

mips.linux.gcc.exe =
mips.linux.gcc.linkerexe =

Then, after doing that I simply needed to pass the correct parameters to the Nim compiler, like this:

nim c --cpu:mips --os:linux webserver.nim

Which cross-compiled the example webserver ready for it to run on my TP-Link WR740N. That actually seems pretty awesome. I think that I need to learn more, perhaps I'll even go and buy the Nim in Action book. All this stuff worked perfectly without any trouble, which is pretty rare, so I am left feeling very impressed so far.

Docker and the MEAN stack

I have been reading the book: Write Modern Web Apps with the MEAN Stack: Mongo, Express, AngularJS, and Node.js and wanted a way to mess about with some examples on the various machines I use (since I'm frequently switching between Mac, Windows and Linux boxes). So I decided to try and Dockerify the process a bit.

I wanted to build a Docker container that I could use on whatever platform I happened to be sitting in front of. I also wanted to be able to run Node and Mongo in a single container. I realise that outside the development environment you'd likely want to split them, but for some simple development I didn't want to have to start up multiple containers.

Of course, when the container runs, I would want to check that it is working, so I also set about including a very simple MEAN stack application as a kind of "Hello, World!" example. But by using Docker Volumes it is easy to replace this default app with something on your local hard disk or perhaps with a Docker Data Volume Container which only needs to contain your app. So the simple default app just needs to prove that Node and Mongo are running.

So my first question was how to go about running both Node.js and MongoDB in a single container, and the solution I have gone with is documented here. It adds a docker-friendly init system to the Ubuntu image. This means that when the container is shut down the init process will try to shut down other processes gracefully, rather than leaving them to be forcefully killed by the kernel. The init process will also reap any zombie processes which may accumulate.

Having a suitable base image, I could then build my own container having specific versions of Node.js and MongoDB. Using specified versions means that I will have a stable set of binaries which will give repeatable behaviour during my development and testing. I don't want to waste time with version conflicts.

Anyway, the result can be found here: https://github.com/davidsblog/node-mongo/blob/master/Dockerfile. I am still tinkering with it, but if you look at the Dockerfile you'll probably get the idea. Both the location of the Node app and the data directory for MongoDB are set up as volumes, so you can override them at runtime. The container then just becomes an engine based on a set of stable binaries, and you can just provide it with your own code and data. You can test it like this:

docker run --rm -p 8080:8888 davidsblog/node-mongo

...and then point your browser to port 8080 of your container. You should see a simple app which allows you to post comments, where the comments are saved to MongoDB. But to switch out the default app to some of your own code you can do this (assuming you are in the directory where your server.js is located):

docker run --rm -v ${PWD}:/vol/node/start -p 8080:8888 davidsblog/node-mongo

...and you should now be running your own program (as long as it is called server.js and assuming it works on the same port).

In the container, the Node.js code is run via Nodemon, which means that when you make changes, Nodemon will restart the app for you - no manual restarting.

In the meantime, I can now mess about developing applications using the MEAN stack without installing everything on my local machine. Cool!

Experiments with Randomness

In software, the amount of randomness collected by an Operating System is called entropy. I have recently been messing about with entropy on my Linux boxes. This happened because I was fiddling with https (SSL/TLS) and cryptography relies on a good source of random numbers. The random numbers need to come from somewhere.

On most Linux machines, you can see how much entropy your system has by looking at the value in /proc/sys/kernel/random/entropy_avail.

If your machine runs low on entropy, it means that any cryptographic calculations will either have to use a weak source of random numbers (and therefore be less secure) or will block until there is more entropy (meaning that things on your system might appear to slow down).

So out of curiosity I decided to experiment with this. I took my CPU monitoring webserver and adapted it to watch the entropy available rather than the CPU use. If you're really interested, the code can be found on GitHub here.

NOTE: you probably won't want to install the entropy monitoring webserver on your machine, because you would not want to tell the outside world how much entropy your system has available. I am only using it for experimentation and learning.

But ... here are some experiments that I did:

  • Driver Activity

    On Linux, the system uses various sources of entropy. Some of the entropy comes from drivers - including the keyboard and mouse drivers. This is why a VM or perhaps even a 'headless' machine might struggle to generate good quality random numbers - because it is unlikey to see the same type of driver activity. The following experiment demonstrated the effect of mouse movements on the amount of entropy available in a VM:

    You can see the entropy increasing much more rapidly when the mouse moves.

  • Process Activity

    Starting a process on Linux consumes entropy. So you can try running some commands in a terminal window to see the impact on your entropy:

    It's interesting to see the entropy drop as I'm running simple commands. I believe that a new process consumes entropy because it will use random numbers for the Address Space Layout Randomization.

It was reasonably interesting to do those experiments. There is some useful further reading about random numbers and cryptography here. I also found some work that has been done locally here in Cambridge at this blog which was interesting ... and also involves the Raspberry Pi.

FSV, or "this is a Unix System... I know this"

In this months (June, issue 16) Linux Voice magazine, they mentioned that the 3D File System Visualizer like the one used in the original Jurassic Park movie has been ported to modern Linux machines. It was just too tempting, so I went and tried it out. I managed to get it running on my laptop, this is how it looked:

That video clip was recorded in realtime, so considering this was done on a 5 year old laptop I was quite impressed. I was doing that on Elementary OS (Freya) and these were the commands (I hope that I noted them all down correctly):

git clone https://github.com/mcuelenaere/fsv
sudo apt-get install autogen
sudo apt-get install autoconf
sudo apt-get install libtool
sudo apt-get update
sudo apt-get install libgtk2.0-dev libgl1-mesa-dev libgtkgl2.0-dev
sudo apt-get install libglu1-mesa-dev
cd fsv
sudo make install

Then you should find the fsv program in your /usr/local/bin directory. You just need to run it.

Although in the end, it was not really as exciting as I expected ... (perhaps that's because there weren't any Velociraptors) but it was a cool thing to do. Apparently, the version used in the Jurassic Park movie was called FSN and was made for IRIX systems.

Elementary OS upgrade

I've just upgraded my old laptop OS (it's a Toshiba Satellite T130, and must be about 5 years old). Previously, I had been running Elementary OS Luna which I found pretty impressive. It had a couple of niggles ... for example the file manager app always seemed to take ages to load. Now that the new version, Freya has come out, I decided to try it. I went for a complete wipe and reinstall.

I am quite pleased with the upgrade. The slow file manager startup time has even gone away, and the whole OS seems even more polished. However, I have had a problem with the pointer getting corrupted if I did drag and drop, which was annoying, I am currently trying this fix, hopefully that will make it go away. Anyway, I celebrated a successful reinstall by going off to the Nasa JPL Wallpapers site and grabbing myself a nice background, so here's a screenshot:

I think that it's still the most visually appealing Linux I have tried and I'm quite happy that I've upgraded to the latest version. It runs nice and fast on my old laptop, and it's nice to have something that looks good without eating all your CPU cycles.

Remote monitoring *VoCore* CPU use

So I really wrote my CPU monitoring webserver program to be able to monitor my Raspberry Pi, but hoped that the code should run on other Linux machines too. Indeed, I have also been testing it in a virtual box running Debian. The code is runnable from Xcode on my Mac, but unfortunately it's a simulation only for testing purposes, because /proc/stat does not exist on Mac OS. So, for the moment, it definitely won't work on the Mac.

But I did think that it would work on OpenWrt, so decided to try it on my VoCore. In anticipation I had already put the necessary stuff in the makefile, so all I needed to do was go to a box with OpenWrt cross compilation set up and do this:  make vocore.

Then I copied the resulting binary executable to my VoCore and it worked straight away. I even made a recording of the initial run for posterity:

Since all the resources (html and javascript files) are embedded in the executable it is really very simple to do, just copy and run a single file. The version compiled for the VoCore came out at 112 Kb in size. Hopefully that's not too bad. I could compress the resource files if space was really important, but I haven't felt the need to do that.

It's pretty good to see this running on a machine about the size of a postage stamp. Obviously I could make it just show a single graph when it runs on a single core machine. Perhaps I'll do that when I get some time.

Vocore has arrived

My tiny Vocore Linux machine has arrived from China. Cool! So far all I have not done much more than boot it up and check that I can log in and stuff. Oh, and I tried the web-based interface too. It seems to be working fine. A Linux box about the size of a postage stamp, what’s not to like?

Mine has the dock attached to it, so I’m just using a USB cable to power the device. I tried to power it off a USB socket on my MacBook … but there wasn’t enough current to allow the wifi to start. Some lights flashed on the Vocore initially, but then it went off a few seconds later. I think that this means that there is not enough current to allow the wifi to start operating… But when I ran it of a dedicated USB power supply it was fine.

Because I have the dock, I used an ethernet cable to connect to the Vocore, which means my laptop can remain connected to my home wifi and I can still use the Vocore with its default settings.

But when sitting in front of the command prompt I got as far as making some LEDs go on and off with commands like these:

echo 255 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness
echo 0 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness

The advantage of doing that is that they use an LED which has already been connected up on the dock … so I didn’t need to wire anything up. I’m going to try the same thing in a little C program next. Blinking an LED is an ideal little test program

The next thing that I’ll do is try my own minimal webserver, which might be useful if I start running out of space. So that’s next on my agenda.

Apart from that, I’m not really sure what I’m going to use it for. I’m sure I’ll think of something...