Open Game Art is a newly started site for
exchanging free Artwork. While one can easily get the impression that
there are loads of such sites around, Open Game Art is one of the very
few that actually is done right.

There are quite some sites like
Free Sounds around offering free artwork
-- but only free as in beer as the saying goes, not as in speech which
of course is really unhelpfull for FOSS projects. And even most of the
sites that have free content often only tell you the license on some
special pice of arts details page.

Open Game Art is quite different from
that. All the license you may choose as a contributor are free (both
in Debian and in FSF terms) and the license is available through a
search filter so you can find stuff that fits you project's licensing
policy. This list, and that's another thing I really like about that
site, is the availability of choice among common licenses including,
next to the copyleft class of licenses a fair share of more liberal
licenses like my personal favourite, the
zlib License.

And because such a site is just as good as it's amount and quality of
data I've started sharing some
recordings. I'm currently really
new to audio recording so I guess it'll take some time for me to
become really good. I'm considering putting some of my experiences and
stuff I've learned here.

What I really like about SFML is the readable
code all through the
project. Every time I was unsure what some function does having a look
at the actual implementation (and some OpenGL
and X11) knowledge turned out to be quite
satisfactory. This is, of course, aided by the fact that SFML's
development is driven by a single Developer, Laurent Gomila.

On the rather weak points I'm still hoping the to-be-released 2.0
Version of SFML will introduce something like a stable API which it
currently lacks (although the API has settled and there are no such
huge changes as from 1.2 to 1.3 in recent updates any more). SFML also
uses hand-made Makefiles for building (now supporting DESTDIR at least
-- in some non-standard way) and has the usual load of embedded
libraries which results in it's current load of patches.

For a nice time burner make sure you take a look at the python
binding's snake-like clone. It clearly misses some important aspects
to form a full game but it's nice nontheless. I have a (not-quite)
small
SFML based Project
myself, a forward ported game from my old DirectX days, however it's
unfortunately not yet playable again und rather stalled at the moment
due to lack of time.

So much for SFML. If you feel like it feel free to join me on writing
about well done pieces of software or just about pieces on how you
think it should™ be done and tell us where you found it happening.

Having my primary working Computer, a Lenovo Thinkpad, going into
repair at the end of December I finally got up to ordering on of those
TouchBook ARM based netbooks
I was looking at for some time. After some processing time it finally
got shipped in April and arrived here last Monday, time to write up my
first impressions.

Some words about the Hardware. The TouchBook ships with a so called
"Beagle Board" featuring a OMAP3 Processor, ARM Cortex A8 running at
600MHz, 512MiB of RAM and a 8GiB SD Card for storage. It has a 8.9"
touch screen and comes with USB and Bluetooth Sticks for wireless
connectivity. The Display part contains all the needed Hardware and is
detachable from the bottom that is just a keyboard sitting on the
secondary Battery. You can open the Top to get at 4 intern USBs (3
USB-A and one Mini-USB) where 2 of these spots are occupied already
for wireless networking and Bluetooth.

First experience

The TouchBook comes with an US Power Adaptor only so when I got the
device I was running for some tiny Adaptor to get the plug into a
normal EU Power Outlet (it's incredibly hard to get one for this
Direction while it's easy to get some travelling stuff to plug EU
Hardware into various different Outlets!).

When I finally booted it the first thing you'll notice is the touch
interface for the bootloader. That's quite a difference to
all-text-based old grub! The shipped SD Card offers 3 Operating
Systems, one custom Linux that might well be interesting to the
average User, a Ubuntu Karmic that really OK
for a Debianoid Hacker- both running a XFCE
Desktop - and a Android that is really slow and doesn't seem to be
good at anything. Needless to say I sticked with the Ubuntu for now.

What to not expect

Well this is a 600MHz CPU with half a Gig of RAM running of a SD
Card. So don't expect it to be good at anything that can profit from
today's High-End Hardware.

The good Points

First of all, I have to admit that the touch screen is a neat
interface, way superior to the Touchpad Area you'll normally find on
a Notebook - at least if you use the stylus. It's quite different from
the inside-the-keyboard trackball the thinkpads have of course.

The Website claims 10h
of Battery life and while I've emptied the battery much faster under
certain workloads (e.g. Playing cards) it does hold that promise with
emacs fired up in org-mode, IRCing on a server over SSH and the
mandatory wireless working. Same for a always-on on campus day which
just works.

Again putting the screen on the keyboard the wrong way 'round will
give you a touchscreen tablet with the keyboard out of your way, an
ideal configuration for playing. And I have to admit playing games
like gtkballs or aisle
riot real fun. So much fun
actually I'm currently thinking on whether it would be feasible to get
openpandora working on it.

What I'm really missing

There are two Properties that are really lacking from the device which
would make it (in my personal opinion at least) a whole lot better: A
simple Ethernet controller I could use to go online when sitting in
the server room doing some maintenance without taking my
WRT with me and some slot to store the stylus
when not using it where it's easy to get out (currently I'm having it
in my wallet).

Then there's something (maybe a Kernel Bug): The Wireless is unable
to find any new Access Point after disconnecting from some and walking
out of reach from that. Force-unloading the kernel module and waiting
30 minutes worked for me multiple times but that's purely
inacceptable.

Finally there are some minor glitches. The shiny red cover just gets
dirty every time you touch the thing and the Keyboard is really small
(what a surprise on a 9" device) and has some of the special Keys
(like the Home key) located at unusual spots (Page-Up/Down only
available through the FN modifier). Shift and End at the right side
are also labeled opposite from their actual function (at least on
Ubuntu).

The last ugliness is the top part battery only charging when the
device is running, which means you"ll have the TouchBook running all
night to get the battery charged and the Battery Monitor not working at
all (at least in the current version of the operating systems).

Where to go now

I've not yet come around to really play with the operating system
(apart from installing wicd, urxvt-unicode and awesome getting the
most needed of my working environment). As I'm a
DebianDeveloper I'll definitely need a
Debian running on it (although I was told it'll be slow with software
compiled for armv4te) and, as it needs to be running all night anyway,
I'll try out gentoo pending another SD Card
for experiments.

Secondly there's currently no useable conforming Common Lisp
Implementation in Debian for armel as far as I can tell. As arm was
already working it shouldn't be that hard, let's see if I can change
that but feel free to join me!

Final Notes

I was thinking of some mobile-ish note-taking device and remote ssh
terminal for University which the device
clearly can do even for 10h away from any power plug while being some
non-standard non-x86 device to toy on (It's actually my second armel
next to the sheeva plug mounted on my
window board.

As a final Remark: This blogpost was written on the TouchBook hacking
some markdown into
emacs while traveling by train
to Erlangen where I study on Sunday Night after having read some
chapters of
Cory Doctorow's Little Brother
on my E-Slick E-Book reader and
finished later in my Room.

Maybe I'll find some time to write a review for this device as well
one day!

So when I was travveling to my parent's for christmas it looked like
I'd have limited computer access. My
Netbook
is quite OK for reading mail but not really useable for any real
hacking. And my trusty Thinkpad (Z61m) was oopsing when X was running
so not much useable either. But as some Live CDs placed here were
working well I decided that this would be fixed by an reinstall. And
as I was reinstalling anyway I decided I could just choose
kfreebsd-amd64. Turned out to be a quite entertaining decision with
lots of stuff to hack away with

wireless

Bad news: there's no wireless support on Debian GNU/kFreeBSD at the
moment. This problem is tracked as Bug
#601803 so
for wireless internet you will need a (plain)
Freebsd chroot. Haven't tried this myself
yet -- busy figuring other stuff out.

SBCL

Having a FreeBSD chroot I decided to give
SBCL on
GNU/kFreeBSD another try
after having failed to get it working in a VM some time ago. With
quite some help on SBCL's IRC channel I managed to build a
patch
that enables building (you need to force a :os-provides-dlopen to the
feature list additionally).

There's currently no multi-threading working so I hae a project for
the rest of the hoidays (well lots of other stuff to do as well ;))

Audio

Some more user-related stuff now. As it is this time of the year I
wanted to listen to some
27c3 streams so I
needed working audio. However there's no OSS device available. Turned
out you just need to kldload the right module (here snd_hda) to get
sound working.

Volume was rather low although hardware controls of the soundcard
where at max. As that's all OSS there's no point looking for
alsamixer. Turns out aumix can do that here.

IPv6 aiccu stuff

Installing aiccu, copying the config in and starting did not work out
as well. I already tried to do that from within the
FreeBSD chroot already (which doesn't work
for some reason) until I discovered just loading the if_tun kernel
module solves the aiccu on Debian issue quite well. To get a default
route up the last step was finding /lib/freebsd/route again --
/sbin/route is a wrapper around that abstracting differences in BSD
route but not supporting IPv6.

There are many ways to run some commands simultaneously on multiple
hosts like cssh or dsh. They come handy for example when you are
installing software updates on a set of hosts.

dsh is a rather simple comandline tool allowing to execute a command
over ssh on multiple hosts. However it doesn't allow any interactive
input -- so you can't look at the potentially upgrading packages and
press y to accept and you can't go through debconf promts or
similar.

This is solved by cssh which opens a XTerm for every host and a
input area that is broadcastet to all of them. this is working really
well -- you can execute your update on all hosts and still do
individual adjustments just as needed: switch focus from the
broadcasted input to one of the terminal windows and anything you type
just goes there.

Now cssh has a big disadvantage: it requires a running X server (and
doesn't do too well with a fullscreen windowmanager). Requiring X is
quite a blocker if you need to run that ssh multiplexer on a remote
host, for example if the firewalling doesn't allow direct
connections. Fortunately you can make tmux behave as we want -- in a
simple terminal:

First you need a script spawning the ssh sessions in separate tmux
panes and direct input to all of them -- here called
ssh-everywhere.sh (you could also write a tmux config I guess):

So this is a collection of things I came about when trying to get a
DebianGNU/Hurd virtual machine running with kvm. Most of it is
properly documented if you manage to find that particular piece of
information.

Kernel Version

Due to a bug in linux 2.6.37 and .38 hurd will only boot if you supply
-no-kvm-irqchip which is not that easy if you are using libvirt. A
wrapper `kvm` script in the PATH will do, as will using a 2.6.39 kernel.

sudo

sudo will hang before returning from executing some command. I'm now
using screen and sudo -i which keeps you a working tty gets you root
and hasn't caused mayor trouble yet

sshd

openssh-server won't come up complaining about missing PRNG – and
indeed there's no /dev/{u,}random in the default install. fix is to
install random-egd from ports.

From the java point of view

Recently I had to get some Scala Tool working correctly. Unfortunately
there are basically no packages in the Debian
Archive at all so I had to use maven to install these (or download +
install manually). Being a highly paranoid person downloading and
executing code from the internet without any cryptographic
verification at all one after the other practically drove me
nuts. Looking a bit deeper I noticed that some of the software in
maven's repository have some signatures
next to them -- signed by the author or release manager of this
specific project.

Why secure sources matters

With my experience in mind I got some Input from other people. One of
the things I was told is that some scala tools just aren't security
critical -- they're only installed and used as the current user. In my
opinion this is, for my desktop system, totally wrong. The important
things on my private Computers are my GPG and
SSH keys as well as my private data. For messing with these no super
user access is needed at all.

Comparing to the Common Lisp situation

Being a Common Lisp fan of course I noticed basically the same problem
for installing Common Lisp libraries. Here the situation in
Debian is quite a bit better -- and I'm
working in the pkg-common-lisp Team to improve this even more. Common
Lisp has some maven-alike tool for
downloading and installing dependency trees called
quicklisp -- without any cryptographic
verification as well. However there's light at the end of this tunnel:
There are plans to add GPG verification of
the package lists really soon.

Comparing the maven and the quicklisp model

So there are basically two different approaches to be seen here. In
maven the software author confirms with his
signature the integrity of his software while in
quicklisp the distributor confirms all
users get the same software that he downloaded. Now the
quicklisp author can't and won't check
all the software that is downloadable using
quicklisp. This won't be doable anyway as
there's way to much software or a single person to check.

Now in some kind of perfect World the maven
way would be vastly superior as there's a End-To-End verification
and verification of the full way the software takes. However there's
a big problem: I don't know any of these Authors personally and
there's no reason I should just trust any of them.

Now comparing this to the Distribution /
quicklisp model. Here I would just have
to trust one person or group -- here the
quicklisp team -- to benefit from the
crypto which might be possible based on karma inside the using
community. However here I don't gain the possibility that the software
is integer.

However idealized if some of these pieces of software was forged
between upstream and the quicklisp team
and attacker would also intercept me downloading the software from the
same address so I get the source from upstream matching the checksum
from quicklisp -- assuming the
quicklisp team does indeed know the
correct website. Additionally I get the confirmation that all other
quicklisp users get the same source (if
the quicklisp guys are fine of course) so
no-one inside the community complaining is a good indication the
software is fine. For this to work there's of course a relevant
user-base of the distributor (quicklisp)
necessary.

Relevance for Debian

So how do conventional LinuxDistributions like Debian fit in
here. Ideally we would have maintainers understanding and checking the
software and confirming the integrity using their private key or at
least know their upstreams and having at least a secured way getting
the software from upstream and a trust relationship with them. Of
course that's just illusionary thinking of complex and important
software (think libreoffice,
gcc or
firefox for example). Maintainers won't
fully understand a lot simpler pieces of software. And loads of
upstream projects don't provide a verified way of getting the correct
source code though that's a bit better on the real high-impact
projects where checksums signed by the Release Manager are more common
than in small projects.

A misguided thought at the end

As I'm a heavy emacs user I like
to have snapshots from current
emacs development
available. Fortunately binary packages with this are available from a
Debian guy I tend to trust who is also involved upstream so adding the
key from his repository to the keyring apt trusts. Now my first
thoughts were along the lines "It would be really nice if I could pin
that key to only the emacs
snapshot packages" so this guy can't just put libc packages in his
repository and my apt would trust them. Now thinking of it again a
bogus upload of the emacs
snapshot package could just as well put some binary or library on the
system at some place in front of the real on in the system path
which would be rather similar bad.

At April 30, I took over maintenance of of
Debian's kFreeBSD
autobuilders. Means getting something
like 4,5k e-Mails this month (gladly no need to sign all those 4k
successful builds any more!), filling nearly 30 RC Bugs (quite a lot
of which got fixed just within hours after filling, wow!),
investigating some of the more strange build failures and such
stuff. In general it turned out to be quite some fun.

Quite interesting which libraries turn out to be rather central to the
Archive. I wouldn't have guessed that a uninstallable libmtp would
prevent a reasonable fraction of the builds to fail -- including
packages like subversion.

Packages builds failing because the disk space is exhausted may be
something most of us have already witnessed, especially those here
that use one of these small notebook hard drives. Build failures
caused by a lack of RAM might certainly be imaginable as well,
especially on highly parallel builds. But have you ever seen gcc fail
because the virtual address space was exhausted on 32 bit
architectures?

Also there's a interesting lot of packages with misspelled build
dependencies which sbuild can't find and therefore can't build the
package. Maybe having a lintian check for some of these problems would
be a good idea?

I'm also regularly seeing build failures that look easy enough to fix
-- like some glob in a *.install for some python package matching
lib.linux*. I try to fix some of these as I see them but my time is
unfortunately limited as well. Someone interested in quick&easy
noticed about these kind of issues? I could put URLs to build-logs on
identi.ca or somewhere on IRC.

There are also some really strange failures like llvm, which builds
flawlessly on my local kFreeBSD boxes all the time, inside and outside
schroot but hangs all the time in the same testcase when building on
any of the autobuilders (any hints welcome!) or perl failing on
kfreebsd-amd64 selectively but all the time.

I'm coming as well! Really looking forward to meet the people from Debconf9 again. Also people from the Games Team and the buildd and kfreebsd folks. And ideally there will be some more people interested in (Common) Lisp as well, we'll see

While
other people are squashing RC bugs
I was using this week to fix (or investigationg) some more kFreeBSD issues -- mostly looking at
failed build logs and trying to fix the problems and after some nice
fish for dinner writing things up.

First issue this week was #639178
a build failure in tar I had reported earlier and didn't manage to
process the response. After sending some findings to the bug I
noticed Petr was faster and did actually find out a lot more
detail. Short story: success in that test suite requires linux
behavior and the failure on kfreebsd is covered by what POSIX allows

#640012 postfix is hard-coding
kFreeBSD versions … up to 7 and therefore won't build on a 8.2
kernel. It also doesn't handle absence of NIS on Hurd and kFreeBSD
#545970

#640159 iozone3 just needed a bit
of massaging to combine the FreeBSD backend with the linker flags
needed for kFreeBSD

Installing the build depends for openjdk-* resulted in a
installation failure for some time. Looking closer it turned out a
minimal testcase was installing menu and python2.6 together. Turned
out dash's test builtin wasn't working
#640334 because it was relying on
the intuitive but not POSIX mandated behavior of the faccessat
syscall #640325

#640341 ed decided not to
build on kfreebsd-i386 in the 40 minutes between -2 and -3
upload. Without any actual source changes. Just trying agan tricked
it to build again but probably someone should look what went wrong
actually

#640385 owfs was failing to some
symbol difference (but otherwise building although being a *fs ;))

the gcc family of packages still has some heisenbug repeatedly
failing when doing regular builds on the buildds. Independent which
one. Multiple times in a row. Building on my test VM or my notebook
doesn't show that problem (but takes ~10h). Building on the same
buildd in the same chroot with the same sbuild flags and it's still
building fine.

If you just updated systemd and ssh to that host seems to hang, that's
just a known Bug (Debian Bug #770135). Don't
panic. Wait for the logind timeout and restart logind.

restart and stop;start

One thing that confused me several times and still confuses people is
systemctl restart doing more than systemctl stop ; systemctl
start. You will notice the difference once you have a failed service. A
restart will try to start the service again. Both stop and start
however will just ignore it. Rumors have it this has changed post
jessie however.

sysvinit-wrapped services and stop

While there are certainly bugs with sysvinit services in general (I
found myself several times without a local resolver as unbound
failed to be started, haven't managed to debug further), the stop
behavior of wrapped services is just broken. systemctl stop will
block until the sysv initscript finished. It will even note the result
of the action in its state. However systemctl will return with
exitcode 0 and not output anything on stdout/stderr. This has been
reported as
Debian Bug #792045.

zsh helper

I found the following zshrc snipped quite helpful in dealing with
non-reported systemctl failures. On root shells it will display a
list of failed services as part of the prompt. This will give proper
feedback whether your systemctl stop failed, it will give feedback
if you still have type=simple services and if the sysv-init script
or wrapper is broken.

zsh completion

Speaking of zsh, there's one problem that bothers me a lot and I don't
have any solution for. Tab-completing the service name for service is
blazing fast. Tab-completing the service name for systemctl restart
takes ages. People traced down to truckloads of dbus communication for
the completion but no further fix is known (to me).

type=simple services

As described in length by
Lucas Nussbaumtype=simple services are actively harmful. Proper type=forking
daemons are strictly superior (they provide feedback of finished
initialization and success thereof) and type=notify services are so
simple there's no excuse for not using them even for private one-off
hacks. Even if you're language doesn't provide libsystemd-daemon
bindings:

This is a
stable API
guaranteed to not break in the future and implemented in less than ten
lines of code with just basic socket functions. And if your language
has support it becomes actually trivial:

Note that in both cases there is no drawback at all on systemd-free
setups. It has the overhead of checking the process' environment for
NOTIFY_SOCKET or for the systemd package and behaves like a simple
service otherwise.

Actually the idea of separating the technical aspect (daemonizing)
from the semantic aspect of signalizing "initialization finished,
everything's fine" is a pretty good idea and hopefully has the
potential to reduce the number of services signalizing the
"everything's fine" too early. It could even be ported to non-systemd
init systems easily given the API.