Off by one. Linux deprecated OSS3, and OSS4 is now opensource.

And not only does it work better (in my admittedly little experience with it), it's also more in keeping with the UNIX philosophy of treating devices just like any other file. Sure, with ALSA you do have device files, but you pretty much have to use alsalib to use them AFAIK. With OSS, you get to use the standard UNIX file APIs.

I had heard that V8 was 32-bit only right now, which is why I was surprised that there was an amd64 package. But everything I've seen online (in the admittedly small amount of searching I've done) indicates that 64-bit support is a low priority. I even saw somewhere mentioned that the code makes various non-portable assumptions such as sizeof(int)==sizeof(void*), which if true means they really weren't planning for 64-bit support when they started. I hope they add proper 64-bit support soon, but I'm not holding my breath.

In the sense that it doesn't pull in the 32-bit dependencies, yes. But rather than fix it, I'll just uninstall. Chrome should hopefully support 64 bit properly at some point, and I'd rather wait until then to try it out than install a bunch of 32 bit libraries for the sole purpose of running a very alpha browser that I'll likely play around with for all of five minutes.

A friend wrote up a Gentoo ebuild for it, which I went and installed (for the amd64 version - I run an almost entirely 64 bit system). Try to run it, and got this message:

That's odd ... double check ... yes, /usr/lib64/libgconf-2.so.4 exists ... No ... they couldn't have ...

*facepalm*

The 64-bit Chrome is *NOT* 64-bit, and will not run on 64-bit systems which are missing a number of 32-bit libraries.

Oh? this (and this follow up post) seem to indicate that it's not so clearcut. Looks like x264 beat MainConcept in most tests, and the major tests it lost in were rather unrealistic.

But in the interest of full disclosure, Dark Shikari is one of the main developers on x264, so he's got an obvious bias. Doesn't necessarily make him wrong though.

Maybe the ones they release here are crap (I don't know, never used one), but I've got no complaints with the Kyocera A5521K I had in Japan a couple years back.

The inclusion of a real web browser isn't really that important in the Japanese market. In Japan, probably more people browse the web on their cellphone than on a computer. This means that my and large, Japanese websites are made with the limited browsers in mind in the first place, though many sites will check the user agent of similar to allow separate versions for computers and cellphones. Because there was demand for it, the mobile web already worked rather well in Japan, and throwing Safari onto a cellphone there doesn't really change things much.

That doesn't really apply to most videogames. The actual cost per unit is the cost of the disk and packaging, so almost nothing. All the development, production, testing, etc are fixed costs no matter how many units you sell, so theit "cost per unit" is really a very fuzzy concept, depending on many different factors. Valve's little experiment here is a perfect example of how lowering the price can even lower the cost per unit.

There are plenty of games out there that I don't feel are worth the price they're asking. Maybe some are, but many aren't. Valve's experiment is still perfectly applicable to many games.

This has been debunked on reddit and probably other places.

1) Bush's robots.txt began very similarly to Obama's, it grew later. Obama's robots.txt file starting small proves nothing. Look again in a year and see what it looks like then.
2) The pages disallowed by Bush's robots.txt file were (almost?) all printer-friendly versions of pages which were not excluded. The information was still there and accessible to spiders.

I'm no Bush fan, but let's limit the bashing to things that are actually true and meaningful, shall we?

Use Flash Lite. It runs on ARM. It's also currently a couple major versions behind the normal Flash plugin, but I believe Adobe's said they're making it a priority to bring it up to date with the rise of netbooks and such.

I used the software that came preloaded on my Kyocera A5521K, which wasn't a particularly high end Japanese cellhpone when I got it in late 2006. It claims to be "MEDIASEEK/KDDI Barcode Reader & Maker 1.2.1"

I do think it's suboptimal having all these separate formats. I would prefer it if they consolidated on one common, open format, and I have a slight prefrence for QR Code there simply because it's the format with which I have the most experience. If I'd been aware of the proliferation of formats when those other formats were introduced, I'd likely have been arguing them as well, but as it is, it's a little late. Right or not, it's easier to argue against a new format than against one that's already somewhat entrenched.

I'll take your word that MS Tags have been more reliable for you. But with as little trouble as I've had, I don't believe that the QR Code format makes it inherently unreliable.

Maybe. Or maybe it has better decoding software. I don't know. I just know that in my experience, the technology is there and it works pretty well. And by the time something like this ever takes off in the US (it's been talked about for a long time, but hasn't really gone anywhere - if anything, this is the advantage of MS pushing it, they'll get publicity), the average cellphone camera will be even better, and so there should be even fewer problems, almost regardless of the particular barcode standard in use.

From Wikipedia (emphasis added):

I could probably be accused of being anti-MS, paranoid about privacy concerns, or a number of other things, but NIH is not really one of them in this case. I'm proposing using the already existing technologies instead of needlessly inventing new alternatives that I don't see as adding anything significant.

Those both worked flawlessly on my Japanese cellphone from a few years ago.

There's also no real good reason for the creation of new formats when existing formats do work well beyond NIH syndrom.

Got a link to one? I don't recall having any problems with a real-world QR Code. Contrived examples like the one on the wikipedia page on QR Codes are problematic, but I don't think I've ever seen someone really try cramming so much data in practice that it wouldn't scan.

And again, URLs encoded in QR Codes still handle the case where there is a large amount of data.

You can't use the tag format without it going through Microsoft, and getting them to agree to store whatever data goes with your tag. Being artificially limited to one vendor is more or less the definition of vendor lock-in.