Archive for December, 2007

Apple: least creative company name ever?

December 21st, 2007

It's no secret that finding a good name for a company is no easy task. We're not exactly blown away by Microsoft, IBM, Compaq. They have no imagination.

There are some names that aren't too bad. Names that aren't too clear about what they mean can be decent, because they sorta make you wonder. Adobe sounds kind of exotic and interesting. Amazon has just the right amount of familiarity and positive association. FedEx is extremely obvious, but somehow snappy all the same, it has just the right amount of consonants. In contrast, UPS is worthless. Intel is also pretty good, you don't know where it comes from, but it's a positive sounding word. Oracle is a name with potential, but the company profile is just so overwhelmingly boring enterprise that they could just as well be called BigYawn. One of the best names is Nero. It has an interesting historical association, plus it's relevant to the function of the software.

The Web2.0 names are all pretty dumb. They don't have that boring cubicle feel, instead they sound like cartoon strips. And most of them mean nothing, but in such a way that you know they mean nothing, there's nothing to figure out. Which makes it dull. Like Google. Even if that meant something, would anyone care? No.

But if there's one company that never gave it more than 2 minutes of thought, it's the World Marketing Champion, Apple.

Apple — For the favourite fruit of co-founder Steve Jobs and/or for the time he worked at an apple orchard, and to distance itself from the cold, unapproachable, complicated imagery created by other computer companies at the time — which had names such as IBM, DEC, Cincom and Tesseract

What a useless name that is. It's dumb at face value, and it's not a pun that would keep your brain busy for 3 seconds. It's just an apple. Even Nail would have been a better name, cause then you don't know if it's the body part or the construction tool.

For a company whose primary concern is image you would think they'd decide to change it at some point. Or can't they come up with anything? Then again they're not exactly known to break the bank for product names either. Apple Computer, Macintosh, Mac, eMac, iMac, MacPro, PowerBook (wow, everyone, a new adjective), MacBook, MacBook Pro, Mac mini, iPod (the most creative one so far). Then there is the software line where again they have spared no expense. iChat, iPhoto, iMovie, iWeb, iDVD, iLife. Yes, all products for creative people, you can really feel the ideas percolating.

And the latest? The iPhone. Boy, that must have been tough to invent.

undvd now in portage

December 18th, 2007

I was pleasantly surprised today to discover that undvd has made its way into portage. It does now have three releases on sourceforge with packages for gentoo (ebuild), ubuntu and fedora. But I haven't made any requests for it to be included, so apparently the powers that be decided it's not completely useless.

It's actually a bit of a dilemma what to do with these small projects. A big project just looks neglected without a website, complete documentation, packages for several distributions, up-to-date entries on various directory sites etc. I did the full scale follow-up with galleryforge, and that now speaks for itself, it presents itself as a proper project. But for one thing it was my first time hosting with one of these open source providers, so I wanted to explore the options quite deeply. And secondly, you don't really know what kind of a future a project will have when you're starting it, but galleryforge isn't used much, not even by me. So it was fine to do then, but it's some effort to put in for every small piece of code like this. (Not so much doing it then, but the burden of maintenance is the key issue.)

undvd is even smaller, and isn't expected to grow much (beyond feature complete by now). It started out as a blog entry and a link on my code page. Then I posted it on opendesktop, and it got seen by a handful of people who happened to be looking at the frontpage when it was added. There was also a regression bug posted there, which spurred me to start tracking it with git to avoid these things in the future. Then I decided I wanted to package it up, because that makes it organized and easy to use. But then I couldn't figure out how to write the url (in the ebuild) for the tarball hosted on opendesktop, because their file hosting is a little sucky. So I registered on sourceforge. The only thing I'm using there right now is the file release function. There's no website, and I don't really see the call for one. Meanwhile, I've been trying to maintain the user guide (which is shipped with the code) clear and up-to-date, to make that the one source of information. I think that's enough for now.

GPL vs BSD, a matter of sustainability

December 15th, 2007

If you haven't been living under a rock the past decade (I suppose Stonehenge qualifies) you may have walked in on some incarnation of the famous GPL vs BSD flamewar. It's up there with the most famous flamewars (now *there's* a research question for a brimming sociology student!) of our beloved Internet society.

Both licensing models have been around for a very long time. I don't know which predates which, but it really doesn't matter. The spirit behind both licenses is very similar: free software is good. But they realize this idea in different ways.

In the GPL license you have the four freedoms: to run the software, to have the source code, to distribute the software, to distribute your modifications to the software. What this implies is that when you obtain the software, you have the *obligation* to ensure that these four things hold true for the next person you give it to. After all, someone had to go to the trouble of preserving these rights for *you*, so you have to do the same for the next guy.

The BSD license is different, because it gives *you* the right to distribute the software, but it does not oblige you to make sure that the next guy has any such right. Well, that's not really a problem, the next guy can ignore you and get the software from the same source that you did (if that source is still available). But if you change it and you give it to him, you can forbid him from passing it on.

So who is right? Well, the BSD camp is. The BSD is no doubt a freer license, it gives you the right to decide what rights to bundle with the software. That is much closer to the absolute meaning of "freedom" than the GPL. Alas, it's not "completely" free, because you can't remove the name of the software's author and replace it with "Leonardo da Vinci".

What the GPL terms "freedom" is actually fairly subversive, because it *forces* you to do certain things. Most people who are forced to do something call that a "restriction" rather than a "freedom". It's true that you have certain freedoms when you get the software, but if you want to pass it on you have restrictions, so they could just as well call it the four freedoms and the four restrictions.

Therefore, if we take the philosophical ideal of freedom to heart, even though both of these licenses promote free software, none of them represent freedom, and the GPL is far less free than the BSD.

Harmless restrictions

Suppose you're a parent and you give your kid a candy bar and say this is for you and your brother, you can have half of it, and when he comes home give him the other half. Do you think that is going to happen just as you instructed? How confident are you?

Well, your intentions were good. You tried to ensure fairness. But we humans are scheming devils, aren't we? So our philosophy is a bit of an idealization, we just don't live up to it.

Is there some way we can find a measure of freedom that is good enough? The fact is that we live with a lot of implicit restrictions without worrying too much about them. If you tell your kid you're free to wear anything you want, eat anything you want, be anywhere you want, and do anything you want, except you can't burn the house down most kids would find that a very satisfying degree of freedom, despite the restriction. They would probably say well I wasn't going to do that anyway, all my toys would go up in smoke.

So what can we do about sustainability?

Freedom in its pure form is a wonderful thing, but it's not inherently sustainable. You can take something and compare it up against freedom and tell if it's free, but you can't use freedom to enforce freedom. That would be absurd.

The GPL model is sustainable. It offers freedom, but with the pragmatic twist that there needs to be some kind of force to keep the freedom in place. In that sense it could even be said to be more free, because the *accumulated* freedom over all people involved is higher than when one person has all the freedom and everyone else has none.

GPL freedom is isomorphic. If OpenOffice needs a way to open jpeg files, and the gimp already has code for this, OpenOffice can just take it. Then two years later if OpenOffice reads jpegs much faster, the gimp can take the modified code from OpenOffice and use it. Both parties have the same degree of freedom, and no freedom is lost along the way, the process is "lossless".

BSD freedom, on the other hand, is "lossy". If I get BSD code I have a lot of freedom, but the next guy doesn't. It's fairly well known that there is BSD code in Windows. And obviously, whatever Microsoft did with that code, they have no obligation to release their changes. So the code *was* free at one point, but it didn't *remain* free. Furthermore, even if they didn't change it one bit, if the original author is no longer around, Microsoft is still sitting on BSD code that is free for *them*, but it's no longer free for anyone else.

So what can we conclude from all this? Both license models make software free, but only GPL software is sustainably free. The BSD gives greater freedom, the GPL gives more freedom. Choose which one you value more.

For a more in-depth discussion see this essay, not only for itself, but also the many many references it contains to other relevant texts.

UPDATE: Alexandre Baron has written a French translation.

undvd: looking ahead. and back.

December 11th, 2007

When you decide to code an application in a problem space that already has a rich bouquet of solutions the typical questions come to mind immediately. What is this going to accomplish? Why not just use an existing application? Why reinvent the wheel? Perfectly valid concerns, and yet every application has some reason to be, or it wouldn't exist in the first place. Sometimes it's a question of timing - better solutions did not exist at inception. Sometimes it's about quality: that one over there works but doesn't do it well enough. And sometimes it's something different altogether. That one does too much and I don't understand it.

There are people out there who are proper movie buffs. People who can quote lines out of a movie and identify passages to extreme detail. I've known a bunch of people like that, but I've never been like that myself. To me watching movies was never a really important thing, it was kind of a second tier interest. But knowing people like this has its advantages, you can borrow their movies. I remember how we used to lug around VHS tapes at school.

So my lack of outright passion about movies is really the reason why I never took after the dvd ripping crowd. When DVDs were fairly new, people were so excited about divx. My friends at school used to discuss bitrates and filesizes. I didn't follow any of that, I wasn't really interested. I didn't have a DVD drive, nor did I think paying 38 for a movie was such a good deal.

But admittedly, ripping the occasional movie is useful. DVDs in general are just a hassle and I don't like to put up with them. Back in those days (a few years later, when I had bought my first dvd drive for my first custom built computer) I would try it a few times. I didn't mirror the excitement of my friends. It took a really long time to rip a movie, and the result wasn't that good. I don't know what I was doing wrong. We used the Gordian Knot suite and followed the guides on Doom9. But while the program gave me every possibility to tweak the settings, I didn't know what they mean, I didn't *want* to know what they mean, I just wanted to rip it and move on.

And that is precisely the point where undvd comes in. I've tried a bunch of tools for ripping DVDs. dvd::rip might be the most merited linux tool. There's also acidrip and a bunch of others I don't even remember anymore. All these tools had the same two flaws:

  • They present a lot of options that I don't know anything about, and I don't care about. And presumably, since my results were never very good, these are crucial for good results.
  • It takes anything from 15 to 45 minutes to actually set up all the options, inputs, outputs, filters, cropping, the whole shebang. When something fails, like the disc can't be read from, the tool sometimes crashes. If it does, all your set-up work is lost. But even if you have a working setup from before and you want to rip another movie you still have to double check all these settings, because ripping takes a long time and if you mis set something by accident you may only discover it far along the way.

Therefore, I think it's fair to say that we have the Photoshop of DVD ripping in place. Personally I want to use Paint for this activity, because I have no deep interest in all the details.

Making it work

So if there is something complicated you have to do again and again, and every time you worry that you'll get it wrong and even if you get it right next time you probably don't remember what you did again. Faced with that, what do you do? In the middle ages monks would copy books by hand, at extraordinary effort. Not only would they transcribe the text, they would also copy and enhance the illustrations so that the copy, while not being the original, would be no less worthy. This was their calling, transcribing was an art form. Then came Gutenberg. Now granted, building a printing press took a lot more effort than transcribing a book. But once you had done that, copying books was a no brainer.

To me ripping a DVD is not an art form, it's a chore. And if I can figure out how to do it once and never have to worry about it again, then it's well worth the effort. So I set out to figure it out, I looked up the details and read the fine print. Eventually I had a fairly good idea of how to do it, and the results were coming along.

undvd became the wrapper around that nastiness I didn't want to look at or remember. And for my money it worked well. It also encompasses certain design decisions that were important to me.

Why no gui?

The Photoshop rippers all come with a gui interface. That's hardly a surprise, the plethora of settings they allow you to fiddle with would look like mplayer's list of options if they weren't gui apps. It's practically impossible *not* to have a gui for those guys.

But DVD ripping is not inherently a gui centric activity. You need the gui to write your missile launch plan, but once you start ripping the gui doesn't serve any purpose anymore. It just sits there in memory, and you could just as well remove it while ripping and then bring it back once it's over. So 95% of the time the gui isn't being used.

Apart from the simple fact that coding a gui is a lot more work, I consider a gui a hindrance in this case. There is nothing a gui would do for undvd that would improve how the program is being used.

Why not interactive?

There are some non-gui rippers/encoders out there, like h264enc and ripdvd (and probably a bunch of others). Common to them is that they run interactively. They ask you a series of questions to determine everything they need to know about ripping the DVD before they can start doing the work.

Unfortunately, interactive mode suffers from the same problems that a gui interface does. You have to answer all the questions whether you know what to answer or you don't. And more importantly, it's hard to reproduce the result, because you don't remember what you answered the last time.

And crucially, an interactive program won't let you just run it and go do something else, you have to stick around to do your part before the app will do its part. With a ripper this isn't such a big deal, because all the interaction happens at the beginning, but it's still something I like to do without.

Why bash?

The standard way of building a ripper is to wrap an interface around the scary mencoder command line interface. Whether this is a gui or not has no impact on how the ripper interacts with mencoder. There is no programmatic interface to mencoder, so you're stuck running it from a shell one way or the other.

Taking this into account, a bash script is pretty much the easiest way to handle shell commands. (If you're a perl nut, perhaps that would suit you better, but I'm not.) I've tried running commands from python (and using it to capture the exit code, stdout, stderr etc), and it's far easier just to use plain bash.

As a self imposed restriction, it will also keep the program from becoming too big. Bash is not exactly the greatest abstraction language and takes quite a bit of discipline to keep it from getting totally convoluted, which is why I would not use it for anything bigger than a simple application.

Feature creep

Unfortunately, every program that evolves will face the issue of new features. Personally I think undvd does what it does well enough, I'm satisfied. But any one-size-fits-all strategy is bound to be somewhat constrained. The question is where to stop?

Two things came up that weren't intended for undvd:


To start off with the first issue, undvd makes the assumption that the output video will be smaller than the original. This is fairly sensible, given that most rips are done this way, and considering that 6x compression does demand a lot from your encoder unless you compromise a bit on dimensions. Crucially, even if you watch a movie full screen the software/hardware scaling does a good enough job of stretching the image without clobbering it. Having said that, undvd's decision to scale to 2/3 of the original size is arbitrary and I accept that it's not a well justified constraint.

So scaling will be added.

Bitrate and 2-pass encoding

The bitrate issue, on the other hand, is hairy. Very hairy. I kept thinking about a meaningful way to set the bitrate. The obvious thing is to make it an integer parameter, like say 1000kbps. But what is that? It's just a number, a meaningless number. The "right" bitrate differs from movie to movie, from codec to codec, perhaps even from encoder to encoder. We are back in Photoshop land.

So I follow the convention of setting a file output size instead. If you say you want this title ripped to a file of 700mb, the bitrate is calculated automatically. This method is flawed, however, because the size we can accommodate for the video depends on how much space the audio requires, and there's no way to know this exactly. (Currently the mean audio bitrate is presumed 160kbps.) So the output size tends to come within 10% of the user-specified size.

The thing is, if you start messing with the bitrate you should also consider 2-pass encoding, because you can mess up your video quite badly that way. undvd tries to do "the right thing" by picking 2-pass encoding if the calculated bitrate is below the default. But you can always override to 1-pass or 2-pass whatever the case is.

In any event, if you don't use these new options then undvd does exactly what it always has.

And now for some screenshots

what makes RoboCop such a great movie

December 9th, 2007

Some works are just.. the only ones of their kind. RoboCop is such a work. The first of the series dates back to 1987; the last, to 1993. Altogether the three movies form a body of work that stands out from the plethora of supposedly similar works, action movies, cheap-story-big-boxoffice productions. It is simply.. art.

On the face of it, RoboCop is a lame story about the decay of society as a pretext for violence. The world portrayed in the story is dystopian, there are raving bands of hoodlums, there is organized crime, social order is all about defeated. And it's a cold world, filled with cruelty, void of compassion, a world of desperation. And above all, a world where corporations have taken over.

In this world, the dead police officer Alex Murphy becomes the cyborg RoboCop. A robot with a half-human mind, preserving some of his memories and emotions. But programmed by the powerful Omni Consumer Products (OCP) corporation to obey the directives he has been given. Essentially a killing machine, but a somewhat restrained one. Imagine a slow thinking, emotionally numb human, in terms of decision making.

Irony and comedy

But appearances can be deceiving. Sure enough, there is enough gunfire to go around, but the writers saw no reason not to have a little fun with the story. Picture your average worker stuck in a dead end job who has to pretend he's taking it very seriously, but when the boss isn't standing over him, he finds ways to amuse himself.

In order to drive home the point of a violent world in need of an enforcer like RoboCop, we have Media Break, the news program that reports nothing but violence. Since the writers already had this means of narration, they decided to put in some commercials as well, just like on real tv. These ads are wonderfully ironic and humorous. One is for a board game called Nukem, showing your average family sitting around a table playing wargames, where the culmination, of course, is the nuclear strike that wipes out everything.

Another ad goes like this:

*attractive woman by the pool in a robe* They say 20 seconds in the California sunshine is too much these days. Ever since we lost the Ozone layer. *takes off robe, now wearing a bikini* But that was before Sunblock 5000. Just apply a pint to your body *stars smearing herself with an opaque blue substance* and you're good for hours. See you by the pool. *by now completely covered in the blue stuff*

But there are other humorous angles to it. Take how RoboCop, who is by no means the brightest intelligence, suddenly develops deep sensitivity, so that when the little girl says she misses her parents, and he scans his data to learn that they were killed in the riots, he decides not to tell her. For a robotically enhanced killing machine he's also quite polite (compared to the humans around him), never curses people, the worst he ever called anyone is scum. In a rather unfortunate reprogramming mishap he even becomes politically correct, condemning wrong doing by lecturing delinquents rather than arresting them. Then, in a risky act of self-sacrifice he electrocutes himself to restore him own judgment.

Or take how in order to wrap up the story (whose premise it is that the OCP corporation controls the world) in some fairly definitive way, the writers decided that an unannounced, amateur broadcast of 2 minutes over the corporation's network would result in OCP's stock to drop to zero within 5 minutes. Problem solved. Then, just as we remember from The Karate Kid, Part II, the powerful owner of the Japanese company which absorbed the OCP in a hostile takeover came out to meet the people who had valiantly defended themselves against their corporate aggressors, decided he had made a mistake and paid tribute to them.


For all the parents out there on the fence about whether they should let their kid go see RoboCop, there is plenty of educational value in these movies.

Lesson #1: Crappy tv commercials never go away

That commercial with the bald guy and the hookers who says "I'll buy that for a dollar" appears several times in the first movie, and reappears in the last one.

Lesson #2: The success of the corporation is the suffering of humans

The big, evil corporation OCP is plotting to tear down all of Detroit to replace it with some sort of high tech metropolis called Delta City. But before that can happen, goes the story, crime must be brought under control. They even deploy their own special "security force" to speed up the process. And they own the police, so they can tell them what to do. The only incentive for any corporation is more profit, which means ever decreasing freedom for the average person, and ever increased in-fighting inside the corporation itself. Another movie that explains this is in great detail is The Corporation, so have that one ready when the kids start asking about it.

Lesson #3: Media is run by corporations
Media Break is driven by an agenda to be a scare mongering institution, a propaganda device. All they ever report is violence domestically and violence abroad. This is exactly like modern day media institutions which have lost all credibility and only pander to corporate interests. CNN, anyone? But at least Media Break has more of a conscience, as one of their reporters walks out in the middle of a newscast because she can't stand to dish out the misinformation.

Lesson #4: A system can only be secure when it's physically secure

Over the course of the three movies various people get their hands on RoboCop and reprogram him. In the third movie the little girl even plugs into the ED-209 robot using her laptop and makes it friendly to the rebels. This is the truth about computer security that everyone knows. If your system is physically compromised, you can't trust it. Sending a robot out into the world gives everyone access to it and they can plug into it just like you do at the lab.