René Rebe

opensnoop didn’t really cut it, so here we go:

syscall::open*:entry
{
printf(”%s %s”, execname, copyinstr(arg0));
}
syscall::stat*:entry
{
printf(”%s %s”, execname, copyinstr(arg0));
}

For years the German flagship IT trade-shows loose visitors. The Systems is now even history. And last year the Embedded World and CeBIT managers were as stupid to use the same date for the shows???

Our company used to visit the Embedded World as guests. We always where considering to exhibit there, as we did on Linux shows, or the CeBIT. For our start-up every year it became more likely to join the Embedded World, however all abruptly stopped last year when (IIRC) the Embedded World for the first time happened to be the same days as the CeBIT.

It is certainly bad enough to loose visitors to competing shows overseas, such as the Computex or CES. But how can those regressing shows steal each other’s exhibitors and visitors? In the same country, week.

I doubt we are a single incident here. Like us certainly many more have partners at the other show or would like, or have to exhibit on both. There should be at least some days gab between the shows, to make it possible for more to attend both shows. This would still allow foreigners to optimize their travel schedule and visit both in one go. Another, I think even better, option would be to have half a year between both shows. For example move the Embedded World to the autumn. To better match product cycle and product placements.

But on exactly the same days?

The Apple Mac OS mouse cursor speed is one of those “love it, or hate it” domains. Personally I find the default speed already way too slow, always falling asleep on a fresh Mac install, or at the login window.

The max used to be barely endurable, so far, e.g. with the Mighty Mouse - until I got the Magic Mouse the other day. Directly compared the Magic Mouse moves way slower with at the same setting. No idea how Apple got this inconsistency in their own, few products. I also have no idea why mouse pointer movements can possibly be that slow. Not only the default, but also the maximal configuration value, …

Fortunately there is no limit behind the back, so you can tune it with:

defaults write -g com.apple.mouse.scaling -float 8

The 10.6.2 maximal UI value appears to be 3, …

Update: Some more review: The slowness aside, the Magic Mouse is pretty decent. The biggest improvement over the Mighty Mouse is the touch sensitive cover. The former microscopic scroll ball was prone to accumulate dirt inside and near to impossible to clean. (To really clean and remove dust and dirt from the ball axes one hat to cut(!!!) the glued mouse housing and disassemble it fully, …). So from this usability standpoint it’s a great improvement. The major downside is, that only a Bluetooth version is available. I personally find the weight of the two AA batteries too hefty - that was also already a problem with the Bluetooth Mighty Mouse. For my excessive workdays I would prefer a lighter, cabled version to reduce the wrist stress, …

However, while the “magic” features do not appear to work (out of the box) under 10.5, the pointer tracking appears to be way faster – 10.6 might artificially slow the magic mouse tracking down, … ?!

Yep, I just downloaded the Wireless Mouse Software Update 1.0 for Leopard and the Magic Mouse becomes as slow as under Snow Leopard, 10.6. Expands the Preferences, brings battery level indicator to the menu extra. Actually some 30MB download, unpacks to nearly 100MB. Just for a mouse driver! Well, the useless tutorial videos blow it up significantly, … Wished OS X would stay as lean and clean as it was in the beginning.

Update 2: Under normal, office-use conditions, the battery life with the shipped alkaline battery is just about a month. To safe the environment I always only use rechargeable batteries in any device after the first batch of shipped batteries died out. On an mid-quality (2400mHh NiMh Ansmann “Photo”) batteries I already had in the shelf it lasts way less, 1-2 weeks of busy office use :-( Guess I need to get a pair of higher capacity, quality, more expensive NiMH or even check out those new kinds of NiZN batteries. Hopefully those do not burn out the Magic Mouse :-)

Update 3: As the Ansmann 2400 mAh “Photo” NiMH batteries drained out so quickly, I got a pair of Ansmann 2850 mAh NiMH. However, I was surprised the Magic Mouse did not turn on at all!!! After a quick investigation it turned out that the surrounding plastic of the holder where the batterie +pole goes in is a little fat. The hole is simply too tiny for that pair of batteries!!! Who would have believed that, …

To: Apple Inc.: In the future please but a little more thinking into your basic, plastic structure. This is so unnecessary incompatible, most other equipment has just a rectangular area with a metal latch not posing exactly such problems, …

To compensate I placed a shim into the hole:

Attention: Due to the holes in the plastic foundation the shim can easily slip into the mouse, and you need to be pretty patient to shuffle it out again! My tip: By applying some magic -gravity-, holding the mouse up, into the air, with the bottom to the ground let’s the gravity magically support your shuffle game, …

To avoid exactly this in the future, I simply put adhesive foil (sticky tape) over the holes. In case you need a similar mod, maybe a good idea for you to do upfront to avoid slipping something into the mouse case in the first place.

Well, these days most news sites just publish the press releases of product announcements. Or re-tweet news from other sites. Personally I find really authentic, journalistic work such as the recent Tom’s Hardware video driver, 2D blitting vs. Windows 7 review particularly outstanding. Heck, they even wrote their own performance metric test utility for it!

With T2 r35579, I just added the required build system, configuration and glue to let the T2 SDE (System Development Environment) utilize clang and clang++ as the default C and C++ compiler. And I just successfully compiled the first packages on a x86-64/T2/Linux test build:

-rw-r–r– 1 root root 3949 Feb 16 15:41 9-atop.log
-rw-r–r– 1 root root 21444 Feb 16 15:45 9-libelf.log
-rw-r–r– 1 root root 55854 Feb 16 15:45 9-fontconfig.log
-rw-r–r– 1 root root 3827 Feb 16 15:45 9-renderproto.log
-rw-r–r– 1 root root 34883 Feb 16 15:46 9-libxext.log
-rw-r–r– 1 root root 12765 Feb 16 15:46 9-libice.log
-rw-r–r– 1 root root 22070 Feb 16 15:46 9-libsm.log
-rw-r–r– 1 root root 31354 Feb 16 15:47 9-libxt.log
-rw-r–r– 1 root root 15357 Feb 16 15:47 9-libxmu.log
-rw-r–r– 1 root root 15243 Feb 16 15:47 9-libxpm.log
-rw-r–r– 1 root root 12157 Feb 16 15:48 9-libxrender.log
-rw-r–r– 1 root root 13854 Feb 16 15:48 9-libxft.log
-rw-r–r– 1 root root 13782 Feb 16 15:48 9-libxkbfile.log
-rw-r–r– 1 root root 135931 Feb 16 16:00 9-openssh.log
-rw-r–r– 1 root root 344112 Feb 16 16:05 9-openssl.log
-rw-r–r– 1 root root 17024 Feb 16 16:06 9-screen.log

The resulting ssh and screen even worked as expected (so far, anyway).

(more…)

ExactCODE just released another major ExactScan product family update: the new version 2.9 brings vast improvements all over the App. Most notably are excessive image processing performance improvements. For weeks we did nothing else but revisit our algorithms and fine tuned line of code that stood out.

With years of solid foundation code at ExactCODE, ExactScan already was pretty solid. However, even we received reports about issues. So likewise, for months, we where tracking every single stability issue brought to our attention. All of this contributes to making the version 2.9 the most performing and stable release, ever.

It even comes with new, built-in scanner drivers. For example the new Avision D2 models are now all supported, e.g. the AV220D2+, AV320D2+, and various other (yet unreleased) models, even various other vendors.

Of course work continues on the next planed updated, 2.10. For this next, of course free, update we even have another major surprise for you. Stay tuned, it’s just some weeks of QA away.

Read more: ExactScan homepage

Day, life could be so great:

!> ./configure: line 14867: syntax error near unexpected token `$SDL_VERSION,’
!> ./configure: line 14867: `AM_PATH_SDL($SDL_VERSION,’

Damnit.

To quote David S. Miller:

“whirrr, whirrr, whirrrrrrrrr…” :-)

That’s the sound my brain makes when I’m working on low-level sparc code.

Well, it’s also the sound my brain makes when I look at this macros, of macros of generated and M4 processed script fluff. Just that low-level OS, SPARC, etc. code is certainly more entertaining, educating than this useless piece of sh*t script.

Update: And just because your compiler is accidentally not named “gcc”, or “cc”, you end up with gibberish like:

libtool –silent –mode=compile clang …
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `–tag’

Your system keeps telling you a locale is not supported by your system’s C library? For example:

svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct

or:

firefox: (process:4376): Gtk-WARNING **: Locale not supported by C library.
Using the fallback ‘C’ locale.

or even while compiling software, such as:

setlocale(LC_CTYPE,”en_US.UTF-8″) failed!
make: *** [extra/locale/c8tables.h] Error 1

You can use “localedef” to add them to the cache from the verbose source definitions:

localedef -i en_US -c -f UTF-8 en_US.UTF-8

Update: Note to self:

iconv -f windows-1252 -t utf-8 in.txt > out.txt

…, Clang is now self-hosting! Congratulation to the LLVM and Clang team around Chris Lattner.

Guess that’s the days where I should start making clang a system compiler option in T2, and leave GCC and it’s C days of the ’80s behind :-)!