I’m going to present this post somewhat out of order. Here’s the proposal.

I want to think about moving this blog (or starting another?) to be a blog/wiki hybrid, and at the very least, moving forward I’d like the “discussion” or comment’s link to link to a wiki page rather than a comments thread.

I’ve been thinking about the blog recently. I really enjoy writing posts, and there are days when I rely on writing a blog post to get me thinking and moving in the morning (or afternoon!) and kinds of projects that I don’t think I would be able to work on if it weren’t for having the space to write and the opportunity to have conversations with you all.

I’ve done some work recently to streamline and simplify the publishing process, which does a lot to make me more likely to post on the fly, but I’m not sure that the tone of this site, or the current design, or my own habits would really support a different kind of publishing schedule.

As an aside, I think the technological shift that made blogs possible were “content management systems” and website building tools that made updating a website with new content incredibly simple. While blogging has come to mean many other things and is defined by a number of different features, having the ability to publish on very short notice has a large effect on the way people write blog content.

So here’s the thing about blog comments: I don’t think that they’re used particularly well, and there are some important flaws in so many of the options around. First, the best systems, like the one used on LiveJournal, IntenseDebate, and Disqus (which I use on this site) are all proprietary systems that are depending on an external service to function. The worse systems all have independent authentication methods, often lack proper threading (which most comm enters aren’t terribly good at using anyway,) and it’s very difficult to prevent all these systems from being filled with spam.

What’s more, people don’t really comment that much. At least for most blogs.

• better comment systems, better discussions.
• catering to people who want to write a lot. in comments.
• allowing the conversation to grow from comments, in productive rather than purely discursive ways.

And once you’ve moved comments into a wiki, why not move the rest of the blog as well? My preferred engine, ikiwiki, has support for blog-like content so while there would be some work involved, it wouldn’t be a major hassle to manage. And the worst case scenario is that the old content remains in the old system, which might not be a bad thing in the end.

Anyone out there in reader land have any thoughts on the subject? While I’ll probably make some sort of revision to the way I blog/maintain tychoish.com, any such change is probably a month or two in the future.

I have misgivings about Open Stack. Open Stack is an open source “Cloud” or infrastructure/virtualization platform, that allows providers to create on-demand computing instances, as if “in the cloud,” but running on their own systems. This kind of thing is generally refereed to as “private clouds,” but as all things in the “cloud space,” this is relatively nebulous concept.

To disclose, I am employed by a company that does work in this space, that isn’t the company that is responsible for open space. I hope this provides a special perspective, but I am aware that my judgment is very likely clouded. As it were.

Let us start from the beginning, and talk generally about what’s on the table here. Recently the technology that allows us to virtualize multiple instance on a single piece of hardware has gotten a lot more robust, easy to use, and performant. At the same time, for the most part the (open source) “industrial-grade” virtualization technology isn’t particularly easy to use or configure. It can be done, of course, but it’s non trivial. These configurations and the automation to glue it all together--and the quality therein--is how the cloud is able to differentiate itself.

On some level “the Cloud” as a phenomena is about the complete conversion of hardware into a commodity. Not only is hardware cheap, but it’s so cheap that we can do most hardware in software, The open sourcing of this “OpenStack” pushes this barrier one step further and says, that the software is a commodity as well.

It was bound to happen at some point, it’s just a curious move and probably one that’s indicative of something else in the works.

The OpenStack phenomena is intensely interesting for a couple of reasons. First, it has a lot of aspects of some contemporary commercial uses of open source: the project has one contributor and initial development grows out of the work of one company that developed the software for internal use and then said “hrm, I guess we can open source it.” Second, if I’m to understand correctly, OpenStack isn’t software that isn’t already open source software (aside from a bunch of glue and scripts), which is abnormal.

I’m not sure where this leads us, and I’ve been milling over what this all means for a while, and have largely ended up here: it’s an interesting move, if incredibly weird and hard to really understand what’s going on.

I was writing a blog post about the ideological tendencies in free software and I found myself on a side note that I think really wants to be it’s own post. Funny how that happens. I was thinking about the role and importance of system administrators in free software communities and development. This post is part of an ongoing thread on dialectical futurism about systems administration and its implications.

One might think, because free software communities produce software, that free software communities are communities of software developers. Programmers make software, free software is software, ergo… But I really think that a significant differentiating factor between free and non-free software is that free software tends to be created, shaped, and designed by people who are systems administrators by trade and inclination rather than people who are primarily software developers.

This is a somewhat difficult argument, and one that requires us to presume that the boundary between developers and administrators is impermeable (it isn’t,) but I think people who are programmers first and administrators second approach technological problems. Systems administrators write code. Lots of code. Any system that must be administered (deployed, modified, and maintained) “by hand” is probably a broken system. Scripting and automation are the keys to making systems maintainable in the long run. And the boundary between writing a few (dozen (dozen)) scripts and writing an operating system is probably not that great in the grand scheme of things.

And knowing how operating systems work is probably a key to making them work. In this case, we can imagine that systems administrators like open source operating systems (i.e. Linux and GNU based ones) because their inner workings are knowable, so system administrators are likely to reap much larger benefits from free software than other classes of users.

I’ve often found that understanding the richness and complexity of the “value” of Free Software and Open Source software is important for understanding why free software continues to exist and may be worth adopting. The value of free software comes from: the fact that there are no licensing costs, the freedom you have to modify the software to your needs and potentially largely ameliorate development costs, finally free software is valuable because it creates smarter users by virtue of its origins in academia and the way that it promotes user independence and community involvement.

Business decision makers might like the fact that the initial cost of free software is minimal and controlled, but most software related costs are probably support related and free software may not do much to minimize those costs. Developers may like that free software could make their jobs easier, but they may also suffer from “not invented here” syndrome, and be resistant to working on projects that (potentially) suffer from design decisions that they disagree with. Systems administrators may have preferences regarding certain pieces of software, but will generally like the additional control that free software offers them.

I wonder about the inverse: has the involvement of systems administrators in free software had an affect on the shape of that software? Do we use Linux and BSD-Unix because they’re easier to administer? Does this extend to the network protocols and technologies that get used more frequently?

Let’s file this under “questions I wish I knew how to answer…”

Onward and Upward!

Welcome to this new little blog/wiki project. I made a post to the ‘blog about reorganizing the way I did my blog comments and blogging called a modest blogging proposal.

I wrote this post a few weeks ago. I was so inspired by the prospect of reorganizing the blog, and also so frustrated by the less-than-useful structure of my blogging that, I did the “big reorganization” of the blog the very same day that I published the post that started it all.

This proves, it seems, the neccessity of these changes, which are:

• Moving the “dialectical futurism” blog to my “Critical Futures” domain, as an “essay” blog. I’m planning to post a new essay here every Tuesday. I might also add a second day a week for some other feature (podcast? contributed essay?)
• Move the “wikish” wiki that I’d been hosting on the “tychoish.com” domain to be tychoish.com, and add a more short-form blog to the “blog/wiki.” I’m calling it “Rhizomatics,” and this is the first post. I’ll be writing here pretty regularly, and with less intense posts.
• Do all of the above in a way that doesn’t break all of the existing links.

And I think I’ve done it all. I’ll be doing some tweaking in the next few days and weeks to make it all work a bit better, but suggestions are always welcome.

Stay tuned!

I do some work as a systems administrator, both personally and for friends. And I work with a lot of admins, but I don’t really think of myself as a sys admin. Though you may feel free to argue the point. Nevertheless, I spend a lot of time trying to figure out the way systems administrators think and work. This makes sense: as my professional work is written for entry level systems administrators and I work with a bunch of admins. But I think it’s probably bigger than that. This post is part of an ongoing thread on dialectical futurism about systems administration and its implications.

The best systems administrators are unnoticed and unremarkable. When a system is working smoothly, it works and no one has reason to think about who is maintaining the system. Thus, to be a better systems administrator you have to become confident in your abilities (leading to a somewhat grounded stereotype in arrogance) and you have to be resistant to change.

For example, take this slide deck of a systems administration problem. It presents a thorny sysadmin problem where the chmod utility (which is used to render files executable) has been marked unexecutable. The presentation goes through a number of different methods of fixing this, however (spoiler alert) the final solution is “the easy fix is to reboot the machine and fix it then (or something), and the machine’s running so there isn’t a problem.” While this is a funny example, I think it’s also largely a true example of the way systems administrators approach and resolve problems.

I’ve seen this kind of “well it' may not be perfect, but it works,” logic as well as the “is it worth building something new and different that might be better?” reasoning at work, and I think it’s probably apparent in all sorts of free software and other discussion forums where sys admins discuss things.

Thus, I wonder: Does this ideology extend beyond the administration of systems and into other spheres of life and thinking? About technology? About politics and economics? I’m not sure, though I’m of course inclined to say yes, and I think it’s something that requires some deliberation, and further thinking.

I look forward to hearing your thoughts, and figuring out the best way to answer this question.

Onward and Upward!

About a week ago, time of writing, I switched all of my instant messaging to a little program called Bitlbee. Basically this is a program that runs locally as an IRC server and connects to various instant messaging and “presence” protocols and exposes them to the end user client as if they were IRC. Weird.

This is, emphatically, the wrong solution to the problem of finding a sane technological solution to consuming real-time information (e.g. instant messaging, twitter, xmpp, etc.) Previously, I’d been using an XMPP-only client and running jabber-to-IM transports on the server, which I think is more of a right solution. Why then did I switch?

• I wanted to use irssi, which I think one of the most cleverly designed and useful pieces of software out there.

• Transports that allow XMPP to interact with other services are an ideal solution and I think the inclusion of transports in the design of the XMPP protocol is a major selling point for the XMPP technology. At the same time the most stable transports aren’t terribly stable and while there could be transport widgets for all sorts of things there are only a few general purpose transports.

  Practically speaking the jabber-to-AIM transport that I had been using, had a habit of dying without cause once or twice a week, and it used a lot of system resources for something that could (should?) have been much simpler.

• The truth is that while XMPP is a nifty technology, and I really enjoy using it, I’m starting to think that it’s not ideal to expect that XMPP replace IRC, as both accomplish different things for their users. So while I always saw bitlbee as “giving into IRC” it’s really just an interface. And frankly IRC clients do IM better than IM clients do IRC.

• Bitlbee works really well as a client for Facebook chat (which is a weird XMPP flavor) and is a functional twitter client. With the delight of using irssi, I’m able to really interact on these networks without having to spend too much brain power sifting through crud.

So here I am. Switched. The buddy list on bitlbee leaves something to be desired (but I have a particularly large buddy list) and I’ve yet to get used to the syntax for creating and administering group chats inside of bitlbee, but other than that? It’s pretty rocking.

Onward and Upward!

I spent a lot of formative time in high school and college listening to writing teachers and would be mentors tell me that I was too sloppy or too disorganized to write effectively. They were probably right. Furthermore, this is probably not something that I think I’ve been able to keep secret from anyone who has read my blog for any measurable period of time. (Though I do think most of my more recent entries are better than nearly all of my early entries.) What no one really dared to tell me, are probably the most important things I’ve learned as a writer:

• First, that editors are not only essential to the writing process, but that there’s something fundamentally wrong if something leaves the original author and is handed to final readers without passing through at least one editor, and often more.
• Second, the skill of writing isn’t necessarily being able to write artful sentences, or being able to perfectly apply all of the rules of grammar (which, aren’t detrimental to the craft of writing). No, writing is about being able to get things written. Writing is pobably about being able to do research while keeping in mind the parameters of the project and ending up with a few paragraphs on a given topic that make sense and enlighten more than they confuse. That is considerably more rare.

The problem, and I wish I had a solution for this, is that there is no real way to teach people to write and to love writing. Exposing people to lots of examples of writing (i.e. literature) is helpful in teaching people to read and cherish the practice of reading. Unfortunately, I think reading and writing pull on vastly different skills. And while readers have a useful and required prospective on the text, readers who don’t write often provide ambiguous and difficult to assimilate feedback.¹

Fundamentally, I think, readers live on the plane of words, and writers--at least writer’s like me--live on the plane of paragraphs. And then there’s the whole issue of confusing a love of reading with a need or desire to write, but that’s another story for another time.

The way, I think, to learn how to write better is to write a lot of crappy stuff and learn how to “fail” better and more gracefully. Blogging has and is a great tool for me in this regard, but it’s not a cure-all, and I think integrating blogging in the writing curriculum is a difficult project that requires a very nuanced view of blogging, and the right set of learning objective. Beyond this, the project of learning to write and learning to write “better” is one that I’m not sure how to properly facilitate in myself or in others.

At the end of the day, I think it’s important to realize that growth as a writer isn’t the kind of thing that happens quickly. Being a writer is a life-long project with slow and steady improvement, minor regressions, stunning breakthroughs, dashed hopes, and tactical successes.

Onward and Upward!

There are so many sexy topics in computing and information technology these days. In light of all this potential excitement, I’m going to write about email. Which isn’t sexy or exciting.

This isn’t we should be clear, to say that email doesn’t matter, because it seems that email still matters a great deal. Rather that email is still a relevant and useful paradigm. What’s more, the email system (i.e. SMTP and associated tools) remains in many ways superior to all of the technologies and platforms that have attempted to replace email.

The Good

Email works. The servers (e.g. Postfix, Exim, Sendmai, but most Postfix) are stable, known, and very functional. While there are flaws in a lot of email clients, there are a lot of tools that exist for processing and dealing with email, and that makes it possible for everyone to interact with their email on their own terms, in a variety of contexts that make sense the them. And email is such that we can all use it and interact with each other without requiring that we all participate in some restrictive platform or interface.

In short, email is open, decentralized, standard, lightweight, push-based, and multi-modal.

Compare this to the systems that threaten to replace email: Facebook and social networking utilities, twitter, text messaging, real-time chat (i.e. IRC, IM, and Jabber). The advantages of email on these crucial, I think, dimensions are pretty clear.

The Bad

The problem, of course, with email is that it’s terribly difficult to manage to keep current with one’s email. Part of this problem is spam, part of the problem is “bacon,” or legitimate (usu sally automated) email that doesn’t require attention or is difficult to process, and it’s undeniable that a big part of of it is that most end user email clients are inefficient to use. And there’s the user error factor: most people aren’t very good at using email effectively.

It Gets Better

No really it does. But I don’t think we can wait for a new technology to swoop in and replace email. That’s not going to happen. While I’m not going to write a book on the subject, I think there are some simple things that most people can do to make email better:

1. Do use search tools to make the organization of email matter less. Why file things carefully, when you can quickly search all of your email to find exactly what you need.

2. Filter your email, within an inch of it’s life. Drop everything you can bare to. Put email lists into their own mail boxes. Dump “work” or “client” email into its own folders. Successful filtering means that almost nothing gets to your “inbox.”

3. Use your inbox as a hotlist of things that need attention. Move email that needs responses to your inbox, and move anything that got through your filters to where it ought to be.

4. Use multiple email addresses that all redirect to a single email box. You only want to ever have to check one email system, but you probably want multiple people in multiple contexts to be able to reach you via email. This makes email filtering easier, and means that you just spend time working rather than time switching between email systems and wondering where messages are.

5. When writing emails, be brief and do your damnedest to give the people you’re writing with something concrete to respond to. Emails that expect responses but are hard to respond to are among the worst there are, because you have to say something there’s nothing worth saying.

6. Avoid top posting (i.e. responding to an email with the quoted material from previous exchanges below your respone.) When appropriate interleave your responses in their message to increase clarity and context without needing to be overly verbose.

7. Email isn’t real time. If you need real time communication use some other medium. Don’t feel like you need to respond to everything immediately. Managing expectations around email is a key to success.

That addresses most of the human problem. The technological problem will be solved by addressing spam, by building simpler tools that are easier to use effectively and support the best kind of email behaviors.

Why Email will Improve

1. Email is great in the mobile context. It’s not dependent upon having a net connection which is good when you depend on wireless.

2. Email is a given. Having email is part of being a digital citizen and we mostly assume that everyone has an email. The largest burden with most new technologies is often sufficient market share to make a “critical mass” rather than some sort of threshold of innovation.

3. Email is both push-based (and delivery times are pretty fast) and asynchronous. Though this doesn’t sound sexy, there aren’t very many other contemporary technologies that share these properties.

Onward an Upward!