When I want to install an application on a computer that I use, I open a terminal and type something to the effect of:

apt-get install rxvt-unicode

Which is a great little terminal emulator. I recommend it. Assuming I have a live interned connection, and the application I’m installing isn’t too large, a minute later or less I have whatever it is I asked for installed and ready to use (in most cases.)

Indeed this is the major feature of most Linux Distributions: their core technology and enterprise is to take all of the awesome software that’s out there (and there’s a lot of it,) and make it possible to install easily, to figure out what it depends on, and get it to compile safely and run on a whole host of machines. Although this isn’t the kind of thing that most people think when they’re choosing a distribution of Linux, one of the biggest differentiating features between distributions. But I digress.

I’ve written about package management here before, but to summarize:

1. We use package managers because many programs share dependencies, that we wouldn’t want to install twice or three times, but that we might not want to install by default with every installation of an operating system. Making sure that everything gets installed is important. This, is I think, a fairly unique-to-open-source problem, because in the proprietary system the dependencies are installed by default (as in there are more monolithic development environments, like .NET, Cocoa, and Java¹, and other older non-managed options).
2. One of the defining characteristics of open source software is the fact that it’s meant to be redistributed. Package management makes it easy to redistribute software, and provides real value for both the users of the operating system and for the upstream developers. Or so I’m lead to believe.

In the end, we’re back at the beginning where, you can install just about anything in the world if you know what the package is named, and the operating system will blithely keep everything up to date and maintained.²

While GNU/Linux systems get flack for not being as useable as proprietary operating systems, I see package management as this huge “killer feature” that open source systems have on top of proprietary system. We’ll never see something like apt-get for Windows not because it’s not good technology, but because it’s impossible to mange every component of the system and all of the software with a single tool.³

And then all these “App Store” things started popping up.

As I’ve thought about it, “App stores,” do the same thing for application delivery on non-GNU/* systems that package management does for open source systems. We’re seeing this sort of thing for various platforms from cell phones like the iPhone/Blackberry/Andriod to Inuit’s QuickBooks and even for more conventional platforms like Java.

Technically it’s a bit less interesting. App stores generally just receive and distribute compiled code,⁴ but from a social and user-centric perspective, the app store experience is really quite similar to the package management experience.

I’m surely not the only one to make this connection, but I’d be interesting to move past this and think about the kinds of technological progress that stem from this. App stores clearly provide value to users by making applications easier to find, and to developers who can spend less time distributing their software. Are there greater advancements to be made here? Is this always going to be platform specific, or might there be some other sort of curatorial mechanism that might add even more value in this space? And of course, how does Free Software persist and survive in this kind of environment?

I look forward to hearing from you.

A mostly technology-centric collection of links:

• Emacs starter configuration scripts. I can’t, for the life of me, recall why I went looking for this, but last week I ended up with a whole host of basic configuration files that people have published. I’ve thought about doing this for my own files, but I’ve not had it properly cleaned up and working in a non-embarrassing way in a while. Most of these are on github, which is a phenomena that could tolerate some investigation, but no matter. Here they are, linked to by screen name: ki, elq, jonshea, larrywright, defmacro (har, just got it), jmhodges, technomancy, markhepburn, and al3x. I’d love to collect more of these, so maybe comments or the cyborg wiki.

• Adjunct to that, a few more cool emacs and related links and points: First, paraedit which is a little tool which makes editing lisp easier, as well as an org-mode tip from Nathan Yergler about using org-rembmember with firefox and ubiquity. which might be of interest to some of you. I also have in the file [this link about yet another lisp dialect (yald?) called Lysp, but I don’t have much more than that. I, on the other hand will have more to say about this in the coming few weeks.

• My **friend Chris Fletcher discusses his experience with contemporary blogging services** in this post. I’m not sure. Right? I mean blogging is so different today than it was when I got into it. I remember when you handed FTP credentials to blogger so they could publish your blog with their system to your site. Surely people don’t do that anymore. One of the things that I noticed at Podcamp (more on that on another post) that, frankly horrified me a bit, was that there was a whole class of bloggers who wanted to do “this thing,” but they had no interest in running their own website or making that investment of time and energy.

  And maybe that’s what blogging has become. In a lot of ways doing a blog is something anyone can do pretty easily, and having a website is no longer a big part of participating in this discourse. While I’m a big fan of independence, and I don’t think the technological burden is that high. “Doing websites,” very much made me the geek I am today, so I’m not sure. Having said that, LiveJournal has never easily fit into a niche: It was blogging before there was blogging. It was social networking before we said that. It was subculture/niche before that became the thing. If I had more time in my life I’d figure out some way to study and capture that history.

• For all of you OS X Desktop User Interaction Geeks, there’s this thing that lets you hide unused windows baked into the window manager. I think. I have access to OS X, but I don’t really use it enough to give this a try. GNU Screen and lots (and lots) of Emacs buffers make it possible to keep a lot of irons on the fire without getting distracted.

• A **good example of a zshrc** file if that’s your thing. I think it’s my thing. Alas. I’ll write more about this once I get more used to it and figure some things out. Mostly, I’m finding that one can use it as a pure superset of bash without ill effect.

I wrote a post for the Cyborg Institute several weeks ago about the idea of “Reusable Software”, and I’ve thought for a while that it deserved a bit more attention. The first time around, I concentrated a lot about the idea of reusable software in the context of the kinds of computing that people like you and me do on a day to day basis. I was trying to think about the way we interact with computers and how this has changed in the last 30 years (or so) and how we might expect for this to change soon.

Well that was the attempt at any rate. I’m not sure how close I got to that.

More recently, I’ve been thinking about the plight of reusable software in the context of “bigger scale” information technology. I’d say this fits into my larger series of technology futurism posts, except that this is very much a work of presentism. So be it.

To back up for a moment I think we can summarize the argument against reusable software, which boils down to a couple of points:

1. With widely reusable software, most of the people who use computers on a regular basis can pretty much avoid ever having to write software. While it’s probably true most people end up doing a very small amount of programming without realizing it, gone are the days when using a computer meant that you had to know how to program it. While more people can slip into using computers than ever before, the argument is that people aren’t as good at using computers because they don’t know how they work as well.

Arguably this trend is one of the harbingers of the singularity, but that’s an aside.

2. Widely reusable software is often less good software than the single-use, or single-purpose stuff. When software doesn’t need to be reused, it only needs to do the exact things you need it to do well and can be optimized, tuned, and designed to fit into a single person’s or organization’s work-flow. When developers know that they’re developing a reusable application, they have to take into account possible variances in the environments where it will be deployed, a host of possible supported and unsupported uses. They have to design a feature set for a normalized population, and the end result is simply lower quality software.

So with the above rattling around in my head, I’ve been asking:

• Are web applications, which are deployed centrally and often only on one machine (or a small cluster of machines), the beginning of a return to single use applications? Particularly since the specific economic goals of the sponsoring organization/company is often quite tightly coupled with the code itself?
• One of the leading reasons that people give for avoiding open source release is embarrassment at the code base. While many would argue that this is avoidance of one sort or another, and it might be, I think it’s probably also true more often than not. I’m interested in thinking about what the impact of the open source movement’s focus on source code has had on the development of single use code versus multi use code in the larger scope.
• What do we see people doing with web application frameworks in terms of code reuse? For starters, the frameworks themselves are all about code reuse and bout providing some basic tools to prevent developers from recreating the wheel over and over again. But then, the applications are (within some basic limitations) wildly different from each other and highly un-reusable.

Having said that, Rails/Django/Drupal sites suffer from poor performance in particularly high-volume situations for two reasons: Firstly, it’s possible to strangle yourself in database queries in the attempt to do something that you’d never do if you had to write the queries yourself. Secondly the frameworks are optimized to save developers time, rather than run blindingly fast on very little memory.

I suppose if I had the answers I wouldn’t be writing this here blog, but I think the questions are more interesting anyways, and besides, I bet you all know what I think about this stuff. Do be in touch with your questions and answers.

Onwards and Upwards!

As I said in “The Odd Cyborg Out,” I’m thinking of giving StumpWM a run. So I did some musing about tiling window managers, because I am who I am. Here goes,

So, like I said, I’ve been tinkering a very little with StumpWM, and I thought some background might be useful. For those of you who aren’t familiar, StumpWM is another tiling window manager, like my old standard Awesome, except Stump is written in Common Lisp, and is descended from different origins from Awesome. Here’s the history as I understand it.

The History of Tiling Window Managers

There was (and is,) this very minimalist tiling window manager called dwm which is written in less than 2000 lines of code, and is only configurable by modifying the original C code and then recompiling. It’s intentionally elitist, and targeted at a very high level of user. While this is ok, particularly given the niche that are likely to want to use tiling window managers, there were a lot of people who wanted very different things from dwm. In a familiar story to those of us who follow free software and open source development: lots of people started maintaining and sharing patch-sets for DWM. These added additional functionality like easier configuration tools, integration with menus, notification libraries, theeing support, API hooks, and the rest is history.

Fast-forwarding a bit, these patch-sets inspired a number of forks, clones, and children projects. DWM was great (so I hear) if you were into it, but I think the consensus is that even if you were geeky/dweeby enough for it, it required a lot of attention and work to get it to be really useable in a day-to-day sort of way. As a result we see things like Awesome, which began life as a fork of DWM with some configuration options, and has grown into it’s own project “in the tradition of dwm.” dwm is also a leading inpsiration for projects like Xmonad, which is a re-implementation of dwm in the Haskell programing language with some added features around extension and configuration options.

This default configuration problem is something of an issue in the tiling window manager space, that I might need to return to in a later post. In any case…

Stump, by contrast has nothing (really) to do with dwm, except that they take a similar sort of approach to the “window management” problem which is to say that window behavior in both are highly structured and efficient. They tiling windows to use the whole screen and focus on a user experience which is highly keyboard driven operation. Stump, like xmonad, is designed to use one language exclusively for both the core program, the configuration, and the extension of the environment.

And, as I touched on in my last post on the subject I’m kind of enamored with lisp, and it clicks in my head. I don’t think that I “chose wrong” with regards to Awesome, or that I’ve wasted a bunch of time with Awesome. Frankly, I think I’m pretty likely to remain involved with the project, but I think I’m a very different computer user--Cyborg--today than I was back then, and one of the things that I’ve discovered since I started using Awesome has been emacs and Lisp.

My History with Awesome

Lets talk a little bit more about Awesome though. Awesome is the thing that set me along the path to being a full-time GNU/Linux user. I found the tiling window manager paradigm the perfect thing that lets me concentrate on the parts of my projects that are important and not get hung up on the distractions of organizing windows, and all of the “mouse stuff” that took too much of my brain time. I started playing around in a VM on my old Macbook and I found that I just got things accomplished there somehow. And the more I played with things the more I got into it, and the rest is history.

When I finally gave up the mac, however, I realized that my flirtation with vim wasn’t going to cut it, and I sort of fell down the emacs rabbit hole, which makes sense--in retrospect--given my temperament and the kind of work that I do, but none the less here I am. While Awesome is something that I’m comfortable with and that has severed me quite well, there are a number of inspirations for my switch. Some of them have to do with Awesome itself, but most of them have to do with me:

• I want to learn Common Lisp. While I know that emacs’ lisp, and Common Lisp aren’t the same there are similarities, and Lua was something that I’ve put up with and avoided a lot while using Awesome. Its not that Lua is hard, quite the opposite, it’s just that I don’t have much use for it in any other context, and while I know enough to make awesome really work for me, my configuration is incredibly boring.

  Not that I think Common Lisp is exactly the kind of thing that is going to be incredibly useful to me in my career in the future, but like I said: I like the way Lisp makes me think, and it’s a language that can be used for production-grade types of things, and it’s a standard, it’s not explained from a math-centric¹ perspective, and like I said reading lisp code makes sense to me. Go figure.

• There are several of quirks with Awesome which get to me:

• If you change your configuration, you have to restart the window manager. Which wouldn’t be a big problem except…

• When you restart, if you have a window that appears in more than one tag, the window only appears on one tag.

• The commands for awesome are by default pretty “vimmy,” and while my current config has been properly “emacsified,” you have to do a lot of ugliness to get emacs-style chords (e.g. “C-x C-r o a f” or Control-x, Control-R, followed by o, a, and f.) which I kind of like.)

• Because one of my primary environments is running a virtual machine (in Virtual Box) on an OS X host, I’ve run into some problems around using the Command/Windows/Mod4 key, and there’s no really good way to get around this in awesome.

So that’s my beef, along with the change in usage pattern that I talked about last time, which is probably the biggest single factor. I’m not terribly familiar with Stump yet, so I don’t have a lot to offer in terms of thoughts, but I’ve been tinkering in the laptop, and it fits my brain, which is rather nice. I’ll post more as I progress. For now I think I better cut this off.

So what’s the answer to all this operating system and hardware driver angst?

I’m going to make the argument that the answer, insofar as there is one is probably virtualization.

But wait, tycho, this virtualization stuff all about servers. Right?

Heretofore, virtualization technology--the stuff that lets us take a single very powerful piece of hardware, and run multiple instances of an operating system that, in most ways “think of themselves” as being an actual physical computer--has been used in the server way, as a way of “consolidating” and utilizing the potential of given hardware. This is largely because hardware has become so powerful that it’s hard to write software that really leverages this effectively, and there are some other benefits that make managing physical servers “virtually” a generally good thing, and there aren’t a lot of people who would be skeptical of this assertion I think.

But on desktops? On servers where users access the computer over a network connection, it makes sense to put a number of “logical machines” on a physical machine. On a desktop machine this doesn’t make a lot of sense, after all, we generally interact with the physicality of the machine; so having multiple, concurrently running, operating systems on your desk (or in your lap!) doesn’t seem to provide a great benefit. I’d suggest the following two possibilities:

• Hypervisors (i.e. the technology that talks to the hardware and the operating system instances running on the hardware,) abstract away the driver problem. The hypervisors real job is to talk to the actual hardware, and provide a hardware-like-interface to the “guest operating systems.” Turns out this technology is 80-90% of where it needs to be for desktop usage. This makes the driver problem a little easier to solve.
• Application specific operating systems. One of the problems with desktop usability in recent years is that we’ve been building interfaces that have needed to do everything, as people use computers for everything. This makes operating systems and stacks difficult to design and support, and there is all sorts of unforeseen interactions between all of the different things that we do, which doesn’t help things. So desktop virtualization might allow us to develop very slim operating systems that are exceedingly reliable and portable, but also very limited in what they can accomplish. Which is ok, because we could have any number of them on a given computer.

I only need one instance of an operating system on my computer, why do you want me to have more?

See above for a couple of “ways desktop hypervisors may promote the growth of technology.” But there are a number of other features that desktop virtualization would convey to users, but it mostly boils down to “Easier management and backup.”

If the “machine” is running in a container on top of a hypervisor, its relatively easy to move it to a different machine (the worst thing that could happen is the virtual machine would have to be rebooted, and even then, not always.) It’s easy to snapshot known working states. It’s easy to redeploy a base image of an operating system in moments. These are all things that are, when we live “on the metal,” quite difficult at the moment.

For the record, I don’t think anyone is ever really going have more than five (or so) instances running on their machine, but it seems like there’s a lot of room for some useful applications around five machines.

And lets face it, TCP/IPA is the mode of inter-process communication these days, so I don’t think application architectures would likely change all that much.

Won’t desktop hypervisors have the same sorts of problems that “conventional operating systems,” have today. You’re just moving the problem around.

If you’re talking about the drivers problem discussed earlier, then in a manner of speaking, yes. Hypervisors would need to be able to support all kinds of hardware that (in many cases) they don’t already support. The argument for “giving this” to hypervisor developers is that largely, they’re already working very closely with the “metal” (a great deal of hardware today has some support for virtualization baked in,) and hypervisors are in total much simpler projects.

Its true that I’m mostly suggesting that we move things around a bit, and that isn’t something that’s guaranteed to fix a specific problem, but I think there’s some benefit in rearranging our efforts in this space. As it were

Don’t some of the leading hypervisors, like KVM and others, use the parts or all of the Linux Kernel, so wouldn’t this just recreate all of the problems of contemporary Linux anew?

I’ll confess that I’m a huge fan of the Xen hypervisor which takes a much more “thin” approach to the hypervisor problem, because I’m worried about this very problem. And I think Xen is more parsimonious. KVM might be able to offer some slight edge in some contexts in the next few years, like the ability to more intelligently operate inside of the guest operating system, but that’s a ways down the road and subject to the same problems that Linux has today.

So there you have it. Thoughts?

I made a quip the other day about the UNIX Epoch problem (unix time stamps, are measured in seconds since Jan 1, 1970, and displayed in a 10 digit number. Sometime in 2038, there will need to be 11 digits, and there’s no really good way to fix that.) Someone responded “whatever, we won’t be using UNIX in thirty years!”

Famous last words.

People were saying this about UNIX itself years ago. Indeed before Linux had even begun to be a “thing,” Bell Labs had moved on to “Plan 9” which was to be the successor to UNIX. It wasn’t. Unix came back. Hell, in the late eighties and early nineties we even thought that the “monolithic kernel” as a model of operating system design was dead, and here we are. Funny that.

While it’s probably the case that we’re not going to be using the same technology in thirty years that we are today (i.e. UNIX and GNU/Linux,) it’s probably also true that UNIX as we’ve come to know it, is not going to disappear given UNIX’s stubborn history in this space. More interesting, I think, is to contemplate the ways that UNIX and Linux will resonate in the future. This post is an exploration of one of these possibilities.

I suppose my title has forced me to tip my hand slightly, but lets ignore that for a moment, and instead present the leading problem with personal computing technology today: hardware drivers.

“Operating System geeks,” of which we all know one or two, love to discuss the various merits of Windows/OS X/Linux “such and such works better than everything else,” “such and such is more stable than this,” “suck and such feels bloated compared to that,” and so on and so forth. The truth is that if we take a step back, we can see that the core problem for all of these operating systems is pretty simple: it’s the drivers, stupid.

Lets take Desktop Linux as an example. I’d argue that there are two large barriers to it’s widespread adoption. First it’s not immediately familiar to people who are used to using Windows. This is pretty easily addressed with some training, and I think Microsoft’s willingness to change their interface in the last few years (i.e. the Office “Ribbon,” and so forth,) is a great testimony to the adaptability of the user base. The second, and slightly more thorny issue is about hardware drivers: which are the part of any operating system that allow the software to talk to hardware like video, sound, and networking (including, of course, wireless) adapters. The Kernel has gotten much better in this regard in the past few years (probably by adding support for devices without requiring their drivers be open source), but the leading cause of an “install just not working,” is almost always something related to the drivers.

“Linux People,” avoid this problem by buying hardware that they know is well supported. In my world that means, “Intel everything particularly if you want wireless to work, and Nvidia graphics if you need something peppy, which I never really do,” but I know people who take other approaches.

In a weird way this “geek’s approach to linux” is pretty much the same way that Apple responds to the driver problem in OS X. By constraining their Operating System to run only on a very limited selection of hardware, they’re able to make sure that the drivers work. Try and add a third party wireless card to OS X. It’s not pretty.

Windows is probably the largest victim to the driver problem: they have to support every piece of consumer hardware and their hands are more or less tied. The famous Blue Screen of Death? Driver errors. System bloat (really for all operating systems) tends to be about device drivers. Random lockups? Drivers. Could Microsoft build better solutions for these driver problems, or push equipment manufacturers to use hardware that had “good drivers,” probably; but as much as it pains me, I don’t really think that it would make a whole lot of business sense for them to do that, at the moment.

More on this tomorrow…

I really don’t want to use the web anymore. This should come as no great surprise to most of you, but I think it’s worth pondering a bit, particularly because like all “breaking ups,” it’s a bit difficult. To recap, the reasons for the break up:

• The software we use to browse the web is awkward and difficult to use efficiently. I’m talking here about things like Firefox, Safari, and Chrome. While “webkit” generation browsers are better than everything that’s come before (even if their lack of comparability with the Firefox Platform makes them useable,) every browser I’ve interacted with is a huge program that just feels unwieldy.
• There are two many distractions in the browser. I’ve managed to find ways to assimilate and interact with nearly all of the information that comes at me in the course of a day or a week in a sane, balanced, and efficient way. Except for the browser. Where I find myself refreshing Facebook or twitter endlessly. I don’t even like facebook and the twitter website all that much.
• The web is too sensitive to the availability of data connectivity. While I have an Internet connection nearly all of the time that I’m in front of a connection, I don’t really like to rely on this to do my work. I don’t want to use applications that rely on connectivity, and I hate situations where I have a few moments to do something, and I have a computer with me, and I get started and then I have to check a fact, or read a little bit about {{something}} on wikipedia, and I can’t because I don’t have a connection.
• I don’t like that the presentation layer of the web provides so much flexibility to make websites so unreadable and difficult to comprehend. Web browsers interfaces like emacs-w3m improve this somewhat, but even that is somewhat lacking. This isn’t a problem with software, but rather it’s a problem with designers, design, and the “way the web works.”

So to end on a somewhat positive note. Here’s what I think we really need in the next generation of digitally connected applications.

• Some sort of very smart predictive caching software that would run locally. We have the hard-drive space in contemporary machines that we could dedicate--as much as 100 gigabytes to a cache of network data and never really feel a space crunch. In some cases even more. I think most people’s digital music collections tend to top out in the 75-100 gig range, and “small” desktop hard drives have at least 500 gigs. Nothing else--well videos--takes up space. This would make the offline web a much more realistic proposition, it would speed things up and we could work on ways of only sending diffs between the cache and the servers, and it would rock.

• Databases need to mostly move off of the server and onto local boxes. Extension of point above. Content doesn’t change that much, local machines are now fast and smart enough to really be able to handle this. This is in HTML5, but having said that, I worry a bit. Because I’m me.

• We can import a lot of the “intelligence” of computing onto clients. There’s moves toward this already, with Adobe AIR and it’s competitors, but this seems to be all about adding “bling” to the web experience, and use the cross-platform nature of web technologies, even the proprietary ones like Flash, to reinvent desktop application development. I think we can go even further with this. Lets think about the next generation of desktop RSS clients. Offline wiki/wikipedia software.

  I’m not trying to buck the “software in the 21st century is social and connected” trend that we’re in the middle of, but rather seriously rethink the interface and work-flow paradigms of the web.

• I hope that the next generation of web-document standards (of which I think sygn is an example) will focus on structure and organization and a much more limited set of “features” (less is more) that will let content creators make content more useful rather than better looking.

  Take design out of the content, and put all of the display logic (aside from headings and meta-data) on the client. Don’t like how a site displays? Use a different client. And so forth.

Anyone with me?

I said to my office mate this week, “I’m switching to zsh,” and I believe he said something to the effect of “oh dear, what’s next.”

I should back up. I’m something of an odd duck when it comes to the way I use computers. I’m a geek, even in the context of my coworkers who are (also) huge geeks. I’m the only one who uses emacs. We’re an OS X shop (for the desktop, at least) but I run Arch Linux inside of a virtual machine. Because I’m like that. And now, I’m switching away from the by-now unix standard “bash” shell to “zsh.” I’m a bit weird. I’m ok with this.

So zsh. Why should you care? Well…

I’m not expert, having only really used it for a few days but there are a few things that have won me over:

• It’s mostly backwards compatible with bash. So, except for the stuff that configured my prompt, I was able to copy over my old .bashrc file pretty much as is. There’s been no real “brain adjustment” from all my old bash habits.
• It’s faster. You know, this is the kind of thing taht you don’t believe, “my terminal is faster than your terminal” is kinda lame because bash is pretty peppy compared to GUI stuff. I mean what, bash is a 300-400 kb, how slow can it be? The answer is, zsh just feels faster. This seems to be a quasi universal experience.
• It does tab-completion within commands. This is seriously amazing, because while command completion and path completion is awesome in bash, you still have to remember all of the sub-commands. This is particularly rough for big commands like “git” and “apt-get” or “apt-cache”. Very awesome.

Getting up the courage to switch and to rewrite my prompt was something that took a little bit of doing, but now I’m happy, and I strongly recommend it. If you like me live in the terminal, or have thought about using the command line more, give zsh a try, it’s good stuff.

The other thing, almost certain to provoke an “Oh dear” reaction on the part of my geeky friends is the fact that I’m strongly considering switching from the Awesome Window Manager to the Stump Window Manager, or more practically StumpWM or just Stump. Here’s some background on my adventures with tiling window managers:

When I started using Awesome every thing I did with the computer lived in it’s own little window. I was coming from the mac, so I lived with ten or fifteen open TextMate windows, a like number of open tabs in my terminal emulator, and a browser with a gazillion open tabs. I thought that this was sort of “the way I worked,” and so I replicated this kind of workflow in Awesome.

And here’s the thing. Awesome is great for managing a huge number of windows. With 9 workspaces/tags (or more!) it was possible to keep twenty or thirty windows afloat… a few browsers, a few chat windows, a dozen terminals, a few emacs frames, and the like all happening at once. And the window manager made it possible for me to only have to look at 2 or three windows at a time.

Then I progressed. With emacs’ server/daemon mode, I only have one instance of emacs and 20 or so buffers, and in an extreme moment I sometimes have as many as 4 frames open at once, but more often I just have 2 or three (org-mode, writing, and a spare for something.) And terminals? I’ve taken to using screen which multiplexes an untabbed terminal, so I typically have a single screen session with 8 screen-windows, and I keep a couple of instances of that open at once for different contexts, so lets say another three windows. I have a remote screen session for IM and chat now that I connect to, and a single web browser.

Frankly, it’s sort of gotten to the point where I don’t really need to manage very many windows, and I probably never use more than 4-5 tags/workspaces. My needs for a window manager changed, and one of the core problems that problem that Awesome solves, is one that I’ve solved by using multiplexed applications. And that leads me to Stump.

I see that I probably need to spend a little more time talking about this tiling window manager stuff again. Stay tuned!

I got a Blackberry last December. I blogged about it then, but I haven’t really talked much about it. There’s been a bunch of hubbub recently about the iPhone finally getting Multimedia Messaging Service (MMS) support, and this has spurned some thought on my part about smartphones and mobile technology, and all that jazz. It’s a big space in the technology world, and most of the time I just ignore all of it, because I don’t much care about it. I’m a “big computing,” kind of guy, and I don’t much like the whole “talking on the phone thing,” but this doesn’t--you’re surely not surprised to learn--mean that I don’t have opinions on the subject.

Despite my disdain for telephones, I really like the whole Blackberry thing. The physical keyboard means I’m way faster at typing up messages and notes than I would be otherwise, and that’s incredibly useful. Blackberries aren’t, “sexy” as smartphones go, and frankly the software is sort of insane with regards to how it all works, but in comparison to how other phones work, I’m pretty happy with the way things are. Here are the Pros:

• I like that I can run applications in the background on the Blackberry. Being able to get alerts when emails come in. Being able to leave a message that I’m writing, and go respond to another message, or make a call, or get an instant message or twiddle with Google maps, is really great.
• I enjoy that the phone is messaging centric. Furthermore, I really like that all messaging: Blackberry Messaging (IM), GoogleTalk (jabber), SMS Texting, and email all appear in one great queue. There’s one big list of things, to check and that’s it. The key to making this work is good filtering, but that’s another point.
• I really enjoy the ecosystem of applications available for the phone. Blackberries like many smartphones (including the Android platform, after a fashion) use the J2ME (java) platform, which means and the platform is rather established. Sure the sexy things that people do with iPhones aren’t there for my phone, and there are applications that I wish I had (better SSH, a text editor, some sort of file synching ability,) but the apps I have all work well, are stable, and integrate well with the system (ie. the messaging thing.)
• There are host of little things that are great. The charging cradle is an awesome thing. The fact that it’s “smart” enough to alter its behavior based on if it’s in the case or not in the case, so that if it’s on your belt it does something different than if it’s laying on your desk. It also has a “bedside” mode which I think is similarly brilliant. Not a huge feature, but exceedingly useful.
• So Google does this thing with their Sync Tools where your contacts from Gmail end up on your phone, and the sync is pretty seamless. No more futzing around with adding people by hand, no more worrying about backing up your database. I’m not thrilled about this reliance on Google, but it just works, and that is an intensely good thing. I do kind of wish that more things on the phone were like this.

What I don’t like?

• The twitter apps don’t integrate well into the messaging, and I can’t think of a sane way to use twitter with my phone.
• There is no real XMPP/Jabber application aside from Google Talk that I’ve found to be useable. (Though I’d love to be proven wrong.) It would be nice to be able to connect to my general use XMPP account under a different resource and go from there.
• I think, as an interaction modality the trackball is a horrible idea, and I think something more joystick-like would be a much more useful and quick. Even, perhaps something that used the keyboard more effectively. As it is, all navigation and system operation uses the trackball, and that’s kind of annoying. It’s done as well as it could, but I think it could be better.
• Email filtering is non-intuitive and difficult. Possible, certainly, but difficult. I’d like an interface to be able to exclude and block various senders on the phone itself.
• Configuration options are Byzantine and difficult to navigate. There are so many options particularly around the various noises that the phone will make that I’ve not bothered to really modify any of them. I might load up the beginning of “Thick as A Brick” for my ring tone (and part two for the alarm clock?), but for the most part there are too many chirps and chatters that the damn thing does, that it’s hard to really modify it in any real way. It makes it interesting to be in close proximity to other Blackberry users for any length of time, because those noises get embedded in your consciousness.
• The Blackberry is pretty unfriendly to Free Software stuff, which is a shame, partly because of the whole lack of freedom issue, but almost more because everything else I do with technology uses free software stuff, that it’s annoying that my existing stuff doesn’t work right on the phone.

Would I get another Blackberry? Probably. Though the lack of a good SSH client is a bother, and I’d like something that did a bit better with things like PDF/electronic-text reading, but all in all I’m pretty happy.

The interesting thing is that at this point I can’t fathom going back to some sort of “non-smartphone:” this just seems, to me, to be “the way a phone should work.” That’s a pretty strong endorsement, I’d say.

Onward and Upward!

I have an absurd number of tabs open, and I’d like to present some interesting reading that I’ve had on my plate for a while. Nothing incredibly current, but all of it’s good stuff. For your consideration:

• Interlaced Knitting Chart from Kim Salazar who is a master knitter/crafter. I’ve enjoyed her blog for years, and I keep coming back to this pattern and I’m interested in figuring out how to integrate it best into the project I’m thinking of working on next/soon.
• This Thread about Package Management in Emacs, which is an incredibly essoteric subject, but I think it’s a useful conversation, and I think something that will--if its implemented--make emacs even more awesome, and make it easy to spin off specialized instances of “emacs distributions,” which I think will help emacs be more helpful to more people. I’d like multi-threaded support though.
• I’ve had this article about Open Source Business Models open in my browser for weeks, and my mind boggles at it. I tend to think that Free Software and Open Source have pretty much the same business models as all software businesses. There are companies that make money on licencing free software (i.e. Red Hat, Novell), there are a bunch of companies that provide services and custom development around open source software (too numerous to cite,) and there are scads of companies that have businesses offering services that are enabled by open source software (i.e. every Internet company, but Amazon is a great example of this.) So I’m not really sure how to respond to this. But it’s there, and now I’m closing that tab.
• Open Source: The War is Over or so one blogger thinks. I actually think there’s some truth to the idea that proprietary software is mostly a failed project, and most people realize that--moving forward--open source methods and practices are ideal for technology. But I think “winning the argument and beginning to move toward open source,” and “the war being over,” are two different things. Furthermore, I’m not sure I’m comfortable equating “enterprise adoption of open source,” as the singular marker of success for Open Source (let alone Free Software).
• Michael Berube on Cultural Studies in the Chronicle
• I guess it’s hard to really take me out of the academy. I’m a huge geek for this kind of stuff still. I guess my thoughts are:
  1. Michael Berube might be a great blogger, and I think the thigns he’s thinking about in this peice are quire useful and worthwhile, but as a piece of writing, this article is too short to really get into a lot of depth about anything, and too long to be easily read
  2. American Academic Marxism is a mostly failed project, and I think the “inter-discipline” of Cultural studies has been a poor steward of said.
  3. While Cultural Studies is a liberating interdisciplinary proposition, it’s pretty unbalanced (English+Sociology) and I think a bit more economics and anthropology would be helpful. Berube is on the right side of this argument but I think he’s too kind to CS on this point.
• Gina Trapani’s Smarterware got a new look and it’s both amazing and I think points out the importance of leaving design to the professionals. Good stuff.
• Against Micropayments and the Media Industry Interesting post, that gets it right. The future of media and publishing of all forms is something that I think about more than a little bit. If people are ever going to pay for content again, it’s going to have to be tied into the way that people pay for connectivity, which is also a non-scarce resource, but one that we’ve grown used to paying for. There’s some unpacking and investigating to be done here, for sure.