Al Hoang

OpenBSD gets high remarks even though their OpenBGPD offering is rather new.

Read it yourself

Gen Kanai writes about S. Korea’s dependence on Internet Exploder due to misplanning a Public Key Infrastructure

South Korean legislation did not allow 40 bit encryption for online transactions (and Bill Clinton did not allow for the export of 128 bit encryption until December 1999) and the demand for 128 bit encryption was so great that the South Korean government funded (via the Korean Information Security Agency) a block cipher called SEED. SEED is, of course, used nowhere else except South Korea

…

one legacy of the fall of Netscape is that Korean computer/Internet users only have an Active X control to do any encrypted communication online

Read it yourself

Eugenia of OSNews writes a nice lengthy review on the Nokia N800. It has many improvements compared to its predecessor. Some things they got right:

• Good Battery life (10-15 hrs standby, 3-5 hours in actual usage)
• Faster processor
• Great Wi-Fi reception
• Some support for VoIP (GoogleTalk, Gizmo?)
• Future Skype Support
• Opera Web Browser version handles Flash now
• Sure support for SD cards >1GB
• Reasonable price (~$400 USD)

However there are some flaws:

• They broke backwards compatibility with the previous N770 apps
• Flash can’t handle Google Videos or Youtube
• Craptastic MPEG-4 support

I have to say no Youtube and crappy MPEG-4 support for me is a dealbuster. There are a gazillion of these small devices that playback video however none of them play back ENOUGH video formats for me to be compelling. Although the N800 this time comes much closer. I guess I’ll wait for the N900 to roll about.

Other Reviews

There are other reviews floating on the net… here’s a list. I didn’t bother reading them as Eugenia’s was thorough enough to not require sifting through tons of probably useless fanboy lushing in order to find how it stacks up.

• Mobile Burn’s Review
• CNet’s Review
• ZDnet Review
• Gizmodo’s N800 News Feed

In an
earlier post
I wrote about the pains of Core 2 Duo motherboards and Linux support. Since September, there has been quite a bit of progress in the Linux community to support the JMicron SATA/PATA controller that is on the Intel P965 based motherboards. However, I’ve found that things are STILL not all rosy with my
MSI-7265 (aka the P965 Neo F model) motherboard. After looking around I found an interesting review on the MSI-7265 motherboard:
The Register Hardware writes:

The P965 Neo is a simple, no fuss but no frills motherboard with a decent layout

What this means is that the MSI-7265 does not offer very good access to many of the devices via the BIOS versus some other P965-based motherboards do such as the Asus P5B. After a bit of wrangling of my Gentoo installation I was able to get Linux installed, upgrade the kernel to 2.6.19-*mumble some Gentoo patch*, and boot properly.

What’s working

• The SATA AND the PATA controller on the jmicron chipset. (Allows using a DVD drive and the hard drive)
• Onboard Audio
• The onboard Realtek 8110SC-based ethernet port (requires getting a driver from the Realtek website)
• The USB ports

What’s NOT working

• Any of the Serial ATA ports off the ICH8 controller
• Suspend (It sleeps but never comes back up)

References

The Reg Hardware Review on the MSI 7265 Motherboard
Ubuntu Thread on MSI P965 Neo Install
An older Ubuntu thread on the MSI P965 Compatibility
Linux SATA Driver Status Page (Really useful!)
A Japanese post on trying to get the MSI P965 working (They failed)

The Problem

Dependencies won’t install when I try to install from a local gem. For example if you have a my-cool-project which
needs your-awesome-lib (available via Gems) using a command like:

gem install pkg/mycoolproject-1.0.gem

It WON’T pull in your-awesome-lib. This is documented in this email post on the Ruby Talk ML

Workarounds

At present the problem still exists and I can’t seem to find a bug related to it on Rubyforge (Perhaps a bug should be submitted?) so you can get around this by installing your dependencies first then installing your local gem

gem install -r your-awesome-lib
gem install pkg/my-cool-project-1.0.gem

Keith Packard of X11 fame wrote a blog post on revision control repository formats. In it he describes why he chose git as the new system that will manage the source code for Xorg and he had some choice comments on Mercurial repository format

Mercurial uses a truncated forward delta scheme where file revisions are appended to the repository file, as a string of deltas with occasional complete copies of the file (to provide a time bound on operations). This suffers from two possible problems—the first is fairly obvious where corrupted writes of new revisions can affect old revisions of the file. The second is more subtle — system failure during commit will leave the file contents half written. Mercurial has recovery techniques to detect this, but they involve truncating existing files

However, some people who use Mercurial have answered back to those criticisms.
RVBurke writes:

Mercurial uses a compact representation of data with separate revlog files for each tracked file, manifest and changelog, which are all append-only. Due to the append-only nature of those writes, the changes in each new revision don’t affect previous revisions. You are that way as safe as you can be in any other system with respect to writes and the space usage is very good.

To achieve similar space efficiency git needs to pack the repository data. This is done rewriting the repo, and the operation has to be done from time to time (repack).

IF the atomic append-only writes to the manifest and revlog files in Mercurial can be considered dangerous, then repacking is even more so, as it forces a rewrite of all the repo data, multiplying the chance of a failure.

So, if any corruption can happen on a faulty write it will hit git (unpacked) or Mercurial in the same way, but anytime you pack your repo in git you’re risking your data and the write fails you can corrupt its repository.

and Matt Mackal in an email to the Mercurial mailing list has the following reply:

Mercurial files are append-only. New revisions (corrupted or not), do
not affect old revisions. If a hardware or operating system bug causes
a write to scribble over the wrong part of a file, all bets are off of
course. But such bugs could just as easily scribble over any other
part of the disk, so I think this is no more of an issue than it is
for any other possible system.

Personally, I’m a bit confused. I’m not an expert on repository formats so I don’t fully understand whether the criticism or the defense is stronger. However, I have chosen to use Mercurial in most of my own personal projects because it has one feature for sure that git does not. Windows compatibility. While many will denigrate native Windows compatibility. It’s also good to remember that a huge portion of machines on this planet still run Windows. The fact that there’s little information on running git on windows besides ‘Install cygwin’ makes it hard to evaluate whether git is ‘good enough’ on Windows or not.