Hacking at Random: Day 1 Ochtend

Hacking at Random: Day 1 Ochtend

So after passing out fairly early last night, i woke up far to early, and now i'm taking advantage of the quietness to get my bearings organized. Unlike most conferences, this one doesn't start presentations until sometime in the afternoon. They know their crowd here.

To give you all an idea of what's going on, let me give you an overview. Hacking at Random is the once every four year Dutch hacking camping conference and lan party. This year, there is a stronger focus towards technology and society than there has been in the past, so much so that the MPAA and Brein have shown up.

As for Fedora, we've put together a conglomerated village between various groups and individuals Alex C. and i know, made up mostly of the people we want to sit around and drink beer with. On the Fedora and CentOS side, we have Andreas Thienemann, Didi and Chris Meyer, and on the other side we have a mix of all sorts of visual artists and DJs from FreeJ/Dynebolic and a group of other people Alex knows from all over. We're also situated right across from the lake and right across from the CCC dome. We also have a few spaces staked out for a couple more people who are coming, including Dag Wieers. True to form, when Jaromil arrived, he managed to squat a tent, which someone set up, but left empty. Being the good citizen that he is, he made sure that the tent didn't stay open for junkies to come in and destroy. Now there's an active community revolving around this tent. (House squatting is legal in the Netherlands.)

We had planned to put together something marketable as a tent, but unfortunately, the Fedora banners did not arrive in time for us to use. I may try to convince someone to drive me home on Friday to check to see if they might be there by then, but until then, we are sitting relatively anonymous. Despite that, we already have a reputation as "Fedora and CentOS" here, and with these sorts of things, word of mouth marketing can be very valuable. We're still trying to get all of our things together in the tent, and at the moment, Alex, Buzz, and Zmatt are setting up lighting in the tent, so we can put on a nice light show later. I really want to publically thank Alex C and give my kudos to him. He's put quite a bit of his time in organizing this tent, and it's come out quite nicely.

I think my next task is to go around and try to market our BarCamp as much as possible. Compared to the rest of the event, our setup is quite small, but we're looking to hold a few media workshops, hackfests, and demos / presentations, and especially if you're doing it on top of a Fedora or Fedora based system. (Or even a derivative of a Fedora derivative, like Jaro is using.) Since BarCamps are the preferred format by Fedora for things, i will be giving the BarCamp presentation to the birds, and then people will go ahead and do their thing. If you're on the terrain, you should definitely come check it out on Saturday.

Hackers on a Bike: Done

Hackers on a Bike: Done

So i'm alive at the Hacking at Random terrain. My GPS gave me a grand sum of 58km. Now i'm sitting in my tent about ready to go to sleep. I'll post more as events unfold.

EDIT: I should add that i'm right across from the CCC dome. Sleeping is going to be a challenge.

Extra HAR ticket available

Extra HAR ticket available

It seems that Bert has come down with the Taco Hoest, and now i have an extra ticket for Hacking at Random available. If you are a Fedora Ambassador and would like to go to Hacking at Random last minute, i can arrange it for free. If you are just looking for a ticket, i can sell it to you for the original discount price of 150 euros. If you're in some kind of financial straits, we can work out a better deal as well, as the ticket is already paid for.

If you're up for it, i also have some space in my tent for you, and as i've already gotten the flu that's going around, you stand very little chance to get infected from me. Also appreciated is if you can come to Wageningen Tuesday night to help out with Hackers on a Bike, though this isn't required.

So let me know via the usual methods, but do it quick, HAR starts this Thursday.

Off to Arnhem

Off to Arnhem

Because Jeroen was relocating his servers today, i got stuck with a two hour blocker at work due to stale DNS entries in the local server. Instead of doing nothing, i decided to go home to fix my bike to get ready for Hackers on a Bike. I was planning on finishing up at home later in the evening.

Of course, i love sudden changes in plans. On my way home, Alex C. sent me a message about going to Arnhem to pick up some saddle bags with him, also for HoaB. So now i'm off on a bike trip to Arnhem and back tonight. This should be fun.

Infra on a stick

Infra on a stick

No sorry, that's not infrared but infrastructure. At work, i've been looking at switching our infrastructure over from our current puppet setup to a combined cobbler + puppet setup on top of puppetmanaged.org. The idea is to get our servers provisioned as quickly as possible with the right kernels, and just enough information to hook up to the network so we can remote connect to it. From there, everything can be managed via puppet, even puppet.

In order to get a feel for how this might work, i've been working on bootstrapping this from scratch. When you manage puppet via puppet, you need a base config to start from, and i've been trying to figure out the most minimal puppet config i can use to start up another puppet server. This got me thinking about a potential puppetmanaged.org live spin. This could be a CD or USB stick with either a barebones config, or respun for your local organisation with a git checkout of your internal configuration. There would be a running DHCP, DNS, Cobbler, Puppet and Func server on it. (Yeah, i know Func doesn't call it a server.) I'm assuming these are the basics you need to get your network up and running. The spin would also have a couple of scripts, where you can point it to up to five different servers, baremetal or virtual, get them up and running, deploy your local config if needed, and then via func, flip a switch so that they look at each other for updates, rather than at the computer running live.

I'm hoping i can get a good basic puppet bootstrap up and running before i run off to HAR.

Why Setuptools?

Why Setuptools?

I've been having alot of conversations with Jeroen (kanarip) lately about using setuptools instead of autotools for Python programs. He's not convinced, and to be honest, some of our projects in Fedora won't trannslate easily from an autotools setup to a setuptools setup. There's always room to improve, though it would be nice if autotools could automatically generate egg.info metadata and provide a convenient setup.py (or even a pavement.py).

Let me point out though why you might want to consider using setuptools instead of doing it wrong.

Part of the PEP 8 and PEP 328 is that absolute imports are used as often as possible. The idea is that you specify exactly which module needs to be imported to make the code work. Even if the code is relocated, it still works. It also means that the system can arrange the files any way it wants, so long the Python interpreter sees the same structure for the modules. This lets distro developers and operating system designers put Python modules wherever they feel necessary, as well as letting tools like virtualenv override the OS defaults on a per user or per application basis.

However, if you use an 'alternative' directory structure in your project, you might find yourself running into trouble. Say you have a module you're building called 'foo'. In your source directory, you have some directory /src/foo/some_code.py . There's also some script /run_foo.py at the top level of the source tree. If there is a line in run_foo.py that calls 'from foo import some_code', Python will raise an exception that the module foo cannot be found.

One common, although very wrong and messy solution is to catch said ImportError. In the corresponding catch block, there is alot of code to check to see where the code is being run. Then it digs into the internals of the module import system in Python so that it pretends it can really see the module foo and all its submodules. This is a rather unfortunate way of writing code, because it really limits what you can do in the source tree. For every script that you have, you may have to copy and paste this code. Furthermore, if you change the layout in the source tree, you may break all your scripts and have to change them manually. Finally, you have to question the sanity of putting file system specific code in a program. There are clear places where such code makes sense, but tinkering with the filesystem and path environment is not one of them.

Luckily, setuptools can do all this work for you. It can translate any on disk file system layout, such as /src/foo/some_code.py to foo.some_code for you. It can also direct installation to work properly. It can even modify your Python path environment so you can work directly out of your source tree. Any changes you make will show up automatically. Finally, we can isolate all the code into one place. The entire mapping is just a simple dictionary in one file, which is analogous to a configure.ac file.

I may post something later about where setuptools fails, and how we might be able to work around it.

Fedora == Debian ?

Fedora == Debian ?

Jeroen just told me that Fedora's Everything spin fits on 33 CDs (for the 64 bit version), which is just about as many CDs as Debian takes up. I guess we're the new debian.

I want a Fedora Everything on floppy. My work machine, despite having entirely new hardware inside right down to a complete lack of PATA controllers, has a floppy drive. I want to relive the experience of installing Debian via floppy, but this time in Fedora. For old times sake. I want a pony.