How to install your very own XMonad XMas

Last night, I posted up some xmonad packages for Fedora 8, sans install instructions. Here they are now. Right now these packages are only for i386, although the SRPMs are there, so if someone can compile them for another target platform, I'll include them, if I don't figure it out first. Do the following as root:

# wget
# rpm -i ynemoy-xmonad-1.0-1.fc8.i386.rpm
# yum install xmonad.i386 ghc681-xmonad-contrib.i386
# rm ynemoy-xmonad-1.0-1.fc8.i386.rpm #clean up a bit

This should install xmonad. To set it up, you'll need the directions from the following sites.

How to prepare your GNOME Session:
A sample configuration using contrib extensions to run in GNOME:
A screenshot of this config:


bug reports, issues, complaints, and pictures of cute femmes in christmas costume can be sent to xmonad-fedora <squiggle> hexago <blip> nl

A very XMonad XMas

Last summer when I was working at my internship, I noticed some funny usage patterns when working with GNOME. As a testament to Red Hat's ability to challenge a person, I had 10 virtual desktops set up with something going on on each one. Usually there would be a virtual machine doing foo, a Turbogears app doing Bar, A Jboss server doing baz, and eclipse being totally useless. I also had all the accompaniments, amarok on another destkop all by its lonesome, MySQL administrator on another, mail apps, random web browsing as a catch all bucket, and terminals everywhere.

Since emacs would do just about nothing except make Java and Python code look pretty, I would generally have two or three terminals along side eclipse just calling rebuild via a few keystrokes. I would wake up the computer every morning would start arranging terminals like flower petals all over the system, in places so I could find them. All that talk people say about metacity 'getting out of your way, so you can get to work' was utter crap. Metacity just wasn't working for me.

Had I known about tiling window managers then, I might have made the switch. Who knows what I could have done, had I had a tiling window manager available to me. I might have been able to finish all the projects I set out to do, I might have even made my group look very good. Who knows? I might even have been able to make that 100 yard pass and cured cancer.

Since then, I've gone back to school, and writing papers really doesn't need all that craziness. (If anything, Hans de Goede's latest patches to gstreamer will make it easier to do my homework without having to go to the labs just to use a windows machine for media.) But being the hip, up to date, thoroughly modern person that I am, I've finally discovered the joy of Monads and X. Wanting to learn more about Haskell at the same time, I started tinkering with it, and so far, I've found it a joy to work with. As a side effect, I'm even noticing better VI habits thanks to the similarity in keybindings. Wanting to see Fedora packages, and learn a little more, I decided to hack cabal-rpm to make it create sane packages. Below are the product of these changes, your very owns set of XMonad packages for Fedora. I'm currently dogfeeding myself with them now. Enjoy!

(Just so you know, this is what Jewish people do on XMas when there are no good Chinese restaurants or good theaters around town. It was far more interesting than tearing toilet paper, which is a major Qabalistic thing, I kid you not. And by Qabalistic, I mean the teachings of the ancient Rabbis passed down by word of mouth from generation to generation, not the packaging system for Haskell packages.n)

Smolt and Privacy

The first public draft of the Smolt Privacy Policy is available. Publically that is.


(discussion is in and #smolt on freenode)

GTK Theming

This makes me so happy.

I had a dark theme i was using for a while that had transparent window decorations that seemed to clash slightly with the non transparent ones. Glad to see i'm not the only crazy person.

Thanks to: GNOME theme engine designer adds transparency to GTK

How to split a repository in git

We've decided in Smoltland that having a git repo would be a better idea. We were using Mercurial up till now, but as git seems to be the more popular choice in Fedoraland, it seems like it would be a good decision. Mercurial is actually a great system, and there are many aspects about it that I like, but there are a few features I feel I would use in they were available. Also, since git is more popular, it's more likely that when we have questions, we'll get an answer rather than 'hmm.... that's funny, git does this differently'.

I also think it's a good idea to split up the client and the server into two separate repositories, and therefore decided to do a bit of experimenting.

The process of converting a repo from hg to git is well documented. It was simple, and I used the script here:

Splitting a repo was a bit harder though, but after some searching, I came across this link here:

I had to make a few changes though.

yankee@dao:~/Projekten/Python/Smolt$ git filter-branch --tree-filter 'rm -rf benchmarks database .hgtags .project .pydevproject .settings smoon' HEAD
Rewrite d644ecb4d74fc0ca3245239dae97f051f825fdb1 (668/668)
Ref 'refs/heads/master' was rewritten

These refs were rewritten:

yankee@dao:~/Projekten/Python/Smolt$ ls
benchmarks client database doc GPL README smoon TODO

yankee@dao:~/Projekten/Python/Smolt$ git reset --hard
HEAD is now at dc4a914... 2007-12-11 Piotr Drąg (via

yankee@dao:~/Projekten/Python/Smolt$ git gc --aggressive
Generating pack...
Done counting 3633 objects.
Deltifying 3633 objects...
100% (3633/3633) done
Writing 3633 objects...
100% (3633/3633) done
Total 3633 (delta 2463), reused 0 (delta 0)
Pack pack-79afd8906cd79a2c59c60cd152e71988d0384452 created.
Removing unused objects 100%...

yankee@dao:~/Projekten/Python/Smolt$ git prune

yankee@dao:~/Projekten/Python/Smolt$ ls -a
. .. client doc .git GPL .hg .hgignore .hgsigs README TODO


This had a few extra added benefits. I got rid of some cruft that happened to be sitting around. While rewriting a repository like this on a regular basis is not a good idea, there are a few times you need to do this. The documentation for git-filter-branch is also good for removing copyrighted files, and other nasty things, that you do not have the rights to distribute.

The end result is that I have a repo that is just the client.

UPDATE: I should mention, backup everything first! These changes are permanent to the working directory, and if you should decide you want to go back, you must make a backup. Remember, git does use hashes to identify updates, so if you need a particular version, save the hash. But that's just common git sense.


Nope, this isn't some obscure Finnish Folk Metal band. It's about one of my cats.

So you're sitting in a forum, as far as sitting in an electronic web page goes, which is probably something only my cat fully understands, and there's some troll lurking about being as contentious as possible. And by troll, I mean anyone, because we all like being contentious these days, or am I wrong? You're lining up the thoughts in your head as how to maximise insult when suddenly your cat jumps into your lap. Her name is Black Pearl and she's very cute. Suddenly the tension melts, and you can think of nothing but warm cuddly thoughts for this alleged troll. You're thinking of letting the troll off just this once, perhaps brining the world that one bit closer to Nirvana and World Peace. Hey, you never know. Maybe one of these days we can use stem cells to give pigs wings.

And then she digs her claws into your leg. BAM, and boy does he get it. Might as well get back to doing that paper. There'll be no flying bacon for dinner tonight.

Smolt and Privacy

One of the biggest issues with Smolt that seems to draw a lot of conversation and controversy is privacy. Everyone is justifiably worried that Smolt could be used to track the total hardware capacity of anyone by IP address, and I agree, the potential for abuse is very real. The beauty of Open Source lets anyone poke around Smolt's source code and see that none of our databases have any conspicuously named fields 'submitter_ip' or 'suckers_ip'. This is certainly far greater than many other web applications out there, such as Gmail and Microsoft Live Whatever, who certainly won't release source code as a matter of internal IP. Certainly, there is a bit of doubt, because once we deploy Smolt on the server, no one but a select few Red Hat employees can see it.

So what is it about Smolt that turns it into a pariah web app when I start requesting comments on some great ideas people bring up? This past week, one of the file systems people mentioned it would be interesting to see statistics on the file system of choice per distribution. Red Hat has had their hands invested in ext3 and their gfs, but other distros tend to favour flavours like reiserfs, jfs, and even xfs. Nothing beats real world statistics to get a real idea of what works and what doesn't work.

On friday, I posted [1] to the fedora-devel-list, and I got comments on everything but file systems. I'm not upset that people are aware of these issues, and keep bringing them up, but I don't quite understand why there is all this confusion about what Smolt does. We're so used to using Google, Wikipedia, Comcast, and Internet backbone physically in the US, that most of the time we don't think twice about what people might be storing about us, but when one extra tiny bit of tracking is brought up, there's nothing but confusion.


In order to clear up any confusion, I've decided we need to become more mainstream. I certainly can't make Smolt a household work, as I'm not sure what it would mean to sit there smolting in your kitchen while the chocolate chip cookies are in the oven. But we certainly can start by having a privacy policy.

I've put together a few notes as what should be considered a privacy policy, and I want to run it by a few of the internal Red Hat people before I unleash it on the community, just for legal sanity. But here's my next RFC.

What would you put, oh dear lazyweb, on your privacy policy? Remember, we never store IP addresses inside Smolt, although Red Hat maintains the rights to monitor incoming traffic to their machines, and no information can be used from Smolt to be traced back to any particular machine. You require some private bits only the client has.


In Werewolf? I commented that werewolves are the most awesome things ever. They are in fact the greatest thing that ${deity_list} have/has ever created. Apparently the Fedora Developers realize this as well, which can be seen here. Right now I'm running Fedora on both my boxen, and pretty much ignore Debian and Ubuntu anyways, since Fedora lately has been more interesting. To encourage lycanthropy en masse, I am hereby resigning all status as a Debian Addict for the next six months.

Lawsuits and Language

I got a funny shock this morning, when I turned on my computer and my Mugshot thingy told me that RH is being sued. I think the most interesting part about this, is experiencing it from the point of view I got from the internship I did at RH. If I were just doing things the old way, I would have most likely found out sometime really late this evening when I do my daily OSNews read.

Instead, the first thing I see is Greg DeKoenigsburg's post, and that practically the whole world (all 10 people) have read it. As I'm sitting there working on a debate project for school, more and more posts and blurbs keep showing up on Mugshot, to the point that I end up looking into it just a bit for the debate project, which coincidentally happens to be on international debate treaties. It will certainly make things more interesting this coming Monday.

Finally, I get a chance to sit down and read up on what's going on. I realize, I know who Mark Webbink is, I know what's at stake, and I know exactly what Novell and Red Hat are going to have to stand for, and stand up to. (Curiously, they are in the same boat despite having two very different outlooks on Open Source in general.) Ultimately, thanks to the things I learnt from Red Hat, it's actually very exciting!

(Dare I say more interesting than a Steelers game?)

Anyways... I just want to mention, the world is multilingual, and it's great that p.fp.o is. I also enjoy the chance I get to work on the languages I do know, as if I'm not being swarmed with class work already. It is a great opportunity for any language students, and even non language students, or even just human beings in general to see how technology shapes the language we use, and how other languages cope with technological terms and vocabulary coming out of an English dominated world.


Werewolves are the most awesomest thing ever. If Fedora 8 becomes the Werewolf Edition, I'm going to completely ignore Debian and Ubuntu up till Fedora 9. (Well, I'll read the news, but they won't be installed anymore, with the exception of my very stable file server.) So vote Pedro ... I mean Werewolf.

20 Minutes with Rawhide

Over the past couple of weeks, I've been watching my preferred distribution of choice, Debian, crud itself into a hole, watching random packages disappear. It seems NetworkManager is only working on my laptop on a wing and a prayer, and hibernate works sometimes. It's very strange, since I had similar problems with Fedora 7 on the Thinkpad Redhat loaned me over the summer. Debian worked like a charm.

So I had every plan of giving Fedora 8 a spin, and if it worked well, using it while I am busy with school. Instead I decided to take the plunge a bit early, and installed 7.91 on my machine. If you're a journalist or aggregator of some kind, bear in mind my setup is not the stereotypical clean box, but a real world working system, with all the little quirks that are involved. My system is a Gateway MX6931, with everything split up via LVM. I maintain three seperate primary partitions, each 100mb each that can be used as boot partitions for three different OSes. Currently they are Debian Etch, CentOS 5 (which is by far the most stable and pleasant to use), and Fedora Rawhide. The last is an LVM Physical Volume that holds everything else. Each OS gets 10G, a 15G home partition, and a 40G partition for music and an ever changing list of movies.

The installer worked perfectly. I was easily able to create new volumes, mount the old home directory, use the same swap partition, etc... Since I am letting Debian manage the grub instance on the MBR, I had to add those in manually, but letting Fedora manage the boot sector on its own boot partition lets me see exactly what I need to copy and paste. There was a small hangup in the installer when it couldn't figure out why the pre-existing home volume didn't have SELinux contexts. Some minutes of hard drive and CD chugging later, I was able to boot up into first boot quite easily.

This is where I hit the first snag. SELinux didn't like my home volume. So much went wrong. To start, every file on it had the 'nfs_t' context, which I assumed was the arbitrary default. Debian does not even use SELinux, which is a shame really, although, last I heard, Coughbuntu is going to be setting up AppArmor. While it'll be interesting to see how those two compete, for the love of a bearded hippy and all that might have some very sentimental meaning, these two competing standards is going to make it difficult to share volumes between OSes. I would have loved to have been able to load up 'home' and 'media' right away, and had a working Fedora desktop with all of my personal settings from the beginning. So a bit of SELinux foo later, I was able to mount /home properly, only to find the second SNAFU. I presume this is old territory, and no one has been able to coordinate this properly, but the UIDs and GIDs, (the file permissions,) on my files were messed up. Now every time I boot up into Debian or Fedora after using the other, I will have to change the permissions on each one just to logon. It's a shame, because I use a very consistent user name and password scheme across several computers, and being able to retain permissions at least by user name makes life much easier for me, and presumable someone else as well.

These problems aside, loading the Gnome desktop was *fast*. I got a few random error messages, one about the keyboard settings, a couple more about the lack of Iceweasel, but everything was retained, down to keyboard shortcuts. This is one very good testament to the reliability of Linux vs. the Wintendo world. A bit of tinkering, and I can see the new Nodoka theme. Kudos the the artwork team, and Martin Sourada in particular. It's a little glossy for my tastes, but it's also very clean already, and I can only hope there will be more good things coming from this. Font rendering also seems much better to me, even at the low DPIs I like to use. I had alot of fun experimenting with the different fonts I've accumulated being able to see them render nicely in Linux for the first time. The only catch is Firefox, which seems to render everything at a few DPI points lower than everything else. Two minutes of Google and a tinkering of layout.dpi.css later, Firefox is rendering everything a little bigger, but I can live with it for now.

The only other severe problem I've found is power management. The Gnome team has put alot of effort into this, and it works great. And by great, I mean it's horrible. I can actually set the brightness of my laptop monitor to any setting I want, for the first time ever in Linux. What ever piece of code is managing this though is constantly trying to set modes that don't exist. When I plug and unplug my laptop, the screen flickers black as it turns the bulb on and off trying to get to its new setting. This is probably going to cause lots of wear and tear on the mercury bulb inside, and is probably not a good thing. A bug report is definitely forthcoming.

Otherwise, so far Fedora 8 is shaping up to be an amazing release. Pulseaudio is working great, Hooverphonic sounds awesome, Smolt Rocks (shameless plug), and apparently Snati is the most common name for a dog in Iceland. You pronounce that like you might describe nasal fluids.

The human fecal matter has collided with the bladed air circulation device

It's finally happened. One of my professors tried to send me an OOXML document. It's a good think it's just some zipped up XML. All I need to do is unzip it and, oh wait, tab completion won't work since bash-completion doesn't realize that .docx is just a zip file. Now I have to type out the full name, escaping spaces included. So it unzips, all over my home folder, not into a nice neat folder of it's own like every well behaved tarball does. At least it's XML which is human readable, right? Well it seems the world's biggest bloat maker incidentally forgot how to use bloated white space in the biggest joke they are pulling on the free world. C'mon Bill Gates, can you be any more clever?

Well one polite, yet long explanation to my professor how I can not read this file later, and I think I need to keep my eyes a little more open as to what's being used at the University of Pittsburgh.

So dear not quite so lazyweb, are there any of you freedom loving people in or around the University of Pittsburgh or Carnegie Melon that want to help ensure the freedom of information in the Pittsburgh area? I'm going to start campaigning so this can hopefully be the last I see of .docx from one of my professors.

Smolt and School

A status update.

Smolt's gotten some pretty big or small changes since the last time anything's been mentioned. I've been spending alot of time fixing up random issues in the logic level, because there are a suprising number of edge cases we've come across. The more I work with Smolt, the more I realize this is alpha software. It certainly won't be that way soon enough though. It certainly is in a far better state to download and try out on your local machine than it was before. The only catch is that it requires DB specific things from MySQL, and the requirement is only going to get worse, not better. I hope we could switch to Postgresql, but that remains to be seen.

Today I worked on two big changes. Firstly, everyone's been sharing links to their Smolt profiles. Since I hate security through obscurity, I'll come out and say right away, DON'T. The link contains your UUID which identifies your machine. Currently it's the only authentication token needed to update your machine. Seeing how the fine work on FAS is maturing, I plan on added that as an optional security layer. In the meantime, there is a way to share your profile using a different token that gives the viewer read only access. It's in the source control, so all we need is a certain someone to deploy the change.

Secondly, I fixed a pretty critical bug. Browsing item information by Hardware class presented by HAL is a pretty heavy operation on the database. Well, it's cached too. Practically everything slow is cached now, so it's unlikely there'll be any showstoppers in the future where something doesn't work. After I make the information presented cleaner and more useful, I'm going to experiment with some custom query generators that will be of better use to hardware vendors, like seeing how many 'live' systems as opposed to dead systems are still using their hardware.

As for school, well it's going to get busy. I have ultimate bum schedule at least. On Mondays, Wednesdays, and Fridays, I have one hour of class at 1 PM. I could feasibly be drunk Thursday, Friday, Saturday, and Sunday night, and still make it to class. Not that I do these things.

The class lineup? As if you actually care :P
Social Implications of Computing Technology
Professional German 1
Reading Literary Texts (that's in German)
Swedish I
Structure of Programming Languages

Finally, whoever manages the Peoplesoft system at the University of Pittsburgh must be a God amongst Oracle hackers. It runs decently fast, is not hard to navigate, does not break common usage patterns, and ultimately lets you get the information you need. Some things require one or two more clicks than absolutely necessary, but overall the experience is good. I think a little village in Norway froze over.


Well, my internship is coming to an end.

Of all things, I enjoyed working on Smolt the most. Turbogears and SQLAlchemy are a blast to play with, and make life so easy. Maybe I'm spoiled now, but I doubt I could ever do another web application in Java again. I don't see a reason to do so.

I see alot of blogs pointing out things about Smolt, that to me is just simply old news. So allow me to highlight what is going on with Smolt. Please keep in mind these are in the development version currently.

  • SELinux stats are collected
  • Ratings are collected, although the implementation is a little buggy.
  • The server has been rewritten to be a little more robust, so it will be easy to make some widescale improvements pretty quickly.
  • Smolt is compatible with Fedora, RHEL, openSuSe, SLED, Debian, Ubuntu, Archlinux, CRUX, Frugalware, Mythdora, and Mythvantage. We still need help packaging for these distros though.
We plan on getting out a community release of the client in the next couple of days, such that it's possible to start packaging things. I can guarantee that this client will work with any version of the server that we are running, although we haven't set any deprecation dates yet.

I also have plans to make the web interface more informative. Right now it only spews out a ton of junk collected from hal, and we really need to make it give you more information in human terms. There'll also be links to a wiki where users can comment on any part of their system, so others can find out how to fix things that are broken, or where to complain to their hardware vendor.

On the vendor side, we plan on giving more information and statistics that will be useful to you. Want to know how many people can't get your wireless card working? Just check Smolt.

We'll have some exciting things ready for Fedora 8.


You take a glass...

1) Fill half way with baby killer (cheap vodka)
2) Fill near the top with cherry ginger ale
3) Add a splash of diet coke and a splash of red wine

Et voila, you have a drink that will do more than just kill babies.

What is a Community?

This week Mike McGrath started an interesting flame war here which asked us all the very interesting question: What is Fedora's Market. This of course led to the usual affirmations that Fedora is 'bleeding edge', 'for the hobbyist/tinkerer', or really just for the person who wants to do new and exciting things. Today however, I saw a funny blog post by Tom Callaway, on his efforts to introduce a new feature in Fedora that allows people to track packages by license. Unfortunately for Tom, and my heart goes out to him, his idea was shot down a bunch of people whose response was to "Whine, Bitch [and] Moan." I had also been reflecting on how Con Kolivas is no longer writing kernel patches.

This had me wondering at a second and even more nebulous question to ask.

What is a Community?

Growing up, I had the fortune to live in a jewish community that talked about the morals of building a community through religion and social exercise. People always commented that my high school class was amazingly unified between all the different levels of classes socially, and there wasn't this stratification of who belonged to the 'smart' classes or the 'dumb' classes. At the same time, I would go home to see my parents and family integrated, but looked at funny because we had ever so little less money than our neighbours, and were ever so stranger than they were. So if you asked me what a community is, I would say right out that it's a group of people that align themselves together based on some common bond. Well, it's not necessarily an open community.

An open community, however, is an entirely different breed. It's a group of people that are willing to accept anyone regardless of who they are other than their desire to participate. It certainly has been a mantra of the Open Source development style. It accepts anything, and everything, and of course, if you can't keep up, you sink underneath the mess. If you manage to stay afloat, you're rewarded with the best of the best software available to mankind. This is also the bazaar style development, or in some cases the bizarre.

There are of course always the closed communities, which in the software world leads to cleverly, but cleanly architechted software. Even when they are open source, there is certainly this base hierarchy of being either in the inner sanctum or pond scum. Oddly enough, this has actually been Red Hat's model for years, and continues to be that. They take what they like, polish it into first RHL, now RHEL and friends, and then return as much source code as they can back to the community. Red Hat has been very clear about who stands in their community, and who doesn't, and it all starts with a paycheck.

Fedora is going through an interesting transition though. For six versions, it's been a closed off effort, courtesy of Red Hat, whereby the only people that could directly contribute were Red Hat employees. However everyone started realizing that outsiders could make better packages than Red Hat, and eventually Fedora was opened up. Cool! But now what? I'm hesitant to bring in other distros into these sorts of discussions, since they eventually turn into flame wars, but let me give you an abridged list of "Open Community Distros" (by my standard of course ;): Debian, Gentoo, Ubuntu, and *BSD (generally speaking). These are the best models to look at if you want to understand how an Open Community operates. Well, *BSD's aren't really open, the rules to submit patches and have them accepted are strict. Ubuntu and Debian have that crazy MOTU and NM processes, and Gentoo seems to have lost it's wind. Not than anyone is perfect of course. But one thing that these distros are good at is accepting all sorts of ideas, incorporating them, and weeding out the bad ones. (Yes, I do know *BSD is not a 'distro').

One of these distros has a little funny document called the Debian Social Contract. This is the defining document for what constitutes the basic foundations of the distro, and the community that surrounds it. From that came out a rock solid distro, that serves practically any need one might have from Linux. You can call it overkill if you want, but to be quite honest, I enjoy Fedora development more working inside Debian than I did on Fedora.

So in response to this ugly trend I've been noticing where people are getting shoved out of the Open Source community, and feeling left out, I want to propose the start of a Fedora Social Contract. (Disclaimer: I have read the DSC (the Debian one) before, though it's been a couple of years. I haven't read it lately, although if this catches on, I will of course read it for inspiration. I do not want this to turn into a clone of the DSC, although if it does, I think it means that the DSC is a very well written piece of fine bathroom literature :) ) (Second disclaimer: I enjoy reading in the bathroom ;) )

So without further ado (except this one: ADO!):
1) Fedora is open source and an open community
2) Everyone is welcome to voice an idea, and everyone is welcome to say no. The Fedora project is of course neutral. Implement your idea.
3) We are part of a larger community, participation in this one implies participation in the larger one as well.
4) Therefore, everyone is welcome to submit changes, fixes, improvements, anything they wish to see. Provided it's technically feasible, we will make your submissions available for evaluation by the community. This is not a guarantee that it will be submitted to a release.
5) If one other person finds this feature useful, the submitter will have an option to submit it in some way to the Fedora Project, should there be an objection greater than the desire for submission (and a lawyer will hate me for that last sentence ;)), all efforts will be made to ensure that the submission remain optional, and not installed be default.
6) To ensure that we provide a quality distro, there should be a core set of packages that have been approved by people trusted by the Fedora Project to this purpose. The term core packages can imply 20,000 packages if we ever had that much time on our hands. For a submission to pass this review, it must meet quality standards (not limited to proper package naming, quality of install scripts, likelyhood of the package destroying the universe being minimal, etc...), however, so long as it is packaged properly, it is up to the community to decide if they wish to use it.
7) Should the submitter, or an heir to the package leave the project, only then is the removal of the package from Fedora up for discussion. If members want to see a package in the distro, they have to do the work to make sure it stays there.

I'm sure there's plenty more that can go there, but they would probably be elaborations on the same thoughts. I'm also sure there are plenty more social contract type clauses that would fit, and I just haven't thought of them yet. Anyways, I make them available via the Creative Commons if someone else would also like to write a social contract. I'm sure I'll have plenty more to add by Monday.
  1. I'm 23 years old. Pretty strange, huh?
  2. I just signed up for mugshot and twitter. Now I have my facebook integrated into my mugshot integrated into my twitter integrated into my facebook. It's a wonder they don't explode or start a flamewar.
  3. Smolt is getting better. Every random complaint I keep seeing is already in the upstream repo, or two lines of code away. Soon it will eat your soul, and you will thank it.

Turbogears and Seam

I want to shake Kevin Dangoor's hand. I probably would like to meet Gavin King someday, because he seems like a smart fellow too, but Kevin Dangoor is a genius. We've been struggling with JBoss and Seam in our group for over six weeks now, and so far have produced an overengineered, complex, brittle application that works on only half of our boxes. To be honest, development has picked up quickly when more energy is applied to it; however, if you look at it mathematically, I think it's a useless point. Out of curiosity and frustration, Robert and I hammered out a simplified version of the app, complete with CRUD pages in two nights, using Turbogears and tgcrud. It's far from complete, but it didn't take that long. Fleshing out the data model to include all the information should be relatively easy compared. Generating the crud pages again will take about 20-40 minutes depending on how complex it gets. But if seven people were to work on adding in the other stuff, in an organized fashion, I think we could have this app done in about two weeks time.

What I really don't understand is if Seam has all these goodies, (and the sheer number alone really impresses me, coming from a Struts background), why does it take longer to develop for it? Well, I probably do. Our group certainly isn't within the statistic norm. For most of us, this is the first time doing an enterprise application. When the code base expands, seam should keep the maintenance required fairly level, and the level of difficulty in adding more content should also be low. In contrast Turbogears is missing alot of these features. Yet setting up what we needed on a basic level was Very Very Fast (TM).

Either way, here is what we've done in the past three days.
  • We discussed a simplified version of the data model, so that we could do some RAD, rather than making sure stupid stuff, like validators for each and every piece of data were correct and functioning.
  • That was implemented in almost no time at all in SQLObject
  • Bobby pointed me to tgcrud, which I spent an evening going through, and setting up. It's buggy, it's not polished, but I got some useful starting pages out of it.
  • I put a few touches on them, and we have some barebones crud pages that will let us populate the database theoretically.
  • Using one of those CRUD pagesets as an example, I've been working on a CRUD Widget, that can be embedded anywhere almost pythonically. I'm nearly done.
The CRUD Widget is my little pet :). I was looking through Seam's and other's ideas about CRUD and realized that they leave a few questions about relationships (such as the whole OneToOne and OneToMany thing) unanswered. Let's say I'm entering information about Employees and Divisions. An employee is in only one division. The relationship is fairly obvious. So let's just say I'm going through a list of things I have to entire in, name, address, phone, payroll information, hair colour, astrological sign, favorite food and colour, most recent dream, and shoe size. Oh yeah, and Division. I go through all the rest, with little trouble, but when I get to division, i realize that he is the first person to work for the newly opened Pizza Eating division (which every company should have one.) So I click "select division, then new division" and a popup shows up that gives me a form to create a new division. I click save, get a flashed message "Division Created, word domination options available", and then go along my merry evil genious way. Having a crud widget that can be fetched from the server to show up in AJAX, or a popup or a whatever (ever hear of a flooxamble? I hear they are a popular input method of choice on gthBoxl these days).

To put this in MVC perspective, there is the model, that is the database object, in a nutshell, with metadata such as validation. There is the view, that shows how to display a view to do whatever to said model, and the controller which can push data changes from the view back to the model. It's a mini MVC component, that can be integrated almost wholesale into the app. The cool thing is that you will be able to put controller code, via python that will know how to get information from the view to the model. Likewise, there will be a small snippet of code that has to almost cut and paste into the KID file, for parsing. Finally, I want to make this generic, and templatified (I made that word up ^_^) so that I can make this simple to do via tgcrud.

What's left to do? Make complicated pages with more unique ways of looking at the data. Such as having a user login and only see information pertinent to their group, rather than just a generic list of events. There are a number of things that Seam does quite neatly to make this easier to develop. TG doesn't have them. It'll be interesting to see how far I can go in my spare time to make this work.

Happy 4th, aka declaration of presumed (falsely) right to bully the other nations of the world day!
Somehow it's been a crazy week. I worked on a different project everyday. The electricity went out one night. The police were inspecting everyone's bags on the NJT on wednesday too.

I think this is good for a friday. Thanks to Dani for finding it for me :)

Linux - The Video Game

I've been throwing around an idea a bit around the NYC office today, and it's been getting a pretty interesting reaction, so I want to share it here as well. The idea is to make the Linux Desktop more like a Video Game. It starts with the Spinning Cube.

First I want to throw away our concept of the windowed desktop. Managing a set of windows is something a bunch of programmers came up with to manage their own development workflow, and it's something that the home user ignores at best, and is frustrated with at worse. In the OLPC project, they managed to completely do away with the whole notion, and switched to full screen apps, with an overlay that can be accessed by the push of a button. I want to take this a step further. In Sugar (OLPC) the user is faced with a single context, which is the task that he/she/it is working on. Given the power of our computers, and the preference of some users, they may want to check their email, facebook, friends blogs, chat, and download po^H^Hmusic all at once. If we treat each one of these as a separate context, we need to provide ways of letting the user switch between them easily. Well, let's say the user presses a button on his/her/its keyboard that says "Chat", we need a way to give him/her/it a visual clue that we are switching to there. A spinning cube is an excellent solution. Seeing the desktop zoom out, spin, and zoom in is a great clue to the user what is happening. Later, the user can turn it off for speed, but by that point, it's hardwired into the user's brain what is happening. We can take this one step further, and explain all the visual effects are good training tools.

Let's run another use case. The user wants to configure their system. Since we've so conveniently explained to them that their system is a cube (well, i'd prefer a dodecahedron, cubes are overrated these days), it would be trivial to assume we could zoom out of the cube, and view 'settings' lying beside it. Perhaps setting could be a great Atlas holding up the cube on his shoulders, or perhaps four elephants standing on the shell of a giant turtle. Naughty apps could be punished and forced to sail off the edge of the cube. But I digress. The user zooms out, and a menu pops up. If you've ever played a video game, it's fairly analogous to what happens when you press Pause in the middle of a game. That is the crux of the idea. Replace the bulky desktop metaphor with the sleek interface of a Video Game, and use some favoured fork of a Compiz tool as the graphical engine.

Anyways, sometimes I think in design requirements lists better than in highbrow literature, so here is one:

  • The core interface must be accessible with an Xbox controller, Playstation controller, or a Wiimote. Although the standard 105 key keyboard could be used, along side a mouse, ideally a custom keyboard with similar D-pads, and context switchers would be very nice. Any hardware geeks out there?
  • At some point, we'll need a good input method for typing text without the burden of a keyboard. Maybe this is a bad idea.
  • Social Networking is the future. Heavy integration with any and all social networks is a must. Hooks need to be in place to 'share' any general activity with a friend. This is analogous to the social networking features in the OLPC project, however a little more sophisticated.
  • Use of 3D effects as visual cues to direct the user's attention to important things. They should be minimal in effect, although a bit of smoothness goes along way. The cube is one example. Using subtle ripples on the screen to point the user in one direction is another. Perhaps ripples following the mouse cursor if the user loses it. Bouncing windows however cool should not be enabled by default, but is always a good option to show as a demo. Chuck Norris's fist bursting out of the screen on the other hand when the user does something stupid is quite acceptable.
  • Abolish the file system. I didn't bring it up earlier, since it's orthogonal to the GUI effects, but it's one more gotcha that burdens the user. I'm proposing a history based system. Arbitrary tags are also good. Being able to set commonly used filters are even better.
  • Physical awareness. Recognizing that the user's laptop is on the home network might be a good time to sync up all the shared files. Realizing that the laptop is in the same room, and willing to be used as such, the system can hook up with the laptop, and use it as an auxiliary screen. For example, while playing a game, having "you got mail, you won three auctions, and that hot chick you met last night wants to talk to you" showing up on your laptop might be a fun to implement feature.
  • User and Expert mode. There is a huge debate on how much information the user needs to know. The developers of a certain instant messaging client believe that the user is not interested in which connection mechanism is being used to chat with. Sometimes the user doesn't care, but sometimes he does. Rather than argue about what the user really needs, just give them two options, all or nothing. Being able to customize what information the user really wants might be a version 2 thing, but hey, it's also open source.
  • Speaking of which, the entire system should be open to development. While no dev tools or compilers are installed by default, it should be pretty trivial to say "show me the source" and have the system download everything, and setup a new context for development. Then ideally it would say "i'm sorry dave, but this will void your warranty" at which point you go and remove critical components while your Okama Gamesphere sings Daisy, and then dies. The build system should then let the user tweak an option, compile and deploy it, and see it take effect as soon as possible. IE, the user decides he doesn't like file chooser, and he wants to write his own. He downloads the source, edits it in place, says 'show me the new file chooser' and voila, a gentoo minute later, his entire system is switched over. Let's say he wants to share this with his friend. Well, his source tree is just a clone of a mercurial (or another distributed source manager) which he can commit to, and share.
  • Speaking of which, a repository for user patches with ratings would be necessary at some point. Of course, supposing that a slew of 13 year old males with a penchant for naughty language discover the joys of open source software and flood a repo with comments that are generally unwanted, it should be very easy for a user to create his own repo. This way quality members to the community can contribute, and work on a reputation based system rather than a clog the network with odd ratings system. I think this one is probably a little more complex than I really meant, but it should be very easy to open, hack, and share, and hopefully merge back into the main stream.
Well, I had a bunch more ideas, and more details, but it's very hard to write things down when running, especially when it's raining like it was earlier :) All the same, we have a playstation in the office. I'm gonna see what I can do to get the bluetooth game controller to control my window manager, and see if I can go from there. I really hope I can make this a reality.

Oh yeah, and a MythTV context. Turn that expensive playstation into a very cool box. :)

The art of getting work done

In the madness that ensuing with the JBoss project we're trying to get working in my department, I've decided the best way to get work done right now is not to touch it at all. Instead, I spent my time today laying the groundwork for my 1% project that I'll be doing later this summer. So without further ado, I point you to the brand spanking new mercurial repository for Kefir:
My New Repo @
Commiting is very easy, since it's using mercurial, so all you need to do is email me with patches, if you're interested in helping out.

If you don't know what Kefir is, it's a pretty simple concept. The graphic designer sketches out a great new concept for your GUI in Glade. It's gonna be the greatest thing since sliced bread, or at least Gnome HID compliant. Unfortunately, now the developer is screwed into writing massive amounts of boiler plate code to interact with libglade. Since you, the developer, is smart enough to be using Python, I'm guessing you're also smart enough to hate boiler plate code. This is where Kefir helps.

For every top level window in your GladeXML file, Kefir sketches a frameclass in Python, that when instantiated creates a replica of that window on your screen (or alternative). If you specify any callbacks for any GTK events, Kefir creates a call back function ready to be filled in. Sandino Flores Moreno wrote a brilliant guide on it's predecessor, Tepache, on how to write a web browser in under 100 lines of code. Kefir makes your life simple (and healthy if you drink it, providing you're not lactose intolerant or allergic to dairy, cows, or life.)

The funny thing is, whether you're a fan of Object-Proxy or MVC, Kefir can do them both. Kefir can function as both a Thick client proxy, or as the Controller in some elaborate MVC scheme. Writing a guide on how to do both is on the agenda this summer. Stay tuned for that and other fairly bizarre things, like my Todo list, and perhaps a look into my collection of old children's books.

Speaking of which, I went tag sale hunting this weekend, and picked up a few excellent finds. It's getting harder to collect old vinyl cover art, as everyone seems to want to hold on to their old vinyl's these days. The only ones that are being sold it seems are near perfect quality records at exorbitant prices. Alas. But I did walk off with a few nice things to add to my book collection. I now have yet another copy of the Hobbit, complete with yellowing pages, and the original artwork. I found two pieces illustrated by Maurice Sendak, which will be nice to add, a copy of "Butt Wars" I plan on passing on to the short people that run around my dad's house (after I'm done reading it of course), and to save the best for last "Elihu the Musical Gnu". This classic piece of literature features rhymes like

He had a Kazoo, brought from Kalamzoo,
which he blew and he blew.
But the tunes that he knew
-and he knew quite a few-
were sticky as glue.

I wonder if RMS has a copy yet.

Life is like a surrealists nightmare, it still makes too much sense.

JBoss and Deployment

After a rocky start trying to determine the scope of a few projects my colleagues and I would be working on, we set to working on a few projects using the JBOSS stack. Is there a word for the nightmare you get when you try to develop production grade material with beta software?

I spent my entire day mucking around with Eclipse trying to put together an IDE + Build system set up in an all in one package for everyone else on the team. Last summer, when I worked for Krones AG, they used a three level system for their database design. From what I got out of their thinking is that they prefer to think in database terms over object oriented terms. They treated web development as the icing on top of their databases, and the testing and QA processes revolved around this. First the database developers would develop their stored procedures and setup the tables into an SAP database called KE. Once tested to work, they would deploy them to a testing stage KQ, where we, the web applications department, would setup our pages to work on top of what ever disasters were created. Finally we would declare our stuff done, deploy the Java, Oracle, and SAP apps to their respective servers, and the devs would redeploy from KE to KP, where all the users got their data from. Once a month, they would copy the data from KP back to KQ, so we could have fairly good test data to work with, but there would be no worries that we would clobber any of the production data.

This is what I'm thinking for our purposes. Since testing JSF sites along with all the rest of the Java Junk requires a running server, it's best for basic development to run that locally, until the app coalesces into something usable. There is also a fairly decent SQL server written in Java that can be run along side the server, so we can make sure persistence works between deploys of the app. But when I run seam-gen, the build.xml files I get out of it seem to understand that there is only one server this app will ever be deployed to. So I'm left with a very tough layer to implement. For testing/QA and production, I want to create two more layers named exactly that. (Actually I like the idea of Mr. and Mrs. so I can be totally ambiguous.) The production AFAIK is going to be running JBoss proper, with MySQL. Or Postgresql, but I don't think that matters much. So naturally, I want the testing to be running the same thing. The tricky bit, is I want to be able to pick up the latest nightly, and run a single command that deploys it directly to testing. This would be simple, but it means changing all the deployment config files. As it stands, they are single mindedly set up for one type of server, at one address, etc... I'm thinking an ideal situation would be a command that took a JBoss server address, port, SQL server, and port, and type, and could flexibly deploy anywhere. Superideally would be a screen in Eclipse to do the same thing.

Or maybe I'm just wasting my time with eclipse, and I should learn how to do this all on the command line, like Chuck Norris would.

The Boston Tea Party

The past two days, we, the interns at the NYC office, were up in Boston to meet the OLPC and Westford offices. We didn't actually get the chance to throw crates of Fedora Discs into the Boston Harbor to promote the release of Fedora 7, but we did get to eat cake with some of the people who worked on it. Present were the tubes and trucks with which had been used to collaborate and develop Fedora 7, so it was only fitting that they were also present, and in the form of cakes and pies. Sadly I did not have a digital camera with, so I'll have to wait till the film is developed, or some of the guys up in Westford send me the pictures to use. *wink wink* *nudge nudge*

Wednesday though, we got to see the OLPC's main office on the MIT campus. If you don't know what this is, google could tell you most of it. It's a concept to bring very low cost laptops in bulk to all sorts of nations all over the world, in order to bring computer resources to areas where they don't even have electricity or running water. They give the kids these green laptops that are designed to survive a hurricane practically, or a monsoon. And they are so small, have bunny ears and are so cute! Did I mention they are bright green?! They are very awesome. Holy crap, they are so cute.

Well, being made a guinea pig for testing Fedora 7 was not my idea of fun, but I had alot of fun going up there all the same. We have our boxes working again mostly, so things aren't too too bad anymore.

First Post!

I suppose the dubious slashdot honour is lost when you're the only one with write access to a blog, but I suppose the blog feels honoured all the same.

Well, here is where I'll be posting about my internship with Red Hat. I'm going to be working on the Fedora Project, working on a few pet projects of the various overlords in the New York office. Well so far my experience with Fedora has been this urge to tear apart the package manager from head to toe. There have been many less than obvious surprises I've been finding, but I think I've come to terms with it finally. Rumour has it, we might be doing work on it anyways.

Over the past week, I've mainly been spending my time just getting setup, and meeting the other interns. Except for one who is going to be working remotely in Denver, they all come from pretty much a traditional Com-Sci background, so it will be interesting learning how to work with them. My background is more just practice, having used open source software since the end of 2001, and occasionally poking my nose in code when I'm bored. It'll be fun to see how much code I can crunch out in one summer.

So, Pittsburgh, Raleigh, Newark, Manhattan, Brooklyn, Westpoint, and next week Westford. I think by the end of the summer, I'll want just one thing. My own bed.