René Rebe

Recently a radio broadcast of “Gossip’s Music for Men” made me curious to go to a nearby music store (yeah, I love those old fashioned CDs that you actually own, can listen to in a decade, not until some DRM server goes down), and it struck me: They must be watching too much “Knight Rider” in the 80’s – the base theme line of “Heavy Cross” and “Vertical rhythm” resembles the series’ soundtrack pretty much, … :-)

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 :-)

In 2006 I started this blog with a just 1.6GB of photos, in 2007 the photos stacked up to 4.6GB. Today, after sorting in our latest vacations, we got some 24GB of images on this site!!!

The rise of the mega-pixels, SLR, and RAW certainly play their role :-)

Among the latest greatest shoots I got moon craters:

And a last millenium Borgward Isabella:

Enjoy!

PS: Yes, I hacked the photo gallery to grok RAW imagery and in various other ways, nearly no code line was left unmodified, …

So you got to be some desperate soccer fan and want to watch the FIFA World Cup™ on your PC at work?

Well, bad news. the live streams are so busy, you barely get to log into one. Certainly see more time outs than tune in, …

You know what? It is (mostly) just because the telcos where so unbelievable lazy adopting IPv6 and with it proper multicasting.

This way the humble server farms need to send out a dedicated high bandwidth video data stream to each of your video clients. Unlucky you, I feel with you – though for all the bits going wasted on this!

Update: The H covers it, now, 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;)