The Integrated

Today, Google finally announced Chrome OS and showed it off a bit. It’s just as it was rumored to be and just as it sounds: the Chrome web browser basically is the OS. You turn on the computer and you get the browser, that’s it. All you can use are webapps. The idea is that most people spend 95% of their computing time using webapps and surfing anyway, so why not focus on that experience and streamline it. In the process, it aims to nix a lot of the issues that users have with their computers—a Chrome OS device will have a lot less going on under the hood than a traditional PC, so it’ll boot up faster and be immune to malware (since you can’t install ANYTHING on it, benign or malicious). Trouble is, the world isn’t quite ready to go webapps-only just yet. Even Google admitted during the press conference that they expect people who buy a Chrome OS netbook to keep their standard desktop or laptop system around for the things they can’t do on the web yet (or don’t want to). But honestly, I don’t think I would even install Chrome OS on my netbook. Looking at my boxen, this is a quick list of everything that would prevent me from switching from Windows to Chrome:

• Most critically, a Chrome OS box obviously won’t be able to be joined to a Windows domain. Whether I log on to my desktop or my netbook, I need to have access to my documents, and if I change a file on one it needs to be synced so that I’ll see the change on the other. Obviously logging onto the domain with a roaming profile accomplishes this; for Chrome, there would have to be a file-syncing service like Dropbox that works under Chrome without installing anything.
• Desktop apps that just aren’t replaceable yet. A few examples:
  • Photoshop. Granted, I only use this on my desktop because it would be unusable on a netbook anyway. Still, Photoshop is a beast of a program and it would be impossible for Adobe to create a web version with anywhere near the same functionality. (There is a “Photoshop” webapp but it’s nothing like the actual Photoshop CS4 software.) Javascript performance is going to have to get faster by an enormous factor before you could ever think of implementing many of PS’s features in the browser. Not to mention the colossal size of the high-DPI, hundreds-of-layers PSDs that professionals work with. I think this will forever remain an app for beefier Mac & Windows PCs.
  • Skype. A good videocalling webapp that meets or beats Skype’s ease-of-use and functionality probably could be done, but nobody’s done it yet. Google did just buy a VoIP company recently so maybe they’re working on it.
  • Microsoft Office. It’s still the de facto standard, and neither Google Docs nor Microsoft’s online Office suite can touch it yet. This one will go down fairly quickly though. Google is claiming outright that Docs will catch up next year (which, not coincidentally I think, is also when they expect to release Chrome OS).
  • KeePass (or insert your favorite password manager here). There are password manager webapps, but to be honest, I still don’t trust this data to the cloud. I have more than just passwords for websites in my KeePass database.
  • Games. Goes without saying, but they won’t ever run on Chrome OS and there’s no intention for Chrome OS to be used for gaming. This is also a primary reason why I’ll never switch to Mac or Linux. As long as I’m a gamer, I’ll be at least dual-booting Windows on at least one of my machines. (And if you think I want to go through the hassle of rebooting just to launch a game, you’re crazy.)

If Chrome OS is successful, it’ll be successful in pushing webapps forward to fill in a lot of these gaps and provide the features and tools that are missing so far. If that happens, and I would love to see it because this is actually the area I’m looking to get into with my degree, I can certainly see myself running Chrome OS on a netbook in the future. But we’re not there yet.

Netflix notified me today that my disc to activate PS3 streaming is in the mail. I was hoping Netflix wouldn’t be an Xbox-exclusive feature among the consoles. It’s nice to see them expand support. How long will it be now before basically every new HDTV, BD/DVD player, game console, or video device of any kind comes with Netflix built-in? I was a subscriber and a big fan of Netflix before they had streaming service at all, and now I’m just waiting for the day that I can turn off disc shipments altogether because everything is available on Instant Play.

For now, though, I’m using my computer monitor as my PS3 monitor on an HDMI switch, so it won’t be that different than loading up an Instant Play movie via the website; it’ll be interesting to see if there’s a difference in picture quality. But someday, I’ll have an actual TV.

So, I’m out of the Air Force now. I drove over 4,000 miles from Anchorage, AK to Jackson, MI, then drove back to Minneapolis a few weeks later to move in to my new apartment. Now that I’m settled here and school is underway at the University, I’m looking to start blogging again.

I’m still gathering topic ideas and links, but I do want to make a note right now on the password management system I wrote about. One issue that I’ve encountered is that TrueCrypt requires local administrator privileges to run. That may or may not be an issue for you. If you need to get into KeePass on public computers in computer labs or internet cafes, TrueCrypt’s not going to be usable, unfortunately. In this case, I would lock KeePass with a password rather than the keyfile, and use the password guidelines I described for the TrueCrypt container. Obviously this has the downside of not having that nice safe storage space for sensitive data in case you lose your thumb drive, but you will still have safe, secure passwords.

I also want to continue Project Euler but I may not for a while, perhaps not until I get into my comp sci coursework.

Since I discovered it yesterday, I’ve been hooked on Project Euler, working furiously on solving as many problems as possible. It’s a site that poses hundreds of math problems designed to be solved by writing computer programs, and tracks which ones you’ve solved. Naturally, I’m using JavaScript, and I’ve solved the first ten problems so far. Now, given my inexperience, the solutions I arrived at are going to be flawed—mostly in terms of efficiency—but obviously they work.

I made a file for the project, euler.html, where I’ll write my solutions for each problem. Of course there will be some functions shared among different problems, which is part of the reason for doing it in a single script. I’ll put a button on the page for each problem that’ll run its solution and spit out the answer. Although it doesn’t really matter here, I’ll also stick to best-practices and avoid polluting the global namespace by encapsulating my script’s functionality in a self-executing function. Common, private variables and functions will be defined, and then a hash will be returned with a member for each problem. This exposes them to the rest of the page (so the aforementioned buttons can call them), but they’ll have access to the private stuff thanks to closure.

var Euler = (function() {
  // private stuff here

  return {
    P1: function() {
      // algorithm for problem 1
    },
    // etc...
  };
})();

On to the first 10 problems. Note: If you want to solve them yourself, “spoilers” follow after the jump! Please don’t cheat.
Read the rest of this entry »

• ASUS’ upcoming Maximus Formula III motherboard looks slick as hell. And I dig the RoG Connect.
• If I’d been in the military 50 years ago, I might’ve worked on this beast of a system.
• Obama’s plan for gay rights.
• Here’s a hilariously truth-free promotional page for Internet Explorer. Oh, Microsoft, you never fail to fail to create believable hype. Or fail to maintain IE’s status as the shittiest modern browser. Free advice for you: I wouldn’t boast about web standards when your product scores 20/100 on Acid3 and your competitors score 94, 100, 100, and 100 (FF 3.5, Chrome 2, Opera 10, and Safari 4 respectively). Also: The reason you can claim that IE is compatible with the most sites on the internet is because you single-handedly held the development of the Web back by a decade with IE 6.
• Slightly old, but: This is a good article about a master of compromising physical security devices.

Following up on my last post, I want to note that there is some merit to the classical argument against writing your password down. If Alice’s password is posted under her keyboard, you have an auditing problem, because you can’t be sure that Bob—who works in the office and is also a legitimate authorized user with his own network account—hasn’t logged on to Alice’s account and done things in her name. If Alice writes her password down and puts it in her wallet rather than under the keyboard, though, there’s nothing wrong with that, which is what I was getting at.

Think fast: How many passwords do you have?

A lot? Surely you have many systems that you log in to, but perhaps you’ve taken to using a particular password on multiple sites, to avoid confusion and the hassles that go with forgetting a password.

Maybe you even use the same password to log into your computer, to log into YouTube, and to log into your online banking site. It’s just easier that way—I hear that sentiment loud and clear.

How strong is that password? Realize that if an attacker somewhere on the internet cracks your YouTube password, even though you may not care about YouTube they have now also gained access to your finances if you use the same password for your bank!

Unfortunately, we’re stuck with an online world in which a variety of destinations, tools, and services use only username/password authentication. As we rely more and more on these services and the risk as well as the potential damage of identity theft rise, it becomes ever more critical to have strong, unique passwords and protect them carefully. What I’d like to do here is explain my approach to password management and how you can have a set of exceptionally strong and unique passwords for everything you log into, without ever worrying about forgetting them.

Step-by-step guide after the jump!

Read the rest of this entry »

…is, according to Thermaltake, to bring world-class industrial designers in to do it for you. Behold the Level 10, designed by BMW. Yes, the auto manufacturer.

I’m not sure if I like it or not, but it’s certainly unlike anything else on the market, and the hot-swappable hard drive trays are a convenient feature. See more pictures here.

Update, 7/1/2009: Switched code sections from manual coloring to an automatic syntax formatting plugin.

NOTE (6/20/2009): I didn’t intend to close comments on this post. The setting is on “enabled” and I’ve tried disabling and re-enabling them to no avail. Some glitch either with the WordPress 2.8 update or installing the new theme has screwed it up. If you have something to say about this post, drop me a line. My Gmail username is the same as everywhere else.

I haven’t been posting much lately; I have, however, been thinking about my future in some area of computer science, software development, and/or web development. And I’ve been tinkering more with JavaScript since my last post. One thing I’ve discovered how to do is baking event handling into your custom objects. This isn’t really innovative—all the major frameworks out there include it—but I had fun figuring it out on my own. Here’s the solution I arrived at.

I decided that the best way to store and fire event listeners was in an associative array, where the keys are the event names and the values are associative arrays linking IDs to functions. So, for example, a set of registered event listeners for an object representing a door might look like this:

Door.Event
   "Open"   => "a"  => function
   "Close"  => "b1" => function
               "c"  => function
   "Lock"   => (empty)
   "Unlock" => "b2" => function
               "d"  => function

The IDs here are just quick meaningless samples; the idea is that they come from and uniquely identify the object that registered their respective event listeners. They will be used by their originating object to unregister its own event listeners and not any other object’s event listeners if need be, since you may have multiple objects registering listeners for the same event, possibly even the same function registered as a listener by multiple objects. As an example of this, consider a card game. If there are two cards on the board that say, “Whenever a player discards a card, that player takes 5 damage,” you will have two instances of the triggered function (dealing 5 damage to the player) registered on an array of global events for “Discard”, and when that event is fired, both will go off and the function will be executed twice. Yet, if one of those cards is destroyed, it should remove its own specific instance of event listener registration—perhaps the other has had a spell cast on it modifying its effect, so it could matter which one gets deregistered.

Using this system, implementing event listener registration is simple.

Read the rest of this entry »

Update, 7/1/2009: Switched code blocks from manual coloring to an automatic syntax highlighter plugin.

Looking for JavaScript optimization tweaks, I encountered a claim that a decrementing do-while loop is faster than an incrementing for loop. I decided to do a quick-and-dirty test to see if there’s any clearly discernible difference. I wrote two scripts, each of which does the exact same thing: create 100,000 DIVs and append them to the body of the page. First we have the standard for version, then the do-while format that the site claimed was superior.

Version 1:

for (var i = 0, d; i < 100000; i++) {
  d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
}

Version 2:

var j = 0;
do {
  var i = 100000 - j,
      d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
} while (--j);

Note that the do-while has an extra line to set a variable i that will increment just as i does in the for loop, thus we get the same result of DIVs numbered 0-99,999. But what if the direction doesn’t matter? What if going backwards and numbering the DIVs from high to low is acceptable, or even what we actually want? The do-while proponent cited in support of his claim that computers are simply faster at counting down than they are at counting up. Whether that’s true or not, I don’t know. But it seemed worthwhile to include two more variants in my testing:

Version 3:

for (var i = 99999, d; i >= 0; i--) {
  d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
}

Version 4:

var j = 99999;
do {
  var d = document.createElement("div");
  d.innerHTML = "DIV #" + j + "";
  document.body.appendChild(d);
} while (j--);

I tested each version 10 times. Each test ran in a fresh instance of Firefox v3.0.6 with no other open tabs. Here are the results:

There seems to be no significant difference here between different looping techniques. In light of this, I’d call it a matter of clarity/readability and somewhat personal preference. If you have to increment, obviously the for loop is clearer to read. For decrementing, either seems fine, though I like the do-while.