PrivateTax auf Mac OS X 10.7 Lion installieren

Schon wieder ein Hack! Diesmal auf Deutsch weil mit geographisch eng beschränktem, aber grossem Nutzen für diejenigen, die wie ich auf den letzten Termin im Kanton Zürich die Steuererklärung 2010 einreichen müssen, und einen Mac mit 10.7 Lion haben.

Wie jedes Jahr habe ich mir dazu das kostenlose Programm "Private Tax 2010" heruntergeladen. Da stellt sich heraus, dass dieses Programm einen PowerPC-Mac oder Rosetta benötigt, und deshalb auf Lion gar nicht installierbar ist. Toll! 5 Jahre nach der Umstellung auf Intel bei Apple!

Doch halt - PrivateTax ist doch ein Java-Programm? Das hat doch nix mit Intel/PowerPC zu tun? Ein Blick in das "" Package zeigt sofort den Schuldigen: da ist eine Uralt-Version von InstallAnywhere (von 2006) drin.

Da war wohl jemand zu geizig (wir müssen schliesslich Steuergelder sparen, jaja), die Lizenz auch nur einmal in den letzten 5 Jahren zu erneuern.

Zum Glück ist die Lösung recht einfach: Man suche sich irgend ein halbwegs aktuelles anderes Mac-Programm, das mit InstallAnywhere installiert wird (Google - "mac installanywhere" findet allerlei). Nun öffnet man im Finder mit "Rechtsclick->Paketinhalt anzeigen" die "" von PrivateTax und die entsprechende *.app des anderen Programms (die muss nicht unbedingt "" heissen). Aufgeklappt sehen die Inhalte auf beiden Seiten etwa so aus:

PrivateTaxInstallerContentsDas angewählte "Setup" ist das Binary des InstallAnywhere, das im Fall von PrivateTax PPC-only ist. Dieses wird nun einfach durch das entsprechende Binary aus dem neueren Installer ersetzt (wenn es im anderen Installer anders heisst, einfach in "Setup" umbenennen).

Damit ist der Installer modernisiert. Jetzt einfach direkt das "Setup"-Binary doppelclicken, dann öffnet sich ein Terminal, der Installer startet normal mit GUI, und PrivateTax lässt sich installieren. An der Stelle dachte ich schon: Geschafft! Leider noch nicht ganz.

Denn die installierte App "Private Tax" ist technisch selber wieder ein InstallAnywhere. Das heisst, es hat genau dieselbe Struktur wie oben gezeigt, und genau dasselbe veraltete Binary, diesmal heisst es aber "Private Tax 2010". Also braucht es den gleichen Trick nochmals - einfach auch hierhin das Binary aus dem neueren Programm kopieren, und es "Private Tax 2010" nennen.

Als Letztes muss nun noch das Cache von Mac OS X überlistet werden, welches immer noch fest glaubt, die installierte App sei PowerPC-only, und darum den Start verweigert. Das geht, indem die ganze "Private Tax 2010"-App (aus /Applications/Private Tax 2011) an einen anderen Ort hin und wieder zurück kopiert wird. Dabei verschwindet die Verbotstafel auf dem Icon, und ab jetzt ist der Start ganz normal möglich.

Das alles selbstverständlich, wie bei jedem Hack, nur ganz auf eigenes Risiko durchführen!

Bei mir hat es prima funktioniert, ohne Nebengeräusche beim Benutzen von PrivateTax nachher.

Fröhliches Steuererklärungsausfüllen!

How to make the MacBook Air SuperDrive work with any Mac

Note: for Mac OS X 10.11 El Capitan and later, please see this updated post instead.

(Edited/clarified Nov. 2012, Nov. 2013, Jan 2015 and June 2016)

The story is this - a while ago I replaced the built-in optical disk drive in my MacBook Pro 17" by an OptiBay (in the meantime, there are also alternatives) which allows to connect a second harddrive, or in my case, a SSD.

To be able to continue using the SuperDrive (Apple's name for the CD/DVD read/write drive), the Optibay came with an external USB case which worked fine, but was ugly. And I didn't want to carry that around, so I left it at home and bought a shiny new MacBook Air SuperDrive (by 2012, Apple USB SuperDrive) for the office.

It just didn't occur to me that this thing could possibly not just work with any Mac, so I didn't even ask before buying. I knew that many third-party USB optical drives work fine, so I just assumed that would be the same for the Apple drive. But I had to learn otherwise. This drive only works for Macs which, in their original form, do not have an optical drive.

At this point, I started to search the net, finding hints, disassembling Mac OS X USB drivers and finally patching code in a hex editor which was the first, but ugly, solution to make the superdrive work, and gave me the information to eventually find the second, much nicer solution presented below. For those interested in the nitfy details of disassembling and hex code patching, the first approach is still documented here.

For actually making the SuperDrive work in clean and easy way, just read on (but note: while it has proven to be a quite safe method, still you'll be doing this entirely on your own risk! Using sudo and editing system files incorrectly can damage things severely!).

Apparently, Apple engineers had the need to test the superdrive with non-MacBookAir computers themselves, so the driver already has an option built-in to work on officially unsupported machines! All you need to do is enable that option, as follows:

The driver recognizes a boot parameter named "mbasd" (Mac Book Air Super Drive), which sets a flag in the driver which both overrides the check for the MBA and also tweaks something related to USB power management (the superdrive probably needs more power than regular USB allows). So just editing /Library/Preferences/SystemConfiguration/ and inserting the "mbasd=1″ into the "Kernel Flags" does the trick:

[For OS X 10.11 El Capitan onwards please see here for updated instructions instead!]

  1. open a terminal
  2. type the following two commands (two lines, each "sudo" starting on a new line)

    sudo plutil -convert xml1 /Library/Preferences/SystemConfiguration/

    sudo pico /Library/Preferences/SystemConfiguration/

  3. Insert mbasd=1 in the <string></string> value below the <key>Kernel Flags</key> (If and only if there is already something written between <string> and </string>, then use a space to separate the mbasd=1 from what's already there. Otherwise, avoid any extra spaces!). The file will then look like:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
    <plist version="1.0">
    <key>Kernel Flags</key>

    [Important update for users of Trim Enabler (thanks boabmatic!): Since Yosemite, installation of Trim enabler puts another flag "kext-dev-mode=1" into the, and, unfortunately, also converts the .plist to binary format which shows as mostly garbage in many text editors (that's what the "plutil" line in step 2 above takes care about: it converts the file back to XML so you can edit it). Note that the system will not boot any more when trim enabler is installed, but "kext-dev-mode=1" is missing! So to apply the "mdasd=1" with trim enabler active, you need to combine both flags, such that the line will read
    <string>kext-dev-mode=1 mbasd=1</string>. For details on Yosemite and Trim Enabler, see here]
    [Update: As CyborgSam pointed out in the comments, the file might not yet exist at all on some Macs. In that case, the pico editor window will initially be empty - if so, just copy and paste the entire XML block from above].

  4. Save (press Ctrl-X, answer yes to save by pressing Y, press enter to confirm the file name).
  5. Restart your machine. That's it!

I tested this [Updated:2013-11-03] on Lion 10.7.2 up to 10.7.4, Mountain Lion up to 10.8.4 and Mavericks 10.9 so far, but I expect it to work for all Mac OS versions that came after the initial release of the Macbook Air Superdrive, which is probably 10.5.3, and is likely to work with future versions of OS X. Just let me know your experience in the comments!

BTW: the boot options plist and how it works is described in the Darwin man pages

The only one who really cares about your data is you!

Once more, yesterday's Dropbox authentication bug shows a fundamental weakness of centralized services. Dropbox is just a high profile example, but the underlying problem is that of unneeded centralisation.

Every teenager who starts using facebook is told how important it is to wisely choose what to put online and what not, and always be aware that nothing published on the internet can ever be completely deleted any more.

However, the way popular "cloud" services are built today unfortunately just ignore this, and choose a centralized implementation. Which means uploading everything first, and then trying (and sometimes sadly failing, like dropbox yesterday) to protect that data from unauthorized access.

Why? Because it is easier to implement. Yes, distributed systems are much harder to design and implement. But just choosing a centralized approach is inevitably generating single points of failure. I really don't think we can afford that risk for a long time any more.

It's not even only a technical problem. It's a mindset of delegating too much responsibility, which is fatal. Relying on a centralized storage to be "just secure" is delegating responsibility to others - responsibility that those others are unlikely to comply with.

The argument often goes: it's too hard for a smaller company to run their own servers and keep them secure, so better leave that to the big cloud providers, who are the experts and really care. That's simply not true. Like everyone else, they care about their profit. If they loose or expose your data, they care about the PR debacle this might be for them, but not for the data itself. The only one who really cares about what happens to your data - is you.

Even assuming the service provider was able to keep your data safe, there's another problem. As we have heard again in the discussion about Dropbox's TOS, there are legal constraints on what a cloud service may and may not do. For instance, they may not store your data encrypted such that "law enforcement" cannot access it under certain conditions. Which means that Dropbox can't offer encryption based on really private keys (only you have the key to your data, they don't) even if they wanted to.

What they could do, and IMHO must do in the long term, is offering a federated system. Giving you the choice to host the majority of data in a place where you are legally allowed to use strong encryption with your entirely private keys, such as your own server. Only for sharing with others, and only with the data actually being shared, smaller entities need to enter a bigger federation (which might be organized by a globally operating company).

That's how internet mail always worked - no mail sent among members of a organisation ever needs to leave the mail servers of that organisation. Same for Jabber/XMPP. This should become true for Dropbox, Facebook, Twitter etc. as well. They should really start structuring their clouds, and giving the option to keep critical data by yourself, without making this a decision against using the service at all.

Unfortunately, one of the few big projects that expressedly had federation on the agenda, Google Wave, has almost (but not entirely) disappeared after a big hype in 2009. Sadly, most probably exactly the fact that they did focus on federation and scalability so much and not on polishing their web interface, has made it a failure in the eye of the public.

Maybe we should really do away with that fuzzy term "the cloud" and start talking about small and big clouds, more and less private ones, and how and if they should or should not interact.

Still, one of the currently most opaque clouds is ahead of us - Apple's iCloud. Nothing at all was said in public about how security will work in the iCloud. And from what was presented, it seems for now it will have no cross-account sharing features at all.

The only thing that seem clear is that all of our data will be stored in that huge datacenter in North Carolina, so I guess that using iCloud when it launches in a few months will demand total trust on Apple to get it right (and as said above - this is a responsibility nobody can really take).

On the other hand, Apple could be foresighted enough to realize the need for federation in a later step, for example allowing future Time Capsules to act as in-house cloud server. After all, and unlike other players, Apple profits from selling hardware to us. And to base a speculation on my earlier speculation (still neither confirmed nor disproved), iCloud might be technically ready for that.

But whatever inherent motivation the big players may or may not have to improve the situation - it's up to us to realize there's no easy way around taking care of our data ourselves, and to ask for standards, infrastructure and services which make doing so possible.

iCloud sync speculation

Here's my last minute technical speculation what iCloud will be in terms of sync :-)

It'll be sync-enabled WebDAV on a large scale.

I spent the last 10 years working on synchronisation, in particular SyncML. SyncML is an open standard for synchronisation, created in 2000 by the then big players in the mobile phone industry together with some well known software companies.

SyncML remained a niche from a user perspective, despite the fact that almost every featurephone built in the last 9 years has SyncML built-in. And despite the fact that Steve Jobs himself pointed out Apples support for SyncML when he introduced iSync in July 2002 at Macworld NY.

As we have learnt by now, iSync (and with it, SyncML for the Apple universe) will be history with Lion. And featurephones are pretty much history as well, superseded by smartphones.

Unlike featurephones, smartphones never had SyncML built-in (a fact that allowed me earn my living by writing SyncML clients for these smartphone platforms...). The reason probably was that the vendors of the dominant smartphone operating systems, Palm and later Microsoft, already had their own, proprietary sync technologies in place (HotSync, ActiveSync). Only Symbian was committed to SyncML, but forced by the market share of ActiveSync-enabled enterprise software (Exchange) in 2005 they also licensed ActiveSync from Microsoft.

So did Apple for the iPhone. So did Google for Google calendar mobile sync. Third party vendors of collaboration server solutions did the same.

For a while, it seemed that the sync battle was won by ActiveSync. And by other proprietary protocols for other kinds of syncing, like dropbox for files, Google for docs, and a myriad of small "cloud" enabled apps which all do their own homebrew syncing.

Not a pleasant sight for someone like me who believes that seamless and standards based sync is as basic for mobile computing as IP connectivity was for the internet.

However, in parallel another standard for interconnecting calendars (not exactly syncing, see below) grew - CalDAV. CalDAV is an extension of WebDAV, which adds calendar specific queries and other functionality to WebDAV. And WebDAV is a mature and widely deployed extension of HTTP to allow clients not only reading from a web server, but also writing to it. Apple is a strong supporter of WebDAV since many years (iDisk is WebDAV storage), and is also a driving force behind CalDAV. Mac OS 10.5 Leopard and iOS 3.0 support CalDAV. And more recently, Apple implemented CardDAV in iOS 4.0 and proposed it as an internet draft to IETF, to support contact information the same way as CalDAV does for calendar entries.

This is all long and well known, and CalDAV is already widely used by many calendaring solutions.

There's one not-so-well-known puzzle piece however. I stumbled upon it a few month ago because I am generally interested in sync related stuff. But only now I realized it might be the rosetta stone for making iCloud. I did some extra googling today and found some clues that fit too nicely to be pure coincidence.

The puzzle piece is this: An IETF draft called "Collection synchronisation for WebDAV" [Update - by March 2012 it has become RFC6578]. The problem with WebDAV (and CalDAV, CardDAV) is that it is was designed as an access method, but not a sync method. While it is well possible to sync data via WebDAV, it does not scale well with large sync sets, because a client needs to browse through all the information available first just to detect the changes. With a large sync sets with possibly many hundred thousand files (think of your home folder) that's simply not working. The proposed extension fixes exactly this problem, and makes WebDAV and its derivates ready for efficient sync of arbitrarily huge sync sets, by making the server itself keep track of changes and report them to interested clients.

With this, a WebDAV based sync infrastructure reaching from small items like contacts and calendar entries to large documents and files (hello dropbox!) is perfectly feasible. Now why should iCloud be that infrastructure? That's where I started googling today for this blog entry.

I knew that the "Collection synchronisation for WebDAV" proposal was coming from Apple. But before I didn't pay attention to who was the author. I did now - it's Cyrus Daboo, who spent a lot of time writing Mulberry, an email client dedicated to make best possible use of the IMAP standard. Although usually seen as just another email protocol, IMAP is very much about synchronisation at a very complex level (because emails can be huge, and partial sync of items, as well as moving them wildly around within folder hierarchies must be handled efficiently), so Cyrus is certainly a true sync expert, with a lot of real-world experience. He joined Apple in 2006. Google reveals that he worked on the Calendar Server (part of Mac OS X server supporting CalDAV and CardDAV), and also contributed to other WebDAV related enhancements. It doesn't seem likely to me they hired him (or he would let them hire him) just for polishing the calendar server a bit...

Related to the imminent release of iCloud, I found a few events interesting: MobileMe users had to migrate to a new CalDAV based Calendar by May 11th, 2011. And just a month earlier, Cyrus issued the "WebDAV sync informal last call" before submitting the "Collection synchronisation for WebDAV" to IETF, and noted that there are "already several client and server implementations of this draft now". And did you notice how the iOS iWork apps just got kind of a document manager with folders? After becoming WebDAV aware only a few months ago?

So what I guess we'll see today:

  • a framework in both iOS5 and Mac OS X Lion which nicely wraps WebDAV+"Collection synchronisation for WebDAV" in a way that makes permanent incremental syncing for all sort of data a basic service of the OS every app can make use of.
  • a cloud based WebDAV+Sync storage - the iCloud
  • a home based WebDAV+Sync storage - new TimeCapsules and maybe AirPorts
  • and of course a lot of Apple Magic around all this. Like Back-to-my-Mac and FaceTime are clever mash-ups of many existing internet standards to make them work "magically", there will be certainly more to iCloud than just a WebDAV login (let alone all the digital media locker functionality many expect).

In about 5 hours we'll hopefully know...

Weit hergeholt? Der Appstore und das Grundeinkommen

In fast jeder Diskussion zum bedingungslosen Grundeinkommen (BGE) kommt die Frage auf, weshalb denn der Steuerzahler das finanzieren soll. (Was ist BGE? S. z.B. hier oder hier)

Wer sich mal die Finanzierungsmodelle angeschaut hat, weiss, dass bei einem BGE nicht mehr umverteilt würde, sondern vor allem auf eine andere Weise.
Aber was bringt diese "andere" Weise (die Bedingungslosigkeit) denen, die heute kein Grundeinkommen brauchen? Diese fragen sich, weshalb sie Steuern zahlen sollen und einfach hoffen, dass die Menschen damit via BGE Sinnvolles tun, anstatt auf der Kontrolle, also den bedingten Sozialleistungen, zu bestehen.

Das ist eine sehr zentrale Frage, deren Beantwortung aber im Theoretischen sich nur aus dem Menschenbild der Antwortenden ergeben kann. Ob der Mensch sozial oder doch rein eigennützig sei, darüber lässt sich trefflich und endlos streiten.

Umso überraschender ist es, ein Grundprinzip des BGE, nämlich die Leistung nicht im Nachhinein zu entschädigen, sondern durch einen Vorschuss zu ermöglichen, an einem ganz unerwarteten Ort eingenistet zu entdecken.

Dieser Ort ist der AppStore, der on-line Laden für Zusatzprogramme (Apps) für das iPhone und das iPad. Dort ist in den zweieinhalb Jahren seit Eröffnung im Sommer 2008 eine neue Art von Software-Markt entstanden, den es vorher nicht gab. Zuvor kosteten Programme dieser Art, wie sie auf einem Mobiltelefon laufen, mehrere dutzend Geldeinheiten. Der AppStore hat aber mit einer (willkürlichen) Vorgabe gestartet, dass eine App nicht mal ein Zehntel davon kosten sollte, also meist weniger als eine Tasse Kaffee.

Die Freude beim Publikum war gross, und einige Apps liefen deshalb dermassen gut, dass die Hersteller auch mit dem Spottpreis so richtig reich wurden. Das sind die Goldgräbergeschichten, die durch die Medien breit gefeiert wurden.

Der Aufwand aber, eine App zu schreiben, ist nicht kleiner als früher. Deshalb setzte bei den Entwicklern bald Katzenjammer ein. Wie soll man von den Spottpreisen leben können, wenn man nicht einen Top-Hit landet? Das war der Tenor der Diskussion vor ca. einem Jahr.

Diese Frage ist natürlich nicht vom Tisch. Es ist die Frage danach, wer denn jetzt die 90% bekommt, um die der Durchschnittspreis gesunken ist. Nur wer 10 mal mehr verkauft als früher, hat gleichviel wie damals. Und, warum sollte das, ausser bei einzelnen Glücklichen, der Fall sein?

Eine Antwort: Weil sich das Verhalten der Kunden geändert hat. Früher (und heute noch beim klassischen Softwareverkauf) haben diese 10 kostenlose Demoversionen ausprobiert, und schliesslich diejenige, die am Besten gefiel, für z.B. 20 Geldeinheiten gekauft. Alle anderen hatten zwar Aufwand mit dem potentiellen Kunden, gingen aber leer aus. Im AppStore hingegen werden für eine Aufgabenstellung viel eher einfach einige App-Varianten für je ein, zwei Geldeinheiten gekauft. Eine davon ist dann schon die richtige. Die total ausgegebene Summe ist pro Kunde und Aufgabenstellung etwa dieselbe.

Man kann dieses lockere App-Kaufen nun bloss als weiter angeheiztes Konsumverhalten mit neuen Mitteln sehen. Ich glaube aber, da spielt sich etwas ab, das sich im Kontext des Grundeinkommens näher zu betrachten lohnt. Denn das lockere Kaufen, das sich hier zeigt, weicht die klassische 1:1-Forderung nach direkter Gegenleistung für jede Geldausgabe auf.

Ich zahle mehrmals einen geringen Beitrag fürs Ausprobieren, streue quasi Geld aus, ohne im Vornherein zu wissen, ob ich das gesuchte Ergebnis wirklich bekomme. Aber im Vertrauen, dass im Schnitt schon jemand die gewünschte Gegenleistung erbringen wird, und eine App liefert, die mein Bedürfnis erfüllt. Dass ich dabei 9 anderen, die mein Bedürfnis nicht erfüllt haben, auch Geld gegeben habe, vielleicht sogar jemandem, der wirklich lausige Arbeit gemacht hat, stört nicht oder kaum. Soweit: nichts verloren – ich komme immer noch auf meine Kosten.

Was aber habe ich gewonnen? Die Entlastung vom Kontrollaufwand! Keine Angst mehr, vielleicht das Falsche schmerzhaft teuer zu kaufen. Die konkrete Erfahrung, dass im Schnitt, trotz Betrügern, Blendern und Schmarotzern, ein brauchbares Return on Investment herausschaut. Und ich lerne mehr Produkte kennen – auch wenn sie für mich nichts taugen, so erfahre ich etwas darüber, was anderen gefällt.

Nun, an sich ist die Erkenntnis recht trivial. Risikokapitalgeber arbeiteten schon immer so. 10 Versuche, 9 in den Sand gesetzt, doch einer gelingt und bringt mehr.

Dass sich dieses Verhalten in einem hochkompetitiven Markt für Endkunden, denen man in letzter Zeit kaum mehr als "Geiz ist geil" zugetraut hat, herausbildet, finde ich jedoch interessant.

Und noch mehr die Anschlussfrage: was hat denn dazu geführt? Meiner Meinung nach im Wesentlichen ein einziger Parameter – die willkürliche Herabsetzung der Preise auf einen Zehntel. Oder anders herum betrachtet: die Tatsache, dass den Kunden potentiell die 10-fache Kaufkraft einfach mal gegeben wurde, ohne Bedingung. Das hat aber nicht dazu geführt, dass einfach 90% des Umsatzes in diesem Markt wegbrach, obwohl man das rechnerisch durchaus hätte befürchten können (und auch hat).

Massiv verringert hat sich nur die Abhängigkeit des einzelnen Kunden vom einzelnen Anbieter. Nicht aber die Bereitschaft der Kundschaft als Ganzes, der Anbieterschaft als Ganzes genug Geld zukommen zu lassen. Und auch nicht der Anteil dessen, was der Einzelne von seinem (klassisch durch eigene Leistung verdienten!) Einkommen dafür einsetzt.

Ich will diese Beobachtung nun nicht als "Beweis" ins Feld führen, dass ein Grundeinkommen funktionieren wird. Aber ich möchte dazu anregen, mit den Behauptungen und Befürchtungen auch in scheinbar weit entfernten Kontexten wie diesem intensiv zu spielen.

Zum Beispiel weiterzuspinnen, und anhand der zwei verschiedenen Kontexte auch mal zu versuchen, die Befriedigung durch Konsum etwas zu sezieren. Worin liegt dort die Befriedigung? Worin der Betrug, die Sucht? Könnte es etwa die (vermeintliche) Unabhängigkeit, die Selbstständigkeit des Kaufentscheids sein, die so attraktiv ist? Und wenn, könnte es gesellschaftlich nicht effizienter und gesünder sein, diese Unabhängigkeit tatsächlich zu gewähren, anstatt sie nur durch immer raffiniertere Taktiken vorzuschützen, gleichzeitig aber Entmündigung voranzutreiben?

Why doesn't this exist already? [August 2010: now it does]


Why doesn't this kind of device exist for a long time already?

Since I have a MacBook PRO which allows using multitouch gestures on the trackpad (especially scroll and zoom) I miss these a lot when I work on a desktop Mac.

The "photo" above is of course a very amateurish work of Photoshop editing my external keyboard and and the MacBook's trackpad together.

However, should I get access to a broken MacBook body with the trackpad still functional before Apple or someone else makes a real product like this, I'd probably try to create one myself.

As the internal trackpad is a regular USB device (only connected internally), all I'd have to do would be connecting it to a normal USB cable, cutting the Trackpad plus the needed frame material from the MB(P) body, and putting everything together in a decent housing, probably made from a thick sheet of aluminium. I guess I'll be better at doing that in the workshop than in photoshop…

Donations of broken MBP cover plates are welcome - pointers to external trackpad products that might already exist as well, of course! But remember, it's the multi-touch I look for, not just an external trackpad.

[Update: just saw this product - altough it is for PC only and looks ugly to me, it is a step into the right direction. Still, I guess Apple's rumoured multi-touch mouse is more likely to provide what I am looking for]

[Update2: Indeed, it looks like Apple just released (kind of) what I was looking for: The Magic Mouse.]

[Update3 - August 2010: The Magic Mouse was a first step, but apparently they have really listened (to me? ;-)) and thus created the Magic Trackpad. I already got one and yes, it's exactly that what I wanted]