Today is the monday after FOSDEM 2014, and I'm slowly waking up.
Being in charge of the video team, and after having spent a whole
week preparing followed by a whole weekend stressing about, today is a
day of slowly waking up from hibernation and returning gear to various
rental companies.
At FOSDEM 2013, we had recorded five rooms. Even though we did lose a
few talks, I felt pretty good about the whole thing, and I think we did
pretty well then. It had been my plan to increase the number of rooms to
be recorded from 5 to a reasonably higher number say, 10 or
so but
someone convinced me to
do
all of them.
I'll readily admit I was afraid. Scratch that, I was terrified.
Petrified, that we wouldn't be able to pull it off. For previous
editions, we'd kept the number conservative, since video work is a
high-risk business: if something goes wrong with volunteers work (say,
the heralding volunteer doesn't show up), you find a replacement, or you
have a staff member introduce a speaker, and the show will go on.
Not so with video work: if something minor goes wrong, you will most
likely lose content. If something minor goes wrong in one devroom, I'll
deal with it. If something minor goes wrong in 20% of devrooms, that's 4
to 5 devrooms, and I can't deal with it. Moreover, finding enough
volunteers to manage the video for five rooms was a challenge last year;
I couldn't even begin to imagine how to do so for
22 of
them.
We did work out a way that didn't seem
too far-fetched, and
that might work: why not look for volunteers from the devrooms
themselves? But then, they couldn't be expected to have the required
experience, so we'd have to do a lot of handholding.
The week before FOSDEM, four of us sat down in an office in Mechelen,
and started preparing. We had a lot to do; and when you do, more jobs
keep being added to the pile; TODO lists tend to grow longer, not
shorter. Installing servers, testing cameras, setting twinpact
dipswitches, configuring laptops. Changing a few tests in the config
management system, and having to go over the laptops again. Buying extra
gear. Buying yet more extra gear, several times. Buying cardboard boxes
when it appeared that the plastic foldable ones we'd ordered wouldn't
make it in time, and unloading the pallet of them when it did, after
all, so we could load them into the van with all of the other gear.
Laminating instruction sheets. Receiving shipments of rented gear.
Calling another supplier last minute when one of our other suppliers had
contacted us to let us know one of their cameras that they'd promised us
had broken down, and couldn't be repaired in time. Calling that
last-minute supplier
again when we found out that some of the
cameras we'd rented could do HDV only (and not DV), and we needed to
find more than the ones we'd already asked for. Discovering that
his cameras were of the same problematic model and so
also couldn't be used. The feeling of relief when he called me
a few hours later and told me he'd managed to scrounge up enough cameras
to help us out after all.
And then it was time to go to the ULB and start setting up
everything. On friday, we had a little bit of help, but did have to do
most of it ourselves. After setting up everything in every room and
testing as much as possible within the time constraints that we had, we
picked up the most expensive bits of the gear, brought it down to a safe
place, and went home.
On saturday and sunday, for me it was mostly a matter of handing out
gear to various devrooms, running around to fix various issues, and then
in the evening receiving boxes back, using a checklist to ensure
everything expected was in the box (and that things not needed would
remain in the room, or be sent back).
It was exhausting, to the extent that on saturday afternoon, I had to
take a bit of time off so I could go and rest.
I think it's safe to say that something like this hasn't been done
before. FOSDEM is a huge conference; most conferences with multiple
rooms don't have more somewhere between 5 and 10 of them. The fact that
we have so many more,
and the fact that we record
all
of them, puts FOSDEM video work in a class of its own, to the extent
that the professional cameramen I talked to in order to get the right
cameras would incredulously ask "what do you need
that for?"
when I gave them the numbers we needed.
As such, I didn't expect, nor was aiming for, perfection.
Unfortunately, with video work it is close to impossible to attain
perfection; I have told multiple people during the event that I would be
happy if we reached 85% of talks recorded at acceptable quality; and
though it is much too soon to say for certain, my gut feeling tells m
that we've probably achieved that.
One thing we hadn't planned for was streaming. During the past three
years, FOSDEM enlisted the help and sponsorship of flumotion to get
streaming going. Unfortunately, that did not work out this year; and
since we already had far too much on our plates with everything else, we
decided to forego streaming and focus on recording, only.
A few days before the event, however,
Steinar
Gunderson took it upon himself to fix that. While we couldn't
support him a great deal, we could give him access to the secondary
laptops (which weren't otherwise doing much anyway) on which he could
then do his thing. This was mostly transparent to us; we did communicate
to some extent (e.g., when a machine that had been down had fixed and
was working again), but he mostly did his thing while we did ours. Full
details, for those who want it, in the linked blog post.
Today, then, I spent most of my time handling hardware: waiting for
other members of FOSDEM to drive the van up to my office; waiting for
the laptop rental company to retrieve most of the laptops; waiting for
two of the camera rental companies to retrieve their cameras and
tripods; driving over to the final camera rental company to return their
cameras and tripods; and finally, driving up to the ULB to retrieve the
last laptops who had been copying files all night.
As I write this, some video files have already been uploaded to
the FOSDEM video archive. However,
these are extremely low-quality renditions of video snippets that need
to be reviewed; they are not ready yet for public consumption. When
those files exist, expect an announcement through
the main FOSDEM website.
The simple external-comments code is now complete enough for me to stop poking it on a daily basis:
This weekend I attended FOSDEM, as I did for the past 4 years. As always, it
was a great experience, even if most of the talks I attended were not so
interesting.
One of the great things about these events, is to get together with other Free
Software enthusiasts. One of them introduced me to the new kid on the block:
Back in 2006, the compiler in Ubuntu was 
Here s today s snapshot of Debian s unstable archive for the past year (at the start of May you can see the archive unfreezing after the Wheezy release; the gaps were my analysis tool failing):
Ubuntu s lines are relatively flat because everything that can be built with hardening already is. Debian s graph is on a slow upward trend as more packages get migrated to dh to gain knowledge of the global flags.
Each line in the graphs represents the count of source packages that contain binary packages that have at least 1 hit for a given category. ELF is just that: a source package that ultimately produces at least 1 binary package with at least 1 ELF binary in it (i.e. produces a compiled output). The Read-only Relocations ( relro ) hardening feature is almost always done for an ELF, excepting uncommon situations. As a result, the count of ELF and relro are close on Ubuntu. In fact, examining relro is a good indication of whether or not a source package got built with hardening of any kind. So, in Ubuntu, 91.5% of the archive is built with hardening, with Debian at 55.2%.
The stack protector and fortify source features depend on characteristics of the source itself, and may not always be present in package s binaries even when hardening is enabled for the build (e.g. no functions got selected for stack protection, or no fortified glibc functions were used). Really these lines mostly indicate the count of packages that have a sufficiently high level of complexity that would trigger such protections.
The PIE and immediate binding ( bind_now ) features are specifically enabled by a package maintainer. PIE can have a noticeable performance impact on CPU-register-starved architectures like i386 (ia32), so it is neither patched on in Ubuntu, nor part of the default flags in Debian. (And bind_now doesn t make much sense without PIE, so they usually go together.) It s worth noting, however, that it probably should be the default on amd64 (x86_64), which has plenty of available registers.
Here is a comparison of default installed packages between the most recent stable releases of Ubuntu (
The other leaderboards can still be viewed via the usual selector:
I've found it curious but not altogether surprising how this mere change of default dramatically affects one's mindset.
After years under Mako s loving care, iron-blogger is now under 
This year I am able to join the Debian Booth on FOSDEM again. I am also looking forward to meet some projects like foreman and many others. I also hope that I find the time to do some listmaster work, like accepting new lists or getting my new solr based search engine for lists.debian.org online. If you want to meet me, try the debian booth or drop me a short mail or twitter message (@formorer).
While the user may have simply pressed the "call" button, Lumicall alerts them to several ways that they may proceed:
For 
