Topic: Open source

So I’ve upgraded to the latest version of Ubuntu, 9.04 “Jaunty Jackalope,” and I thought I’d post some thoughts on the matter.

On my desktop the upgrade (eg. sudo apt-get dist-upgrade) was a bit touch and go, but I managed to save things (logging in running the old kernel into a root shell to fix the upgrade which mysteriously held back some packages it shouldn’t have) and here I am. The laptop was easier to upgrade, and I suspect this has something to do with the blob video card drivers I’m using on the desktop.

On the whole, I can’t say I’ve toyed with the updates to gnome terribly much so I don’t know what to say, but I suspect that they are in fact newer, better, and worthwhile if you’re using intrepid and or interested in trying out ubuntu. It’s really a great OS, and it does a great job--in my experience--of just working with minimal fussing.

I’m not sure that I’d choose an Ubuntu distribution again knowing what I know today. At the same time, I don’t know that I’d know as much as I do about Linuxes today without it, and given that this still works, I’m not switching.

My jaunty upgrade, however, inspired a few changes to my setup, and I’m quite happy with those improvements. They are:

• I switched to using rxvt-unicode as a terminal emulator (I had been using gnome-terminal). I really like this, because the terminal is low resource (and can run demonized, so you can have a lot of windows open). It’s hard as hell to setup (in my experience,) but you can learn from my .Xdefaults file if you’re interested.
• I started (finally) using gnome-color-chooser and gtk-chtheme (debian package names) to remove gnome-settings-daemon from my list of background programs, while still having windows that don’t look like 1992.
• I stopped using vimperator in firefox, opting instead for firemacs (to control keybindings) and LoL for keyboard navigation (hit-a-hint links). Having access to the Awesome bar is a good thing indeed.

Still on the list of things to update?

• I need to upgrade to the latest awesome version, as I’m behind.
• I need to actually ditch gdm, which irritates me still.

Hey folks,

Having spent a few hours (heh) going through my blog and converting and modifying it for jekyll, I think it would be appropriate to list some general directions for improvement of the software. Jekyll is pretty good and it’s certainly more than usable, but I think there is enough room for improvement, and some additional features that would be rather interesting to explore. Because I think it’s really easy for us to all develop our own forks and work in relative isolation, I worry that there’s limited space to have a conversation about how to best improve the platform. Here’s a starting point:

• Performance Jekyll, particularly for larger sites can take a considerable time to run.

  I’m not familiar enough with ruby to be able to speak to any areas of improvement in terms of code optimization, though I’m not sure that this is the best way to approach this issue. Rather, I think it would probably be best to figure out ways of gracefully preventing jekyll from recompiling pages that haven’t changed every time there’s an update. The possibility that makes the most sense to me at this point would be to include “masks” in the config file, that jekyll can skip over unless run with an --all option.

  Another option might be to develop a way to cache/store certain kinds of output files that require a lot of data to crunch (I’m thinking mostly of things like archives and of other long post loops.) Maybe developing some sort of internal index?

• I’m (preliminarily) looking at using rpeg-markdown as a another markdown option, which should both allow the extended markdown syntax to work (woot!) and run much faster than maruku (and hopefully rdiscount). It seems difficult to install, but would generally be worthwhile.

• Increase usability While jekyll just works, and the documentation is reasonably effective given the audience; there isn’t any automatic workflow for jekyll use. Having a few shell scripts and/or a “using jekyll” tutorial that explains day to day use would be quite helpful once you get started.

  As I finalize and put it through it’s paces for a few days I’ll get more clear about this, but, in general I’m thinking of things like: using git hooks to generate the content automatically on commit/etc.

  It would be valuable to write up how to use rsync as that would likely make more sense in some situations. Same with running tasks in cron.

• Template Directory: Most of the jekyll powered blogs that I’ve seen have been pretty good about publishing the repositories for their sites. This is a good thing indeed, but given how the templates work, I think it would be good to collect various templates together for ease of access and educational proposes.

• Make Categories More Flexible: While the current blog categories support is great for adding “multiple blog” support, it makes it difficult to interact/loop posts that aren’t in different categories. I’d like to have arbitrary site.key.value objects that work like site.categories.CATEGORY. There are ways to program around this, but they aren’t pretty. This would make jekyll even more incredibly powerful, but I think it’s a much lower priority.

  If you use jekyll, I’d love to hear what you’d like to see from the jekyll in the future. A number of these options (rpeg-markdown, usability/workflow documentation, template directory) are things that I can work on (and will, for sure), but a few of them are beyond me and I’d love to help folks do some of this work, if possible.

Onward and Upward!

(ps. my _posts directory is about 6.2 megs, with a file count that’s a bit south of 1,300 files, so if you wanted to assert that I’m pushing the system a bit hard, that’d be totally reasonable.)

People who use free software are almost all “open source/software freedom advocates” in on sense or another. There’s something empowering about the experience of using software that you control, really control, and we want to share this with others. That makes sense, not just on a “lets get the family using GNU/Linux” level, that we want to increase the user base of free software as much as possible.

One of the chief recruiting concerns for communities, seems to be “lets make this piece of software more usable.” This gets us into a lot of trouble as a community as there are a lot of similar and intersecting issues that get confused in the project of increasing usability. While “usable” is a subjective thing in the end, there are a lot of factors that make software more or less useable, they include:

• greater or lesser functional complexity,
• more or less visual clarity (of control interface and data visualization,)
• functional and/or visual minimalism,
• thoroughness of documentation and support materials, and
• the learning curve.

One of the most powerful effects of free and open source software is the way that it encourages users to learn more about the software and systems they use. We say that one of the reasons for software freedom is “education,” and you might think that this relates to the great potential for the use of GNU/Linux in schools, but I think it really relates to the way free software encourages users to learn more about the software they’re running.

Given these notions, I must say that writing software that “even a non technical user could learn” (dumbing down features and interfaces) doesn’t strike me as a very productive project, and a poor excuse for providing good documentation and support for a given project.

But maybe that’s just me.

I’m working on laying the seed content for a new wiki that I hope to launch in a few weeks. I want the wiki to be a free text/open source, and I have been giving some thought to the best way to accomplish this. This is, as it turns out, is pretty hard to accomplish: open source software licences are designed (not surprisingly) for software, and while Creative Commons Licences are great, I don’t think they support community authorship in a way that matches with my ideals/gaols.

The brilliance of the GPL (to my mind) is the way that it equalizes the relationship between all contributors (big and small) and between the “authors” and the “users.” While in a lot of open source projects these groups/interests overlap, they don’t sometimes and those cases where those interests might obstruct the freedom of the work, the GPL equalizes it.

There are two mechanisms in the GPL (to my mind) that make this possible: first, the requirement that source code be made available (and reproducible) with any distribution means that you don’t get anything extra because you were/are the original author of the code. The second, is the “viral” or “share alike” provisions where you can trust that anything released under the GPL will stay under the GPL.

While these mechanisms increase freedom and equity in situations where there are a select group of contributors and one legal author¹ the freedoms are most powerful when the boundaries between contributor and author and user are blurred.

This is all very basic stuff in the area of software freedom after all. The truth is that, as near as I understand there aren’t terms that can be used to get a similar effect with non-code projects (exactly.) There are a couple of copy left licenses, issued by Creative Commons and even the Free Software Foundation, but there are problems with both of these strategies. Here are the issues as I see them:

The GNU FDL is designed, primarily for software manuals and documentation in support of free software, and is strategically designed for this kind of text. It, as a result, lacks a certain… grace and elegance for dealing with other kinds of text, particularly when dealing with derivative and physical reproductions of a work.

In contrast, the Creative Commons Licenses² (CC) don’t have a concept of “source,” so that while they provide the same sorts of rights regarding distribution of work (and thereby equalize some of the rights between distributor/user), they don’t facilitate derivative work in the same way that open source licenses do.

I’m mostly worried about the following scenario. Say I release a piece of audio-art in a lossless (high quality; source) format (eg. FLAC/WAV) as well as MP3/OGG file (lower quality; compiled) under a CC license that permits derivative work under a viral/share alike terms. Then you turn around, re-equalize, and mix my audio-art with some other similarly licensed audio, and release it as a derivative work. That’s cool. But the derivative work needed be in the higher quality format, because CC doesn’t have a concept of source. Not having a concept of source doesn’t effect the possibility of derivative works, but it does mean that derivative works are second-class citizens, as it were. CC doesn’t equalize this relationship.

If I’m wrong about this interpretation, I’d love to be corrected, for the record.

For works where there’s a single author, having derivative works as second-class citizens isn’t a bad thing, and I can imagine that it would be seen as a feature in some cases. In cases where a text/work is authored by a community this is a major flaw.

I hear that there’s a project to Simplify the GFDL (or provide a way to use the GPL for documents/texts) that might remedy these problems (haven’t dug through it yet). In the mean time, I’m wondering what folks think on the subject.

My inclination is to just use the GPL with the specification that “source” would be some sort of plain text (ASCII/UTF-8/UTF-16) compatible file. That achieves the goal required, without too much fuss or concocting a new license that would prove incompatible down the road. I think mandating a particular format (markdown/org-mode/xhtml/LaTeX) is a bit too strict, but I’d hate to see a document developed in the open, released as a PDF derivative without making (say) LaTeX sources available.

Though I’ll be the first to acknowledge the irony that for non-software works, the “source” isn’t “human readable source code” but rather “machine readable data source.”

The only real practical concern is that if the FSF releases a 2.0 of the FDL (or a SFDL) that becomes the a standard for free/open source non-software/text projects then going with the GPL might make that a difficult/bothersome transition on that. So the question, seems to be would providing the option to upgrade to the GNU FDL make sense (eg. this work is licensed under the GPL [with an understanding of what the source is] version 3 or (at your choice) a later version [or a later version of the GFDL]).

Anyway, back to writing.

So I was hoping to write you this morning from a brand new blogging system powered by jekyll that I did a little bit of tweeking on. Unfortunatly, all the pieces aren’t all in place, yet. So tychoish is still a wordpress event still on wordpress. The highlights:

• It seems to have not worked, because it’s notion of categories isn’t a bit more firm than my own notion of categories (ie. coda and tychoish), and there isn’t any clever (or not so clever) way to get around this. It’s way more geeky than normal, but basically there’s no way (that I can figure) without categories to get an array/object of some segment of the posts without using jeykll’s categories.

  The categories that jekyll has are really powerful, and my problem isn’t so much how they work, as it is that I have 1300-ish posts written “in the old way” that I need to figure something out for. I’ll do that, but it’ll take a bit longer, and it’ll mean that there’ll be a more substantive update to the site.

• I did something that I think improves jekyll, by adding an aditional permalink format to my fork. I’m not even passingly familar with Ruby (and I may have a slight professed disdain for it) and while it wasn’t a big change nor did it require a bunch of logic/smarts, it works and I think I did it “right” for whatever that means.

  I also, in the course of this, got sed to work right, which was mostly just a case of me reading the manual wrong for years and then avoiding it. But personal victories are victories all the same.

I can explain my jekyll issue/need in more detail if anyone wants to help me hack on this. Cheers!

For my good (and yours), here’s a list of things that I think I should know how to do in emacs, but somehow don’t:

• Use the version control package so that I’m not constantly popping between bash (terminal) and emacs to talk to git, and I don’t think that’s necessary.
• Batch renaming with Dired. It should work, it should be simple, I’ve just not gotten there.
• File specific org-mode settings, for properties, tags, and TODO keywords. I understand that it’s possible, but my brain/system doesn’t have room for that yet.

So I’ve noticed that my impulse on these shorter blog posts (codas) that I tend to just do my normal essay thing only shorter, which is more of an old habit than it is something productive or intentional. Weird. To help break out of this bad habit, I’m going to post some links that I’ve collected recently.

I saw a couple of articles on user experience issues that piqued my interest, perhaps they’ll pique yours as well: Agile Product Desgin on Agile Development and UX Practice and On Technology, User Experience and the need for Creative Technologists.

Cheetah Template Engine for Python. This isn’t an announcement but I’ve been toying around with the idea of reimplementing Jekyll in python (to learn, because I like python more than Ruby). Cheetah seems to be the template engine for python that looks the coolest/best. I need to read more about it, of course

I didn’t get to go to Drupal Con (alas), but there were a few sessions that piqued my interest, or at least that I’d like to look into mostly because the presenters are people I know/watch/respect: Sacha Chua’s Rocking your Development Environment Liza Kindred’s Bussiness and Open Source James Walker’s Why I Hate Drupal.

Sacha’s because I’m always interested in how developers work, and we have emacs in common. Liza’s because Open Source business models are really (perversely) fascinating, even if I think the Drupal world is much less innovative (commercially) than you’d initially think. Finally, given how grumpy I’m prone to being, how could walkah’s talk not be on my list?

Anyone have something good for me?

In the latest/forthcoming version of GNU Emacs there exists a daemon mode. The intent is to make it easier to run in one instance of emacs, and rather than starting new instances, you can run everything in one instance. Less overhead on your system, and everyone’s happy. Without daemon mode, you can still run in server mode and get nearly the same effect, but you end up with one emacs frame that’s the “host,” which means, if you’re dumb and close it (or it’s running inside of another process which crashes…) all of the frames close.

I suppose, as an interjection, that my attempt to explain why this is cool to a generalized audience is somewhat of a lost cause.

In any case, there’s a problem daemon mode doesn’t behave like anyone would want it to. This post explains it better than anything else I’ve read thus far, but it’s not all that clear. Basically when you start emacs --daemon it doesn’t load your .emacs init file correctly, and so things like display settings are off kilter, and can’t really be fixed. I resorted to running my “host” emacs frame inside of a terminal/screen session, because that worked and was basically the same from my perspective.

Nevertheless I’ve discovered “the fix” to the emacs daemon it to work like you’d expect. Run the following command at the command line (changing username and font/fontsize):

emacs -u [USERNAME] --daemon --eval "(setq default-frame-alist \ '((font-backend . "xft") (font . "[FONT]-[SIZE]")))" -l ~/.emacs

And then, open an emacsclient.

… and there was much rejoicing …

There are a couple of things that I can’t get to work reliably. Most notably, though the emacsclient works in terminal instances, it has some sort of problem with attaching new clients to X after an X crash/restart. No clue what this is about. Not quite sure what the deal is with this, but needing to reboot every time X goes down is a bummer. Other than that? Emacs bliss. For the moment.