Ich gab’s ja zu, theoretisch ist mir die Abhängigkeit von Google ja bekannt und sie ist nur virtuell minder schlimm als die Abhängigkeit, in die man sich mit einem Apple-Gerät begibt. Allerdings geht »don’t-be-evil«-Google subtiler vor.
Klar, beim Start eines Android-Gerätes wird man dezent darauf hingewiesen, daß ohne Account bei Google die Erfahrung keine Schöne sein wird. Und auch im Betrieb fällt gelegentlich auf, daß man ja doch deutlich mehr in Richtung Google preisgibt, als man gemeinhin preisgeben wollen würde. Dazu eine Anekdote am Rande von Dienstag, Einkauf im Getränkemarkt:
Verkäuferin: Haben Sie auch die Deutschland-Card?
Ich: (etwas energischer als geplant) NEin.
V: Oh, das war deutlich. (grinst leicht)
I: Naja, irgendwann ist auch mal gut mit den ganzen Plastikkarten ….
V: Ja, ich hab’ sie auch nicht. Muß ja nicht jeder wissen, was ich alles zum Essen einkaufe …
Eigentlich ein wahres Wort. Und daß ich bei jedem Start der Google-Suche Google meinen Standort mitteile, ist eigentlich auch nicht meine Idee gewesen — die Macht der Voreinstellungen … Allersdings fällt die Abhängigkeit in der Regeln ja gar nicht auf; wir geben Google Real-Life-Data, im Gegenzug dürfen wir deren Dienste (frei) nutzen.
Aber heute bekam meine schone Android-Google-Welt einen Dämpfer, ja fast den Todesstoß: »Google Konto vorrübergehend deaktivert« beschied man mir, als ich mich per Web bei Google-Mail anmelden wollte; meine Androiden monierten nur ein angeblich falsches Passwort — was irgendwie nicht stimmen konnte.
Warum, wieso, weshalb: Google verrät’s nicht. Und außer einem Ausrufungszeichen in der Android-Statuszeile gibt es keinen weiteren Hinweis, Googles Dienste stellen die Funktion stillschweigend ein. Die Entsperrung war simpel; nur die Frage bleibt, was ich getan haben soll. Schließlich kann ich ein Verhalten nur dann ändern, wenn ich darum weiß, daß es unerwünscht ist …
Einen ziemlich faden Nachgeschmack hat diese Aktion seitens Goggle bei mir hinterlassen; einfach *schnipps* so von elementaren Diensten wie dem Kalender abgeschnitten zu sein, das saugt.

Der eine oder andere Follower mag’s mitbekommen haben, vor ein paar Nächten lieferte ich mir mit Teymour aka @icedsoul src=”http://blogdoch.net/images/twitter_image_icedsoul-2_thumb.png” float=”left”/> ein kleines Zwiegespräch auf twitter (ein nahezu vollständiger Abzug unten; da twitter nur den Rückwärtsbezug kennt, fehlen ggf. mehrteilige Antworten, auf die nicht »nach oben« geantwortet wurde) über Sinn und Unsinn von Apple, iPad, WePad, auferlegten Fesseln durch Apple vs. Rechten des Geräteeigentümers, … Nein, twitter eignet sich nicht wirklch dafür — aber offensichlich hatten wir beide ein Mitteilungsbedürfnis ;)
Heute morgen nun kam ein Tweet von @pixelpipe rein, der mich wieder einmal darin bestätigte, in Apple keinen vertrauenswürdigen Geschäftspartner zu sehen. Denn Apple hat Pixelpipes iPhone-App gekickt:

Another app pulled from the iPhone App Store, this time it’s Pixelpipe

March 27, 2010 · 5 Comments

After over a year in the iPhone App Store and a half dozen separate approved submissions, Apple has unfortunately decided to remove our application from the store. While I admit we were cutting some corners to provide functionality outside the API we were not using any private APIs & just being creative with-in the bounds of the of the public media directory.
What were we doing wrong? Simply scanning the contents of the DCIM directory to create a list of the photos & video. This provided our users with the capability to quickly multi-select any media from their photo gallery for upload instead of the one at a time functionality provided with-in the official API.
What makes this most unfortunate though is the fact it was another developer that complained about the functionality we were providing outside the official API, Apple was forced to react to the complaint & remove our application.[…]

 
Sofern ich das richtig verstehe, bietet also Apple keinerlei API an, um mehrere Mediendateien in einem Rutsch zu selektieren und einer Anwendung App zur Bearbeitung zuzuführen — schon das würde mich ja nerven, aber wer mit einer Maustaste klarkommt, klickt vielleicht auch gerne öfter … Anyway; @pixelpipe hat offensichtlich drum herum programmiert, sodaß deren App benutzerfreundlich arbeiten kann — was einem anderen App-Autoren mißfiel und der sich bei Apple beschwerte; daraufhin kontaktierte Apple @pixelpipe und forderte mit Fristsetzung von einer Woche eine Codeänderung, anderenfalls würde man die App aus dem Store schmeißen.
Mag das auch alles formal seine Ordnung haben, dieser Vorfall zeigt wieder einmal, warum ein geistig normal denkender Mensch sich nicht auf die Apple-Plattform einlassen dürfte: wenn es Apple gefällt, gibt es ggf. die Lieblings-App nicht mehr. @icedsoul argumentiere sinngemäß, daß natürlich Apple das Recht habe zu entscheiden, was auf deren Produkt an Apps laufen dürfe, und eben auch, was nicht:

@icedsoul 2010-03-27 02:55:26: @wusel naja seltsame einstellung. deren produkte dürfen auch deren regeln haben. und klar gibts alter. aber halt selten so gute.

 
Das sehe ich halt differenzierter; mit Apples App-Store, dem von Apple so konzeptionierten einzigem »legalen« Weg, Software, »Apps«, aufs iPhone zu bekommen, maßt sich Apple an, auch nach dem Verkauf der Hardware »iP…whatever«zu kontrollieren und zu bestimmen, was auf meinem Eigentum, dem Apple-Gerät nämlich, an Software installiert werden kann und was nicht. Ich denke, kein normaler Computernutzer würde sich von seinem OS-Hersteller vorschreiben lassen, welche Software er installieren darf und welche nicht; nicht zuletzt würden sicherlich die Kartellbehörden hellhörig, würde z. B. Microsoft aktiv die Installation von Firefox behindern.
Qualitätssicherung ist das eine; zensurmäßige Bevormundung der Kunden eine andere und dem Anschein nach tendiert Apple doch eher zu letzterem Verhaltensmuster :( Denn die Entfernung der @pixelpipe geschah augenscheinlich nicht wegen Nichtfunktion, sondern weil einem App-Mitbewerber es nicht gefiel, daß die Pixelpipe-App innovativ war.
Nunja. Apple und ich werden in diesem Leben wohl keine Freunde mehr; eigentlich schade, diese Wandlung des (gefühlten) damaligen Paulus’ Apple zum heute gefühlten Saulus miterleben zu müssen.
Hier nund der twitter-Austausch :)

Hachja. Nun wollte ich gestern »mal eben schnell« ein kurzes Video für die Großeltern zusammenklicken, welches deren Enkelin auf einer Schulaufführung zeigt — während der moderne Erwerbstätige ja flexibel zu sein hat, stellen mit zunehmendem Alter 300+ km Entfernung, zumal ohne adäquate Bahnanbindung, doch einen Hinderungsgrund dar, mal eben vorbeizukommen. Nunja, wozu gibt es DSL und/oder DVD, und schließlich rockt – für ein freies und kostenloses Tool – OpenShot ja die Hütte …
Nun, ich muß mein Urteil revidieren/konkretisieren: generell ist OpenShot ein feines Stück Software, unrund an vielen Ecken noch, aber imho auf dem richtigen Weg und weiter als vieles andere, was ich in dem Bereich gesehen habe. (Daß man chroma keying nicht auf einen Bereich beschränken kann, stört wahrscheinlich echt nur Leute wie mich, die keine Studioaufnahmen machen …)
Allerdings kotzt, Verzeihung, OpenShot 1.1.0 auf Ubuntu 9.10 ganz massiv ins Essen, wenn es MTS- (MPEG Transport Stream) Dateien meiner Panasonic TZ7 (AVCHD Lite, 1280x720p50, H.264-Video mit AC3-Audio) verarbeiten soll. Stimmt die Synchronität von Audio und Video bei komplett verwendeten Dateien noch meistens, ist ein Ton-Bild-Versatz beim Schnitt die Regel, die gelegentlich trotz Schnitt in OpenShot synchron bleibende Schnipsel bestätigen :(
Notgedrungen reencode ich die MTS-Dateien nach AVI — ja, leider reencode (ffmpeg -i $basename.MTS -vcodec libx264 -vpre hq -b 15M -bt 1M -threads 0 $basename.mp4), da ein simpleres Umpacken (mencoder $basename.MTS -ovc copy -oac copy -o $basename.avi) zwar von mplayer noch abgespielt wird inkl. Video, in OpenShot aber nur noch ein ziemliches fettes Audio-File ist. Any hint appreciated …
Warum das? Nun, mit den Mitteln von OpenShot – Bildschirm und Kopfhöhrer – Synchronität wiederherzustellen grenzt an eine Sisyphus-Aufgabe, zumal bei schlecht erkennbaren Lippenbewegungen. Da ist selbst das Reencode von x264 nach x264 mit 2 Frames pro Sekunde besser investierte Zeit …
Insofern möchte ich auch @_refugee_ nahelegen, beim angekündigten Test auf die unterschiedlichen Eingangsformate und deren Bearbeitbarkeit mit OpenShot ein Auge zu haben. (In meinem, final 20 Minuten langen, Zusammenschnitt gab es rd. einmal je halber Stunde Bearbeitungszeit einen Crash von OpenShot; ganz offensichtlich macht das Handling von x264-Streams zumindest in MTS-Containern noch massiv Probleme :( Ah, und apropros: OpenShot kennt kein Autosave; wer also MTS-Container beackert tut gut daran, häufiger seinen Bearbeitungsstand selbst zu speichen. Und keine Bange, wenn nach einem Crash & Reload des Projektes der Positionszeiger nicht mehr sich mitbewegt: einfach ‘n Schnipsel hinten anhängen, danach tat’s zumindest bei mir wieder …)