After a recent apt-get:
Fetched 1B in 0s (42B/s)
Well. That settles that question! :-)
After a recent apt-get:
Fetched 1B in 0s (42B/s)
Well. That settles that question! :-)
I've been on Twitter for over a year and a half now. If I had to explain why I like it, and why it's so popular now, I would use an analogy:
Twitter : IRC :: Blogs : Usenet
(This applies equally to other "micro-blogging" services, but I am about to explain why I believe that's not the right metaphor. You may also substitute mailing lists for Usenet.)
With the older media, you have a place -- a newsgroup, or a channel, that people went to, with a distinct culture, and that (mostly) weren't "owned" by anyone, but rather by the community. With the new ones, we are all sole proprietors of our own streams, and we "tune in" to the subset of people we find interesting, rather than topics we invest in. So, instead of bumping into the same person in a couple different groups, or never reading their words at all, you might find that your feeds overlap a bit more than they do with most people. This is how I find people to "follow" and blogs to read, in fact -- as my network expands, more people become loosely joined to it, and as I notice ones worth reading I add them.
Is one model better than the other? Probably not. I could make an analogy to music. In theory, I'd rather read what my favorite critics have to say about a wide variety of new releases -- some of which I'd never know about otherwise -- than keep up with the discussion of bands and genres I really like, even if most people writing about them are terrible (remember, 90% of everything is crap). But I also lose that sense of community of being a "fan" of something; I no longer have a deep connection to what's going on in the fandom or the scene, which I also would never know about otherwise (some of it is just too obscure for my favorite writers to cover).
In practice, it seems the new approach has been more popular, but maybe that's because more people are on the net now, and both kinds of communication are/were shaped by the technology available at the time (destinations make much more sense with limited/centralized computing resources, and aggregation makes much more sense with powerful clients and a wider, less specialized user base).
Anyway. This post is not actually about social media theory or whatever you want to call it; it's about some software I have packaged.
Because of all the above, I have always wished that I could use Twitter from something more like my IRC client. Like, say, my IRC client. One could abuse the concepts of IRC to make an "on the fly" channel of whoever happens to be in my feed. (I once read a blog comment somewhere complaining that Twitter could easily be implemented on any existing IRC server using one +m channel for everyone and some client-side direction of messages from all such channels to a single window. +1 for cleverness, but they did sort of miss the point of why normal people sign up for web sites rather than installing and configuring clients for obscure chat protocols.)
So, I had grand plans to write a Twitter client which was an IRC server, with some clever mapping of IRC concepts and commands to their equivalents over there. I never got around to it, as I barely have enough time for anything I do now. But last month I noticed that someone else had implemented such a thing: tircd. I had seen Twitter/IRC services before, but like the official Twiter XMPP service, they were all implemented as bots, which I detest for this sort of application. Bitlbee, for example, translates various IM protocols to IRC, but only halfway -- for anything else you have to use a bot as a sort of poor man's command line. If I want a command line for Twitter, I already have several; IRC can do better. And tircd really does! It's great. You're not required to edit the config file, and there's no extra layer on top of IRC for things like logging in or adding people.
I've finally packaged the latest release, which is waiting in NEW currently. I got a request for sneak preview packages, so if you want to install some unapproved .debs check this repository.
I may still pick my own project back up, as Twitter itself, being a centralized service, feels like a stopgap solution on the way to to a more generalized 140-character equivalent of the, er, blogosphere as envisioned by open-source projects like Identi.ca. In the future, perhaps, when we use a certain micro-blogging "service" we might be randomly connected to one of any number of servers run by different individuals but all mirroring messages back and forth to each other. Which, now that I think of it, sounds vaguely like some obscure, obsolete chat and news-posting protocols I know.
In related news: with sup out of the way, I have returned to packaging Mnemosyne, the program that powers this blog. It is also in NEW, so expect to see it soon. (Like sup, which is packaged as sup-mail since sup is the Software Update Protocol, it is mnemosyne-blog since mnemosyne is the program formerly known as PyQt MemAid.)
If you're just joining us, Mnemosyne compiles a Maildir into a static site. You can use it for a blog or just about anything else where a traditional CMS would be overkill. It's all XML and Python-extensible. The documentation kind of sucks, though, so I'm also hoping I get some more users from this to tell me what to fix. It hasn't otherwise seen much action since the beginning of 2006. Drop me a line if you have any feedback!
(If it's not obvious, I think blog "comments" in general are pretty worthless. But with some craftiness, they could certainly be implemented within Mnemosyne as it stands. As could a general mailing list archive, etc...)
After some weeks of final testing, I've just uploaded packages for sup-mail to NEW. I'm pretty excited about this.
Sup is a console-based MUA, like mutt (which I have used for many years). A few things distinguish it from most mail readers targeted at geeks like us:
- Sup has no folders, a la Gmail. After watching many friends and even fellow hackers switch to Gmail, I have to admit: this literal hierarchical organization thing doesn't scale. I was planning to totally redo my mail folder system Any Day Now for about six months prior to starting on this. It was never going to happen.
- Sup uses a Ferret full-text index to make this approach plausible. Search is super fast and beats (for me) both any kind of "organization" I could have disciplined myself into and the fine-grained control of something like mutt's search. It's sort of like git: until you do it, you don't realize how much more productive you can be when previously-expensive operations become instantaneous.
- Sup works with threads, not messages; this is another thing Gmail got right. I used to waste brain cells thinking about which messages in a thread were worthwhile enough to save or not. Given the absurdly cheap price of disk relative to what we can type out in plain text since, like, a decade ago, this is crazy. In the index, I only have to look at whether a thread has new chatter or not, not its size, shape, or where the new messages are relative to it. All that's in the thread-view buffer where I actually read content.
- Sup is written in Ruby. Back in the dawn of time, I used Gnus, and while I wasn't very good at elisp, the hackability afforded by being written in a high-level language was very nice compared to programs mostly implemented in C (even if they had a tacked-on scripting language). Plus, I love Ruby right now.
Despite all of those wins, sup currently has many drawbacks, and I don't recommend it for everyone. (And I mean everyone who thinks that the above are good ideas and are interested in using it; plenty of people, I'm sure, already think everything about this is idiotic, not new, or inferior to their preferred MUA. That's fine! You can ignore it all.) Here's what's still problematic:
- At version 0.6, sup is very much not-yet-1.0. While it handles insanely large amounts of email without breaking a sweat, I still keep an additional backup of everything. (If Ferret crashes, the original copies of mail will be untouched, but it never hurts to be paranoid.)
- The flow of data from your physical mail store to the sup index is currently one-way only. Actually removing deleted/spam messages is a big hack (if it works at all), and labels/flags/etc live entirely in Ferret-land. If you want to manipulate an actual mailbox, mutt is still the tool for the job (and then, you need to re-sync sup). This is probably the deal-breaker for most of us. I jumped in anyway because I feel like it can be solved (or more likely, made irrelevant) later.
- William (upstream) is currently re-designing the whole thing from scratch, replacing the index library with Sphinx, and decoupling the index from the console frontend. As a result, the previous item is pretty much a non-priority (and bugs in general are not going to get the same amount of love as usual). I am hoping that we end up dumping mail into the index directly, then writing more frontends to write to Maildir backup, serve as webmail/whatever, but this is a long way off. On the plus side, thanks to Thrift, they will not be limited to Ruby.
- Ruby's ncurses library still doesn't handle Unicode correctly. It can be patched (still doesn't work totally right), but I'm trying to find a more permanent solution for Debian.
So, if you're interested enough that you want to deal with these warts for now, apt-get install sup-mail (as soon as it hits the archive) and join us! Hopefully being in Debian will increase the userbase and get things fixed faster. If you're unsure, stay tuned for the next-generation version later.
(There are screenshots and a few introductory docs over at Rubyforge that illustrate and explain all this in more depth, which I recommend checking out if you're still saying, "...huh." Me, I'm a sucker for any piece of software with a manifesto.)
What can I say, except maybe
- Emacs (the rudiments, anyway) is like riding a bicycle
- When I say vi, i mean vile, not vim. vim gives me hives. vile is teh awesome.
I am working on a set of vile-ish bindings, and I can't say I feel any pressing need to stick hjkl in. You could start from there, but that's missing the point, I think.
(You know what's also awesome? My email is still down, so I won't even have to delete flames from people who take their choice of editor/browser Very Seriously until sometime tomorrow.)
I spent some time banging my head against SSL certificate stuff this weekend in the hopes of implementing a Really Awesome Solution to this awful Firefox security theater thing everyone was complaining about, but I didn't get anywhere. However, I noticed something interesting: Mozilla does not trust the CAcert root certificate. A number of useful sites, like Freedesktop.org's bug tracker, use a CAcert-signed certificate rather than a self-signed one.
I really know nothing about this organization, but they seem to have their stuff together, and if you run a largish free software project, you could potentially save a lot of people the trouble of checking yet another self-signing CA. Around the lab, or in one of my tiny projects, I don't think I'd bother, but it is free.
Anyway, we ship their root CA thing in Debian, and OpenSSL stuff picks it up fine. Mozilla's process is somewhat more mysterious. There's an apparently hardcoded list of the usual thugs from the Verisign/Thawte/etc protection racket, and then there's a database in each user profile for whack-a-mole stuff. There is not, shockingly enough, somewhere for an operating system to set system certificate policy. (I guess there is not much room for an operating system in the Mozilla world-view at all). So you have to shove it in there once for every user times every single profile.
Here is the command to do it.
- apt-get install libnss3-tools
- certutil -d $HOME/.mozilla/firefox/$HLAGHLLAGHGAAHLGALHHGHLAGH.default -A -n 'CA Cert Signing Authority - Root CA' -t CT,C,C -i /etc/ssl/certs/root.pem
It's only slight pain relief, but it's something. You can also not install certutil, and click through ten million dialog boxes to import it, but screw that.
UPDATE: A commenter points me to StartSSL, another service that may deserve a look here, and is on Mozilla's good side. It appears to be an unholy mix of things that sound awesome (client-side certs for OpenID, web-of-trust identification) and things that seriously skeeve me out (trademark symbols everywhere, Aladdin dongles). They, uh, also have a Linux distribution. No, really.
UPDATE 2: James Andrewartha points out that we should eventually see Mozilla move this stuff out of libnssckbi.so and into SQLite, which sounds like a big win for us. Hopefully before that time I will figure out how to get sqlite(1) to work on my cookies.
This is mostly for my own reference, because the thing in the manual didn't work for me and it took too much googling. I just wanted these steps listed in order.
- debootstrap --variant=buildd --arch i386 --foreign sid base-i386
- chroot base-i386 /debootstrap/debootstrap --second-stage
- vi base-i386/etc/apt/sources.list (there must be some way to do this exactly like pbuilder --create?)
- (cd base-i386 && tar vczf /var/cache/pbuilder/base-i386.tgz .)
- pbuilder --update --basetgz /var/cache/pbuilder/base-i386.tgz
I'm not sure if this is quite right, as I did end up tidying up both amd64 and i386 by hand at some point. But it's functional.
Brown paper bag bugs cause you to scramble to get a fixed version out as soon as possible, which causes more bugs and that causes more grief, which causes you to screw up the upload. I suck. Maybe we should discourage being your own upstream.
I have a line in my ~/devel/TODO under aewm that says “UPDATE THE FUCKING VERSION NUMBER IN aewm.h YOU DOLT”. Will I remember to read it? Who knows?
<decklin> but that will actually be FUN unlike hacking gaim which is AWFUL
Yeah, that’s why, mainly. I think I just need to be more professional.
Snakes on a Plan9!
I still have the port of rc, but it is pretty much “done” these days as far as fixing bugs and I don’t think I’ve uploaded the Debian package in a year or so. I may get back into it and add some improved readlineiness someday.
Generated by Mnemosyne 0.12.