While I had stay at work all night until the morning, I really didn’t do much besides get Mephisto up and running again. This all started because I got sick of the Scribbish theme (which is, nonetheless, a great theme—I dig the hAtom support). I tried to install the Clarity-Orange theme but because Safari irritatingly always decompresses files, I ended up with a folder instead of zip file.

So I try to recompress it, but since I’ve forgotten what switches to set so that things get zipped recursively, and because I was too lazy to RTFM, I ended up uploading a borked file.

But instead of realizing that the recompressed file was borked, I ended up surmising that my version of Mephisto was too old (close, but not quite, 0.8) and tried to upgrade.

In reality, the upgrade went without a hitch. Because Hosting Rails has a git client installed, all I needed to do was follow Patrick Lenz’s directions on how to setup a local git repository to simplify upgrades to Mephisto.

Unfortunately, I had forgotten there was some funkiness with getting Image Science to work as a thumbnailer. A tweak to config/environment.rb may be the solution, but I’m too exasperated to try it right now. I ended up disabling thumbnailing instead.

The last thing to do was restore my database, which I had accidentally deleted during this fiasco. Luckily, I had the foresight to back it up before messing around with anything. Unfortunately, I couldn’t do it from work since it’s sitting on my system here at home. Fun times!

For “fun”, I decided to try and build rpm5 on top of Fink. The ostensible reason was that I wanted to extract a source from an SRPM. It would be pointless and would probably bork my system if I tried to use RPM and dpkg simultaneously. But mostly, I just wanted to see if it could be done.

After several hours, many of which involved banging my head upon my desk, I managed to get it to build. It has a ton of dependencies, and beecrypt doesn’t exist in Fink. In the process, I ended up updating a few outdated packages in Fink.

WARNING: These are extremely experimental and may very well destroy your file system. Don’t say I didn’t tell you so.

1. beecrypt 4.1.2 (crypto/finkinfo) – beecrypt.info – beecrypt.patch
2. sqlite3 3.5.6 (main/finkinfo/database) – sqlite3.info – sqlite3.patch
3. neon 0.28.0 (main/finkinfo/libs) – neon28.info
4. libxml2 2.6.30 (main/finkinfo/libs) – libxml2.info – libxml2.patch
5. popt 1.13 (main/finkinfo/libs) – popt.info
6. db46 4.6.21 (crypto/finkinfo) – db46-aes.info
7. rpm 5.0.2 (main/finkinfo/util) – rpm.info – rpm.patch Counter to the recommendations of the RPM development team, I used the external version of the Berkeley Database in a futile attempt to circumvent the libtool bug that continues to plague even libtool 1.5.26, namely the inability to install to a staging directory without causing grief within the *.la files. I ended up replacing RPM’s ltmain.sh with the one from libtool 1.5.26 and adapting some of the patches supplied by the Debian libtool package. It looks like the Fink validator is now happy. And so far, I can at least run rpm --version without segfaulting. I have yet to see if I can do anything else with it.

I looks like the version targeting debacle is still very much a heated topic.

Instead of Microsoft forcing people to stick cruft into their code, there’s an alternate solution. Allow multiple versions of IE to co-exist.

The solution seems so much simpler than creating bizarre tags and resurrecting the ugly practice of browser-sniffing that plagued us during the Netscape/Microsoft Browser War, clogging our bandwidth with crufty, convoluted Javascript and redundant HTML tags.

Admittedly, neither Firefox nor Safari make it easy to have multiple versions of themselves to exist on the same computer, but it’s not impossible.

For Firefox, all you really have to do is create multiple profiles. (The post details how to do it in Windows and Linux, but you can do the same thing Mac OS X, you just have to run the actual binary from the command line the first time you launch.)

For Safari, it’s a little bit trickier. Michel Fortin provides Multi Safari, where you can get every non-beta version of Safari that has been released. (Unfortunately, you have to muck around with the command-line to get it to work on Leopard, and I don’t even know if versions less than 2 will actually work at all.) An alternative would be to actually build Webkit. (The source code is available back to r25668 from around September 2007, although unfortunately I’m not sure what version of Safari that corresponds to.)

Both of these approaches are really moot, though, since the goal of both browsers is full standards-compliance. It would be perverse to rely on a bug from older versions of Firefox or Safari. These approaches are probably more useful for people who want to try the bleeding edge browser while keeping their stable browser intact.

Now I realize that Microsoft is not one to give into open-standards committees or the open-source community. (Just look at the OOXML imbroglio, and the still ongoing saga of SCO, a subsidiary of Microsoft that tried to claim that Linux infringed on their IP.) But instead of mutilating the Internet, they could make version targeting go away completely by allowing the peaceful co-existence of IE6, IE7, and IE8 on one machine. Hell, Microsoft wouldn’t even to do that! They could just allow a user to keep whatever broken version of IE they want instead of auto-upgrading to IE8. Then if you needed to, you could just run a virtual machine for testing (since Mac OS X users have to do this already in order to test any version of IE.) No version targeting needed. What say ye, Bill GSteve B? (Not to be confused with that Steve. Nor the other Steve.)

I agree that Microsoft should have to deal with their own backward-compatibility quagmire without burdening web developers. The author brings up the IE-dependent components of Windows and other legacy, propietary software solutions (for example, the emergency department at one of the hospitals I work at uses an IE-dependent computerized physician order entry (CPOE) and charting system) and these are less trivial to upgrade to standards-compliance than a web site would be.

But why bother web developers with having to add kludges to their already standards-compliant code?

What Microsoft will probably need to do is continue to support two modes of operation: (1) legacy-brokenness and (2) standards-compliance. The default will have to be legacy-brokenness because, as the author of the article points out, it may not be trivial to add meta tags to legacy code. IE8 will probably have to continue relying on DOCTYPE declarations to figure out if it needs standards-compliant rendering.

While this may seem to be just as burdensome to web developers, at least it’s already a documented standard. And while it may seem to tacitly acknowledge IE6/IE7 as the de facto web standard, the browser scene is no longer hegemonically dominated by Microsoft, with the emergence of Firefox, Safari, and most importantly, web browsers that run on mobile phones. Anyone today who develops a site or webapp explicitly for IE6/IE7 is asking for a stream of angry phone calls about their site or webapp not rendering properly on the growing number of non-IE platforms.

Jeff Croft brings up version targeting again, and casts it in the old “The Right Thing™” and “Worse is Better” debate.

While I still think version targeting is a stupid idea, my opinion is certainly not going to stop Microsoft from putting it in IE8. I predict that they will. But from the developer’s stand-point, the issue is still the same: do you put up with Microsoft’s bugs and broken design? Or do you code for the masses, and avoid this sort of kludgery and stick to the standards? (Because if you’re coding specifically to IE6, then you’re screwing all the Firefox and Safari users out there, and while 15%—give or take—may not sound like that much, that’s going to be about 150 million computers (assuming an estimate of 1 billion computers by the end of 2008). Most businesses would not choose to ignore this many potential customers. Hell, I’m sure even Microsoft is keeping an eye open as that number continues to creep up.) In addition, you are also screwing people using IE7 and early adopters of the erstwhile IE8.

The key question is, will Gecko and Webkit support version targeting? My suspicion is no. As far as I can tell, neither engine has ever tried to emulate the brokenness of IE6. And why would they add such cruftiness to their code base anyway?

So I actually don’t think it’s going to be that big of deal. The only people who really need it are developers too lazy to fix their sites to be standards-compliant, and who are continuing to rely on IE6’s brokenness. So basically these sites will only run on IE6 and IE8 and nothing else, not even IE7. They certainly won’t run on your Symbian-based Nokia, your Blackberry, your iPhone, *or* on your PSP or Nintendo DS. Ridiculous.

Face it. IE6 is going to end up on the trash heap of obsolescence just like everything else has. But as long as you’ve got access to open source code repositories and a compiler, you’re always going to be able to view a web page in Firefox 2.0. So don’t worry about document obsolescence. Backward compatibility isn’t the holy-grail everyone makes it out to be. If you’re going to upgrade, do it right, get rid of the cruft, and don’t look back! If you’re not, stick with tried-and-true technology (that doesn’t have bugs—so IE6 doesn’t count.) No one, not even Microsoft, can make you upgrade.

ADDENDUM 2008 Jan 26 at 5:27 pm:

I really don’t understand the rationale for breaking the web with version targeting. Look, you can still read websites designed in 1996 in modern day browsers. It’s not pretty, but at least there’s some sort of content. But you’ll also notice that these sites have since revamped their markup. That’s the real solution to version number inflation: revise, revise, revise. You can be as forward thinking as you want to be in 2008, but once 2038 rolls around, when the world-wide web as we know it has ceased to exist, and all your data is floating around in holographic form around you, and everything including public toilets and washing machines has a kinetic or tactile interface that makes the Nintendo Wii or the iPhone look clunkier than the ENIAC, it’s gonna suck ass if you’re forced to downgrade your experience to IE6 because of some stupid version tag.

On the other hand, when 2038 rolls around, and you want to reminisce about the early 21st century, I’m sure you’ll have an emulator for the obsolescent x86 desktop experience for which you can still download and install moldy copies of ancient versions of Linux, and therefore, you can still experience the early 21st century blogosphere the way real geeks surfed the web and launch Firefox 2.0 on your virtual (and probably holographic) machine.

All without version targeting. How about that?

The crux of the eternal static versus dynamic typing debate is just how much are you willing to let the computer (or more accurately, the language implementers) decide what you mean. Those who favor static typing tend to favor explicit direction over implicit intuitive understanding, and strictly-defined categories and hierarchies rather than free-for-all tag webs and interconnections. The static typist immediately recognizes that the computer (specifically, the compiler or the interpreter) is a non-intelligent entity that must be told exactly what to do, or else you’re liable to saw your own foot off. The dynamic typist, while not delusional about just how intelligent the computer is, is willing to have a little more faith in the language implementers, believing that they will do the Right Thing™ with the input that is fed to them.

It is apt that most dynamically typed languages are interpreted. It is not just metaphoric that the most important part of the interpreter is the parser. What I believe the goal of dynamically-typed languages is to be able to take input from a programmer, and output machine language that does pretty much what the programmer means. In other words, interpreters of dynamically-typed languages need to be able to understand human idioms.

This is intrinsically more likely to result in unexpected behavior, but we aren’t talking about obvious operations like addition or concatenation. We’re talking about more abstract things, like how certain tables in a database should be related to one another, or what to do with that extra parameter when the object passing a message isn’t expecting it.

The static-typist is most comfortable with telling the computer exactly what to do in these circumstances. This can be a time-consuming, and error-prone activity. The dynamic-typist is probably more willing to let the language implementers make these decisions, with the knowledge that what you thought you put in may not be what the interpreter actually thinks you put in, resulting in perhaps wildly erroneous output (but not a crash!)

Some authors comment on the fallacy that we’re talking about the difference between strong typing and weak typing. For example, any language that lets you implicitly cast between different types is de facto a weakly-typed language, and the most popular statically-typed languages allow you to do just that.

So the real axis is static vs dynamic typing.

But I think another level on which to think about these things is the difference between brittle handling and flexible handling.

In the day and age when we have clock cycles to spare, with CPU cores running idle, I think we should really expect more of our computers. I really think that computer programming should be more tolerant with bad input. I’m not saying that a compiler should just ignore syntax errors, or let a grossly mis-cast variable go ahead and ruin your stack, but language implementers really should start using all this extra CPU time we have. Capabilities like self-reflection are the beginnings of this.

Now it all makes sense.

Apparently, the trend for all computer languages is to approximate Lisp. And, at least today, Ruby is as close as you can get without having to use recursively nested parentheses.

The interesting thing about Lisp is that is was designed to be notation rather an actual programming language. Lisp was intended to be a systematic way in which you can describe a Turing Machine. In other words, it was meant for communication, specifically, from one human to another human, and was not just meant to tell a CPU how to spin its registers.

While people talk about the elegance of lists of lists (and it is elegant in its way), what I find most intriguing about Lisp is its human language aspect.

One can argue that perhaps car and cdr are not the most transparent things in the world, but I think it’s not for nothing that Lisp is associated with AI in the minds of we who have a bare inkling of it. In truth, the most I have ever been exposed to Lisp is random dabblings in Scheme, and my time spent screwing around with Logo.

With Logo, the language aspect thing always intrigued me. Like I mentioned, I had long been interested in writing a text adventure game—interactive fiction. And parsing of natural language is one of the things that lists of lists are good for handling. But it ended up way beyond what my 8 year old brain could handle, so I moved onto procedural languages, which were easier to grok.

And interestingly, the whole thing with the Lines of Code issue is not necessarily LoC per se, nor is it even necessarily complexity. The issue is what I would call semantic density, and it’s related to the sociolinguistic concept of context-dependence.

In the end there is a trade-off: the potential ambiguity of implicitness for the tedium of explicitness. —JA Robson’s comment on ”Size is the Enemy” on Coding Horror

This is the difference between languages like Ruby and Perl versus Assembly/C/Java, and it is related to the difference between Mandarin Chinese and English.

The thing to remember is that, while most people just think of a programming language as a way to tell the CPU what to do, in reality, it is just as important as a way to communicate your intent and your formulation of concepts to whoever else might have to maintain your code.

Particularly in this post-modern world, where everything worth doing has already been done, and all the clever algorithms have already been formulated, trying to re-invent the wheel is an exercise in futility.

This is probably why Lisp has such appeal. Ultimately, it is a human language for talking about computer algorithms. This is where it gets a lot of its power: it leverages the existing language of mathematics.

Steve Yegge’s rant about huge code bases and how Java exacerbates the problem is definitely circulating the internets. Jeff Atwood at Coding Horror chimes in and agrees wholeheartedly.

I recall running into static typing issues making my code unnecessarly verbose back when I was using Turbo Pascal. (Mostly because you had to declare how long strings were, and because of the way you had to declare records/structures, you might even have to create classes of certain string length, like String80 for an 80-character string, and String78 for a 78-character string.) But the issue really isn’t typing. True, I do believe static typing tends to add nearly meaningless, semantically sparse lines to your code, but if you think about it, most of the popular interpreted (i.e., scripting) languages are actually strongly typed as well. In Microsoft Basic 2.0 (the interpreter that the Commodore 64 used), you declared type by appending a special character, so you always knew that A$ was a string, A% was an integer, and A was float, and that was all you really had, unless you counted arrays, which were made up of these base classes. In Perl, $var is a scalar (which can be a string or a number, to be sure, so maybe it’s not that strong in terms of typing), @var is an array, %var is a hash. And while Ruby doesn’t really use these markers, you have to explicitly re-cast Integers to Strings (using tos) or to Floats (using tof).

So typing doesn’t have anything to with it.

I think what the problem is, is that most people don’t construct sane objects.

Sometimes the problem lies in the base classes of the language. There may be too many redundant classes—similar but not-quite-the-same—and you end up having to figure out which methods can take which objects, and sometimes you end up writing all sorts of kludgery to use the objects you want and process them with the methods you want—because polymorphism in C++ isn’t all that it’s cracked up to be.

Sometimes the language isn’t quite completely object-oriented, and a lot of the idiom is still procedural in style. A lot of these languages had OOP grafted onto them, when their lineages are clearly from procedural languages. (Perl is certainly evidence of this, as are ObjC and C++)

On the other hand, it seems like most of the coders who disagree with Yegge and Atwood are more into procedural code, and some are even overtly hostile to OOP. I think part of the problem lies in the fact that a lot of people ended up learning OOP through C++, which, from what I remember, isn’t much fun. It was easier to write kludgy C than it was to deal with C++’s class system.

The other thing is that it seems like it’s really difficult to tailor your classes to the functionality you want. While most OO allows polymorphism, this isn’t quite exactly what you need. I feel like the right solution to the problem of creating subclasses is to either go the ObjC/Smalltalk way, and utilize message passing, or go the Ruby way (which also allows message passing,) and utilize mix-ins.

The way to decrease the number of lines a developer needs to write is to come up with intelligent (not just intelligently-designed) base classes and interfaces. So when you throw a not-quite-right object at it, it won’t just crash-out, and it won’t perform completely unexpected and often destructive operations. The idea of self-reflection is a step in this direction. Rails uses this to its advantage (as does ObjC and Smalltalk, from what I understand.)

Ultimately, you have to choose: do you want to control the means, or are you more interested in the ends? What assembly and C allows you to do is control explicitly or almost explicitly what the machine does. I believe this necessarily has to come at the expense of the end results. In contrast, semantically dense OO systems like Smalltalk and Ruby are good at delivering the end results as you intended, but you have very little control over what algorithms are used to actually deliver the results. This is the reason why C is often touted as the epitome of speed: every command translates easily into the appropriate machine code. Whereas interpreted languages inherently have a lot of overhead, and a lot of indirectness, but it’s easier to get from point A to point B.

Not sure where exactly this entire weekend went. My mind feels like it’s been liquified, and I’m not sure if I’m coming down with something, if I’ve grown allergic to my parents’ dog and my sister’s dog, if I’m suffering from really severe caffeine withdrawal, or if I’m quite possibly losing my mind.

I’m playing around with SimpleLog’s theming engine. I haven’t quite figured everything out, and I realize this theme looks pretty rudimentary. But I’m digging on the simplicity of Helvetica.

To do:

• figuring out how to create a complete archive list in the sidebar. As an example:
  • 2007
    • November
    • October
    • September
    • August
    • July
    • June
    • May
    • April
    • March
    • February
    • January
  • 2006
    • December
    • November
    • October
    • September
    • August
    • July
    • June
    • May
    • April
    • March
    • February
    • January
  • 2005
    • December
    • November
    • October
    • September
    • August
    • July
    • June
    • May
    • April
    • March
    • February
    • January
• making a list of tags
• adding my del.icio.us entries (using javascript, I guess)
• adding my Google Reader entries
• lots of additional tweaking to the CSS
• turning the horizontal rule \

  ---

  into a fleuron

I went home to L.A. this weekend because it was my Dad’s 64th birthday. (That Beatles’ song pops into my head.) We didn’t really do much except eat at Tony Roma’s.

I think maybe the fact that the sun hadn’t come out for like six days was really getting to me. I started feeling really weird today when the sky completely cleared up.

The other night while lying in bed I had this weird sensation of intense pain in my chest that I knew was purely psychosomatic. It was just this feeling of incredible loneliness, made manifest as physical pain. Somehow, I managed to ignore it, and was able to go to sleep, instead of ending up ruminating on all the wrong turns of my life, and remarkably, I was fine the next morning.

I don’t know. I’m too frazzled and fried for some reason to write coherently. I’ll try again tomorrow.

Yikes! Programming for Windows definitely has some harrowing pitfalls.

I’m reading about how Windows manages file locking (inspired by an article describing the FILESHAREDELETE flag) and find it mind-boggling. Not that file locking in UNIX isn’t complex, but I guess it’s more familiar to me since (1) UNIX was assumed to be the OS you were using in all the self-paced computer science classes I took as an undergrad and (2) I’m currently using a UNIX-like OS.

I know that it sounds like a cheap bash on Windows programmers, but it still surprises me that some of them write code like it’s 1989, with the assumption that their program is the only thing running on someone’s system. Kind of makes a pre-emptive multitasking OS useless, if you ask me. Still, I guess that’s what happens when you have to preserve backward compatibility to MS-DOS. Now, I’m just as nostalgic about the 8-bit golden age as the next geek, but I wasn’t quite expecting it to show up in modern day code.

Now, don’t get me wrong. I’m not a developer. The extent of my hacking history lies in the good old 8-bit days when I was hand-coding machine language programs into BASIC DATA statements. I learned, of all things, Pascal (which happened to be the programming language tested on the AP Computer Science test) and tried to muck around with C and C++, but eventually gave up with that and ended up learning Perl instead.

I once wrote an extraordinarily kludgy medical record-keeping application for my dad in Turbo Pascal 5.0 (He still kept hard copies of everything anyway, thankfully) and when I used to work as a medical biller, I wrote a little script to help me keep track of things in Visual Basic for Microsoft Office(!) which rapidly turned into a nightmarish, molasses-like application experience.

So I’ve never really written a program that anyone has (exclusively) depended on, and I did very little bug-fixing, and much less optimization.

I can only imagine what it means to be involved in a massive corporation working on a little subroutine or object class that happens to be crucial to the project, and hoping that it’s well-implemented enough and documented well enough that it won’t bring the entire project crashing down.

On the flip side, I gave up on Windows in 1999, and most of the apps I use are Open Source, or at least based on Open Source. From 1999 to 2002, I was running Red Hat Linux as my main OS, until I decided to get a laptop. (At the time, Linux support for laptops kind of sucked. It would’ve been a major pain in the ass, I think.) I couldn’t stomach the idea of switching back to Windows, so I bought a Mac.

The irony is that as an undergrad, I was a proponent of x86-based hardware, and thereby staunchly against the very proprietary nature of Macintosh hardware. Now I don’t think I ever thought Windows was “cool”, but me and my roommate would have Mac vs. PC arguments all the time.

The other issue I had with the Mac was it’s GUI-only nature. I had grown up on the command-line, and I couldn’t (and actually still can’t) fathom the idea of interacting with your computer only through a mouse. (Even as I type this, I have a few terminal windows open in Mac OS X. It’s still easier for me to hit Cmd-Tab, type cd ~, and then open some-file—using command completion in zsh—than it is for me to click on the Finder icon, navigate to my home folder, scan the thousands of unsorted files sitting there, and finally double-click on it.)

But bizarrely, it was Linux (along with X and GNOME) that taught me to love the GUI. You could do all sorts of weird stuff with the various window managers available, like have windows resize to set dimensions (useful for previewing HTML at small screen sizes) or automatically having all your windows roll up and stack themselves in a line on the right side of the screen. It was a matter of a few mouse-clicks to get a window to stay at the top of the pile, no matter how many other windows you opened up. I also grew dependent on multiple desktops (the fact that this is missing in Mac OS X is only made bearable because of Exposé.) And at the time (in the summer of 2000), GNOME had the only open-source web browser with tabs (Galeon), a feature that all modern browsers now have, and which I can’t use a browser without. (IE 6?! Bleh. Bleh. Bleh.)

The only thing that made switching to Mac OS X palatable was the fact that it had an entire UNIX subsystem running underneath the pretty GUI. Meaning, unlike Mac OS Classic, you could drop out into a terminal, and navigate and manipulate your filesystem with little cryptic commands like cd, ls, find, xargs, and grep. And meaning that you could (1) run an X server and (2) compile all the apps that I was using on Linux and use them on the Mac. For a while, Galeon still remained my browser of choice (until I found Camino, neé Chimera)

But X is a hungry beast, and after a while, I got tired of hard drive thrashing, and I couldn’t afford to buy more RAM. So eventually I settled into Mac OS X proper. Right now I have seven applications up, not counting the Finder or the Dashboard: (1) Mail.app (2) Vienna (3) Safari (4) iTerm (5) Chicken of the VNC (6) VLC (7) Preview.app. Five of these seven are open source projects. All of them have equivalents on Linux and Windows (with Cygwin installed.) As you can see, I’m not a big fan of proprietary software. (Hell, I grew up in a time when people would type in huge programs from the back of a magazine, sometimes entirely in raw machine language—just strings of unadorned hexadecimal numbers. My word processor of choice on the Commodore 64 was Speedscript, which came out of the back of Compute!’s Gazette.)

What inspired this rehashing of my own personal computing history was this post on The Old New Thing discussing a very poorly thought out function called IsBadXxxPtr which supposedly tells you whether or not a pointer is valid or not.

And frankly, I find it astounding. Not so much that these functions exist, because they are probably useful to somebody somewhere trying to debug something. But that these functions would be allowed to escape into production code, resulting in a situation where you can’t just get rid of these functions without breaking apps.

I try to figure out why this should be so, and why such practices never make it into production UNIX code (other than the fact that the standard APIs don’t have functions like these.)

Is it because there are so many Windows developers, in contrast to the number of *nix/Linux/Mac OS X developers? That maybe these kinds of kludgy functions exist in core APIs, but they can be easily deprecated because not that many apps actually rely on their bad behavior? That the apps that would break wouldn’t cause a massive uproar?

I don’t know. I feel like backward compatibility is overrated. If you want to stay compatible, then you shouldn’t upgrade your system. Problem solved. I mean, people still run CP/M and VAX/VMS, don’t they? There are probably even a few MS-DOS boxes floating around somewhere, maybe even connected to a network!

Meanwhile, the bleeding edge can throw out the baby with the bath water and actually innovate. And if you, as a developer, feel that you just can’t live without these new features, then you’ve got to rewrite your app so that you can compile it against the new API.

Isn’t this a massive reduplication of effort? Not necessarily. If you have clean code that is well documented, you might get away with just rewriting a few functions here and there.

This certainly reminds me of the general debate about Windows Vista. Microsoft could’ve pulled an Apple and they could’ve just scrapped all the legacy code and started fresh. And to keep the break from being overly traumatic, they could’ve done what Apple did with Mac OS Classic. They could’ve just turned the old Windows stuff into a stand-alone virtualized system. After all, they already own Virtual PC, so why not? Most people have dual-cores these days, and the other core just sits idly by, why not give it something to do? And maybe they could also have a compatibility layer (akin to Apple’s Carbon API) so that all those Windows developers wouldn’t have to just start from the beginning all over again, and they could continue to develop new apps that would run both on XP and Vista—natively, without having to run the virtualized Windows Classic.

All sorts of doom and gloom was predicted when they abandoned Mac OS entirely and adopted Jobs’ baby, NeXTSTEP, which much of OS X is based on. But that’s now ancient history, with Apple making yet another jump (albeit this time on the hardware side.) And how many people still write Carbon apps these days?

But a lot of these problems stem from the fact that, despite being nearly 40 years old, C is still the dominant language for developers. Sure, there’s C++, but is new and delete really all that different from malloc and free? Manual memory management seems like such a Sisyphean task. That’s why I quickly gravitated to scripting languages which generally use garbage collection. After all, I learned to program in BASIC, of all things. Commodore’s BASIC 2.0 was infamous for the incredibly long pauses when garbage collection was triggered, but I could live with that. I mean, it wasn’t bad for a computer running at 1 MHz.

In time, we’ll have a generation of coders who have cut their teeth on Java and C# and Python and Ruby, who won’t know or care about dangling pointers. Until then, we’ll have to continue to deal with the kludgy ways that developers utilize in an effort to avoid shooting themselves in the foot, and their crash-provoking consequences.

At the risk of sounding like a raving, gibbering Apple fanboy, I’ve got to ask, what’s up with all the FUD? [fear, uncertainty, doubt] First there is the paranoia about Apple tracking you through your DRM-less $1.29 downloads, and now there’s this big deal about no longer being able to convert DRM’ed AACs to DRM-less MP3s (discovered via boingboing.net.)

In summary, perhaps the easiest hack to strip the DRM from iTunes Music Store AACs is to burn the songs to disc, then re-rip them. Personally, I would re-rip them to Apple Lossless, because the songs are already cut-rate quality as they are, and re-encoding them into a lossy format like MP3 or AAC can introduce very subtle but very annoying artifacts into the sound. The corresponding Apple Lossless track is about 10x bigger than it’s AAC counterpart, but hard drive space is cheap, and who really needs all 7,000 tracks that can fit on a 30GB 5th generation iPod? According to iTunes, it would take me 42½ days straight to listen to all of my music without repeating a single song, and unless there really is gonna be another Great Flood coming our way, I think I’ll be OK with having a few hundred-or-so less songs on my iPod.

But I digress.

The concern is that in iTunes 7.2, for some reason, you can’t play the re-ripped tracks on your iPod. I don’t know if this was intentional or not. It sounds weird, though, because apparently there isn’t a problem if you re-encode the songs as DRM-less AAC.

Even if it was on purpose, all you would have to do is use another CD ripping program like LAME (or for the command-line-phobic, use Max instead) and then this would fail to be a problem.

Come on, people, buck up. Just because corporations are known for screwing people over doesn’t mean you can’t get up, work around them, and screw them back. No need to whine. Just stick it to The Man like the hippies did!

Still, the Apple fanboy in me is pretty skeptical that they did this on purpose. I want to see what iTunes 7.2.1 is gonna be like, first.

Man, that was an incredible waste. Three hours down the drain just to get a stupid RSS widget to work in Myspace. I wish that Myspace would just let me crosspost to their blog engine, but noooo.

It would probably be worthwhile to chronicle how I ended up having to write my own widget, and to document all the dead-ends I ran into until I settled on doing this, but, frankly, I’ve wasted enough time. Bleh.

In other news, the levels of procrastination to which I have risen no know bounds. I honestly need a swift kick in the ass. And I need to turn off this stinking computer. Damn.

Procrastination is like masturbation. At first, it might feel pretty good, but in the end, you’re only screwing yourself. —Anonymous

Hope? Don’t talk to me about hope. One day at a time, brother. One day at a time.

I found this a little bizarre. It’s on LXer, a Linux News site that tends to feature a lot of Linux zealotry and fanboyism.

But there is a project out there called Tux 500 trying to raise money so that they can have a car race in the Indy 500. Which is all fine and good. People are free to do what they want.

Any sort of exposure is can be helpful. I suppose.

But Linux is not some monolithic mega-corporation that has tons of money that they can just toss around like Microsoft or Oracle can. When these companies sponsor this kind of event, sure, they get a lot of eyes to see their company logo, but what exactly does this mean? Does seeing the Windows icon plastered all over the place really make you want to go out and buy a copy of Vista right now? Does seeing the Apple ensignia compel you to run to your local Apple store to line up now for your copy of Leopard?

Merely painting your logo on a car does not necessarily equal mindshare.

Good marketing is well-targeted and specific. You don’t see RedHat or Novell or any of the other big distros putting out TV ads because their money isn’t made from home users. In fact, I don’t see how you could possibly make money from home users, because they can download a distro for free off of the Net. What Linux companies target is the enterprise, and while random exposure could possibly catch the attention of some CIO out there who likes car racing, wouldn’t it be wiser for them to just go to the events and conferences where they can specifically target the CIOs who would be making OS and app decisions for their company? Getting a huge company to switch is likely to provide much more exposure than the twenty seconds that a blurry version of the Linux penguin will be flashed on the screen during the race.

Now the Open Source world has room for all kinds of people. There are the corporations out there interested in selling a good enterprise solution. There are the power users, the hackers, the crackers, the nerds, the masochists. There are the zealots and the fanboys. The guys who won’t settle for anything less than a free-as-in-speech OS. The folks who just want a decent desktop environment that lets you do all the things a Windows machine can do without all the blue-screens-of-death or all the Big-Brother pop-up dialog-boxes, and still cost nothing. The people who want Linux to take over the world. The demographic of Linux users probably cuts across all political ideologies, all religions, all nationalities, and so on.

But, c’mon. You can’t tell me that Free Software wasn’t built entirely on so-called Haight-Ashbury, Abbie Hoffman idealism (the turns of phrases utilized by a post addressing critics of the Tux 500 project.) Just read the freakin’ GPL. Meditate on the fact that without Richard Stallman, none of this would’ve ever have happened. Say what you will, but the ‘60's counter-culture has done much more to change the world than the Indy 500 ever will.

If you really want to give your money away to a cause that will allow you to continue using your computer without having to pony up $300 to Microsoft every five years or so (not adjusted for inflation), I think your money would be much better spent supporting the Free Software Foundation and the Electronic Frontier Foundation. Donate to Groklaw and stop MS from spreading their FUD.

If you’re really interested in making Linux a better desktop environment, help work on GNOME or KDE or XFCE.

The real draw to particular OS platforms are the apps it supports. If you want more apps worth running, why not participate in Google Summer of Code?

(For a more scathing criticism of the Tux 500 project, read ”and now for something completely stupid”)

The Old New Thing discusses the different macros you have to set in order to ensure library compatibility in Windows.

It seems like a complicated mess, but it’s not like Linux and Mac OS X are really all that better. Except for one factor: most of the time, you actually have the source code.

While Windows has multiple flavors, some of which can share code, and some of which can’t, Linux has at least a hundred different distributions, all of them running different kernels with different versions of the C libraries and with different versions of different toolkits (GTK+ vs Qt, for example) This makes it pretty dicey to try and mix and match binaries from different distros.

Since Mac OS X comes solely from Apple, you would think that you wouldn’t have to deal with such messes, but the fact is if you want to use the latest open source tools, you end up screwing around with various distribution mechanisms: do you just compile from source yourself and link against the system defaults, do you install Fink, or do you install MacPorts (neé Darwinports)?

But the fact that you have the source means that you can always have the latest version of the latest app in the open source world. Compile it yourself (or with the help of Fink or MacPorts on Mac OS X, or whatever mechanism you use on your flavor of Linux) and it will tell you which libraries you may need to upgrade (although this path can still lead you to dependency hell) And if you don’t have the latest version of Gtk+ or Qt or GNOME or KDE or Perl or Ruby that the app needs, you can compile that too.

Yes, compiling is a lot more time consuming than simply clicking on an installer, but you’ll always know that the app your running is compatible with your system and it’s own idiosyncracies.

And the maintainer only has to maintain a single code base with the minimum of versioning macros. You can compile exactly the same app on the hundred different versions of Linux, or you can compile it on Mac OS X, or any flavor of BSD, or even Solaris, AIX, or HP-UX. Hell, you can even compile it on Windows if you use Cygwin.

Now I realize that most end-users couldn’t give a damn about this, but I still think having access to the source code is a big deal.