Much to my surprise, my essay of a few months ago on Why Arch Linux Rocks is quickly becoming one of my most popular posts. Who would have thunk? In any case, while I’ve written a few additional bits here and there about using Arch, I thought it would be good to write some more concrete and practical reflections on what I’ve learned from Arch and hopefully someone out there will find this useful.

The thing about arch, is that it’s by nature a very minimal operating system, and it doesn’t shy away from the command line. There’s this peculiar logic amongst GNU/Linux Distribution Developers that says: we want people to use our operating system and to use Free Software, and since most people are scared off by command line interfaces and editing config files, lets try and obscure the command lines and the config files as much as possible. That’s a good idea.

Right. Not really.

And for some distributions, this really works. Arch says, rather, that while command line interfaces and config files can be confusing they’re not “bad,” and it’s possible to teach people how to interact with the command line and edit their config files. Furthermore, while command lines and config files might be different and unfamiliar to users who are used to checkboxes and menus, they are extraordinarily simple.

Back to the minimal part.

When you install Arch, you get a prompt, the basic GNU tool chain (install base-devel during the install process, it’s worth it,) the Kernel (of course), the GRUB boot loader, and that’s about it. Everything else you have to install yourself. While you might thing “this is a huge bother” the first time you install Arch, the when you get to the end of the process you have a system that does exactly what you want it to and nothing more. Having a computer system so tailored to your needs and workflows is actually, sort of a unique and wonderful experience. Rarely, I think, in this day and age do we get work with a computer in this way.

Nevertheless, having a system that is this minimalist means that setup can be a bit… intense. Once things are installed the right way it works great, but I found that the first few times I ran an Arch install, it was like I spent the next two weeks installing little things over and over because I couldn’t keep track of what I needed. And then I installed a second system, and it was the same thing over again. The third time I did it, I’d wised up and managed to have a better time with it. A few weeks ago I created and redeployed a virtual machine (in virtual box) that I use as my primary work computer (long story), and it was painless.

What remains of this post are a collection of lessons that I’ve learned and some suggestions I have for having the best arch experience possible.

1. Save your /home directory and copy it to the new machine. I used the following command over the local network from the home server: :

   rsync -azrv /home/tychoish tychoish@192.168.256.1:/home
   

   Changing the paths, usernames, and IP address to their relevant and valid values. This way all your configuration files and data end up on the new machine, with permissions preserved. This typically takes the longest time of any setup operation.

2. Run system updates as soon as possible. Arch is a rolling release distribution. The longest you’ll typically go between updates is the time between when the installation media was created and when you install your machine. The longer the divide between current status and when you run an update the greater the chance of breakage happening.

3. Use ABS, the “Arch Build System,” to compile any software that isn’t in the main arch repositories. Save the PKGBUILD scripts (if not the packages you’ve made with them,) in your `~/abs/`` directory. This makes installing all of the weird and tedious software much easier.

4. Avoid getting a machine with weird or uncommon wireless or video drivers. At this point, I’m choosy enough about my hardware that I won’t get a computer (much less install Linux on it,) if it’s not “Intel everything:” wireless card, video card, chipset, etc. Sure a fancy NVidia card might be more sexy, and there are a lot of good reasons to use AMD and ATI silicone. But, one can be very sure that Intel hardware is going to work with Linux; and with other gear, it’s much more hit and miss. Or it can be. And my time and serenity is not without value.

5. Maintain a list of what packages you want to install on your system:

   • X11 Dependencies

     Lets not talk about how long it’s taken for me to remember to install the X11 keyboard and mouse drivers:

     xf86-input-keyboard xf86-input-mouse
     

   • Additional package management tools

     The abs tool provides a BSD-ports like interface for building packages, while the ‘yaourttool makes it easy to make and build packages from the [Arch User Repository][aur] (AUR.) Typically I use [yaourt][] to download a package and then build it in theabsdirectory. Make sure you've installedbase-devel` as well, because you’ll want to eventually.

• Music Applications

  I use the music player daemon and a number of additional applications to play music. And I install these packages as a matter of course.

  mpd mpc gmpc alsa-utils jack-audio-connection-kit
  

• The tychoish Tool Chain

  Your specific list of “tools that you must have in order to function properly,” probably varies a bit. Here’s mine (some packages are from AUR):

  git emacs emacs-org-mode emacs-w3m-cvs rxvt-unicode
  screen wcalc sudo htop urxvtcd zsh swiftfox-i686
  

  To explain quickly those packages which aren’t obvious from their title: wcalc is a command line calculator tool; swiftfox-i686 is an optimized build of Firefox, except it runs more smoothly in my experience and is compatible with the FF plugins that I depend upon. urxvtcd is a shell wrapper for urxvt that opens a client of the urxvt-daemon (urxvtc) if there’s a daemon already running, and starts a daemon and opens a window if there isn’t. htop is a system process monitor.

• Email Tool Chain

  I use the following packages to manage my email:

  procmail msmtp fetchmail gnugpg
  

  From AUR I also use:

  lbdb mutt-sidebar
  

  lbdb is an address book database tool, and I use my build to get the best mail-reading client in the world.

• Window Management

  Arch is great for having pretty good support and inclusion of up-to-date packages for esoteric window managers. The sequence for installing StumpWM is a bit non intuitive. First, install the following packages from the normal repositories:

  sbcl nitrogen gtk-chtheme
  

  The last two are tools for changing the look and feel the desktop and GTK applications (respectively). Now from AUR, install (in the following sequence):

  clx cl-ppre stumpwm-git
  

  Put the following code in your ~/.sbcl file:

  (require 'asdf)
  (pushnew #p"/usr/share/common-lisp/systems/" asdf:*central-registry* :test #'equal)
  (asdf:operate 'asdf:load-op 'cl-ppcre)
  (push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
  (asdf:operate 'asdf:load-op 'cl-ppcre)
  

  And you should be good. Configure your .xinitrc to your liking, and make sure your have a .stumpwmrc.

• Networking Tools

  To manage my own connections and connect to the OpenVPN I use netcfg and OpenVPN. This requires the following packages:

  netcfg netcfg-auto zsh-netcfg netcfg-openvpn openvpn
  

  There are also a suite of network diagnostic tools that I always install, but seem to forget for various parts of a week.

  mtr whois dnsutils
  

  Also, I’m always befuddled by this for a few moments, but ssh isn’t installed by default. I, as a result install the following tools:

  openssh sshfs
  

  And add the following line to /etc/hosts.allow to permit inbound SSH connections.

  sshd: ALL
  

• Spelling Correction

  This always frustrates me, though I understand the logic. Install the following three packages to get spelling support thought the system:

  aspell ispell aspell-en
  

  If you need spelling correction for a non-English language, replace aspel-en with that language, or add that language to the end of this list.

I have a collection of links that I’d like to share with you. I hope you enjoy and find them as enlightening as I have. Some of these are dated but, I’ve been milling through them for a while and I feel like they’re worth sharing. In three parts:

Computer Programming and Hacking

• Art of Computer Programing
• Software Artisans
• Unit testing and Agile

There’s a long tradition of computer scientists and eminent developers thinking about their software development as an Art. Donald Knuth’s major work is called “The Art of Computer Programming,” and literate programing is fundamentally an artistic rather than a technical idea. The idea of the “lazy programmer” from the Perl world has some obvious artistic implications (hell, Perl’s license is called the “Artistic License”), and the Extreme Programing (XP)/Agile Programming world is very much about addressing programming as creative challenge rather than a purely technical challenge.

I particularly like the contrast of the first two articles with the third. While I’m not sure it’s particularly conclusive in the brief overview and with such a small sample, the insights about the ways that programmers approach problems is pretty useful. Makes me want to get the book.

• On Functional Programing
• How John Wiegley uses git

I may not be a programmer in the conventional sense (or even any of the unconventional senses that I’m aware of) but there are two things that I know for sure. First: functional programming makes sense to me in a way that nothing else ever really has, and secondly that I am fascinated by the different ways that people use and manage projects with Git.

I think functional program makes sense to me because little blocks that “do something” matches the way my brain is shaped in some useful way. Every introduction to object oriented programming I’ve ever experienced starts with like 50 pages (or equivalent) of crud about data structures and types . Which I’m sure make sense if you know what’s coming next, but if you’re a programing n00b: less than helpful.

Also, regarding the use of git: it’s fascinating how many different ways and different work-flows people manage to squeeze out of software like this! What he’s doing makes sense, a lot of sense on paper, but most people don’t publish long-running branches in such an organized manner. Sure there are “vendor branches” for release maintenance, but branches in git tend to be much more ad hoc from what I’ve seen. Anyway, good one for the file.

• The Trouble With Frameworks

I’ve been looking over weppy for the past few weeks, along with the bindings for a couple of weird databases (of the NoSQL variety, loosely), as part of a brief attempt to learn how to think like a web-developer. (It’s hard more on this later.) I find myself both incredibly enchanted with the prospect of some of these frameworks (particularly the python ones), and yet at the same time very unsure of what they represent in terms of the Internet. Frameworks aren’t going anywhere, and I think by some measure they are “getting better,” I do think they make it awfully easy to avoid putting in the time to “get it right,” which might not matter most of the time, but when it does oh boy, does it.

Academia, Anthropology, Literature

• The Past Future Literary Magazines
• The Future of Books

I wrote a series of articles on the future of publishing and I found myself returning again and again to these two essays as a source of inspiration, and I haven’t quite gotten them out of my head.

I’m not sure if I agree with this consensus, but it seems pretty clear that multi-media websites, twitter, and “blogs” (by some definition of the term) are acceptable replacements for journalistic publishing (newspapers, magazines). These essays, engage literary publishing, and force (particularly the second) us to think about the economics of booksellers, including branding, brick and mortar shops, which I think is incredibly important.

• Aaron Swartz on Disciplinary Bubbles
• Cyborg Anthropology and the Singularity

In the piece on Cyborg Anthropology, Amber Case discusses looks at the Singularity from a much less technical perspective. In a lot of ways this reminds me of my post on the Dark Singularity from a few months back. The singularity is, of course ultimately a cyborg problem.

Aaron Swartz’s piece on the academy… I don’t know that he’s wrong, exactly, but I think I would avoid being as unilateral as he is. On the one had disciplines exist mostly to organize education not research, and if I were going to make a conjecture: we see more disciplanarity and sub-disciplining in fields with substantive funding outside of the academy. Doctors, lawyers, psychologists, biologists, chemists, have teeny-tiny little sub-fields; and by contrast you see a lot more interdisciplinary activity in the academic study of anthropology, literature, mathematics, and, say musicology. Interesting, nonetheless.

The Industry of Technology

Two posts here from James Governor of RedMonk that have guided (at least topically) my thinking in a couple of areas recently. This is particularly noticeable if you look over the recent archives. The first addresses Flash and the business of advancing the platform of the web. My trepidation with regards to flash is mostly the same as my trepidation with regards to all web technology. When you get down to it, my grumbling all goes back to the fact that the web is developing into this thing that is all about media rich software, and less about hypertext, which is where my heart has always been. My argument keeps going back to “take the applications off of the web as we know it, and use a platform that (like GTK+ or QT) that’s designed for applications, and create a hypertext experience that really works.” But it’s nice to have articles like this one to pull my head out of (or into?) the clouds to remind me (and us?) what’s really going on in the industry.

This is an old one from the same source, about the new “patronage economy” which in many ways defines what’s going on at RedMonk. I particularly enjoy how Governor contrasts the New Patronage with other popular web 2.0-era business models. I do worry, looking at this in retrospect about the ways in which such patronages are stable even when the economy is in the crapper (as it were.) I’m not sure if there’s an answer to that one yet, but we’ll see. I guess my questions, at this juncture are: first, does patronage-type-relationships give “start ups” another funding option which is more stable than venture capital. Second, doesn’t the kind of organization and work that’s funded by these patronages subvert the kind of work that they depend upon (i.e. big high-margin businesses?)

That’s all I have at the moment. If you have links or thoughts to share, I’d live to see them!

Email is broken. I don’t think the assertion really even requires an example for everyone to concur. Spam, ongoing wars over decades old standards and protocols, bacon (automatically generated email that you want), listservs, poorly written clients, and mixed expectations regarding replays, make email frustrating to deal with under the best of situations.

Email is also inescapable. There’s no other technology around at the moment which pushes messages out to users as effectively (every other thing is pull), provides administrators with as many tools and options, or has such ubiquitous adoption rates. I’d love to be able to say “don’t send me emails, I won’t get it,” but the truth is that I get and send a bunch of email, and every other option for “next wave” digital communication fails to impress.

Including Google Wave.

Don’t get me wrong, Wave is nifty. Hampered mostly by an interface which is foolish and gimmicky, I think Wave provides capabilities that we need on the Internet. Wave makes multi-user chat useful for people who have trouble wrapping their brain around IRC. Wave strikes the right balance between “real-time” and persistence (which is mighty difficult), and most importantly…

Wave gets people thinking about email, and what the ideal replacement might look like. And that’s a good thing indeed.

Maybe, more importantly, Wave moves many of the trivial uses of email, into a more suitable format (XMPP) so that email, or whatever replaces it, has a more easily defined task. Maybe there are a couple of XMPP applications: Jabber, Wave, and (----)¹ that work in concert to alleviate the pressure on email and make it much more clear what “the email killer” will look like.

To my mind, one of the biggest problems with email is that we use it for too much, including a number of things that it’s not ideally suited for. Perhaps the way to fix email is to fix all of these other communication problem, and see what’s left.

Here’s a list of the things what I think we use email for today, to which it is unsuited, followed by a couple of examples?

• Notifications. There’s been a reply to a comment on your blog, someone has commented on your face-book status update, it’s time to renew your domain name, your payment has been processed. Etc.
• File Transfer. Look at my resume. Here’s the paper I owe you. I was looking for your article and wondered if you might have a copy you could share? Here’s this funny picture my uncle sent me. Etc.
• Content Review. Could you take a look at this essay or bug report? I mentioned this in an IM but didn’t want to send it in that format.

This leaves us with a relatively short list of things: genuine letters (i.e. first class mail; generally “asynchronous personal communication”) and listservs (which like Usenet are probably the best way to have async-group communication online from the users perspective). And spam, but we don’t care about that.

So what’s the best way to handle what’s left? Hell, what’s the best way to handle the rest of it?

I don’t think there are good answers yet, at all, and I look forward to continuing to thing about these issues in a big way.

In my last post on this topic I tried to avoid talking too much about the actual details of an implementation of what my ideal notification system would look like. In part because I think that the problem of staying on top of our digital (cyborg?) in a “real time” manner is something that transcends the specific method of implementation. I and many other awesome people have been thinking about this “real time” problem for a couple of years, and mostly we’ve thinking about things like microblogging (think twitter and identi.ca) and XMPP and related topics. These are all important issues that we need to get worked out, but there are issues regarding the use of “real time data” that I think need to be addressed from a more indivudal/user perspective. This notification issue is one of them.

My requirements, in summary:

1. There should be some common method of creating and distributing notifications that’s easy to setup up and tie into scripts (i.e. with some sort of command line interface.) and that is independent on application. I don’t want notifications from my email to appear in a different place from notifications from IRC, for instance.
2. Taking the above one step further, notifications should be machine independent. If an event that I’d like to be notified of happens on my server (in the cloud, as it were) or the desktop at home, I’d like to know about it on my laptop when I’m on the road. Preferably, I’d like the system to know if I’ve seen a notification on my work computer before alerting me to it at home, but I’m willing to slide on this one.
3. I need the ability to filter and control what notifications I see. There are times when I really want to track a particular word or phrase on twitter, and there are times when the last thing I want to know is weather or not someone has said something or other on twitter. Fine grained controls are key. I’d really like to put some sort of filtering pipe intweent “messages received” and “notifications sent,” so I can use it the way I use procmail for email.

Thoughts on Implementation:

• XMPP seems like an obvious tool for implementing the backbone of this. From my perspective of a slightly-more-than-casual observer, getting one machine to know if a notification has been seen by machines is a bit thorny at best.
• Notifications need to tie into the window manager and desktop experiences. in some sort of unobtrusive way, but also in a way that is consistent with that window manager normally works.
• While many notifications will probably be created by sending a simple string to a command, some notifications will probably be generated from RSS or JSON feeds, and the best systems would provide some baked in support for pulling events from these kinds of data.
• You can get irssi to send xmpp notifications, which is both incredibly ironic, and kind of awesome, as a building block. Also, this emacs-fu for using lib-notify from emacs might be another good starting point.
• Dumping a firehose of notifications in an XMPP window, might be a good start, but I think once a notification has been sent (and logged and dismissed?), notifications need to disappear forever. Also--and this is the point of the filtering--raw events take processing in order to be useful. The firehose, of anything when exposed to the user, isn’t particularly useful.
• [insert your thoughts here]

I will, of course let you know how this goes.

The latest in a fine tradition of tychoish posts…

Five People I Enjoy on Twitter

• soliloqueer
• abstractnixon
• rickerje
• qunnorton
• tommorris
• and a bonus (DeleuzeGuatteri)

Five Improvements to Web Browsers

• Enforce document structure standards on the server. Documents must be structured and organized within the constraints of a couple of conventions or else the server throws a 500 error.
• Locate all design and presentation on the client side, and allow designs to be fully independent of the design.
• Scripting happens on the client side, in sandboxes, and are integral parts of the browser applications.
• Therefore, scripts shouldn’t be provided with the browser or by the viewer, not by the content creator. In other words, die JavaScript, die, and replace it with lightweight greasemonkeyesque+webkit-style browsers. Except might as well use python/perl/ruby/etc. while you’re at it.
• Applications, can and should interact with servers and infrastructure and data over the network, but “the web” shouldn’t convert interactive applications. The goal here is to make the web-as-information-distribution work.

Five Things I’m quasi likely to Acquire in the Next Few Months

• An Amazon Kindle
• Some sort of roasting pan
• A New Laptop Bag
• A table and chairs (one of which might be good for spinning)
• A gym membership

Five Things That are Awesome about Dance Weekends

• You can dance with someone more than once, without it being creepy or weird. At an evening of a dance, it’s only really realistic to dance with someone once because there are 15 or 20 dances max. At an all day dance, we’re talking 60 or 70 dances.
• Innocent and awesome dance crushes.
• The “gender” thing is more flexible at big dance weekends. Which is fun. It’s probably true that part of the fun is in part due to the fact that queering up the gender roles in a contra dance makes contra a little harder, but I also just enjoy it for it’s awesome factor. M.N. also noted that when you come across older men dancing together in the contra lupine, you know it’s all gravy. And that’s more likely to happen at a dance weekend.
• Awesome bands. In short: Giant Robot Dance.
• Squares that don’t suck.

Five Changes in Habits that I Would Have Never Expected to See In Myself

• Sacred Harp/Shape Note Singing
• A Decrease in knitting output and interest
• Weekend plans and events three to four weekends out of five.
• The degree with which I’m a neat freak about my apartment. (Not absurd, but I still have moments where I surprise myself.)
• Contra dancing as my main form of dance, as opposed to Morris and/or International folk.

Wiki started as this weird idea that seemed to work against all odds. And then it seemed to really work. And now wiki is just a way to make and host a website without taking full responsibility for the generation of all the content. To say wiki is to say “collaboration” and “distributed authorship,” in some vague handwaving way.

But clearly, getting a wiki “right,” is more difficult than just throwing up a wiki engine and saying “have at it people.” Wiki’s need a lot of stewardship, and care, that I think people don’t realize off the bat. Even wikis that seem to be organic and loosey-goosey.

I have this wiki project, at the Cyborg Institute Wiki that I’ve put some time into, but not, you know a huge amount of time particularly recently. Edits have been good, when they’ve happened. But all additions have come from people who I have asked specifically for their contributions. I don’t think this is a bad thing but this experience does run counter to the “throw up a wiki and people will edit it” mindset.

I’ve started (or restarted?) [a wiki that I set up for the OuterAlliance][oa-wik]. You can find out more about the OA there (as it gets added) or on the OuterAlliance Blog. Basically, O.A. is a group of Science Fiction writers, editors, and critics (and agents? do we have agents?) who are interested in promoting the presentation and visibility of positive queer characters and themes in science fiction (literature).¹

In any case, the group needed a wiki, and unlike the C2 Wiki, the people who are likely to contribute to this wiki are probably not hackers in the conventional sense. As I’ve sort of taken this wiki project upon myself, I’ve been trying to think of ways to ensure success in wikis.

Ideas, thoroughly untested:

Invite people to contribute at every opportunity, but not simply by saying “please add your thoughts here.” Rather, write in a way that leaves spaces for other people to interject ideas and thoughts.

Create stubs and pages where people can interject their own thoughts, but “red links” (or preceding question marks in my preferred wiki engine) are just as effective as stubs in many cases. The thing is that wikis require a lot of hands on attention. While stubs don’t require a lot of attention and maintenance, they require some. My favored approach recently is to make new pages when the content in the current page grows too unwieldy and to resist the urge to make new pages except when that happens.

Reduce hierarchy in page organization unless totally needed. You don’t want potential collaborators to have to thing very much about “where should I put this thing.” The more hierarchy there is the greater the chance that they’ll have to either think about it and/or that they’ll not find a place to put their contribution and then not contribute. This is undesirable.

Hierarchy is problematic for most organizational systems, but in most wiki systems, it is really easy and attractive to divide things into lots of layers of hierarchy because it makes sense at the time. The truth is, however, that this almost never makes sense a couple of weeks or months down the road. Some hierarchy makes sense, but it’ll take you hundreds of thousands of words to really need 3 layers of hierarchy in most wikis.

Leaders and instigators of wiki projects also, should know that creating and having a successful wiki represents the output of a huge amount of effort. There’s a lot of figuring out what people mean to say and making sure that their words actually convey that. There’s a lot of making sure people’s comments really do belong on the page where they put them. And more often than not leaders put in the effort to write a huge amount of “seed” content as an example to contributors in the future. It’s not a bad gig, but it’s also not the kind of hting you can just sit back and let happen.

Other thoughts? Onward and Upward!

Maybe it’s just be but I think notifications of events on our computers suck. On OS X there’s Growl, and GNU/Linux desktops have the libnotify stuff, and I’m sure there’s something on windows, but I don’t think this really addresses the problem at hand. Not that the software doesn’t work, becuase it mostly does what it says it’s going to do. The issue, I think is that we need, or will very shortly need, much more from a notification system than anything around can handle.

Lets back up.

I don’t know about you but there are a lot of events and messages that I get or need to get, including: new mail, some instant messages, mentions of cerain words on IRC (perhaps only in certain channels), notifications of when a collaborator has pushed something to a git repository, updates to certain RSS feeds, notifications of the completion of certain long-running commands (file copies, data transferes, etc.) and so forth. I think everyone likely has their own list of “things it would be nice if their computer could tell them about.”

The existing notification systems provide a framework that enables locally running applications to present little messages in a consistent, and unified manner. This is great. The issue is that for most of us the things that we need to be notified of aren’t locally running. At least in my case, instant messaging, IRC, git, and the key RSS feeds that I want to follow aren’t “locally running applications.” And to further complicate matters, no matter how your slice things, I use more than one computer, and in an ideal world it would be nice for one machine to know what notifications I’d seen on another computer when I sat down. In other words, my personal notification system should retain memory of what it’s shown me and what I’ve awknowladged across a number of machines.

That doesn’t happen. At least not today.

I have a few ideas about the implementation that I will probably cobble together into another post, and I’d love to hear some feedback if any of you have addressed this problem and have solutions.

It strikes me that there are two larger themes at work here:

1. Personal computing events occur locally and remotely, and notification systems need to be able to seemlessly provide these kinds of notifications. While I think a lot of the hype around clound computing is--frankly--absurd, it is fair to say that our computing is incredibly networked.

2. People don’t have “a computer,” any more, but rather several: phones, desktops, “cloud services,” virtual private servers, and so forth. While we use these systems differently, and our own personal “setup” are often unique, we need to move between these setups with ease.

These two shifts, networked computing and multiple computing contexts, affect more than just the the manner in which we receive notifications. But really, I think, outline the ways that the way we use computing has changed in the past few years. There’s a lot of buzzwords around this shift, in the web appliacation and cloud computing space particularly, and I don’t think that the “hipster”/“buzzword” experience is widely generalizable. It’s my hope that these conclusions are more widely applicable and useful: both for the development of a notification system that we need, and for thinking about application development in the future.

Like I said above, I’d love to hear your thoughts on this subect, and perhaps we can work on collecting thoughts on the Cyborg Institute Wiki. Take care!

I didn’t write a novel last month.

I’ve always been a bit of a contrarian about NaNoWriMo, the project where writers and people who don’t think of themselves as writers attempt a novel writing sprint during the month of November. Well, it’s a 50,000 word “novel,” which is in the end a bit short for a novel and a bit too long for a novella, but we’ll call it a novel for the sake of simplicity.

My basic gripe is that NaNoWriMo is a fun gimmick for people who aren’t used to turning out huge volumes of writing every day anyway, it doesn’t do a lot to really ensure or guarantee success. At it’s heart NaNo has a very democratizing idea: anyone can write a novel, I fear that it does more to impede success than encourage it.

My reasoning:

• November is the worst month, with the holidays and the time change, potentially. November also tends to be bad for people who are in school or who teach school, as the semester draws to an end. December might be even worse in these respects. Here are some arguments for other months: February or March, (in the northern hemisphere) are cold months where you just want to stay at home, and what better time to write a novel? May is upbeat and fresh. June has no major holidays and rides a wave of Summer euphoria. Defenders of NaNo say “There’s no good month, so we might as well use November.” I reject this logic. Picking a bad month of the year can do a lot for the success rate of the people who attempt the project, I figure.
• The novel is too short. While it would probably also decrease success rate to make the NaNo Novel a publishable length (60-80k or so), I think having people end up with a piece that’s sort of unusable in the “real world” can be discouraging as well. If they get something they like from NaNo, and they want to publish it, they have to write at least another ten thousand words and possibly as much as 50 thousand words. Digital distribution helps these things a bit, but the size is an issue.
• What “real writers” do, is write every single day. The trick to being able to be a writer isn’t the ability to turn out a quantity of prose on demand. It’s the ability to sustainably work on projects all year round. To turn off the internal editor long enough that you get something on the paper, and then turn it back on so that “something” doesn’t suck. They’re able to take experiences and turn them into texts.
• I’m not sure that the fetishization of the novel form is particularly productive. I think there’s a lot of power and future in shorter forms. For learning how to be a writer, writing shorter works is probably a more effective way to learn to tell stories and create characters anyway.

Having said that, congrats to the people who did NaNo. Keep writing. You’ve probably found a few extra hours in your day that you didn’t know you had. Keep writing and doing awesome things with that time. And if you’re a huge fan of NaNo, don’t worry too much about me, I’m just an ornery guy with too many opinions.

It’s true: I’ve been working on a Novel for more than a year, and while I’m closing in on the end of the draft. Its now done yet. Soon, perhaps. Also, I think I should probably do some blogging here about learning to write, and teaching writing given that I got here by way of a strange path and feel so strongly about these things.

There’s an issue in tiling window managers, that I think a lot folks who are used to floating window managers never expect. I wrote a post to the Awesome listserv a while back explaining this to someone, and it seems to have struck a chord (I saw the post linked to last week). I thought I’d write a brief post here to explain what’s going on in a more clear and general way.

The Problem

When tiled, windows don’t seem to take up all the space that’s available to them. This creates weird “gaps” between windows. But only some windows: Firefox is immune to this problem, while terminal emulators like xterm, and urxvt, and gVim, and emacs get all funky.

What’s Happening

The application that are affected by this draw their windows based upon a number of fixed width columns. We’ll note that terminal emulators, as well as GUI versions of programmer’s text editors like vim and emacs, all used fixed-width fonts and often allow you to set window sizes based on the number of columns (of characters).

As a result, these applications are only able to use space on the screen in increments of full characters. Most of the time, in floating window managers, we never really notice this limitation.

In tiling window managers you do notice, because the window manager forces the windows to use all available space, except in some windows it leaves these weird gaps at the bottom and right of the window. Sometimes the gaps end up in the window, as unusable buffers, and sometimes they end up between windows. It looks funny, pretty much no matter how you slice it.

What You Can Do About It

The truth? Not much.

The Awesome Window Manager, by default shows the gaps between the windows. I always found this to be the “more ugly” option. You can alter this behavior by searching your configuration file for size_hints_honor and making the line look like this:

c.size_hints_honor = false

This tells Awesome to ignore windows (client’s) when they say “I want to have these dimensions.” It doesn’t fix the problem but it does get rid of the gaps.

The real solution is to tweak text sizes, fonts, and any buffering elements (like a status bar, mode line, or widget box), and window borders so that the windows aren’t left with extra space that they don’t know how to cope with.

By real solution, I really mean “only option:” it’s really impossible to get all of your fixed width applications to have exactly the right number of pixels. You can get close in a lot of situations, and I’ve always found this to be much less annoying than using floating window managers.

The Original Post

Just for giggles, I’ve included a quoted portion of what I posted original to the listserv on the topic.

The one big of information that might be important: The urxvt terminal emulator, when not “honoring size hints,” is unable to really properly draw the “extra space” with the proper background. I suspect this is a bug with the pseudo-transparency system they use. As a result there are often a few pixels with the background in an inverted color scheme. Same problem as above, but it looks funny if you’re not used to it.

What’s happening is that urxvt (like many terminal emulators) can only draw windows of some specific sizes based on the size of the characters (eg. x number of rows, and y number of columns.) So while you may have larger and the equivalent of say 80.4x20.1, urxvt can’t do anything with this extra space.

If you honor size hints, the windows will end wherever they can, and use as much space as they can, but leave gaps between windows if the total space isn’t properly divisible. If you don’t honor size hints, the windows themselves take up the extra room (but they can’t do anything with the extra room, so they just leave it blank, and sometimes the transparency is a bit wonky in those “buffers”).

So there you have it. I hope this helps!

A while back, lets say, in August or so¹, I redid the design of this site and added a new subtitle: “Dialectical Futurism.” The dweeby, philosophy geek in me really enjoys this, just as an idea. As it’s sat at the top of the page, I’ve also thought more and more that the subtitle is actually a pretty good summary of what I’m trying to accomplish here. This post is an attempt to do two things:

1. Concisely summarize my “blogging project” and thus explain what dialectical futurism means.

2. To do a bit of a status update on the blog, as a sort of “self report,” of what I think seems to be working and what doesn’t.

Part One: What “Dialectical Futurism” Meas In Practice.

It’s always risky, I think for a self-claimed “Science Fiction” writer, to declare themselves a “Futurist” of any sort. Because of the genre’s link to the future, I think there the danger that people might think that we’re putting forth our stories as works of prediction.

While I think my interest in futurism comes from a similar place as the interests that drive my fiction, the practice of futurism (in the form of this blog) and the practice of fiction are very different. Ultimately, both are historical endeavors and futurism is tends to be much more tightly focused on the recent history. At least for me.

Dialectical futurism, is about a conversation between me, and the past, and me and the possible future, it’s an attempt to synthesize a pragmatic view of what will happen, with an optimistic view of what I would like to happen. It’s about putting all of the topics I blog about like Open Source, Free Software, Cooperative structure, Economics, and the “New Media” in conversation with each other and seeing what kind of cool innovative things happen.

Part Two: The Status of the Project

The project of being a writer is one of constant self improvement, I think. One thing that I didn’t mention in that post is that no matter how awesome you are as a writer, you’re always trying to get better at writing. There’s always some improvement to make, some short-falling in your ability to communicate that you’re working at improving.

I have the sense that I am getting better, if that’s a meaningful judgment. One improves as a writer, I’m convinced, by writing, and writing a lot, and as I write a bunch for this site and a bunch for work, and a bunch for other projects, I think I’m starting to get better. Also, I get a lot of feedback from coworkers on my writing, which I think has been helpful. Editors are a good thing indeed.

I think I’ve gotten better at figuring out how to write good blog entries--it still takes time, but I get into the grove more quickly. I’m getting better feedback, and I’m reasonably happy with where the traffic is. I mean, there’s always room for improvement, but things are headed in the right direction.

My short term goals are two fold:

1. To focus my energies on reading and improving my background knowledge in a number of areas. I want to be more contextually grounded in existing conversations regarding economics, anthropology, and cyborg-related materials.
2. To spend a lot more time on fiction writing. This means developing new habits, adjusting priorities, and spending some serious time making fiction projects work. So there.

We’ll see how this goes, and thanks as always for reading and putting up with me.