Entries tagged as software
Monday, January 23. 2012
Since I plan to back up my worthy RAW pictures into the cloud (Why?), I collected some reference values of various cloud storage providers with the following important conditions in mind:
- Support for GNU/Linux
- Support for Android
- Available for Europeans
The following graph lists the various providers I found and plots their available volume packages against their prices:
In the following I provide a short summary for each provider, and a conclusion of my personal considerations.
Continue reading "Overview of Dropbox alternatives"
Monday, September 19. 2011
SCOTTY mobil, den mobilen Reiseplaner der ÖBB, gibt’s jetzt auch offiziell für Android!
Endlich! Nach dem, dem, dem und dem wurde das auch Zeit! Und die App funktioniert sogar sehr gut, hat ein interessantes Zeitauswahl-UI und macht Echtzeitdaten abrufbar.
Friday, February 25. 2011
(I started this as a draft two years ago, but wasn’t sure about its correctness then.)
Usually, one uses the -a switch when archiving files with rsync from Unix to Unix. -a is an abbreviation for -rlptgoD, which means
- -r: recurse into directories,
- -l: copy symlinks as symlinks,
- -p: preserve permissions,
- -t: preserve modification times,
- -g: preserve group (ownership),
- -o: preserve owner,
- -D: preserve device and special files,
but this doesn’t make sense if the target is an MS FAT device (such as a USB key) or a CIFS/SMB/Samba host, as that old file system cr4p doesn’t know anything about symbolic links, file permissions, ownerships or other Unixy properties. Thus, rsync fails to match these features at all and synchronizes every single bit of every single file again.
The solution I found is to simply use the tuple of time-stamp and file size as the only criteria whether something has changed. This still results in warnings about that the time-stamps of directories couldn’t be set, but at least the sync works. An example command line could thus be
$ rsync -rt $source $target
Monday, January 31. 2011
Nach einer ersten Auflistung einiger Möglichkeiten im April 2010 und einem Follow-Up im Juni mache ich hier nun weitere aktuelle Ergänzungen und erstelle einen Überblick, zumal immer wieder Leute zu dem Thema hier „aufschlagen“ (z.B. in den Kommentaren oder per einschlägiger Websuche). Die unten angeführte Liste ist nach meiner persönlichen Präferenz gereiht, gemäß folgender Anforderungen:
- Daten aus erster Hand, d.h. möglichst keine halblegalen Apps von Drittanbietern (die z.B. einfach Webseiten parsen und deshalb irgendwann einfach nicht mehr funktionieren)
- Offline Nutzbarkeit: Speicherung von Zugverbindungsdaten zwischen 2 Stationen (Uhrzeiten, Umstiege, etc.)
- Aktuelle Zugverspätungen abrufbar
Hier nun meine Lösungen:
- SCOTTY mobil: Ja, auf Platz 1 landet bei mir die App, die es offiziell garnicht (für Android) gibt, aber per J2ME Runner betrieben werden kann. Die Liste der offiziell unterstützten Mobiltelefone liest sich wie eine Zeitreise in die Nuller Jahre. Dennoch erfüllt diese App alle oben genannten Bedingungen, auch wenn sie sich auf einem Touchscreen mit Wurstfingern eher schlecht bedienen lässt; das war ja nie vorgesehen, damals. Und die ÖBB wird wohl auch ziemlich sicher niemals einen Nachfolger präsentieren. Denn den dürfte sie offenbar in der auf Platz 3 genannten App Quando sehen. Die GPS-Ortung funktioniert übrigens nicht, wenn SCOTTY so betrieben wird.
- DB Navigator: Die Überraschung schlechthin erlebte ich mit dem Tipp für die App der Deutschen Bahn. Das ist offenbar die einzige echte Android-App, die (scheinbar wegen entsprechender Verträge) die Daten der ÖBB aus erster Hand gewinnt. Sie erfüllt alle oben genannten Bedingungen. Damit kann man zwar sogar Zugtickets kaufen, glaube aber kaum, dass die dann auch für rein innerösterreichische Zugverbindungen gültig sind.
- Quando hatte ich bereits zu einem Zeitpunkt erwähnt, als es noch keine Android-Version davon gab; diese kam Anfang September nach. Sie erfüllt immerhin die erste Bedingung, handelt es sich doch um die offizielle App des VOR, dessen Netz allerdings nur den Osten Österreichs (um Wien) abdeckt. Sie war anfangs so schlecht benutzbar, dass sie sich bei vielen Nutzern dauerhaft disqualifiziert hat. Im Market findet man auch unzählige Protestbewertungen, die die ÖBB dazu ermuntern sollen, ihre Daten doch für Google Maps frei verfügbar zu machen – der zweite Faktor, bei dem die Österreicher den Deutschen nicht nachkommen. Ansonsten ist es für Abfahrtstafeln und GPS-Ortung ganz gut nutzbar. Verspätungen sind keine abrufbar.
- Öffi: Hier beginnen wir nun mit den Drittanbietern. Diese App hat sich dadurch bei mir hervorgetan, dass der Entwickler sehr viele, ja fast täglich inkrementelle Updates zur Verfügung stellt, die immer wieder nachbessern bzw. immer weitere Gebiete Europas abdecken. Die grafische Umsetzung von Abfahrtstafeln ist gelungen, auch gibt es eine GPS-Ortung, allerdings keine Verspätungsdaten (und wohl auch keine „Realdaten“, sondern nur den Plan – Zugausfälle z.B. wären nicht sichtbar!).
- FahrplanAT/TimetableAT: Hatte ich schon erwähnt, parst offenbar Webseiten und funktioniert nicht immer. Keine Verspätungsdaten.
- Abfahrtsmonitor: Diesen Tipp bekam ich direkt vom Entwickler. Auch er beklagt die Abwesenheit eines APIs von den ÖBB und muss selbst Webseiten parsen. Ein Test dieser noch sehr jungen App steht meinerseits noch aus.
- Fahrplan Österreich: Kenne ich nicht, hat hässliche Werbeeinblendungen und schlechte Kritiken, werde ich auch nicht testen.
- Webbrowser: Damit auch dieser erwähnt ist. Immerhin erfüllt diese Variante die Bedingungen 1 und 3.
Zum Schluss sei noch auf eine Speziallösung hingewiesen: Offizielle RSS-Feeds über Betriebsstörungen. Ja, diese Feeds gibt es, und sie sind gut versteckt, aber via ÖBB-Streckeninformation zu finden. Sie würden sich gut z.B. in einem RSS-Widget machen.
[Update 01.02.] Ein Twitter-User hat mich darauf aufmerksam gemacht, dass es offenbar im 2. Quartal eine Android-App von den ÖBB geben soll. Dies geht aus einem Kommentar auf der Facebook-Seite der ÖBB vom 5. Jänner hervor.
Monday, November 1. 2010
(The following is a kind of current-state analysis, maybe leading to my long intended anti-WWW rant. It might become more interesting in a few years.)
Honestly, I think Twitter is a broken technology. 140 characters are way too few to provide useful context. And as URLs eat from this character pool, the urge for link shorteners simply leaves this service behind broken, IMHO. Just look at this plot of the distribution of tweet lenghts:
Well, some misuse Twitter as a chat, although IRC would be the technology of choice for that. I mainly use it as a news stream. In fact, Twitter changed their orientation from individual “Took a dump, ate a banana” status updates to personalized news. Although RSS or Atom are dedicated technology for collecting headlines and articles (and keeping their read/unread state), Twitter provides a unified time flow (that passes by, no matter if you read it or not). And while RSS/Atom is a kind of pull technology (i.e. you have to look at different feeds and articles for yourself), Twitter is a push variant where all elements meld into a single data stream.
The problem is, in engineering terms, there’s so much noise in the data; there’s so much irrelevancy occurring in the timeline, at least in mine. I followed more and more people, like “Hey, this guy developped that app, and there’s a link to his Twitter”, or I chose to follow various companies when I noticed they had an account at Twitter. But more and more often I asked myself where a certain guy/gal I followed actually came from.
I’m wasting too much time at Twitter. Meanwhile, I’m following more than 250 people. (Yeah, I think those who follow >300 are simply nuts. How the hell do they handle their timeline? How can they claim Twitter is not a distraction?)
Me wants:
- More than 140 characters please. 200 or so should be OK. Or, better, do it like Google Buzz or Facebook and just collapse longer posts.
- Attach personal notes to provide the context about who this Twitter user is or why it was interesting to follow him/her. Their own bios are often useless.
- Some sort of global maximum tweet rate to allow skipping of irrelevant tweets
- Give weights to followers: “Important” followers should always be in the timeline, while tweets from others are allowed to be skipped if there are too many tweets; also, some followers might be muted, but not unfollowed (i.e. some kind of bookmarking).
- There should also be a rate per user. If one suddenly starts to reproduce audio content from e.g. a conference talk, I shouldn’t be bugged, please.
- The decision about relevance should be made similar to the My6Sense client. This innovative client aggregates from one’s Twitter, Facebook, Google Buzz and Google Reader subscriptions and automatically learns the topics that are most interesting for the individual.
- This automatic learning should be done using the read messages/articles (like My6Sense does) and/or by buttons in a “plus”/“minus” manner to prevent “accidentally” read articles from becoming relevant.
- URLs should not eat from the character pool and be placed in some kind of footnotes. Or, rather, make them the usual linked words.
Of course, a lot of this already sounds like RSS. But there are tweets that are status updates per se and don’t contain URLs.
It appears to me that Twitter and RSS (and maybe the whole social *BUZZWORD ALERT* media) are becoming “the HTTP of a new WWW”: It’s up to new and upcoming user interfaces to aggregate, weight, filter, sort and manage content coming from various data streams; new user interfaces for new devices, but also for the “old scholars”. I noticed recently that things are becoming better for me when using different Twitter—or rather, aggregator—clients, like TweetDeck or My6Sense. It’s becoming important for me to not just scream or hear screams, but to consume and provide relevant information.
Monday, June 14. 2010
Zu meinem Initialposting zu diesem Thema gibt es nun ein Update: Die SCOTTY mobil-Version für (Non-Android) Motorola-Handys, scottymobil_mot.zip, lässt sich nun via NetMite.com konvertieren und auf Android-Smartphones via J2ME Runner (aus dem Market) betreiben. Ob auch die anderen Versionen laufen, war ich zu faul auszuprobieren; vermutlich funktioniert es nun einfach dank eines aktualisieren J2ME Runners. Die Applikation scheint jedenfalls vollständig zu funktionieren. Leider wird damit den ÖBB der Druck genommen, doch noch eine offizielle Version für Android zur Verfügung zu stellen.
Sunday, May 2. 2010
Besides the fact that it was a pain to find out how ImageMagick’s -average option is to be used, it turned out to operate wrongly. The switch calculates the mean of an image sequence, i.e. the mean color values for every pixel. Say, if you have a bunch of images with file names like img*.jpg and want the average saved into avg.jpg, the command line is:
$ convert img*jpg -average avg.jpg
Pretty intuitive. The problem is that you define the mean image Ī[n] of n images I[k] as
while ImageMagick does it recursively as
(with Ĩ[1]=I[1]),
giving you wrong weights 1⁄2n−k+1 like e.g. for n=8
instead of the intended weights 1⁄n like
.
This misbehaviour can be proven e.g. by taking this sequence of a plain blue, green and red image:
and averaging it with the above command. The result is too reddish:
The solution I found was to call convert recursively like this:
#!/bin/bash
i=0 for file in img*jpg; do echo -n "$file.. " if [ $i -eq 0 ]; then cp $file avg.jpg else convert $file avg.jpg -fx "(u+$i*v)/$[$i+1]" avg.jpg fi i=$[$i+1] done
By this, the average of the above example images correctly becomes gray:
There might be similar problems with the other image sequence operators, but I haven’t examined them. Maybe I should file a bug.
Friday, April 16. 2010
Ich bin unlängst von einem Symbian-Handy auf ein Android umgestiegen und wollte die Applikation SCOTTY mobil von den ÖBB dort weiterbenutzen, um bequem aktuelle Zugverbindungen bzw. -verspätungen abrufen zu können, jedoch: Es gibt diese App nicht für Android, und auch nicht auf absehbare Zeit. Daher liste ich hier einmal die Möglichkeiten auf, die bleiben. Eins vorweg: Sie sind allesamt höchst unbefriedigend. - Webbrowser: Die schnelle Lösung in der Not ist, mit einem Android-Browser Fahrplan.OeBB.at abzurufen. Davon gibt es leider keine offizielle Mobilversion, ich kenne nur die in das WAP-Portal Live.A1.net integrierte für A1-Kunden. Abgesehen davon, dass dies nur online erfolgen kann, ist mir keine Möglichkeit bekannt, Verbindungen für einen späteren Abruf zu speichern. Start, Ziel und Zeitpunkt müssen immer wieder neu eingetippt werden, was eine Qual ist, wenn man nur „mal eben“ vorab nach Verspätungen sehen will. Apropos: Diese lassen sich ausschließlich auf diese Weise erfragen.
- SCOTTY mobil mit Tricks doch auf Android nutzen: Ich kenne zwei Möglichkeiten, um eine (J2ME) Java-App in ein Android-Format zu konvertieren:
- J2ME Runner: Diese via Android Market installierbare App erlaubt es, das originale .jar/.jad von den ÖBB in ein .apk zu konvertieren und zu installieren. Ein Startversuch führt dann aber kommentarlos und umgehend zum Homescreen zurück.
- MicroEmulator: Ich habe mir tatsächlich die Mühe gemacht und auf einem PC eine komplette Android-Entwicklungsumgebung eingerichtet. Mit ein paar Kniffen erstellt man damit ein Paket, welches nach Installation am Handy tatsächlich ein SCOTTY mobil startet, in dem sich sogar Haltestellen auswählen lassen! Schickt man jedoch die eigentliche Suchabfrage ab, verabschiedet sich die App reproduzierbar mit einem Force-Close. FAIL.
- Qando.at deckt leider nur den Ostösterreichischen VOR ab. Mit der oben erwähnten MicroEmulator-Methode kann man die Java-App auch auf Android installieren und sogar nutzen, inklusive Touchscreen. Nachteil: Die Android-Softwaretastatur funktioniert nicht, nicht einmal eine Hardwaretastatur wie beim Motorola Milestone. Man ist vollständig auf die integrierte, äußerst schlecht bedienbare und winzig kleine Softwaretastatur angewiesen. Verbindungen lassen sich zwar als Favoriten speichern, die Fahrpläne werden aber stets nur online nachgeschlagen; Verspätungen sind keine abrufbar.
- FahrplanAT: Diese Android-App findet man eventuell auch als TimetableAT im Android Market, benutzt aber offenbar kein offizielles ÖBB-API, sondern scheint unter der Haube einfach die Suchabfragen via Webinterface abzusetzen und die Ergebnisse herauszuparsen. Den selben Irrweg scheint (laut Code) auch die freie und unfertige App open-scotty einschlagen zu wollen. Diese Methode ist zum Scheitern verurteilt und steht und fällt mit dem Wohlwollen des offiziellen Betreibers der Website, also der ÖBB. Die Deutsche Bahn etwa, die übrigens sowohl eine mobile Website als auch eine native Android-Version anbietet, kennt solche Fremd-Apps und duldet sie nur, solange deren Abfragen sich nicht störend auswirken. Immerhin bietet FahrplanAT eine GPS-Lokalisierung und eine Historie bereits abgefragter Verbindungen an. Abrufe erfolgen aber wiederum stets online, ohne Daten über Verspätungen.
|