René Rebe

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

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 of going from 32bit (i386, aka i686 etc.) code to 64bit amd64 (aka x86-64, EM64T, or the likely to mismatch x86, …) 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 since the 386). So normally only 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;)

So we got some new PC server mainboard, and the latest greatest AMD Phenom II X6 CPU. Of course the BIOS would not recognized the CPU, just list an “unknown” CPU, and let it run at a bare 800MHz. Apparently no real OS wanted to boot in protected mode either. So I thought it’d be a good idea to update the BIOS to the latest, greatest. However, turned out that wasn’t so much of an good idea: after the update the board would not boot up anymore. No sign of the BIOS at all, …

The board vendor, however, was so nice to handle our support inquiry nicely and sent out a new 8-pin, serial EEPROM last Friday, and it even arrived the following day, that is Saturday!

So with the new EPROM in the board it actually booted again (puh!), and re-reading the BIOS Release Notes I found that it indicates running the DOS flash EXE with some special arguments, that I obviously did not include when I just run it intuitively the fist time:

PFUDOS.EXE FILENAME /p /b /c

How nice. If I would author some BIOS flash utility, I would rather write it in a way that a run with default, that is without fancy parameters would produce a reasonable, good outcome, …

Anyway, another note: After booting I removed the second, new, good ROM and injected the old, bad flash, and then used above run with fancy parameters to flash it again, and voila: I finally had an BIOS ROM with the latest version that worked !

And yet another note: Flashing from an bootable USB stick with FreeDOS worked just fine.

Sooo, with the latest AMD V105, Nile platform come the AMD Netbooks. 64bit, and such, nice, finally! If, well, if the manufactures would just learn that 1024×600 (or even worse x560) doesn’t really cut it, anymore. Never did. Heck, even the iPad got more pixels real estate! Without Intel’s silly Atom screen resolution restriction at least 1024×768 should be in order (while even that is so last millennium). There is so much screen bezel to cut down.

Personally, though, I find the Nokia Booket’s 1280×720 pretty usable abroad. Wouldn’t want to miss a single pixel of it. It’s Just it’s (Intel Z-series Atom) CPU could be a little more performant, …