Tribut an den Winter …

(Blogged via flickr)

Die Verbindungen am Schlauch haben nichts abbekommen; die beweglichen Geräte allerdings sind fast alle mehr (Bild) oder weniger undicht :( Waren die -1x Grad in der Gartenhütte doch zu viel Kälte?

Kamera: Vignette Vignette for Android

Android (Market), Für und Wider

Ich bin, als Kunde/Anwender, nicht 100%ig zufrieden mit dem, was Google bzgl. Android tut; die Fernkontrolle über Smartphone-Inhalte ist ein Punkt, die nicht-existente OS-Upgradepolitik ein anderer. Grade Letztes ist schon verstörend, so gibt es für mein HTC Magic »with Google« von Vodafone bis heute kein Update auf eine 2.x-Version — und schon vor längerer Zeit wollte z. B. Pixelpipe die Unterstützung für Android 1.5 einstellen …


http://blogdoch.net/images/CAP201006280933-2.png width=180 float=right]So pauschal kann man nicht sagen, daß ausländische Apps mit AMEX nicht bezahlt werden können …

Die Vorwürfe von Jon Lech Johansen bezüglich der Bezahlbarkeit von Anwendungen im Android Market allerdings erscheinen mir zu kurz zu greifen bzw. schlecht recherchiert:

In addition, the price for foreign apps is not displayed in the user’s local currency and developers do not have the option of customizing pricing by country. To make matters worse, you can’t pay for foreign apps using your Amex card or carrier billing. There’s also no support for in-app payments and changelogs (to communicate app changes).

 
Daß man fremde Währungen angezeigt bekommt ist latent vielleicht ärgerlich, ein Problem darin sehe ich als deutscher Europäer, der mit Schweizer Franken, Österreichischem Schilling, Dänischer Krone, Französischen Franc, Spanischer Peseta und nicht zuletzt Englischem Pfund aufgewachsen ist, nicht.

Franc, Schilling und Peseta sind, wie die Deutsche Mark, Euro-Geschichte; mit Franken, Pfund oder auch Krone muß ich aber nach wie vor ggf. umgehen können. In Zeiten eines noch immer relativ stabilen Wechselkurses sehe ich auch und grade für den Endkunden kein Manko darin, mit Frendwährungen konfrontiert zu werden.
Der zweite Vorwurf ist, daß man mit seiner Kreditkarte von American Express – AMEX – »nicht für ausländische Apps zahlen« könne; nun, diese Aussage ist zumindest für eine deutsche AMEX-Karte im deutschen (gibt’s andere?) Android-Market nicht richtig für (manche? Bei mir bislang alle) Apps, die in USD abgerechnet werden. Aber mit AMEX ist man – meiner persönlichen Erfahrung nach nicht nur in Deutschland – generell nicht der beliebteste Kunde, insbesondere Nichtakzeptanzstellen sprechen von deutlich höheren Provisionen und anderen Gründen, die sie von der Akzeptanz der AMEX-Karten abhalten. Und, wie die Screenshots zeigen, ist der Einkauf im Android Market mit einer deutschen MasterCard auch dort möglich, wo die AMEX gesperrt ist (beispielsweise gehen auch Yenn). Das Problem ist mithin mehr eines der verwendeten Kreditkarte denn des Android Markets …
Inwiefern ich »in-app payments« vermisse, weiß ich nicht; vermutlich vermisse ich sie eher nicht, vermutlich fände ich Apps, die kostenlos daher kommen und so kostenlos nur Platz auf meinem Smartphone verbrauchen, jede aktive Dienstleistungs aber extra abrechnen wollen, eher doof. YMMV.

Mobile I Am.

Es ist etwas untergegangen, aber ich habe gestern beim »Public Viewing« – wie übersetzt man das eigentlich, »öffentliches Gucken«? – im Parkbad Gütersloh mehr oder minder zufällig das 4:2 4:1 Deutschlands gegen England (BTW, bei Gelegenheit mag mir mal wer erklären, warum beim »FIFA World Cup« die »Länder« »England« und »Schottland« antreten (könnten), nicht aber auch Bayern, Sachsen oder Texas …) per Motorola Milestone aufgenommen und, einmal ist immer das Erste Mal, per Pixelpile zu flickr hochgeladen:

Sicherlich kein cineastisches Highlight, und die knapp 12 MB .3gp-Video sehen nach Re-Encoding durch flickr auch nicht besser aus; aber irgendwie cool, daß das geht, finde ich das schon ;) (Ich hätte ja auch qik genommen, aber deren App wollte meine Credentials wissen; keine Ahnung, ob ich die App mal aus Frust ob der schlechten »HighQuality« entsorgt habe oder ein Update schief lief — ein Verlust ist die Löschung von qik IMHO eh’ nicht, sodaß ich sie grade vollzogen habe …)

Fritz!App Fon oder: WTF‽

(Blogged via flickr)

Nachdem Sipdroid ersten ausgehenden Anruf im internationalen Format $irgendwen anrief und beim ersten Anruf, den es vom ge-7170-ten Speedport W900V (.70er FW) hätte signalisieren sollen, vor Ehrfurcht einen Milestone-Reset ausführte, wollte ich ‘SIP on Android’ wieder von der Projektliste streichen. Aber da stolperte ich über einen Tweet zu ‘Fritz!App Fon’ – und da es eine Android-App gibt, war Ausprobieren Ehrensache. Tja, das Ergebnis war dann ernüchternd :( Schade, die Box kann und macht SIP, und der Code der App ist angeblich GPL’ed – welchen proprietären Kram hat man denn da wieder eingebaut? :(

Kamera: Vignette Vignette for Android

Von der unerträglichen Langsamkeit des LANs

vdr-1:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
vdr-1:~# mii-tool eth1
eth1: negotiated 100baseTx-FD flow-control, link ok

Mal ganz abgesehen von den uneinheitlichen Signalen, 100 MBit/sec aka 12 MByte/sec ist schon saulahm, wenn man darüber, wie ich, Mediendaten »wuppen« will.
Leider, da 1 GBit/sec im fraglichen System instabli nur funktionierte, müssen alle Daten nun durch dieses Nadelöhr. Meine Fileserver selbst sind nicht viel schneller, trotz GBit-Anbindung: die Platten hängen per USB 2.0 dran und damit sind zwischen (häufiger) 20 und (selten) knapp 30 MByte/sec für NFS realistisch.
Derzeit geht es darum, die über die Jahre »gewachsene« »Struktur« zu entfelchten und die Abhängigkeiten zu reduzieren. In der Zeit vor den billigen DockStars hatte ich immer mal wieder (1-TB-) USB-HDDs an Rechner im LAN geklemmt und als weitere Videoverzeichnisse in VDR eingebunden:

vdr-1:~# du -sh /newvideo.? | gawk '{printf("%s ", $0); systemstr=sprintf("df --portability -h %s | grep -v Filesystem ", $2); system(systemstr);}'|gawk '{printf("%-5s %s %-5s %s\n", $1, $2, $6, $3);}'
136G /newvideo.0 0 /dev/hda3
826G /newvideo.1 199M death:/data-20100401/newvideo.1
0 /newvideo.2 1.9M /dev/hdd3
3.7G /newvideo.3 199M death:/data-20100401/newvideo.3
634G /newvideo.4 0 death.uu.org:/data/newvideo.4
83G /newvideo.5 199M death:/data-20100401/tmpvideo.5
5.7G /newvideo.6 199M death:/data-20100401/newvideo.6
179G /newvideo.7 16M nslug-1:/data/tmpvideo.7
3.9G /newvideo.8 199M death:/data-20100401/newvideo.8

Wie man auch sehen kann: eine gewisse Konsoldierung hat schon stattgefunden, das Gros der Inhalte wurde auf dem Quadcore-Hausserver schon zusammengezogen, die Erfahrung zeigt aber, daß es vorteilhaft wäre, die Funktion »VMWare-Server« und »Fileserver« zu trennen, denn unterschiedliche »Anforderer« greifen zu unterschiedlichen Zeiten auf die Dienste »VMWare« und »Fileservice« zu.
Hier kommen nun die DockStars zum Zuge; einen Fileserver habe ich schon seit geraumer Zeit, und er hat mir schon viel Kummer bereitet. Aufgrund des Preisverfalls habe ich irgendwann angefangen, TB-USB-Disks »zu sammeln«, da die anfänglichen 750 GB der 4 250er HDDs im RAID-5 auch irgendwann endlich wurden. Günstige (externe) Festplatten gepaart mit wenig Zeit und dadurch induziertem erhöhen Platzbedarf – z. B. fehlte die Zeit, automatische Aufnahmem um Duplikate zu bereinigen, die Aufnahmen selbst zu schneiden (Vor- und Nachlauf, ggf. Werbepausen) – schaffen interessante neue Probleme. Denn mehr oder minder planlos an Linux-Kisten geklemmt und jene zum Fileserver erhoben — klar, das geht technisch, aber logistisch ist es ein Alptraum (sind Aufnahmen geplant? Falls ja, bis wann muß ich fertig sein, daß alle FS wieder bereitstehen?).
Der erste Schritt, hier Ordnung reinzubringen, war die Anschaffung einer neuen TB-USB-HDD und eines Linksys NSLU2 — mein nslug-1. Leider war die Plattform dermaßen unterirdisch inperformant – VDR, der MPEG-Datenströme aufzeichnet, möchte schon gerne einen konstanten Datenstrom schreiben können, auch wenn ein anderer Client grade auf das Verzeichnis zugreift –, daß ich das Projekt ad acta legte.
Erst mit den Sheeva-Plugs keimte wieder Hoffnung auf, jene als Fileserver für die Armada an USB-Platten benutzten zu können — gleichwohl wissend, daß 1 USB 2.0-Bus eine Bandbreite von ca. 480 MBit/sec hat, effektiv dort aber 1 Platte nur 20-30 MByte/sec bringt, effektiv also gut 200 MBit/sec nutzbar sind. Und, klar, daß zwei Festplatten an einem USB-Bus optimalerweise nur alternativ angesprochen werden sollten …
Meine beiden Sheeva-Plugs allerdings haben schnell ihre Aufgabe gefunden; einer als Camera-Server, einer als Heimautomatisationsbastelbasis. Je einen Seagate DockStar und einen PogoPlug »pink«, die ja auf ähnlicher Hardware basieren, habe ich mir gesichert; und der DockStar wurde bald zum Bastelprojekt …
… wobei der große Durchbruch erst mit dem Hinweis kam, daß es den »Seagate FreeAgent DockStar« für 20,– EUR bei u. a. Atelco.de gäbe — in der Folge habe ich a) mehr Gehirnschmalz in das Projekt »DockStar als normaler Linux-(Files-)Server« gesteckt und b) bislang 4 weitere DockStars gekauft.
Mittlerweile hat 1 DockStar meinen NSLU2 abgelöst; und statt unterirdischer Performance fluppen die Daten jetzt sowohl per NFS als auch per SMB/CIFS dank GBit-Anbindung und GHz-CPU …
Soweit die erfreulichen Nachrichten; beim bisherigen VDR-Server allerdings stecke ich auf 100 MBit/sec fest, was sich insbesondere dann negativ bemerkbar macht, wenn ich Sendungen, die auf NFS-Mounts liegen, schneiden will: es gibt eine merkliche Verzögerung im Abruf der jeweiligen Szenen. Aber gut, 100 MBit/sec am Fileserver erwies sich als geringes Problem, denn die servierenden kleinen Kisten aben alle GBit/sec – nur eben die angeschlossenen Sever nicht.