blogdoch — jetzt wird zurückgeblogt
Schon cool: »copy link« im Kontextmenü auswählen, ggf. das /#! wegwerfen, und schon stellt ein kleines lokales Plugin gemäß »Ottos« Blogeintrag einen Tweet samt Anhang dar — aus https://twitter.com/wusel/status/197085455915814912 wird:
https://twitter.com/wusel/status/197085455915814912
DAS ist letztlich der Grund, warum ich von SPHPBLOG auf WordPress mit einer fscking Datenbank gewechselt bin :-) (Aber warum wird »Wordpress« oben zu »WordPress«?)
#tw #fb
What’s the suggested plugin, or shall I use multiple, for properly integrating my now WordPress-powered blog with Twitter and Facebook?
I want to be able to selectively post to Twitter and/or Facebook, and want to record external responses (replies/retweets on Twitter, comments on Facebook) in WordPress as well. Posting comments on FB-derived ones in WP will still break the discussion, but that I intend to think about after some trial period.
Furthermore I’m looking for a different Android-App than the one called ‘WordPress’ in the MarketPlayStore, since this one seems to break EXIF data on image upload :-(
So, my dear followers: Any hints appreciated on #tw and FB as well as on the blog :-)
… might never become frieds :-(
P1010411.JPG exceeds the maximum upload size for this site.
Holy shit, this is my bloody site and I do want to upload this 5.7 MB image. Gnampf! #tw
[exif id=”9589″]
Leider nur HSPA+ hier; Vodafone hat zwar die 4G-Keule geschwungen, aber nach dem connect kommt gleich der disconnect :-( #tw
Grade mit meinem Multi-Link-AP kurz nach dem Halt in Hannover Hbf ausprobiert, als der USB-Stick mir Vodafone-SIM LTE signalisierte:
Tue Apr 24 07:34:48 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9082ms rtt min/avg/max/mdev = 38.021/42.213/51.538/4.231 ms
Zum Vergleich, D1 mit baugleichem Stick (Huawei K5005) und o2 mit Huawei E1550:
Tue Apr 24 07:34:49 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 11814ms rtt min/avg/max/mdev = 216.279/3340.028/7213.291/2193.227 ms, pipe 8/
Tue Apr 24 07:34:49 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9778ms rtt min/avg/max/mdev = 208.762/291.890/508.182/78.296 ms
Alles, wohlgemerkt, aus dem schon wieder fahrenden ICE.
(Die Verbindung läuft über OpenVPN (per UDP) über dedizierte Endpunkt-IPs an einem Server im ‘Festnetz’, die über die jeweile PPP-Verbindung der USB-Mobilfunkmodems geroutet werden. Das alleine ist schon ein Big Win bei den laufend abbrechenden PPP-Sessions wegen Abdeckungsmangel …)
Ein bißchen später, so in Höhe Gifhorn im ICE 541, sieht das dann allerdings auch anders aus:
Tue Apr 24 07:57:09 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 10064.308/12367.812/15869.452/1888.586 ms, pipe 10
Tue Apr 24 07:57:08 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 8 received, 20% packet loss, time 57635ms rtt min/avg/max/mdev = 984.208/2262.540/3884.146/834.960 ms, pipe 3
Tue Apr 24 07:57:07 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 85126ms rtt min/avg/max/mdev = 590.445/1558.000/4091.427/1151.067 ms, pipe 2
Internet im ICE — noch immer ein Abenteuer ;) Zum Abschluß — auch der Reise ;) — nochmal Pings aus dem stehenden ICE im Bahnhof Berlin.-SPandau, mit LTE bei D2:
Tue Apr 24 08:58:11 CEST 2012 PING gw-d1.uu.org (193.26.120.204) 56(84) bytes of data. 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=1 ttl=64 time=886 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=2 ttl=64 time=1327 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=3 ttl=64 time=334 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=4 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=5 ttl=64 time=107 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=6 ttl=64 time=155 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=7 ttl=64 time=94.9 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=8 ttl=64 time=103 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=9 ttl=64 time=112 ms 64 bytes from gw-d1.uu.org (193.26.120.204): icmp_req=10 ttl=64 time=221 ms --- gw-d1.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9494ms rtt min/avg/max/mdev = 94.927/345.152/1327.262/399.590 ms, pipe 2
Tue Apr 24 08:58:11 CEST 2012 PING gw-d2.uu.org (193.26.120.206) 56(84) bytes of data. 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=1 ttl=64 time=69.6 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=2 ttl=64 time=65.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=3 ttl=64 time=69.4 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=4 ttl=64 time=65.5 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=5 ttl=64 time=57.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=6 ttl=64 time=59.9 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=7 ttl=64 time=62.1 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=8 ttl=64 time=60.8 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=9 ttl=64 time=61.0 ms 64 bytes from gw-d2.uu.org (193.26.120.206): icmp_req=10 ttl=64 time=71.0 ms --- gw-d2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 57.137/64.225/71.063/4.502 ms
Tue Apr 24 08:58:12 CEST 2012 PING gw-o2.uu.org (193.26.120.208) 56(84) bytes of data. 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=1 ttl=64 time=687 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=2 ttl=64 time=729 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=3 ttl=64 time=229 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=4 ttl=64 time=559 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=5 ttl=64 time=319 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=6 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=7 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=8 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=9 ttl=64 time=239 ms 64 bytes from gw-o2.uu.org (193.26.120.208): icmp_req=10 ttl=64 time=239 ms --- gw-o2.uu.org ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9367ms rtt min/avg/max/mdev = 229.667/372.074/729.099/193.154 ms
Leider ist o2 derzeit, was die RTT angeht, deutlichst im Hintertreffen; 200ms bei einer HSPA-Verbindung ist … unzureichend :-(
Ich habe mein HTC Sensation nun rund eine Woche mit dem aktuellen Android-Major-Release (Android 4.0 aka Ice Cream Sandwich, kurz: ICS) laufen, und mehr und mehr trübt sich der Blick.
Toll, was mit CSS alles geht …
Der Browser hat z. B., wie ich heute herausfand, einen ‘coolen’ Bug mit dem WordPress-Theme des Blogs von @_refugee_ — ein doppelter Tap auf den Bildschirm vergrößert den linken Rand, ein Wisch nach links schiebt dann leider aber den Hauptbereich unter den Layer mit Christians Foto und Tweets.
Auf dem ollen Milestone mit der CM7-Variante von Android 2.3.7 existiert das Problem nicht. Lustigerweise werden mir keine mobilen Seiten mehr angeboten, es kommt immer die »echte« Web-Version — mag aber sien, daß ich das abgestellt habe, und nur nicht wiederfinde, wo zum Henker man das konfiguriert (im Browser (genannt »Internet« *sigh*) jedenfalls nicht. (Nachdem deutsche Verleger von Smartphone-Nutzern Geld verlangen, was sie anderen Webbrowsern kostenlos bereitstellen, ist das Abschalten der Kennung, ein mobiler Browser zu sein, nur konsequent, IMHO. Und nein, den »Schutz« kann selbst ein Jurist nicht als »wirksam« ansehen.)
Gingerbread kennt die Probleme nicht
Ferner scheint kein (Bild-) Datenaustausch per Bluetooth vom Milestone zum Sensation mehr zu funktionieren, jedenfalls kommt auf dem Sensation erst nach einem erneunen Paaring überhaupt eine Anfrage an, und seit dem freudigen »nicht mehr nachfragen«-Haken und Klick zur Verbindungsannahme … tut sich nix mehr. Immerhin kann man jetzt auf dem Sensation, wie schon auf dem CM-Gingerbread-Milestone, das blödsinnige Abschalten der Sichtbarkeit bei Bluetooth abstellen.
Ach ja, und der DB Navigator mag nicht mehr in den Kalender schreiben …
… to WordPress.
Denn der Sascha hat ja Recht …
Nachdem ich die IAD-Blackbox in der Praxis in Gütersloh durch eine Fritz-Box ersetzt habe, habe ich nun immerhin mehr Einblick in das, was da vorgeht. Und das ist nicht witzig, bedenkt man, daß das ein teurer Alice Business-Anschluß ist, der noch dazu auch nach nach rd. zwei Jahren nicht mit den versprochenen 16 MBit/sec, sondern nur 6 MBit/sec bedient wird:
01.03.12 02:23:10: Downtime: 2.58 Minuten, NICHT geplant (Zeitüberschreitung bei der PPP-Aushandlung.) 01.03.12 03:38:32: Downtime: 2.55 Minuten, NICHT geplant (Zeitüberschreitung bei der PPP-Aushandlung.) 01.03.12 07:03:57: Downtime: 6.75 Minuten, NICHT geplant (Zeitüberschreitung bei der PPP-Aushandlung.)
Und gestern war mein Alice Fun-Anschluß in Berlin auch mal wieder ausgiebig unpäßlich:
29.02.12 16:14:31: Downtime: 41.28 Minuten, NICHT geplant (Zeitüberschreitung bei der PPP-Aushandlung.)
Der Stoßseufzer unter ITlern zu derart geballter Unfähigkeit lautet »EINMAL mit Profis arbeiten …«, und nachdem ich nun feststellen muß, daß die in Berlin auf Hansenet-Infrastruktur chronischen PPPoE-Probleme offensichtlich auch auf den teuer beaufschlagten Business-Anschlüssen von Alice nicht unbekannt sind, werde ich meine Ansicht über die Fähigkeiten von o2 als DSL-Dienstleister wohl revidieren müssen — von der, zugekauften, Hansenet-/Alice-DSL-Infrastruktur jedenfalls muß ich nun abraten, dies ist offensichtlich ein fragiles, schlecht gewartetes und nicht verstandenes System :-( Daß es bei zwei Telekom-DSL-Anschlüssen über Wochen keinen PPPoE-Fehler gibt, bei zwei Alice-DSL-Anschlüssen hingegen kaum eine Woche vergeht, wo nicht mindestens einmal die Verbindung gekappt wird wegen PPPoE-Problemen, läßt zwar keine wissenschaftlich fundierte Aussage zu, aber meiner Meinung nach leider eine Tendenz erkennen …
Der Backbone ist imho nach wie vor gut (zumindest der alte Telefónica-Kern; falls die PPPoE-Server grade mal tun, scheint aber auch die Hansenet-Infrastruktur hinreichend zu sein), aber Alice bringt’s offensichtlich nicht mehr. Schade, aber dann muß die Karavane halt weiterziehen.
Ob ich bei Kontakt mit dem (o2-) Support wohl die Mär’ vom bedauerlichen Einzelfall hören würde? (Nein, ich rufe die für mch kostenpflichtige Alice-Hotline bestimmt nicht noch einmal an. Alice/o2 wird mt der Abstimmung mit den Füßen leben müssen, solange a) Warteschleifen gesetzlich nicht kostenlos gestellt werden und b) die kundenunfreundliche Lösung, die Störungsannahme kostenpflichtig zu machen, praktiziert wird.)
Kam gestern an, und hier läuft die o2-Software problemlos; erstes Fazit geht in Richtung ‘nettes Teil, aber leider auf halber Strecke stehen geblieben’. Mehr dazu demnächst im Blog.
Mit etwas Mühe, meine VDRs haben eine neuere Protokollversion am Start als das aktuelle Ubuntu, klappt es nun grundsätzlich mit vdr-sxfe auf dem Joggler unter Ubuntu 10.10. More on that later …