EuroBSDCon was recently held in Malta. The first trip report is from Marius Strobl:
First off, I would like to thank Andre Oppermann and his team for organizing such an amazing conference and developer summit! It would have been a great event even if it had not taken place in Malta but that location really made it outrageous. I totally did not expect to be able to go swimming in the sea at 9:30 PM as part of the social event with water that actually felt warmer than the surrounding air – just to mention one of the many highlights. Seeing all that people having fun in the sea at night with glow sticks around their wrists was a lovely sight, too. Thus, it speaks for itself that I am also very grateful to the FreeBSD Foundation for sponsoring me to attend EuroBSDcon 2013 as well as the associated FreeBSD Developer Summit, which both would have been unlikely undertakings without their generous support.
As with other BSD-related conferences, getting there turned out to be interesting as Ed Schouten had his seat next to mine across the aisle on that plane. Moreover, Ilya Bakulin and three additional OpenBSD folks working at genua GmbH that I know from other events also were on that flight. However, given that EuroBSDcon 2013 was not my first such conference, the list of usual suspects I have not met before gets considerably shorter over time. Nevertheless, I still managed to make contact with some nice people for the first time: Lars Engels, Andriy Gapon, Jeremie Le Hen, Navdeep Parhar, Colin Percival and Gleb Smirnoff.
Things I achieved during EuroBSDcon 2013 and the associated FreeBSD Developer Summit include:
- discussing the sparc64-specific aspects of the GET_STACK_USAGE macro with Alexander Motin (committed as r255937, later on merged verbatim to powerpc in r256007 by Nathan Whitehorn)
- discussing problems with the current powerpc and sparc64 implementations of the counter(9) API with Andriy Gapon and Gleb Smirnoff (unfortunately, no good and obvious solution was found and I have to benchmark some possible approaches first)
- getting a private status update about a GPL-free toolchain in NetBSD by Joerg Sonnenberger
- getting my shiny new PGP key signed by Dag-Erling Smørgrav in his role as FreeBSD Security Officer, as well as by some others
- talking to Colin Percival about getting freebsd-update(8) bits for powerpc and sparc64 in place now that we also and already have switched to cross-building the corresponding releases beginning with FreeBSD 9.2, which he intends to look over in the next couple of days
- talking to Baptiste Daroussin about possibilities for improving the situation with ports and packages for sparc64
- extending my English vocabulary by “wick” with the help of Isabell Long (one torch at the beach the social event took place was missing one)
The session that interested me the most at the FreeBSD Developer Summit was the “Networking” one. It was very informative to get a hold of the various performance issues in our network stack different parties are struggling with and how people intend to fix them. At EuroBSDcon, I probably enjoyed the talk “FreeBSD BHyve Hypervisor hosting Other Systems” by Peter Grehan best. Given that I last had a bit of look at BHyve as part of writing my master’s thesis – which also has some FreeBSD/i386 PV on Xen coverage – around April, it was surprising to see what progress BHyve has made since then.
Before and afterwards, I had some nice and interesting chats with Peter, too. As it turned out, he also is concerned with the direction FreeBSD is going with clang/LLVM and the possibility that some – in his case 32-bit powerpc – platform support will be sacrificed along that road. Moreover, as an employee of NetApp he once more confirmed that GPLed toolchains are of no concern for such companies as these bits are only used for developing products but are not part of the latter themselves. Before, Marcel Moolenaar essentially raised the same worries about FreeBSD/ia64 and effectively said the same about GCC and friends being no problem for Juniper at EuroBSDcon 2011. So the question remains: which are the mysterious vendors who we shall nuke all GPLed source code out of the FreeBSD base at any cost for?