A Little Bit is Better Than Nada

It is a running joke in the X.Org community that X12 development will commence as soon as all of the X11 bugs in the FreeDesktop.org bug tracker have been closed. When I first heard this, my reaction was, of course, "Challenge accepted!" But where to start?

There were about 10,000 bugs open on the tracker at that point, a few years ago. We're definitely improving; there are about 9180 bugs open (at the time of writing) which could be considered relevant to any kind of desktop development. Many of those don't belong to anything in X11, but assuming they did...

Pretend that all of the card-carrying members of X.Org closed 92 bugs. That would be 1% per person. We could be done with X11! So, during XDC 2011, I pulled out my netbook, and started closing bugs. I picked, as my targets, things that nobody would miss, like Xprint.

I closed some Xprint-related bugs, before simply shuttering everything in the Xprint product. I also picked up a couple of stray bugs. Finally, with maintainer permission, I closed everything still assigned to xf86-video-nv.

The results:

  • 24 Xprint-related bugs
  • 37 bugs in Product: xprint
  • 42 bugs in Component: driver/nv
  • 37 bugs in Component: driver/nVidia (open)
  • #9455, #28657, #29832, #30129

A total of 144 bugs. We can do this, guys!

~ C.

Last modified on 2012-01-22 12:00:00


After accidentally hitting yet another window manager key combination this morning, I finally was fed up, and went off to read chromeos-wm source code to discover all of the key bindings. Here's the complete list:

  • Ctrl-F5: Take fullscreen screenshot
  • Ctrl-Shift-F5, Print Screen: Take region screenshot
  • Alt-Tab: Cycle windows forward
  • Alt-Shift-Tab: Cycle windows backwards
  • Alt-1 through Alt-8: Go to window 1 through 8, 1-indexed
  • Alt-9: Go to the last window
  • Ctrl-Alt-t: Create a new shell window
  • Ctrl-Shift-W: Kill the current window

These are only available in overlapping-window mode, which appears to be the default on at least Samsung Series 5 Chromebooks:

  • F5: Toggle overlapping-window mode
  • Alt-Comma: Expand current window
  • Alt-Period: Shrink current window

~ C.

Last modified on 2011-11-29 17:03:00

Poison Was the Cure

glyph and I met for the first time a few weeks ago, and ever since, he's been asking me to do things. Write code, review patches, write blog posts, that kind of thing. Being the lazy person I am, I'm not really up-front or speedy about doing things outside of my habitual box. Thankfully, I got inspired by a troll.

Everybody's read Ted Dziuba's fantastic anti-Node troll, right? It's good food for thought, even if it is a little bit belligerent. I wanted to demonstrate that Twisted doesn't have the same problems as Node. I also wanted to write a small application for Heroku, because I participated in their Python beta and figured out how to run Twisted applications on their platform.

So, I wrote a tiny application that does a few things. First, it runs on Heroku. It includes the Procfile magic for running on Heroku correctly, and only depends on Twisted. Second, it calculates Fibonacci numbers. The idiom that I chose to implement involves not caching the numbers, and instead using threads to do background work. I was going to do something highly idiomatic and Twisted-like, such as setting a timer and coming back to do the work later, but I wanted to show off a feature of Twisted which is completely missing from Node: The ability to write threaded code without leaving your language.

That's right, Node.js does not have the ability to host multiple threads in JavaScript. (Correct me if I'm wrong, but after a half-hour of research and an assertion I made on Hacker News which went unchallenged, I'm pretty sure that this is the case.) Why? I don't know. Possibly because Node's tied to V8, which is very shiny but certainly not as cool as the dominant Python implementations, like CPython or PyPy. Now, make no mistake, many Pythons have GILs or fine-grained locks, which can slow down threaded code, but Node can't even attempt to thread off its CPU-bound long-running computations, and I think that's an important ability to have. And as a well-known anti-threading advocate, when I admit that threads have their uses, I hope people notice.

I also got very annoyed at everybody who felt that they were demonstrating the benefits of Node by writing equivalent servers in Python using the standard library. Python's built-in servers suck. They straight-up suck. Would you deploy a web server written in pure JavaScript with only the standard library shipped with all JavaScript implementations? Probably not! Just like one needs Node to write those servers, Python developers use Twisted to provide that functionality. Otherwise, you're deliberately crippling your examples in order to skew impressions of Python. I'm going to shame you here, because you should know better. You should know about Twisted, if for no other reason than that it is listed on the front page of Node.js's homepage as one of the inspirations for Node. No, really, go check. I'll wait here.

The actual Heroku side of things is kind of boring. Heroku's Python support is fantastic. Use the cedar stack when you create your app with heroku apps:create --stack cedar and put a line into your Procfile which passes the $PORT shell variable into your app somehow. If you're deploying stock Twisted Web, something like bin/python ./twistd -n web --port=$PORT is a good starter. You can, of course, easily deploy WSGI apps on top of this using --wsgi. You must not daemonize on Heroku. That's really about it; it's a very straightforward platform which is easy to use and I'm very impressed by their work.

I have an application running on Heroku right now. The link is currently right here although it might be taken down in a few months when I need to experiment more. I'm a free customer, you see, and I'm not willing to pay a monthly fee just to prove a point about people on the Internets. Anyway, the application does nothing except check how many threads are running on the system, calculate a Fibonacci number, and tell you how long the request took. It can do this for many concurrent users; you might notice, if there are many active requests, that the page will stop loading halfway through as your request to calculate a Fibonacci number sits in line in a threadpool. Your actual browser connection won't be dropped, though.

The code is a demonstration of Heroku's cedar stack and a few fancier things in Twisted Web, like the new templating system added in Twisted 11.0. You can find it on Github; the repo is called "cancer" for obvious reasons.

Oh, and as a closer: Some people have complained heavily about the idiom that was demonstrated at the end of Ted's rant. The reason that he posted that is that JavaScript programmers, unlike Python programmers, never really got in the habit of not using names which haven't been declared or defined. The idiom in Python looks like this:

if my_var is not None:

We don't check to see if my_var in locals() or anything stupid like that, because my_var should be easy to track and the line where it was defined should be obvious. If it's not, you're writing bad code.

~ C.

Last modified on 2011-10-03 10:16:59

Valid CSS!