Input Hotplug Guide

There's been a lot of questions about the new input system (referred to as "input-hotplug" or "i-h") that we've enabled in the latest X upload. Questions range from "how do I configure my keyboard now?" to "why are you making me install all this other stuff I didn't have before?" While the XSF has been dealing mainly with bug triage for the software itself, we've also been wanting some documentation on the system so people can understand it.

Thus was born our Input Hotplug Guide. The first portion of the doc explains the rationale behind input-hotplug and how it works. The second section is a HOWTO, explaining how to configure it. Hopefully this will answer some of the questions that are out there right now. So if you're curious or just plain frustrated with the changes happening to the X server's input subsystem I recommend that you check it out.

How To Follow Major X Issues In Unstable

It's been a long time since I've done any reasonable work on X stuff, so it's also been a long time since I've blogged. But Julien and Brice* just finished off the major task of getting 7.4 in to unstable, and I've been trying to help out with some of the inevitable fallout from that. Overall, the transition has been relatively smooth, although we've had a few major classes of bugs that have popped up. Since dealing with the BTS is rather complicated and doesn't lend itself to simple summaries, I created this wiki page for the team to track the major classes of bugs currently plaguing unstable. This isn't meant to track every bug (that's what the BTS is for), but for major regressions or problems with new features, we'll be trying to use this page to give ourselves and users a way to easily see what's going on with some of the more recent problems. And yes, this does include the infamous hal depends bug, which we are currently discussing, and will deal with accordingly.

* Edit: Removed by request

I Didn't Think I'd Ever Be Celebrating This Victory

This is a wonderful day. The various non-free bits of X donated by SGI have, thanks to the efforts of those at the FSF, been relicensed under the MIT/X11 license. Congratulations to the FSF for pushing this very difficult task through. I've been told numerous times whenever I tried to take a stab at the issue that it was "tilting at windmills," but the FSF persevered and made the impossible happen. This should be evidence for the naysayers that the FSF is out there doing the really hard, and all too often thankless, work that helps keep our software Free.

Goings On

I've been rather disconnected lately, trying to finish my PhD, find a job, etc. I got permission from my committee to start writing my thesis a few weeks ago, so I've been trying to get that in gear, as well as finishing up data for publication. This should all be done by November, if all goes well, so I can get back to spending more time on the things that I love.

I've tried to stay somewhat current with what's going on, and there's been a noticeable change over the past couple weeks in the tone of discussion around the community. I've personally been fascinated by the appearance of two things: the Linux Hater's Blog and the debate about Gtk 3.0. What's striking about both of these things is that they focus very much on the more consumer-oriented side of Linux. It's all about pleasing the independent vendors and grandma, and not about doing cool things. This is a huge shift from a few years ago. When I (and I assume many of us) got started with Free Software it wasn't really about these things, but more about getting your own work done and less about pleasing other people. Pleasing others was good of course, but it wasn't really expected. Just getting the system up and running was cool at the time, but using it exclusively for all your work? Only if you were in the right line of work!

We've come to a point where we expect a hell of a lot more though. We've got very vocal community members who want to spread Linux far and wide, and they want to do it today. And arguably, Linux is ready for it. We have good software that works rather well, can be easily installed and set up, and will run most of what people need. Yay us. On the other hand, after spending the better part of the decade using Linux on the desktop I'm finding that I agree with almost everything that the Linux Hater's Blog says. It's hard to argue with the truth, and the truth is that things are still difficult for people. I've spent the last few years trying to make X in Debian easier for people to deal with, and I've barely made a dent in just this one problem. And there's plenty more to pick and choose from. Sure, you can talk about how Windows and OSX have problems too, but we can't just be as good as them. We have to be better if we want to spread Linux and Free Software far and wide.

But do we really want to do that? Well, to be honest, I don't think it matters. No matter whether or not you care about grandma using Linux, we all want to have systems that work well and are easy to manage. Currently we have a lot of things in modern distros that could be a hell of a lot better. And many of them are directly related to fundamental assumptions we've made that don't really hold up as well as they should. They lead to lots of extra work leading to a sub-par product. We can do better and we should do better. If we have the absolute best system, world domination would be a natural side effect.

That's why I think that things like this need to stop and that we need more things like this. Sure, one is a hell of a lot harder, but no one cares if you solve an easy problem. It's the hard ones that matter, and provide the real payoff in the end. We need a better system to stop the hemorrhage of developers to OSX. When Miguel talks about how the people pushing for gtk 3.0 are all using OSX, I get very worried. If we want to be in control of our own destiny then we need to face our problems head on, and solve them.

Things To Do When You're Busy Trying To Graduate

I've been too busy to do any serious free software work lately, but here's my "low time commitment TODO list":
  1. Give xconq some serious love. That includes bugfixes, updating to the new tk, and a total repackaging with more standardized methods.

  2. Write more docs for X. I think we badly need a simple well integrated user's guide, followed by better high and low level internals documentation.

None of these things require a consistent time commitment (and no mailing lists for me to follow) so I hope I'll be able to get some work in on them soon.
  • Current Music
    Underworld - Jumbo

The Cognitive Load Of Web Development

The most dynamic segment of the software industry that I'm aware of is web programming. Flamewars rage about frameworks and browsers and standards and whatnot, and the openness of the whole thing feels like some of the things that made me fall in love with computing as a whole and Free Software in particular. The problem with all that openness is that it's rather difficult to navigate. Aside from the obvious issues with browser incompatibilities, there's an enormous amount of software solutions on the server side, spanning languages, libraries, and frameworks. Each one is an ecosystem to itself, often being large and complicated.

This makes it rather difficult to do certain aspects of web programming well. You are constantly switching between tools and languages, as well as coding paradigms, in order to build a web app in full. You'll be writing HTML, CSS, and Javascript on the client side, each with its own peculiarities. On the server side you'll probably have settled on one language with its own very different varieties of coding style and patterns. Some, like Ruby on Rails, are their own unique brand of language that makes you work both in the DSL (Rails in this case) and the parent language (Ruby here). Template engines often will do the same thing, such as in the case of Django.

It's pretty obvious that having to juggle all these tools places a fairly large burden on the coder. Much to their credit, it's not difficult to work in any of these languages, but to work in them at a high level becomes more difficult the deeper and wider the software stack reaches. You get this a bit in systems programming, juggling C/C++ with a build system and a scripting language, but that's usually it. You can get that number of moving parts just on the client side of the web with HTML, CSS, and Javascript.

Something interesting that seems to be happening is that people are moving to decrease this cognitive burden. One good example is the Google Web Toolkit which lets you write all your AJAXy client-side stuff in Java, and let it get compiled in to Javascript. That way you cut the languages you have to work in. A similar concept is behind Microsoft allowing Ruby (and Python, if I've heard correctly) in Silverlight. Alternately, you can bring Javascript (back) to the server side, which is the motivation behind Helma and Rhino on Rails (the latter of which I hope sees the light of day).

Personally, I'm rooting for Javascript to not become an assembly language, but to take over the server side again. It's a capable and powerful language (much better than Java in my opinion), and we're collectively leveraging it very poorly. Rhino is interesting and has enormous potential, but it needs library binds in the worst way. Currently it's basically using Javascript to write Java, which is rather atrocious (COBOL in any language, etc) but with some Javascript-style wrappers around the Java classes it could be phenomenal. Alternately, there's Spidermonkey, which could be wrapped in a more capable shell with a good FFI, and we could easily have wrappers to our favorite Free Software libraries. This project seems far along here, but it's currently very windows-centric.

There's a lot of potential here though. Unifying the development language for both web and system apps would benefit the Free Software desktop, and give us the ability to better integrate our stuff with the web. One of the best things about Free Software is that it dropped the barrier to entry in software development. I think we can repeat that success again here.
  • Current Music
    Carl Craig - Busted Trees (C's Spacetrumental) - Directions

Ruby Stuff

So Avi Bryant finally showed off the work he's been doing with the Gemstone folks at Railsconf, and it's made quite a splash. With performance improvements like that it shouldn't be a surprise. The most interesting thing about it to me though is that it's the first time in a very long while that we've seen a proprietary implementation of a major tool absolutely destroy all the Free implementations. We've had things like Intel's C compiler outperforming gcc before, but nothing on this level, especially because the main ruby implementation is so notoriously slow. Just another feather in the cap of Smalltalk's long legacy.

What's troubled me for some time about the post-Rails Ruby community is that it has a distinct bent away from its Free Software roots. I understand Matz actually used to use (not sure about today) Debian Unstable, and Ruby traditionally displayed its roots quite strongly, with a Perl heritage and a community consisting largely of hardcore *NIX people. With the advent of Rails, the move has been towards things like TextMate and OSX. Software like Gems (no relation to Gemstone) fits in fine with one of these systems, but not so well with modern Free Software systems, and I think it's symptomatic of the change. Given this propensity in the Ruby community, and given the numbers Gemstone is posting, I'd be surprised if lots of Rubyists don't move that way as soon as it's available.

Given all this, I really have to wonder if the modern Ruby fits me any more. I generally think it's important for the Free Software community to support itself first and then try to grow out from there, and the Ruby community isn't really on this path right now. That's fine, there's nothing wrong with it, it's just not something that really interests me. It does make me wonder how something like this could happen, and it really comes down to the fact that a lot of smart people who might otherwise be really passionate about Linux systems are choosing OSX instead. Maybe it's hardware support (I hope the modernization of X will help here) and maybe it's just the whole package being nice and easy to use. Whatever it is, people are choosing it and we're the poorer for it.

Card Games

A few months back, keithp introduced me to Treehouse/Icehouse as a generic system for gaming, like playing cards. Recently I realized that I didn't actually know many card games, and most of those that I did know I'd forgotten long ago. So today I spent a good chunk of the afternoon learning a few new games and playing them. John McLeod's site was the first hit I found on Google, and it's a phenomenal resource full of games from all over the world. The games that I learned or re-learned today were Casino, 500 Rum (which is a Rummy/Gin Rummy variant), and German Whist.

It's striking how many games are generally unknown these days. We have so many other forms of entertainment available that we've collectively forgotten how to play most of these games. It's fun to be reminded what you can do with a simple deck or two of cards though.
  • Current Mood
    content content

Upside Down

Things have been strange lately. I've been taking an official indefinite vacation from Debian due to real life priorities making it impossible to participate in the project at the level that I want, which just led to frustration. Mainly, I just haven't had the time to work on X properly, so I'm leaving it to the rest of the XSF for a while. This makes me sad, but they've grown in to a fantastic team so I know they'll keep doing a killer job while I'm away.

I have had some time though, just not enough to follow two major projects like X.org and Debian, so I've been trying to leverage it in productive ways. Perhaps the most notable is that I've been spending most of my time coding Smalltalk using Squeak now that it's in Debian. Squeak has its flaws, but it's very fun to work with and Smalltalk is probably my favorite language at this point, displacing Ruby. This shouldn't be too big a surprise, since Ruby consciously inherits a lot from Smalltalk. Squeak is a good environment, but I don't feel too compelled to write desktop apps in it because they feel so displaced from the rest of the system. GNU Smalltalk will hopefully fix this in time. As a result though, I've been doing my first bit of web coding in a very long time. The main reason for this is the incredible Seaside framework built on Smalltalk. It's been a lot of fun to play with, and although it's very underdocumented, there's enough out there (especially with the new book) that I've used to get going. Right now I'm trying to learn AJAX techniques as well, which is something I never thought I'd be doing.

As a result of learning Smalltalk, combined with past experiences, I've been trying to learn emacs, and switch a lot of my text editing over there. I came to realize that the reasons I chose vim over emacs many years ago aren't really holding up any more, and now that I've got a lot more of both UNIX and coding under my belt that it's time to reevaluate the decision in a more intelligent way. Vim has been great to me over the years, but I found it constraining when trying to work on very large and difficult trees like the X server. I'm hoping that emacs will do a little better, since I like the way it handles multiple buffers better. Additionally, the purity of Smalltalk "all the way down" has made me appreciate the emacs architecture of lisp (almost) "all the way down" and I'm looking forward to making use of it. It's been a painful transition so far, given the years of muscle memory I'm trying to change. I've been avoiding viper mode to really try and learn emacs, which has made it even harder. I don't know if I'll end up using emacs after all is said and done, but at least I'll have a better idea of how the two major editors really compare for my own use.

With all these changes things have been a little strange lately. Debian was the rock that I've clung to over the past few years, and not being totally entrenched in it has felt unnerving. Combining that with very new and different ways of working has been a rather large change. One thing is for certain: it's been very good for me to take a break for a while and work on small things at my own pace rather than try to keep up with large projects. People burn out all the time in the free software community, and I think that disconnecting and working on small fun things is a great way to heal.
  • Current Mood
    calm calm