René Rebe

Yes, there have been long enough flamewars to no end, and we know where Minix and Linux stand today in regards to the installed device base, … however, modern Windows NT, and Mac OS X are a bit micro kernel’ish to some degree, …

In wake of last twelve months (and counting) NSA, GCHQ & Co revelations let’s look at the processes running on a typical network appliance:

PID Uid VmSize Stat Command
1 root 364 S init
2 root SW [keventd]
3 root RWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
8 root SW [mtdblockd]
35 root SWN [jffs2_gcd_mtd2]
87 root 364 S logger -s -p 6 -t
89 root 364 S init
96 root 376 S syslogd -C 16
99 root 348 S klogd
230 root 388 S udhcpc -b -p /var/run/udhcpc.eth0.1.pid -i eth0.1
314 root 388 S /usr/sbin/dropbear -g

Hm, ok, so aside the minimal logging, dhcp server and the dropbear SSH server for administration tasks we got nothing separated in the user-mode context. All the networking, packet filtering, firewalling, load balancing, WiFi stack and what not is all running in the kernel context.

Yeah, right, exactly that kernel context where a typo, off-by-one, etc. pp. likely sooner than later crashes (oops) the whole system, or gives you a root login.

Would it not be nice if such a typo, bug, … in the NIC driver, the IPv4 or v6 stack, or firewall, or mostly anywhere else would just segfault, and restart an associated user-space ipv4d, iptabled, hosted?

With more isolated drivers and sub-system we certainly should have rather less security issues, and given Linus’ famous performance quotes - I do rather trade some percent of performance for more security. Besides, nowadays we run most systems virtualized with even more performance overhead, … for security, management and scalability.

When Apple introduced the massively blurred translucency in iOS 7 I already was skeptical weather that vast amount of number crunch is really worth anything. Wasted for some background effect. Just making everything less snappy and wasting battery life.

Now Apple extends this blurry transparency to Mac OS X 10.10 -Yosemite- (a really bad name to pronounce internationally btw.), and also letting Apps like iPhoto scroll the view content, blurred under the window’s title- and toolbar.

I recently got a pretty fast 15″ rMBP w/ Nvidia GPU to drive my 4k display at work. Of course OS X -10.9 and such- is super snappy on that. Now guess what? The current Mac OS X 10.10 beta with this blurred, transparent windows makes them all bit sloppy to drag around over the screen. This flat UI would normally be a snap to draw for the GPU. No gradients to compute, or bitmaps to blit, … just solid fills. But no, just waste all the GPU power while at it :-/!

Planned obsolescence at it’s best. For nothing. Well, except blurry background content.

You can go ahead and google Gausian blur, and do the calculations of operations required for it. Not to forget the massive radius Apple must be using for this, …

There would be some optimization possibilities, such as not using each pixel, only every 4th or 8th for this blurry madness, though, …

I hereby publicly document a novel implementation detail for Just-In-Time compilers. As I am not too motivated to shell out some ton of money for patent process and therefore like to document prior art in case other go and patent this eventually:

AFAIK the state of the art JIT compilers use a tracing technique like in Google’s V8, Mozilla’s SpiderMonkey and Mike Pall’s LuaJIT that first interprets internal byte code representation to collect data for later JIT’ing hot paths.

This has two major drawbacks: Interpreted code is initially slower, and in addition to the actual JIT “backend” an “interpreter” engine needs to be implemented.
(more…)

As long as the better Android phones are still shipped with region lock and worse battery exchange / repair than iPhone I say: Thanks but no thanks - and stay with the iPhone. Unless of course future models make battery change even harder as well, … :-/

ExactScan Pro had the ability to batch process existing files for quite some time. The Pro version allows to process existing, e.g. archived files as if they came fro the scanner. This allows for TIFF to PDF conversion, adding OCR for searchable documents, adjust colors, compression or whatever your use case or workflow requires.

As we constantly listen to customer feedback carefully and try to work suggestions into our product we further improved this batch feature to also allow to use the input filename as output filename. Before this change the ExactScan logic for scanning documents would have defined the new output filename - which would be something like: ~/Documents/Scan-{Page#}.png or similar.

Since yesterday’s 2.27.4 release we added a new file naming token: {Filename} which is exactly what you would expect now: the original input filename. For this to work you also need to set the Directory to the file-system root: / as the {Filename} expands to the whole input file. We first thought to simply make the new token just the base filename without the whole path. However, that way the file would not end up in the same directory, e.g. ~/Documents instead.

While at it we also added a new {Resolution} token, allowing to name your scans with the actually scanned resolution in the filename, like: Scan-{Page#}-{Resolution}dpi.pdf.

Made in Berlin; Germany.

Just a quick note: The affordable, and color accurate 24″ 4K display from Dell (UP2414Q) does work on recent Macs. Even my not so recent mid-2012 Retina MacBook Pro. However, on these, and even the later Retina MacBook Pro it only runs the full 4k resolution at 30 Hz. On the newer it should work with 60Hz, but this currently looks to be a Mac driver limitation.

Switching to HiDPI mode requires some hackery, as Mac does neither do this automatically according to the DPI that could be derived from the DDC EDID data, nor does it offer a UI option to do so, … :-/
(more…)

For me it is no surprise that most vendors stopped adopting the “RT” flavor of Windows. The main reason people want the old, and buggy pile of junk that is the decade old legacy Windows code are exactly that: legacy Windows apps. Be that office, industrial, games, what not, …

With Windows “RT” you do not get anything of that. Worse: Developers can not even re-compile their existing apps for the “RT” desktop. I guess there would be plenty of smaller, and also bigger Windows companies who would do so with pleasure. But no: Microsoft just would not allow for that. What a pity. And a fail trying to copy Apple even up to the software lock in. For Apple it certainly only works because they had awesome looking and a pleasure to use software on (r)evolutionary hardware. And after a head-start they had enough customers locked into their eco system. But people do not love Microsoft like that. Au contraire: after decades of crashing DOS and Windows, and hindering competitors due their monopoly powers people do not want to be locked into a Microsoft product or eco system yet again. So for Microsoft to gain traction it would have made much more sense to allow side-installs like on classic Windows boxes just as well.

Oh, and then there is the SecureBoot (or what it is called for Windows on ARM). So developers, researchers, students and enthusiast can not even buy the hardware from the overfilled and non-selling Surface RT stock to put Linux or any other of their own OS flavor on it, … :-/

Usually I’m not in this “unboxing” and “hands-on” business. But as the Microsoft Surface Pro 2 arrived early, this morning, here go some public service unboxing shoots:

In generally a quite good first impression, especially as I’m getting so tired of the scratchy and hard edged aluminum cases in Apple’s PowerBooks MacBooks, iPhones and iPads, …

Some first notes: Given the two kickstand positions, I wonder how the 1st, old snap-in position ever could be useful, … For me the 1st position is not even a good match on an office desk, … And why (the heck) is the BIOS/EFI (hold volume [rocker] up button while powering up to get into the EFI BIOS) startup background so ugly red when SecureBoot is disabled (to install Linux and such)?!?!

Update: If the original Surface Pro battery life was short, the v2 definitely is well an improvement for that. 7h battery life for normal office, developer tasks are quite possible. Your milage may vary. However as non-Windows users I’m a bit irritated that still some old fashioned dialogs are not resolution aware, and thus scaled-up blurry. For example System Control ones, like detailed network settings, e.g. static IP config and such, … One should think a huge company like Microsoft gets all such system-wide details covered over the years, …

Update 2: The machine feels pretty solid, in ways quite outstanding engineering, … I just can not get so warm with the Touch and Type covers. The Touch Cover does not really register every key touch, leading to re-typing some words again, and the Type cover too does not feel too solid, with the fabric edges looking like they may peel off as known from the first try already, …

Update 3: Looks like the Surface Pros will only boot thru EFI, that is no legacy BIOS compatibility “layer” in the EFI firmware (BIOS). So you need a “bleeding-edge” Linux distributions and can not boot older versions, nor Windows XP or such, …

I updated my ExactImage-based QuickLook plugin to also support camera RAW images.

Just some week ago I got myself a Sony Nex 5 camera, and used to shooting RAW images for the superior post-production quality with my former, aging Canon EOS 350 I had to notice Mac OS X (10.7) does not support the Sony Nex RAW images by default. There is a camera raw update, but it apparently only installs with iPhoto or Aperture installed, which I do not plan to purchase.

So I finally updated the dcraw support in ExactImage and rebuild the QuickLook plugin with the new support for RAW files, enjoy: 1.8 update w/ camera raw support

If you have another image format you like to preview on the Mac just let me know! Especially if you have camera RAW images that you would like to preview, I likely have to add the file UTI for other files to load, too.

For some time now we had some simple email registration for the free trial of some of our software products. We are aware that some users do not like it, however, we are a small company and also need to think about some trial follow up reminder, questionnaire, etc.

Of course most annoying for us are invalid email addresses, causing bouncing error messages, blocking our email server, support accounts or a combination of those, … So after some week of too many delivery errors we ended up adding some basic input validation. However due to the complex nature of HTML, Javascript, and XML-RPC based AJAX or variants thereof we only, quickly did so in the JavaScript. Just some simply straight forward checking. You certainly get the idea. For normal customers that worked great.

Guess what happened next? Java spam bots eventually found the form and started feeding the usual v1a6ra, and other related medical, drug and other spam thru the form. Of course they where usually sending some random email address for their spam, resulting in the same, and in the end even higher amount of email delivery errors than we wanted to prevent initially.

After too long time the pain became too big. Yesterday we finally moved the input validation into our server backend as it should be. Never trust the client, always validate 100% on your final server side. Of course one shoudl do so from the beginning. Just that Web 2.0, with HTML, Javascript and all the surrounding “technologies” are such a complex, error prone, and not so easy to debug mess, that this is unfortunately a rather complex affair, …

Let’s see what annoying trickery comes next to that simple form, … ;-)