Many photos are available here; feel free to add your own to the pool:
http://flickr.com/groups/938355@N22/pool/

The booth was absolutely crowded for most of the conference. Even though it was slightly odd that OLF was just an expo room over from the US Fencing Competition, it was a great opportunity to introduce new users to Ubuntu and Linux in general, and most of them left the show very impressed. I also had the chance to attend a surprise BoF meeting, though I snuck in late.

A few shoutouts:

• Steve Stalcup (vorian) - setting up the booth the night before and working it
• Derath - getting System 76 and Hackett & Bankwell on board and working the booth
• Delvien - working the booth and helping out the new users and visitors
• Jono - thanks for the shoutout yourself at the keynote!
• Jorge - helping us out with organization of the booth and the BoF
• System76 - provided the nice demo laptops and discount coupons
• Intracorp Ltd - Hackett and Bankwell comic books
• Canonical - thanks for all of the free swag and marketing materials! Seriously, it wouldn’t have been nearly as awesome without it all, and made our booth extremely popular.
• Ohio LinuxFest organizers - planning the event itself! We’ll definitely be back in 2009!

I’ll be posting full impressions tomorrow on FOSSwire.

One particular moment that I thought was interesting was when Jono asked who in the audience (of around a thousand) used Ubuntu, and 90% of everyone raised their hands. Someone post a picture of that in the Flickr pool above!

Though, I think the phrase “Show me some candy” will trigger a somewhat unpleasant mental image for those who attended Jono’s keynote from now on.

A day after I posted the last Xeiso-related entry here, I got some junk packages published. Those junk packages eventually were polished up into a state I now think is bearable. And now, I present a belated makeshift release simply dubbed: “Moar.” “Moar” is a milestone in which I actually feel happy with regarding web services integration (currently called the “Download” menu). No longer is there a simple text interface to download games, but images and requirements to go along with it, along with update checking.

If you installed Xeiso and haven’t updated it since my last post (how dare you) then be sure to wipe your ~/.xeiso directory; it isn’t compatible. Yes, I just broke backwards-compatibility. Being 0.1 gives me the right to do that.

If you haven’t installed Xeiso yet and want to give it a shot, don’t install the Python way. If you do, you will end up with a bunch of conflicting files if you ever try to install the packaged version. Save yourself some time and just use the PPA. I promise, if I make some commit to Bazaar that has some awesome new feature, it’ll be on the PPA within a day.

On a related note, the CD build is making progress. Here’s an older video of it running in VirtualBox:
http://www.youtube.com/watch?v=Up8ywfi8K3U

Yes, the demo game is supposed to crash. It doesn’t exist. But believe me, a lot has changed since that revision. If you’re interested in building a disk for yourself, see this page. Some of the packaging used to build the CD environment is in the branch as well. I probably sealed my fate of ever becoming a package maintainer by breaking probably every Debian packaging law known to man, woman, and lolcat, but it gets the job done for the disk. But don’t install the package included in that branch unless you want your system to meet certain destruction.

The release name is “Moar.” So what next? Aside from the obvious better CD integration, there’s a lot of work to be done. The sound system hasn’t even been started; no Python library has been working out too well for me yet. Then there is Xeiso Connect, the online services component. Ask me about that if you are daring. And of course, packaging. What would a game system be without games? The package format recently changed to make it all even easier. Documentation isn’t complete, but it’s coming. In the meantime, feel free to drop by #xeiso on freenode or shoot me an email if you want to learn some packaging basics.

As always, I’m open to suggestions, rants, raves, nitpicks, and the rest, but keep it constructive. Leave a comment or use one of the contact methods above.

Wind speeds in central Ohio hit 75 mph (~120km/h), nearly as fast as a moderate tornado.

Power was knocked out on Sunday. Calling AEP, if you were lucky, might have gotten you an automated outage reporting system if you didn’t get the “line busy” tone first, with estimates of seven days until power could be restored. Luckily for us, it came back on this morning after two days.

What was strange? There was no lightning, no thunder, hail, or rain, just heavy wind. No tornadoes were reported, yet the wind speed was already there. Almost every street was blocked off by trees, and as of right now, 30% of traffic lights in Ohio are non-functional.

I was going to take some pictures during the storm, but after being whipped in the face with leaves and stray tree branches I decided it was better to wait.

The damage here was minimal compared to other places. Cars were crushed, schools were shut down, and a 5-house fire was started in town from a downed power line.

Who else got hit?

I finally got Istanbul working right in addition to learning Cinelerra last night, so I figured I should at least get some demo footage out there. Check it out on YouTube. As of writing, that is the latest revision.

The biggest feature showcased in that video is the ability to download Xeiso packages, .xpk files. If Xeiso is installed with python setup.py install, then a MIME association is automatically added to open these files with Xeiso to install. By default they are installed to ~/.xeiso/xpk, but can also be loaded from /usr/share/xeiso/xpk for a system-wide setup.
The downloading interface is basic: it shows a package name and description, and then downloads the package to install it. A lot more will come out of that feature in the near future.

The web side of things has also been greatly improved. Xeiso.com has plenty of new documentation to have a look at. Currently under development is a web interface to game downloads in Xeiso, which will probably surface early next week.

Also on Xeiso.com is some new packaging documentation. It’s not complete, but it’s available if you want to have a stab at it.

The Live CD portion of the project has not been started. I’ve been holding it off to develop as a part of my class project for the year, so the pace will pick up very soon. But another reason for the delay is that I’m also trying to make Xeiso easily installable on already-running Linux machines. With the local installation will be a separate series of Xeiso “require-local” packages that don’t contain the game themselves, but call the game if it is already installed on the user’s system.

That said, while there will eventually be a Xeiso PPA, I do not want Xeiso to be in Intrepid. The project is still being constantly updated, and is not currently supported. If anyone manages to get it into 8.10, expect plenty of SRU bugs to be shoved down your throat. Daily.
Edit: PPA ready.

And finally: Revision 39 marks the beginning of more open development. Starting now, I will be accepting patches, merge requests, bugs, and blueprints, all of which can be done on Launchpad. There is currently an open blueprint for sound in Xeiso: while it is supported, Xeiso remains mostly quiet. Boring.

If you are interested in heavy development of Xeiso, start out by branching and making merge requests on Launchpad. There is no official development team (~xeiso is just used on Launchpad for friendly URLs at the moment) but one can be made when necessary. If you need specific help, mail me (my first name at xeiso.com) or visit #xeiso on freenode.

Xeiso is:

• A game console.
• An operating system.
• A bootable LiveCD.
• An intuitive interface.
• Open source.

Time to elaborate: it will be an Ubuntu-based system with a custom interface with the goal of making a fast-booting, open game console. I’ve been researching solutions for a few months now, and have been testing out various languages and methods, from C++/SDL, to Python/Pygame, and back to C++/OpenGL. But now I think I’ve finally found a compatible, fast development and fast running framework for the user interface: Python and Pyglet. Hey, if it can run an OpenGL ortho projection on a 1680×1050 screen at 60fps with minimal CPU usage, it’s good enough for anything.

I’ll stop blabbing for a few minutes while you watch this video:

Xeiso Early Tech Demo

That’s the basic interface. Keep in mind that that demo is relatively old; the current revision is varied quite a bit. But that’s the gist of how it runs: everything, from games to controller options, is configured and controlled via this “slider” interface. It’s intuitively simple: if an arrow appears on the screen, you can press that arrow on the keyboard to go there. Allows for blind and quick motions. Like it? Cool. Hate it? Great. Suggest an improvement on Launchpad or in the comments.

A lot of the meat is under the screen - there is a rather extensible packaging system that allows for anything to be run from Xeiso. In the latest revision (17) there is a basic Neverball package, though currently Neverball must first be installed. “Hey - if this is to be an APT-based distro/system, why not use dpkg?” Good question. Because in the future I’m hoping to support downloadable content - and remember we’re looking for a fast-booting system - “xpackages” are being used. It’s basically a tarball and module system, meaning that packages can be dynamically loaded into memory at boot from an external device without much delay.

Some planned features:

• LiveCD:
  • Fast booting: “Boot to X in 10 seconds or less.” Likely? Not for a while.
  • Ability to use the host HDD or an external device as a “memory card” to store game save data, additional XPackages, boot configuration, etc.
  • Automated CD build system (near completion)
  • Install to system w/ GRUB
  • Partial install: Copy most of the files to the host device, and chainload it from the CD to speed up boot
• XPackage:
  • Ability for banners, small animations that load on a preview screen (almost done)
  • Content distribution system for downloading games (still researching)
  • Patched games to support a freeze menu to reset, configure controllers, etc. (designing)
• Controllers:
  • Mouse/Keyboard, Wii remote, Joystick
  • Key customization
  • Multiple players

Working code is available on Launchpad. It’s still under heavy development, so if you make a feature branch expect it to be 99% incompatible within a day. I’m not currently looking for any main developers - as I said it is being worked on at a fast pace and things can’t easily be coordinated. (I’m having trouble keeping up with my own documentation!)
In the future, though, I’ll be looking for:

• Packagers - work with XPackages and patch games.
• Graphic artist - I’m not too creative.
• Someone good with audio. Can’t have a game console without sound! Mostly creating/finding tracks/sound effects for the UI.

Again - don’t contact me about getting involved with development yet - you will be able to soon.

So far, it seems okay in terms of speed (but who knows what will happen once more users find it) and is fairly simple. It is missing SMS, an API, and a bunch of Twitter features, but more important is that Jabber works. To top the whole thing off is that the entire service is released under the AGPL and uses OpenID.

I’m willing to see how long it holds out. Who wants to help break it? I’m at http://identi.ca/jacob (horray for early-adoption usernames). Anyone else out there?

Comments, suggestions? If you like it, pass it on!

Edit: I’ve reworded apt-get dist-upgrade, switched out xserver-xorg reconfigure and reworded description, and changed apt-get remove to purge.

There are currently two locations that you can attend; the wiki page will be updated with any more:

• Easton (Panera Bread)
• Lima (Rhodes State College)

Click the links above for driving directions and parking information. Both locations provide free WiFi. Bring money for food if you want. Bring friends!

Both parties start at 5:00 PM EST on Saturday. Open to anyone and everyone interested in Linux, Ubuntu, or free software. Sign up so we can get a good idea of who is going to which locations. Registration is optional, but if you do it we’ll have a better idea of who to expect.

See you there!

[jacob] Windows beta releases come in chunks
[jacob] consider that like going down a river on a tour boat that stops at sites for a few days, then keeps going to stop some more. each stop is a beta, and eventually they will arrive at the destination.
[jacob] Ubuntu’s release scheme is like white water rafting
[jacob] you can jump in at any time, and you will constantly get hit with updates
[jacob] eventually you will end up at the end; there are no “stopping points” per say, just landmarks that represent betas

Yes, I’m weird. But hey, it worked.

1. You are using the “combined” Apache2 log format.
2. Logs are stored as /home/username.logs/domainname.com.access.log and compatible logrotate (.1, .2, etc) equivalents.

In a general sense, ckbw parses through all log files in the above directory and gets a file size total for all items used. Some things, such as unbuffered PHP scripts, will not return a file size and so will not be counted. Be sure that you at least have a month of logs if using logrotate or data can not be reported accurately.

Onto the script itself:
ckbw script; Perl

Basic usage:
ckbw apr - grab the bandwidth used in April on the current user
sudo -u bob ckbw apr - get the bandwidth used in April by “bob”

The script is hardcoded to grab the bandwidth per user and not per site, but it should be very easy to adapt it for a getting stats of a single site.
If anyone has a more elegant way of grabbing the output of system() or similar without piping to a file, let me know.