June 23, 2010

iBooks and jailbreaking

iOS 4 was released yesterday, and it's already jailbroken. However, iBooks only works in iOS4 on devices jailbroken with PawnageTool 4.01 and redsn0w 0.9.5b5-4 or newer. For some reason I couldn't get PawnageTool to work so I used redsn0w.

The images below are captured from my iPod touch 2G.

The iPhone ebook in the image above is the iPhone SDK Development book in epub format that I bought from The Pragmatic Programmers that I also used in the Amazon Kindle review previously.

June 21, 2010

Geniuses at work

More Internet censorship going on in Thailand as the government blocks more and more websites for absolutely no good reasons whatsoever. Most recently, for some unknown reason, they decided to block the entire Vimeo site. However, this time, instead of blocking the IP address like what they did in the Google blocking fiasco, they decided to simply block it by the URL, "www.vimeo.com". Fortunately, like all good websites, "vimeo.com" also works for accessing the site, and the geniuses at the government failed to block that URL. So to access your favorite Vimeo videos in Thailand, simply use http://vimeo.com/.

June 16, 2010

Mac OS X 10.6.4

Mac OS X 10.6.4 is released. Full details here. Combo update here.

10.6.4 just came out this morning and I quickly updated. The reason was that since installing 10.6.3 two months ago, I've had this really bad problem where when I resume from standby, the screen's back light doesn't turn on and I have to manually change screen brightness to make it light up. Sometimes though, even doing that doesn't work, and I have to close the lid and re-open, sometimes multiple times, until the screen works again.

After upgrading, the problem seems to have disappeared.

June 6, 2010

Multiseat Windows

I've been keeping my eyes on multiseat Windows for the longest time. The idea of multiseat Windows is to connect two or more monitors to a single computer, and let two or more users share the computer, running different programs. There are a number of such solutions on the market, the most famous probably being BeTwin, but they all seem to be hacks and probably breaks some licensing agreements. I've tried using BeTwin, but it has very specific hardware requirements, and wasn't stable enough for my needs.

Multiseat Windows seems like a throwback to the olden days where dumb terminals connect to a single mainframe for computing tasks, but it's actually quite different. The difference is that multiseating Windows actually involves having multiheaded displays on the system running Windows itself, instead of having a local display buffer like with most terminals.

The market suddenly boomed this year when Microsoft announced MultiPoint Server 2010. MultiPoint Server is actually a combination of the two ideas above. It has to have multiple displays on the system itself, and yet it uses remote desktop services to generate the image. Through a friend's cousin's ex-girlfriend's uncle who works in the academic sector, I managed to borrowed a copy to give it a spin.

I installed it on a cheap Gigabyte GA-MA78LMT-S2 motherboard with a low-end Athlon II X2 CPU and 2 GB of DDR3 RAM that I happened to have on hand. The installation is almost exactly like installing Windows Server 2008 R2, since MultiPoint Server 2010 is based upon that. After installation, it gave me 3 days to activate, just like Windows Server.

The Gigabyte board has two video outputs, DVI and VGA, I simply had to hook up two monitors (one DVI and one VGA), two USB keyboards, and two USB mice, and MultiPoint Server automatically detected everything. At first was that I couldn't get the keyboard and mice to go to their individual monitors, but after looking at the setup diagram from Microsoft, I realized they needed to be on separate USB hubs, so grouping a set of keyboard and mouse onto the same set of USB port at the back of the motherboard worked. The MultiPoint Manager then showed the monitor, keyboard, and mouse all grouped together and linked to their respective stations.

Since MultiPoint Server is actually running as a remote desktop service, and the individual stations are behaving as if they're running remote desktop clients, not to mention this is a Microsoft product and not a hack like all other multiseat Windows solutions, the entire setup is completely stable. Unlike BeTwin that I mentioned above, it also works with all hardware that are supported by Windows. However, running as remote desktop also means everything is slightly laggy due to the remote desktop protocol.

I could only connect two stations to my motherboard since I only have two video outputs on my mainboard. To connect more I would need either another video card, or one of those USB DisplayLink adapters. HP also makes the MultiSeat t100, a MultiPoint Server specific thin terminal that has everything built into a small box.

MultiPoint Server is actually designed for the academic sector, to reduce costs of computers for schools, especially in emerging markets. However, the cost saving may be limited, since only the cost of one (or more) computer can be saved. The software license is still required. For example, Microsoft Office's license is based on the number of users, and not on the number of system it's installed on. Saving from reduced usage of electricity is also limited, unless you're saving the planet. I looked at our relatively cheap electricity costs, the amount of money I could save by using four full computers vs. one single MultiPoint Server with four heads is less than $1 per year.

Finally, one issue I ran into is that since MultiPoint Server is based on Windows Server, many programs that detect the operating system due to either OS differences or (more likely) licensing issues, won't install. So even if the academic institution saved money in hardware purchases, they may need to purchase different software designed to run on a server OS.

June 4, 2010

Windows remote printing madness

Recently we've starting moving to Windows 7 x64 clients at work, especially for the newer computers. Of course, we still have the Windows Server 2003 R2 that I installed earlier. However, my users complained to me that they couldn't print when logged on to the server remotely, eventhough we've been using this setup since last year and we've not had problems before.

After looking at the system logs, I realized that the printer driver was missing. The Windows Server is a 32-bit system, while our new clients are 64-bit. Not a problem, so I installed the x64 printer drivers onto the server. Still not found...

After fiddling some more, I noticed the server has our Canon printers listed as "Canon iP3600", which is the driver that came bundled with the printer, while the Windows 7 clients have it as "Canon Inkjet iP3600", which is the driver that came with Windows. And since the names don't match, driver installation didn't work. I also couldn't just install the Windows 7 drivers onto the server though, since terminal services expects drivers to be pre-installed before they can be used.

This would probably have been easier if I had set my server up with a print server role, but I didn't, and I didn't want to kick all my users out to install a role. So I fired up the Remote Administration Tools for Windows 7, and added the x64 printer driver that came with Windows 7 onto the server.

That still didn't work, then I realized since the server is actually 32-bit, I need to install the 32-bit drivers and not the 64-bit drivers. Unfortunately, the 32-bit drivers only comes with Windows 7 x86, and there didn't seem to be any other way of doing this, short of running the Remote Administration Tools from a 32-bit Windows 7 installation.

Finally, after another hour of installing Windows 7 x86 just to install a printer driver. I now have four different printer drivers on the Windows server for the same printer, and everyone's happy.