Friday, July 31, 2009

Fake post

No post today. Too lazy. I'll do an extra post next week at some point so I'm caught up.

Thursday, July 23, 2009

Lament for the Saturn V

The Saturn V was a magnificent beast, simultaneously a testament to the triumphs and the excesses of the manned spaceflight program of the 1960s. Standing dozens of stories high, with its three stages, and costing billions of dollars per launch, it was capable of delivering well over a hundred tons to low earth orbit. This is the rocket that, 40 years ago this week, carried astronauts to the surface of the Moon - easily the greatest thing that America has done in the past half-century. The Moon landings gave America such an unimpeachable reputation for scientific greatness and exploration that we're only now managing to find ways to tarnish it.

You can still see a Saturn V today if you want, at Johnson Space Center. I drive by it sometimes, and every time I do, it pisses me off. Why? Because you can't see it on a launch pad, or even upright, or even intact - they've chopped it up and put the individual stages on display. A few years ago, as if to add insult to injury, they built some kind of shed over it; ostensibly to protect it from the elements, but I can't help but think that they've managed to cut it off from the sky (where a rocket belongs) in the most literal possible way. Here we have a triumph of engineering, one of the largest machines ever created by human kind, a machine that was meant to go out to a new frontier on a pillar of fire and carry some of us along for the ride... and we've put it on display in a museum, with little placards and velvet ropes, like some artifact of a lost civilization. And maybe that's exactly what it is.

I'm not saying that we should resurrect the Saturn V; it's a hopelessly dated design, and we could do a lot better today, if we really wanted to. And there's the rub. I believe, with all my heart, in the inexorable march of progress, whether in small steps or giant leaps, because technological improvements are good for everybody; if technology always improves day to day, then every day is just a little bit better for humanity than the last. On a very deep level, the thought of this process running in reverse, of technology taking a small step back, really bothers me. So to see a technological artifact on display in a museum, and to know that it's beyond anything that we have available today, just feels wrong. I suppose the thing that bothers me isn't that the Saturn V is behind the velvet rope. It's the fact that it got there without first being replaced by something better.

Thursday, July 16, 2009

So what's this Linux thing, anyway?

There's a lot of confusion about what Linux actually is, and what it can do, even among experienced Linux users. Frankly, I think a lot of the confusion stems from the fact that people keep referring to Linux as an operating system. It's not an operating system in the sense that people usually mean; instead, Linux is a kernel, which is the core piece of an operating system. A lot of other pieces of software fall under the umbrella of what people usually call "Linux". Many of them are written by GNU (credit where credit's due), but a lot of software for Linux is written by random people all over the world, just for fun. Linux, as usually used by people, refers not to an operating system, but to a bunch of disparate pieces of an operating system that people combine into workable systems.

Perhaps a food analogy would help!

Have you ever been to a Mongolian barbecue place? If not, you really should; it's definitely a worthwhile experience. They have raw ingredients (mostly stir-fry fare) laid out buffet-style, and you select the ones you want, choose your sauce and seasonings, and then hand it over to the cook, who fries up the whole thing on a huge metal plate. It can be a bit intimidating if it's your first time having it, but once you get used to it it's a really fun way to eat.

Linux works like a Mongolian barbecue place. Instead of selecting a prepared OS off a menu, you can take all the component ingredients and combine them into something that suits your tastes. Linux distributions are kind of like recipes - you get a good starting point, but you usually have a lot of leeway to customize what you start with. Traditional operating systems, in this analogy, are more like dishes that you order off a menu - you get a few choices, and you pick one, and that's that.

There are some really important consequences of this. The first is that the set of libraries and services that you can expect to be installed on any given Linux system is pretty fluid, because of user preferences. This can make it difficult to write software that will run well on all Linux systems, as the Google Chrome developers discovered a few months ago when they were looking for a GUI toolkit to use. (See this widely quoted thread.) Another concrete example is the state of audio APIs on Linux. (Summary: ALSA is horrible but everything uses it because it was the only game in town for a while; PulseAudio is nicely designed, but still buggy, and looks like the current favorite for the future; OSS was dead for a while because of licensing issues, but may be making a comeback, since it seems like a very clean solution technically.)

Because of this, integrated package management is a necessity for Linux systems, not just a convenience. On a normal operating system, you have a set of interfaces that you can basically count on being there when you distribute software. You can download programs from random places on the Internet, or get then on CDs, or whatever, and they basically just work. On Linux, on the other hand, programs need to explicitly state their dependencies somehow, since you can't always count on them being there, and the system needs to be able to go and install those automatically, or the whole thing would be too cumbersome to use. This is a mixed blessing, because while integrated package management has definite advantages in terms of security and ease of use, it makes things more difficult for developers that want their software to run on Linux.

Linux on the Desktop

There's been a developing tension over the past few years between people pushing for easy-to-use Linux on the desktop, and those that want a lean, minimal UNIX-y OS. The former group includes most popular Linux distros, since widely-used distros are usually the ones that aim to be user-friendly. The latter group, on the other hand, includes a lot of experienced Linux users, who've been around since before many of the recent changes to desktop Linux. Part of the push for making Linux more user-friendly and integrated involves adding a whole slew of new components, such as HAL, D-Bus, various packages ending in -Kit, PulseAudio, and others. These work well, and generally do what they were designed to do, but they lack the simplicity and transparency of the UNIX underpinnings of the OS, and a lot of people resent these changes because of that.

There are dozens of Linux distributions catering to either camp, and quite a few that take up various points in between them. This may indicate that Linux is now diverging in two separate directions; I can't really say. I don't believe that this would be a bad thing, though. One of the defining features of Linux is choice, and the ability to choose between different types of operating systems fits naturally into that. Even so, this is tremendous change in the Linux environment that needs to be acknowledged, whether or not people agree with it. We might look back at this as an epochal shift, or we might shy away from it and see it in retrospect as a huge mistake, but either way the consequences will be huge.

So what is this Linux thing, anyway? Linux is the result of a bunch of programmers that, mostly independently, decided that they wanted their operating system to do more, and that did something about it. It's fractured, sure, and it lacks any kind of overall guiding vision. Thousands of people work on it, and yet, somehow, through some kind of miracle of self-organization, the whole thing doesn't fall apart or spontaneously combust. I think that's pretty neat.

Thursday, July 9, 2009

The American Clean Energy and Security Act

...also known as the energy bill, also known as Waxman-Markey, also known as cap-and-trade, also known as the massive energy tax that will double your electricity bill and murder your pets. Is it really as awesome and/or terrible as they say?

Outline

The bill, which was passed by the House a few weeks ago and is now set to go before the Senate, mainly creates a cap-and-trade system around carbon emissions, and also sets targets for large electricity producers to transition their generation capacity to renewable sources. In a cap and trade system, the government enforces a strict cap on emissions, and then allows businesses which go over the cap to trade permits for excess emissions in an open market. It's a better solution, in my opinion, than just enforcing a cap on emissions.

In economic terms, greenhouse gas emissions are an "externality" - they affect participants in the market who aren't directly involved in the transaction. Free markets are usually pretty bad at handling externalities; the "tragedy of the commons" is a common example. A free market will tend to exploit a shared resource to the maximum degree possible. A cap and trade is a market-based solution to this. By introducing the costs of certain externalities to the market directly, you can come to a more efficient solution than you would through simple regulation.

You'd think conservatives would be thrilled about this, right? Yet somehow, instead of talk of how much better this is than straight-up regulation, all I hear is rhetoric about how the bill is a massive tax that will destroy the economy. First, it seems incredibly sloppy to label it a "tax" just because money will change hands from the private sector to the government when the allowances are auctioned. (It may be that there are other provisions of the bill which do impose taxes, but my understanding is that the auction will be the majority of what the government makes from the bill.)

Second, the bill isn't actually all that terrible - Kucinich even voted against it because it didn't go far enough, in his opinion. Eighty-five percent of the allowances are going to be simply given away to various industries initially; only the remaining 15% will actually be sold in the auction. As for the renewable electricity requirements, 20% of electricity will have to come from renewable sources, but not until 2020 - electric companies have ten years to ramp up to that level of production.

Peak Oil

People are remarkable resistant to the news that petroleum won't be this cheap for much longer (and we have no idea how much longer). The facts are, though, that there's a finite amount of oil in the ground, we've used up a good bit of it, and our consumption is increasing along an exponential curve. It's possible that prices will rise gradually, and we'll have time to slowly wean ourselves off of oil. It's also possible, on the other hand, that a few high-profile events will coincide (several major oilfields drying up at once?), and we'll have a sharp and long-lasting increase in the price of oil. As our country is now, such an event would be the death of us.

The hardest part of rolling out a new technology is the first part, since initial R&D can be really, really, expensive. What ACESA gives us is an incentive to get over that first bump before events force us to. But more importantly than that, it puts us in a really good position when peak oil finally hits worldwide. When it happens, there will be countries that were completely unprepared and that will flounder. I don't want to be living in one of those countries! I want to be living in a country where they had the foresight to put in the R&D money early, so that when the disaster hits, they can sell that technology and expertise to the rest of the world. That's not starry-eyed environmentalism - that's just good business sense. ACESA will cost us money now, but we can come out ahead in the long run by getting a head start on technology that everybody will, at some point, need.

Our environment

I would be sad if all the polar bears died. I might even shed a tear. But in my mind, the polar bears are not the important thing when it comes to the environment. The important thing is maintaining an environment which is friendly to human life. This is another thing that we're all too willing to forget; there is no guarantee that the Earth's biosphere will always be as hospitable as it is today. Now that we have the power to affect the climate on a global level, this is something we really need to actively keep an eye on.

The biosphere is a big, interconnected, and incredibly complex system. Despite the best efforts of ecologists, there aren't really clear answers to a lot of important questions. For instance: "If the amount of carbon dioxide in the atmosphere were to increase by this amount, with the associated changes in temperature, ocean acidity, etc, etc, how would it affect our staple food crops?" In the absence of such information, the best we can do is try to maintain the current state of the environment until our understanding improves.

That's why this bill is important. It's not a solution; it's a first step toward a stop-gap measure, but it's one that I believe is absolutely necessary, both for America and (more tenuously) the human race.

Thursday, July 2, 2009

Death to progress bars!

The innocent progress bar, a mainstay of computer interface design, is actually pretty terrible if you think about it. The core idea may be sound, but through various kinds of misuse, it's become something of a running joke. Over the years, people have committed all of the Seven Deadly Progress Bar sins, and I think we would all be happier if we placed the venerable progress bar to rest.

Opaque progress bars - I mean that in the sense of a progress bar which displays no other information about what's actually going on. A progress bar, by its very definition, represents the progress of some operation, which can be measured in some way. There's no reason save laziness not to include this information in the interface, and it makes life difficult for users. With an opaque progress bar, if the user wants to know how long an operation is going to take, for example, their only recourse is a ruler, a steady hand, and a stopwatch. This is especially problematic with really slow progress bars, since the user has no way to know if the operation has stalled, short of watching pixels as the progress bar moves occasionally.

Mixed progress bars - A progress bar should only really represent one operation. If you try to represent a series of steps with a single progress bar (like many installers do), then you'll end up with a really jerky and unpredictable progress bar, unless you're really careful (like many installers aren't). The poor, bewildered user has no idea why the thing is progressing in fits and starts; as far as they know, it's just your program being erratic. This can be somewhat mitigated by putting a status message so that they know what the program is doing at different times, but even then, it's still not great.

Lying progress bars - On occasion, I've seen progress bars that move even when nothing is actually happening, to try to convince the user that the program hasn't crashed or something like that. I'm almost certain that versions of IE do this, but I haven't used IE in a while. If you're trying to show the status of an operation that isn't actually progressing, you don't need a progress bar! You need help.

Uncertain progress bars - Basically all web browsers are guilty of this one. You'd like to show the progress of a web page loading, but unfortunately, a web page can pull in an arbitrary number of other files from anywhere on the page, so you don't actually know up front how long it'll take to load. If the page is partially loaded, and suddenly a huge image is requested, do you move the progress bar backwards, or just start moving it really slowly so that it all looks like it adds up? This is further complicated by the fact that some files may be on other servers, which you then have to connect to, which could take an unknown amount of time. Do you stall the progress bar while this happens, or do you just try to fake it? Neither; you find a better metaphor, one that actually fits the information you're trying to display.

Flashing progress bars - Slow progress bars are irritating, but some programs have the opposite problem. You see this most often on sloppy installers; the installer fills the progress bar once for each file copied, but since it's copying a lot of files really quickly, the progress bar just sort of flashes on and off. That is basically useless! Instead of that, why not add up the size of all the files, adjust for smaller files being slower, and show a unified progress bar? This is not difficult.

Short-lived progress bars - If the action that I'm supposed to be watching the progress of is going to take less than one or two seconds, is there any point to putting a progress bar on the screen in the first place? Just put a status message somewhere that says what's happening. Little animations of bars filling up don't really help anyone, since by the time the user processes that something is there, it's gone already. The less distractions, the better.

Progress bars that aren't slow-motion clips of Megan Fox running away from explosions - Having seen Transformers 2 recently, I'm convinced that this is actually the best possible way to fill some time. :3