René Rebe

Now this is insane, and sad:

panic(cpu 1 caller 0×21b8c6): “bad exception behavior!”@/SourceCache/xnu/xnu-1504.3.12/osfmk/kern/exception.c:298
Backtrace (CPU 1), Frame : Return Address (4 potential args on stack)
0×71c4bbe8 : 0×21b449 (0×5ce420 0×71c4bc1c 0×2238a5 0×0)
0×71c4bc38 : 0×21b8c6 (0×584e34 0xc1d7b90 0xc1be1f0 0×1)
0×71c4bee8 : 0×21ba31 (0xa175b7c 0×1 0×71c4bfa0 0×2)
0×71c4bf38 : 0×2a844f (0×1 0×71c4bfa0 0×2 0×1)
0×71c4bfc8 : 0×29e80a (0×8b55a20 0×0 0×10 0×8b55a20)

So much for Apple’s “superior OS”, and “Unix foundation” advertisements.

An OS that is catched with pants down that easily is like, well, actually, like Mac OS 9, or even worse: Windows 95, 3.1, etc. Hell, it is like DOS!!!

And this while Steve is just lulling about Flash crashing Macs. Frankly I do not remember a single crash of Safari due to Flash, … It might be slow, but at least it did not crash on me (on OS X).

Even just using Linux, Mac OS X (that is not so much Windows), why the heck does every linker needs to be have differently?

The GNU one for example can not create relocatable, static objects with hidden symbols stripped. The GNU masters just wave you off, telling you to simply ship a zillion shared-object files. When all you want is some program executable? Thanks.

Fortunately Apple’s legacy linker does even allow the above (not that it is too useful if most Unix linkers do not, …) But the Apple linker only supports this for ppc, ppc64, and i386 - that is, not for recently added x86_64. Oh my!

It could not be more bizarre, could it?

Let’s hope that LLVM eventually get’s it straight – maybe fixing the incompatible tool-chain mess in the long run, …

Update: LLVM 2.7 is out!

Thanks god I’m not only wondering how much sense cmake does make!

In the Linux world one is currently a little stuck with Ext4. Since the author of ReiserFS went into jail there is not much development happening with Reiser4 (and the plugin stuff was highly controversy anyway, I just would have wanted the FS basics, without the fancy plugin glue, anyway), and as the BetterFS is not quite there yet, your best bet in the near future gotta be Ext4, …

Fortunately there is a way to convert your existing Ext*FS to Ext4:

tune2fs -O extents,uninit_bg,dir_index /dev/theDevice
fsck -pDf /dev/theDevice

You could also just remount it with -t ext4, however this only gives you some of the new features (e.g. delayed allocations, etc.), but not the other, on-disk format changing goodies (extends et al.).

Just spotted this on my neighbors blog. Sadly I have to fully agree. The amount of upstream breakage, regressions and such, I have to deal with in T2 is beyond believe, and no fun at all.

This is one reason we still use a way older udev version, but that is not even the most broken stuff I have come by recently, …

Update: Looks like others feel the pain, too, …

I do not believe it, until I see it.

This would be way too strange to become real. I mean what would they gain? Not much actually, they can produce their own, optimized, ARM flavor already. The only benefit would be to take ARM away from competing companies. And in that case they would end up with a huge, unprofitable subsidy – unless they lay off most of the ARM staff.

However, if Apple really would cease ARM supplies to competitors it would certainly hurt the whole embedded industry – given that nearly any crapgadget, from your mobile phone, router, access-point to the NAS near you is powered by an ARM cpu.

Well, then, if that really turns out to be true, and Apple would indeed stop licensing ARM to others, there still are MIPS, SuperH, AVR32, heck, even PowerPC. Well, even x86 gets more energy efficient, (think post Atom silicon) … So the other companies still have options to continue their business.

So instead they could also directly burn their money. But still, I get to think that is an good Aprils fool – just 21 days off, …

PS: From my own experience AVR32 is pretty competitive on the performance per watt scale, if they just would scale their core IP to the GHz range (up from the current 140-200 MHz), …

My current displays are a little aging, and with Apple not coming out with updated Cinema Display, and disqualifying itself with those glossy ones I can not work with (too many reflections, need my eyes some more years, …) I got to think about what be the perfect display color. White (light, grey, silver, aluminum, etc.), or black. Some argue for some improved visual screen contrast with black border. Currently my very old ViewSonic display are kind of silver (plastic), and the likewise, but less, aging Apple Cinema Display is aluminum:

Just comment, what do you think?

(Image courtesy Mac Rumors.)

I want one two! I never quite liked the chrome bezel of the iPhones up to now (1st, 3G, 3GS). The frameless style is exactly what I envisioned.

However, a slightly smaller display would not fit into my vision – I’d prefer a slightly bigger one (not just in terms of resolution), to make reading websites or other material more enjoyable. But then again, that might hurt iPad sales, so a smaller iPhone display would certainly favor people getting an iPad for reading. On the other hand I really prefer just to take one device “that fits all” around with me.

I really do not want to be the Apple employee who actually lost the phone in the bar! Unless, of course, it was an intentional leak – to make the media and us desperately long for it, awaiting the new iPhone in the summer.

So with T2 SDE I do this open source thing for over 10 years by now. I was lucky for the opportunity to already toy with an IBM XT (clone) in the 1980’s. And more lucky when my dad invested into a second floppy, a 40GB hard drive, and later a 386SX board (25MHz, with 2MB RAM) and some OAK VGA card (with NEC MultiSync monitor)! I became aquatinted with DOS at that time, and while BASIC didn’t cut it for me, with Pascal and assembly. Yep, assembly. We wrote half of the programs in it at that time. Interestingly with deep knowledge in both, (Turbo) Pascal and assembler, the transition to C was not as easy as I would imagine from todays perspective.

Anyway, when Windows 95 didn’t really cut it, a friend and I start our own protected mode kernel, when we accidentally encountered Linux. The first version I tried (some Debian) sucked and scared me enough to wait another year to try [Linux] again. As it still sucked, but seeing the potential I was about to create an own distribution when I encountered ROCK Linux. We found it usable enough to contribute, and push a Desktop flavor (Desktop ROCK Linux, dRock in short). I even got a photo from this area at the end of the 1990’s:

With all projects came the usual, policy (and marketing) issues, which made me fork of try two.

T2 now comes with over 3000 packages. These are the vanilla upstream packages, not split into the artificial -lib, -doc, -noarch, -whatever slices. To compare this numbers with other, well known distributions, you can safely multiple the count with 3, or 4, …

Since data storage does not cost as much (as the before mentioned 40MB drive) I do not clean up the download upstream source archives on my primary development server for some time now. While working on the GCC 4.5 update, it stroke me to take a look how much sources I got archived: It is 65 gig by now! Yep, that’s 65GB worth of archived open source history! As an overview the storage size for the T2 package sources of the respective release branches:

3.8G mirror/2.1
5.3G mirror/6.0
6.0G mirror/7.0
15G mirror/8.0

The 64GB are just since the Summer of 2006, … wished I’d kept more of the past – though I recently enocounted some source archive backup DVD-R. If I’m lucky it’s still readable, and I could mix in some more history for the fun of it :-)

In the past decade I lived without any Microsoft Windows flavor near me. However, for multiple reasons (e.g. being able to answer Windows questions to my parents in law) I thought it’d be a nice idea to leave the Windows 7 that came with the for occasional “let’s see how the menu item is named there” reboots.

While I initially had triple boot (via Chameleon, not GRUB, it just looks better) last autumn, it broken some time thereafter. As I said, I do not really “need” Windows for anything, less so abroad, so i left it in that un-bootable state for the time being. However, now that I injected an SSD I reinstalled anything, anyway. And just when I had everything installed and setup this stupid Windows 7 beast refused to boot, yet again (with the strange “hardware changed I can no longer boot” message I was already used to)! The Windows installer media repair function was no help, either.

The internet was silent on that matter as well (ok, guess not too many dual-booting their Hackintosh), so I invested some time to finally track this annoying thing down. After some intermitted hours of re-install and analysis it turned out the Mac OS X’s fdisk is the culprit! Zero’ing out the new and optional “disk signature” (4 bytes at offset 440 [0×1B8 in hex]) of the MBR:

— mbr.doesntwork.hex 2010-04-16 20:04:35.000000000
+++ mbr.works.hex 2010-04-16 20:04:26.000000000
@@ -25,7 +25,7 @@
0000180 bb 01 00 fc ac 3c 00 74 06 b4 0e cd 10 eb f5 c3
0000190 0a 0d 62 6f 6f 74 30 3a 20 00 65 72 72 6f 72 00
00001a0 47 50 54 00 74 65 73 74 69 6e 67 00 64 6f 6e 65
-00001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
+00001b0 00 00 00 00 00 00 00 00 10 b8 29 01 00 00 80 00
00001c0 14 00 af fe ff ff 13 00 00 00 ad 60 49 06 00 fe
00001d0 ff ff 83 fe ff ff c0 60 49 06 c0 60 49 06 00 fe
00001e0 ff ff 07 fe ff ff 80 c1 92 0c 00 cd 0e 06 00 00

So Windows 7 (I assume since the new BOOTMGR was introduced in Vista) uses this disk ID to identify the boot device for startup, sigh!

Finally I know why Chameleon ships a custom fdisk, though their README could be clearer, e.g. using a “./” prefix in their sudo calls, and pointing out that preserving the disk UUID is vital for Windows versions since Vista.