René Rebe

So I wanted to see the Ping (:-) and update to iTunes 10 (though that will probably not bring back syncing to my [secondary] Palm Pré, sigh). The iTunes built-in software update tells me “This version of iTunes (9.2.1) is the current version.” – hm, really? I really have to go to Apple’s website to pull it manually? How easy and streamlined is that? Ok, let’s check the system software update, and indeed “New software is available for your computer.”:

iTunes 10 comes with many new features and improvements, including:

• Introducing Ping. Use Ping to follow your favorite artists and friends or connect with the world’s most passionate music fans. Discover the music everyone is talking about, listening to, and downloading.

• Rent HD TV episodes for just 99¢ each. Watch them on your Mac or PC, on-the-go with iPhone or iPod touch, or in your living room with the all new Apple TV.

• Play your favorites on the all new iPod touch, iPod nano, iPod shuffle, and Apple TV.

• Play music wirelessly with AirPlay on AirPlay-enabled speakers, home theater receivers, and iPod accessories.

• Explore many look-and-feel improvements throughout iTunes.

• Enjoy performance improvements which make iTunes faster and more responsive.

• Additional voice support with VoiceOver Kit for iPod.

For information on the security content of this update, please visit: http://support.apple.com/kb/HT1222

At least, unlike Safari, it does not require a reboot, just to quit Xcode, and iTunes itself (do I really have to be notified of the later, and quit it myself?), …

Update: Oh my god! What have they done to the window controls! This traffic lights look ugly! And so does the new icon, oh my, oh my, …

Update 2: In the meantime the iTunes App feed directly get’s the 10 update, too, … and it looks like I hit a nerve with the icon and window decoration criticism, … Personally I do not like the icon, because it simply does not match with any other icon in my dock, neither the Finder, Mail, Safari, Cal, Preview, Xcode, et al. Mostly because the others are not as round. Whatever. The window decoration, however, is really annoying. The fragmentation of Mac UI elements, where every App brings it’s own variants, really contradicts usability and users getting to a look and feel. This really is not what the Mac user experience once meant to be and reminds me on the Unix world, where each X11 environment brings it’s own toolkits, usability, and look’n feel, …

This overzealous review process and random rejections of Apple’s iTunes iOS App store has been discussed in all lengths all over the internet by now. It is just that recently we found enough time to finish the first App to be submitted into said App store.

You may wonder how long their review process does take, and so do I, … Until now it took them 7 full days to answer a basic question regarding a minor application meta info detail, and it has been a whole week the App is still pending for review on their side!

The sad thing is that by now we even have a version with the first post release polishing, but are afraid to reject and reload the binary, as according to the iTunes connect documents this would make the updated binary start at the very end of the review queue, again :-(

Sigh^2!

Update: just after posting this the iTunes connect status flipped to “In Review”, keeping my fingers crossed!

Update 2: now “In Review” for 24h, fun, … (more…)

Recently Roger Mason sent in a patch for T2 adding a new compressor named xz, apparently a successor of lzma.

The google results where a bit brief on comparison between xz, lzma, and the well known bzip2 (and gzip).

So here goes a tiny test, I modified T2 to add support to compress the binary packages with xz, and got this results for a quick test (all compressors are run with -9 for best compression):

204800 lzma-4.32.7.tar
75248 lzma-4.32.7.tar.gz
74304 lzma-4.32.7.tar.bz2
62736 lzma-4.32.7.tar.xz
62655 lzma-4.32.7.tar.lzma

Bzip2 does not particularly shine, and xz neither, … Ok, let us try with something bigger, containing some more raw test, the apache package:

14090240 apache-2.2.16.tar
3098510 apache-2.2.16.tar.gz user 0m1.040s
2331497 apache-2.2.16.tar.bz2 user 0m2.124s
2069252 apache-2.2.16.tar.xz user 0m6.700s
2037338 apache-2.2.16.tar.lzma user 0m13.089s

Hm, xz still does not come out smallest, at least it is not as exorbitant slow as lzma, …

One last try for xz to show it’s potential, let’s use the millions of lines of code that form the current linux kernel:

412897280 linux-2.6.35.tar
88300782 linux-2.6.35.tar.gz user 0m35.118s
69305709 linux-2.6.35.tar.bz2 user 0m54.431s
57065123 linux-2.6.35.tar.lzma user 7m50.453s
56921708 linux-2.6.35.tar.xz user 5m44.266s

Finally! Some 140kB smaller, still slightly faster than lzma, but 10 times(!!!) slower than bzip2, sigh.

All run on an Intel(R) Xeon(R) CPU X5365 @ 3.00GHz, while apparently even the new tools (lzma, xz) only used one of it’s cores (by default).

Your milage may vary.

You need to add Linux system (router, server, etc.) directly onto an 802.1q VLAN trunk? Well, for one there is this old (read: deprecated) vlan, the new way is simply via iproute2’s ip:

ip link add link eth0 name eth0.1234 type vlan id 1234

As usual: just substitute the ethernet interface name, alias, and VLAN ID as needed :-)

So after a whooping 10k change-sets in the SVN repository and two more years than we wanted, it is finally here: T2 8.0.

You may wonder what took us so long. Indeed so do we! It is mostly an issue of free time to work on T2. After all it is a monstrous effort, maintaining all the thousands of packages and taking care (of most) CPU architectures, … And then we even open it all up like no other – with the easiest to locate, use, review, develop and cut’n paste source tree (the most popular vendors notoriously kept their build scripts, ISO generating glue pretty covered, even their source trees are often not too easy to get access to, nor elaborative, …)!

While T2 became recently more and more successful in appliance and embedded space (heck all popular companies appear in our web log: Palm, Nokia, Motorola, … I assume they are longing for some inspiration), few companies keep in contact with us, nor contract or sponsor the project. So pushing the huge project that is T2 forward is a night-shift, weekend-fun, or 20% @work project for many of us (even including myself)!

Another contributing factor is upstream breakage. Half a decade ago most source packages just worked, more then less. These days my personal impression is that it is now rather the other way round: KDE, GNOME, heck even GCC and the C library or just the Linux kernel have more and more source incompatibility with each new release. Incompatibility or bugs that we have to tidy up before it even just builds all together.

It is therefore most irritating when a cooperate users without an support agreement occasionally even call me personally at work, and bug me about bugs in the release candidate, random build issues of non-primary (read not even secondary, GNOME or KDE) packages in the trunk, and when a new stable release will finally be out.

I personally consider this a pretty dark and troublesome side of the Open Source medal, a trend that I saw rather increasing over the last years (and mind you, I am with Linux and Open Source since back in the last millennium’s 90th, when most people did not even know how to spell Linux).

And when I kindly ask to invoice the time or about donations some even get insulting and start to talk about not being open and artificially keeping the trunk broken.

However, fact told: it is exactly the other way round: for minor part we also had no T2 stable release, because our SVN trunk just worked so freaking great! We used T2 trunk builds in-house, for our own projects, servers, and customer projects all the time!

Given the shear modularity and flexibility we even cherry picked single package updates, new packages, and the like into shipping customer products trees all the time, too.

When I continue to receive those unsolicited phone calls I’ll think about getting our company such an expensive pay per call number – and better a secretary with it, too :-)

So you got some virtual machines for the your development, tests. Need to extract some files, do a backup, without messing with the other messy OS?

For one thing there is some qemu fuse code patch (or so), floating around. However, the simple, robust and straight forward way is to simply loop-back mount the partition on a RAW file at the given offset. You can determine the offset with your favorite partition editor, or disktype. Once you know the sector offset you simply multiply it with 512 (usual sector size) as the offset like so:

mount -o loop,offset=$((123456* 512)) img.raw /mnt/tmp

Update: and for qcow et al images:

odprobe nbd
qemu-nbd -c /dev/nbd0 image.img
mount /dev/nbd0p2 /mnt
…
qemu-nbd –disconnect /dev/nbd0

The team around Chris Lattner appears to be spinning at a pretty remarkable high pace, they just added a debugger to their growing family of LLVM sub-projects. Wow!

thinq has a story about MSI claiming they will start putting UEFI into their BIOS ROMs soon. Finally.

Hopefully this will improve their reliability and upgrade procedure on the way.

Personally I’m pretty much BIOS-less since some time, as I got myself Apple’s PowerPC hardware back in the days just for the PowerPC and OpenFirmware part of of it and still run my Linux on the machines. Other hardware, such as the SPARCs near me do not have such defect basic software either, and Apple’s Intel Macs used EFI right from the start, …

However, one should also note that some vendors (Sony and other) already ship machines with UEFI bits.

Normally the performance gain going from 32bit (i386, aka i686 etc.) code to 64bit amd64 (aka x86-64, EM64T, or the likely to mismatch x64, …) is not soo huge. However, unlike classic RISC CPUs -which usually loose performance when comparing their 32 and 64-bit- code due to bigger instructions and thus data bus saturation. For amd64 AMD did a great job defining the ISA (Instruction Set Architecture) in a way that 32 and 64bit operations can be freely mixed. Thus normal programs that do not benefit from 64bit operations remain compact, while single instruction can freely utilize 64bit by adding a REX prefix (similar to the 0×66 prefix introduced with the 386). So normally data moving loops benefit from going 64bit, e.g. multi media codecs, encryption and such.

Doing some performance analysis on a new AMD board I spotted an rather extreme case: openssl’s RSA 2048 bit encryption shows an over 300% boost while going 64bit:

From:

rsa 2048 bits 0.007128s 0.000212s 140.3 4722.2

To:

rsa 2048 bits 0.002380s 0.000068s 420.1 14716.7

Yes, that the same machine (AMD Phenom II), exactly same software stack and such, a whooping 312% increase!!!

alert tcp any any -> any any (msg:”My TEST rule”; flow:stateless; sid:66666;)