FOSDEM 2016 is over

I went to FOSDEM 2016 this year with 8 other colleagues of mine and had a really really good time. A lot of good speeches and stuff to talk about and I feel very motivated for some new projects. Some of the stuff going on right now is incredibly exciting, especially with regards to containerization etc which is something I have a lot of personal and work related interest in. I will be looking into more details in that for the future…

What I did miss was a more “general networking” track with low level stuff like iptables, netfilter, iproute, wireshark, snort, etc. I’m just not sure if this is the right conference for that though. Gathering my thoughts and working out some of the project details in the upcoming week if I get time.

Using AWS EC2 instances for large builds

I experimented a few years ago with using EC2 spot instances (virtual server on the internet, but using unused server capacity). It was fairly successful, being able to run large calculations that should have taken weeks in a matter of days.

Since I started at my current job I’ve been running into building increasingly complex yocto images which keeps growing in size, at this point most images I build can take up to 6-7 hours to build on my laptop. This is an i7-4558U 2.8GHz cpu and 8 gigs of RAM so it’s not bad really, just not enough for these types of builds.

Again I started experimenting and I am really happy and impressed. So far all experiments are for open source projects etc, so nothing that has any non-disclosure agreements or corporate etc etc, I’d like to but this isn’t up to me really. I’ve setup an AMI on EC2 which I can instantiate and have up and running in 2-3 minutes, and then mount a 100 gig EBS volume where I store the sources and build data.

The same build that generally takes up to 6 hours on my laptop takes approximately 30-40 minutes on an EC2 c4.4xlarge machine (16 cores and 32 gigs ram).

My key findings so far is:

  1. Keep an AMI with all the build tools necessary/or script the setup.
  2. Keep an EBS volume with the long term stored data, gits etc for building and mount somewhere suitable in the AMI.
  3. Keep a micro instance (these are free/very cheap) around for mounting the EBS volume when you just want to check stuff out, mess around etc but not make builds.

Qt5.5 QtPositioning PositionSource unable to load due to missing symbols

December 31, 2015 by · Leave a Comment
Filed under: Development, Linux, Ubuntu 

I’ve slowly been working on a “Magic Mirror” for a long time now, trying to pick up some new technologies and making something fun. I’ve been working with Qt on and off for the last 10 years or so, but only peripherally, looking and awing over what they do. QML is absolutely awesome in my humble opinion.

A few weeks ago I started using Qt5.5 and ran into some issues executing the Magic mirror in a qmlscene now that I continued the project. It was fairly easy to reproduce but it seems to only affect the Qt binaries I’ve installed from the installer downloaded from qt.io. I’ve had verification that the code works with packages built from source, and trying to verify this on my own as well right now (building as we speak).

This is the sample code not working with qmlscene:

import QtPositioning 5.5
import QtQuick 2.0

Rectangle {
id: root

PositionSource {
id: positionSource
}
}

Bug is reported to qt.io here: https://bugreports.qt.io/browse/QTBUG-50227

Google photos refused to back up via mobile Hotspot

December 25, 2015 by · Leave a Comment
Filed under: Android, Phone 

I ran into a problem making my father’s phone sync pictures to Google photos, it simply refused to run, just saying “uploading photo 1 out of 489”.

After messing around on my own I started searching the net and finally found this rather obscure explanation, which fixed it for me. Apparently the phone realized it was running over a mobile Hotspot and refused to run because of it. See this blog post to fix it.

http://www.mihneadb.net/unblocking-google-photos-autobackup/

SSL certs updated

October 15, 2015 by · 2 Comments
Filed under: Frozentux.net 

The SSL certificates where updated on this site and I also switched over to a Comodo certificate from StartSSL as I screwed somethings up due to being tired.

If anyone has any problems with the certificates please let me know by email and I will try to fix it.

Systemd oneshot, ExecStop and RemainAfterExit

July 14, 2015 by · Leave a Comment
Filed under: Development, Linux 

I wanted to create a systemd service file that just ran 3 small commands today in a sequence on ExecStart and another set of reverse commands on ExecStop. My initial idea was to use bash syntax with ; between the commands (I keep forgetting that Systemd is not bash…), and the service file was set to being a oneshot file, which meant the ; was actually interpreted correctly, but all the ExecStop commands where also run directly when running systemctl start service.

So I read up a little on Systemd and ExecStart, this is what the http://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= page has to say:

When Type is not oneshot, only one command may and must be given. When Type=oneshot is used, zero or more commands may be specified. This can be specified by providing multiple command lines in the same directive, or alternatively, this directive may be specified more than once with the same effect.

So… that means the ; syntax will only work with oneshot apparently. Also, oneshot means that ExecStop runs directly after ExecStart. Further reading the documentation seems to indicate that RemainAfterExit=yes will make the service stay around according to systemd, so it will only try to execute the first time you run systemctl start, but not the second one. I don’t think this fixes that it runs ExecStop on start however, but I’m not sure.

ABS plastic with plastic modelling accessories

I’ve been building plastic models on and off since I was a kid, and very much so as of late, meaning that I have a lot of modelling accessories available at home.

I accidentally broke off one of the screw holes for the BabyNES Raspberry PI case (http://www.thingiverse.com/thing:449877) almost instantly due to the bad print quality. Reading around I didn’t find any obvious glues to use except acetone. In fact, I found a whole heap of warnings that the fat plastic would probably be hard to glue etc. Hence, I decided to test Revell Contacta Professional glue (http://www.amazon.co.uk/Revell-39604-Contacta-Professional-Glue/dp/B000KJPUL0) and it worked like a charm from what it looks like!

Since this worked so well, I tried some Italeri putty for plastic models (http://www.model-making.eu/products/Italeri-putty-for-plastic-models-28-ml.html) to cover up the sides which shows a lot of layers and some defects. Except the putty smelling really bad, it tacked on really hard and dried enough in just a few minutes to be sanded down.

Since the above went so well, I went ahead and did some more tests by printing a set of battered barrels (http://www.thingiverse.com/thing:535261) which turned out fairly crappy due to the print quality (mind you, much better than the first BabyNES case). Either way, perfect chance to test what could be done using those modelling tools/supplies. Here’s some before through after shots:

2015-03-14 19.43.32 2015-03-19 21.01.34 2015-03-30 22.52.22 2015-04-11 20.48.44

I think a lot of the plastic modeller materials could be used with ABS and possibly PLA plastics as well, especially where you want to make a structure, and then want to improve the details. There are much better printers out there with much better calibration of course, but these materials combined shows some great promise IMHO.

3D printing

February 11, 2015 by · Leave a Comment
Filed under: 3D printing, Development, Hardware, Personal 

wpid-img_20150209_132426.jpgI started working at a new company a while back if I failed to mention it called Pelagicore, doing automotive in vehicle infotainment systems the right way with open source, working in the community etc. They have a 3D printer (Makerbot thing-o-matic) that’s been standing around for a while really grabbing my attention and I’ve wanted to find the time to use it since I started there. I finally took the time and am happy as a clam.

I made my first 3D print at work two days ago, first of three pieces for a BabyNES Raspberry Pi 2 case (http://www.thingiverse.com/thing:449877), a small hatch. When I went on and tried building the two larger pieces I ran into troubles. Running out of time that day, I got around to try and fix it today. Disassembled the extruder stepper motor and realized a screw had dislocated from the vibrations. Re-screw it and assemble everything again, and this time, it worked! Got top and bottom parts done before leaving for home today and am fairly happy. They will do.wpid-img_20150211_163900.jpg

The print quality is pretty shoddy, a lot of settings needs to be tuned I guess, and the print speed was probably too high for the unit. Judging by the software installed, I should probably install newer software and redo the calibrations using those instead. Still, awesome to work with this :)

wpid-wp-1423688980633.jpeg

Iptables-tutorial and ipsysctl-tutorial on github

I guess I should have done this a long long time ago. Both the iptables-tutorial and the ipsysctl-tutorial source code are now available on github. Many many years ago I had an idea of putting the version control system out there for use, but I never realized it for various reasons. Both these documents are old by today, but the basic information is still valid and will likely be for a long time to come it seems.

I apologize for the version history, I moved from CVS in a rather rude way to SVN without keeping the history, which was what I used back in those days.

I invite anyone and everyone to do edits if they wish to and send me pull requests to fix the issues they find, or to add the documentation they’d like to add.

The iptables tutorial is available at:
https://github.com/frznlogic/iptables-tutorial

The ipsysctl tutorial is available at:
https://github.com/frznlogic/ipsysctl-tutorial

Project build speed importance

I began writing this several years ago but never published it for various reasons. I think some of the thoughts are still really interesting, I joined a company named Pelagicore some months ago and we do some rather large builds at this company, similar in build times in the project I refer to in this text, but with some major differences. This build is based on yocto and it actually works really well once you get through the first build (currently a scratch dev image build is up to 4 hours in time, but after that it’s able to rebuild only changed software and recipes as necessary. The scratch build is heavy admittedly, but we are working on some ways to improve that as well, such as sstate caches, icecc distributed build systems, and so forth. I think with modifications we could get those 4 hours down to under an hour, which would be really sweet. Anyways, I thought I’d post this text as is, even though it’s not finished, just because and since I re-read it right now 😉 .

Original text


Again, I’m struck by the importance of a proper build process in projects. No matter how small or big the project is, the build must be kept fast and working from get go to the end — which means its end of life cycle. I am currently working in a large project with a huge code base where the build system is, in my opinion, next to completely collapsed. Build time is in excess of 1-4 hours, and the automated test-suites take from 3 hours to 7 hours to complete, depending on how thorough a test-suite you choose. A gigantic heap of time is spent just…. waiting… waiting…. waiting. Just to make a simple one line edit and then compile to see if it compiles can take up to 4 hours. I’ve previously been a bit spoiled with good and simple build systems, only occasionally running into really crappy build systems — for some reason, a lot of scientific open source software seem to be stuck in this category.

This time, I think I hit pay-dirt on “how not to do it”. Instead of focusing on the bad parts, I will try to focus on the things to do and to keep in mind. Nobody seems to like a grumpy person anyways, which I really am sometimes.

1. Keep the build system simple and manageable. Try to maintain the build system in a logical fashion and in a single language/system (scons/python, Makefiles, etc).
2. Expandable (new directories, files, etc)
3. Scalable (multiple CPU’s, machines, threads, etc)
4. Try to use as few frontends as possible (a single top makefile for example, with targets depending on what you want to do), and keep people informed of changes. Wiki with history via RSS is _perfect_ for this. This doesn’t mean you can create a script to build something, then 2 months down the road delete it because it is no longer needed, it causes a lot of stress for developers who just barely had a chance to find the script.
5. The programmers are (most likely) your customers.

Next Page »