GNU Guix Hackathon-09-2014

In the weekend of September 27th & 28th and to celebrate the 30th anniversary of GNU an on line hackathon of GNU Guix was held. Although I didn't officially joined, I took the chance to try Guix for the first time.

There are two ways of currently running GNU Guix, either it could be installed on top of an existing GNU/Linux distribution, or installed directly on bare metal (or a virtual machine for the instance). Since the virtualization platform I use is VirtualBox, this was my primary target, in contrast qemu is the preferred choice of Guix developers, because its GPL license I assume.

Being in alpha state, the GNU Guix distribution provides a very basic USB image to boot and install the system, VirtualBox currently does not boot from USB, so I had to convert the installer raw image to some format which VirtualBox could handle. I tried VBoxManage at first, but it didn't work or maybe I was unable to figure out how to do so, in the end I used qemu-img command to achieve the task.

In Gitorious you can find my notes and some guides I wrote during this two days of the hackathon.

The latest GNU Guix installer image version available for download is Guix-0.7 which is flawed, guix --version shows the right version but the bundled packages are from Guix-0.6. It is not a showstopper, since you can easily upgrade to the latest version right before installing to your hard drive. This little bug slowed my install a few hours until I found the solution when someone else hit the same problem in #guix at freenode.net

The installer script is rather basic, do not expect anything fancy like hard disk re-partitioning, much less a GUI. It does not mean that it is hard to install, any mididly experienced unix user should be able to use fdisk, e2label, mount, sed and other basic commands to get a running GNU Guix system. One thing I missed though was the lack of vi or ed text editors, my keyboard is broken and keys 'Z' and left 'CTRL' don't work. VirtualBox grabs hold of the right 'CTRL' for its own purposes and the only two editors available in the installer image are nano and zile (an Emacs clone), both unusable with my current keyboard.

Also the installer fetches pre-built binaries from hydra.gnu.org, sometimes this hosts is overloaded or simply unresponsive and you will get this "guix-system: error: build failed: unexpceted-end-of-file" message instead of the cool one "Installation finished. No error reported", just re-run the last command until the task finishes successfully. If everything went well, now you should have a shiny new GNU Guix system ready to be booted into.

EOF

SlackwareARM in Cubieboard2

From early this year I've been playing with an Allwiner SoC, the Cubieboard2 is a System on a Chip with 1GHz dual core CPU, 1GB RAM, 4GB NAND, 1 100MB Ethernet port, MicroSD card slot and a bunch of other niceties, expansion ports and what not. It comes preloaded with Android Jelly Bean, but there are several GNU/Linux flavors available.

Sadly I ain't very fond of none of the available distros, and Slackware has an ARM port which is now officialy endorsed by Patrick Volkerdi himself. So I decided to give it a try.

SlackwareARM has official support for some boards and community support for some others, the main difference is that the official ones work with the standard Slackware installer and the ones supported by the community don't. Luckly the SlackwareARM team provides a compressed mini-root filesystem with the bare minimal to bootstrap the system.

Here I'll give only an overview of the steps needed to bootstrap SlackwareARM 14.1 on Cubieboard2. Detailed guidelines are available in Spanish language in Mi Kiwi.

All my hardware runs some sort of Unix like operating system, everything I describe here was done in a laptop running Slackware64 14.1 with multi-lib enabled.

1. You need to get a miniroot file from here and unpackit somewhere.
2. You'll also need the u-boot-sunxi, sunxi-tools, sunxi-boards and linux-sunxi git cloned repositories.
3. Finally a cross toolchain to build the sources, get one from here. I did choose the arm-2012-03-57-arm-none-linux-gnueabi.
4. Build the sunxi-tools, u-boot-sunxi and linux-sunxi
5. Copy the u-boot-with-spl.bin to the mSD
6. Then copy the resulting uImage kernel and install modules into the rootfs directory.
7. Edit and compile the Cubieboard2.fex into the script.bin file
8. Edit the uEnv.txt file
9. Edit and compile the boot.cmd into boot.scr
10. Edit rootfs/etc/fstab

Place the mSD card into the Cubieboard2 and boot it, if you have an USB Serial converter you can watch/debug the boot and load of the kernel attaching your terminal to the serial console using either, cu, minicom or screen.

For the lazy bums out there, you can download either, a mSD card image file ready to boot, or the root filesystem compressed and the u-boot-with-spl.bin files to customize your install from MediaFire.

EOF

Surveillance, people and power

I just twitted about "The Day We Fight Back" a movement sponsored for some organizations like the Free Software Foundation, the Electronic Frontier Foundation, among other tech-related bodies and associations. Put aside the time (a decade at least) being known for my support to the free software and also open source software, which prompted me to start typing this post is the kind of job I'm doing nowadays.

Going straight to the point, directly under my control are around 10 cameras installed abroad the city where I currently live. This is not the first time I do security related development. And for the most part (thinking as an ex-volunteer firefighter) I really think that the current project which involves more than cameras is really helpful for the people in this city. Let's temporarily forget the goal of the project.

I think about the cameras as the eyes of first response corps, certainly these days (almost) everyone carries a mobile phone capable of doing free calls to the emergency number, a big chunk of this mobile users own a so called smart-phone capable not only of making the emergency call, but also most of these gadgets are equipped with sensors and in some cases software capable of sending geo-location data and media to the emergency control centres. What this devices can't provide neither replace is the training of first responders teams and dispatch operators.

So, the right mix of technology with trained and highly ethic people in charge of the cameras I was talking about in the first place, make the surveillance projects worth. The problem arises from an education and economics background. I can sleep fine every night, since I do a professional and transparent (to maximum allowed extent) work, I was grown educated by certain ethics and in a relatively comfortable environment. Speaking of my current work, all code I've written is being published with some sort of free or open source licence, so it can be openly audited. But what about the high rank officers, middle ground operators and other people with access to the technology and who are able to exploit it for their own purposes?

Technically, I or any person with the right skill set can create things that can be twisted into evil tools by other kind of skilled people, how do you control the later?

I could stop doing what I do, but some one else will do it anyways. The key is education which is the easiest part, since the other part, the economics are a bit more complicated to even think about, but easily controlled by education means though.

EOF