Bones, is it dying?

/var/log/messages.4.gz:Sep 24 11:40:09 death kernel: [3113010.597097] motion[17123]: segfault at 0 ip (null) sp ae42a31c error 4 in libpq.so.5.2[110000+21000]
/var/log/messages.4.gz:Sep 24 11:48:29 death kernel: [3113510.427985] motion[17780]: segfault at 0 ip (null) sp ae31e31c error 4 in libavformat.so.52.31.0[110000+a8000]
/var/log/messages.4.gz:Sep 24 11:50:23 death kernel: [3113624.294781] motion[17921]: segfault at 0 ip (null) sp ae6ba31c error 4 in libpq.so.5.2[110000+21000]
/var/log/messages.4.gz:Sep 24 11:51:42 death kernel: [3113703.785569] motion[18012]: segfault at 1008 ip 0805e141 sp aaaff270 error 4 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 11:54:36 death kernel: [3113877.781585] motion[18217]: segfault at 1008 ip 0805e141 sp ae71e280 error 4 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:02:09 death kernel: [3114330.399101] motion[18943]: segfault at 0 ip 0056a136 sp b70c5fe8 error 4 in libc-2.10.1.so[4f5000+13e000]
/var/log/messages.4.gz:Sep 24 12:11:05 death kernel: [3114866.151856] motion[19991]: segfault at 27b16a09 ip 0806008d sp ad2fdfc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:17:14 death kernel: [3115235.402812] motion[20611]: segfault at 4181f4d9 ip 0806008d sp b700bfc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:31:20 death kernel: [3116081.925025] motion[22230]: segfault at 95afb350 ip 08060088 sp b6f08fc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:54:36 death kernel: [3117478.032021] motion[24479]: segfault at 2 ip 00000002 sp b5efddac error 4 in libavutil.so.49.15.0[110000+c000]
/var/log/messages.4.gz:Sep 24 13:41:07 death kernel: [3120268.384388] motion[27775]: segfault at 54256e5c ip 004be136 sp b7779fe8 error 4 in libc-2.10.1.so[449000+13e000]

WTF? SEGFAULTs klingen irgendwie gar nicht gut, aber irgendwie mag ich nicht an karpotten Speicher zu glauben … Ganz neu ist es nicht, aber aktuell ist es extrem:
/var/log/messages: 1465
/var/log/messages.1: 1
/var/log/messages.2.gz: 0
/var/log/messages.3.gz: 1
/var/log/messages.4.gz: 49

Wobei das Gros der Abbrüche motion (eine Webcam-Überwachungssoftware) betrifft, seltener synergys (Steuerung mehrere Computer mitteles 1x Keyboard/Maus), nie bislang, soweit ich gesehen habe, VMware-Prozesse oder Firefox … Irgendjemand ‘ne Idee, was das sein könnte (OS ist Ubuntu Kotzender Koala)?

Multicast-Stürme im WLAN und andere T-Entertain-Probleme

Im Grunde bin ich mit der Wahl meiner Switche – Netgear GS108T, 8x 10/100/1000 – zufrieden, ich habe seinerzeit auch für meine ehemalige Realschule, an der ich nebenbei »ein bißchen Netz gebastelt« habe, diese als Backbone-Switches anschaffen lassen. Mit rd. 100 EUR/Gerät und der grundlegenden Managementfähigkeit finde ich sie recht günstig — zumal, wenn man von den Preisen der IGMP-fähigen Alternativen ausgeht.
Leider funktioniert aber grade dieses IGMP-Snooping nicht reibungslos, zudem hängt sich die Managementoberfläche einer meiner 3 Netgear GS108T nach relativ kurzer Laufzeit komplett auf, der Webserver reagiert nicht mehr, ohne Power-Cycle ist der Switch nicht mehr administrierbar :-(
Aber auch wenn, lt. Weboberfläche allles im Lot scheint, etwas liegt im Argen. Zwar zeigen die Switche brav an, daß nur bestimmte Ports partizipierten …

GS108T UG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 8
2 1 01:00:5E:23:8B:0B 4 ,8
Port 4: VDR mit IPTV-Plugin sowie den (ÖR-)T-Entertain-Kanälen in der channels.conf
Port 8: Link ins EG
GS108T EG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 3 ,4
2 1 01:00:5E:23:8B:0B 1 ,3 ,4
Port 1: Link ins UG
Port 3: X301T im Wohnzimmer (Direktanschluß an Switch)
Port 4: Link ins OG
GS108T OG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 1 ,3 ,8
2 1 01:00:5E:23:8B:0B 1 ,3 ,8
Port 1: Link ins EG
Port 3: LAN-Port des Routers (Dockstar mit igmpporxy)
Port 8: GBit-Switch “Layer1” (unmanaged)

…, doch die Realität sieht anders aus; sowohl über’s WLAN (802.11n 150 MBit/sec), über welches in dem Moment nichts anderes rüberkommt, als auch auf einem Gerät an Port 5 des GS108T im Untergeschoß fliegen diese Meldungen durch den tcpdump:

00:01:50.900314 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 327
00:01:50.903940 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 327
00:01:50.907573 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 336
00:01:50.911445 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 336

IMHO dürfte sowas nie und nimmer auftreten; leider geschieht dies auch bei der neusten Firmware (3.0.4.10). Clues, anyone? So sind die GS108T jedenfalls für den Einsatz in Multicast-Umgebungen un-brauch-bar :-(
Und, mal ganz ehrlich: so langsam frage ich mich, ob T-Entertain den Streß und die heimischen Infrastrukturkosten (die 3 GS108T habe ich auch nur angeschafft, um den Multicast-Wahnsinn von meinen WLAN-APs fernzuhalten (da jene nämlich sonst nicht mehr als AP funktionieren können …) wert ist — neben den damals rd. 100 EUR für eine bis heute nicht in der beworbenen Form (2 DVB-T-Tuner, USB-Port für mehr als nur Stromlieferant für die PS3-Pads) bereitgestellte SetTopBox, die keinerlei Möglichkeiten der Sicherung der Aufnahmen vor einem Plattenausfall vorsieht, also weitere 300,– EUR direkte Kosten nur, damit man über’s »Internet fernsehen« kann … (Und mit »Internet« hat T-Entertain ja auch nur das Protokoll gemein …) Was für eine Sat-Anlage bekommt man wohl für 300,– EUR?

Herbstlicher Kehraus in der heimischen IT

Es find letztlich damit an, daß ein weiteres meiner heiß und innig geliebten, also auch viel eingesetzten, D1171-Boards von FSC, diesmal in einem Scenic B, rumalzheimerte …
Aber von vorn … Im Zuge des Green-IT-Wahns habe ich vor geraumer Zeit den Full-Blown AMD Athlon XP im Keller stillgelegt — er war nur noch VDSL-Router und OpenVPN-Endpunkt und damit ziemlich oversized … Geplant ist (war) eigentlich, den GuruPlug Plus als VDSL-Router und OpenVPN-Endpunkt einzusetzen, da GlobalScale hier aber leider nur einen Heizkörper anstelle eines im Rahmen der initialen Spezifikationen funktionsfähigen Computers produziert hat, fällt diese Option erst einmal flach.
Und da nichts länger hält als ein Provisorium … hat sich hier auch lange Zeit nichts weiter getan, der neue Router, ein Scenic B, bekam eine zweite, LowProfile, Netzwerkkarte und hatte somit auf eth0 die heimischen Netze und auf eth1 die Verbindung zum VDSL-Modem.
Irgendwann begann dann, bei meinen nur noch kurzen Besuchen auf der Heimatbasis, das WLAN rumzuzicken, 30% und mehr Packetloss, das ist unspaßig, aber dermaßen auch … Und da mehrere Geräte nun über n-Draft-WLAN verfügten, lag es irgendwie nahe, auf wenigstens den n-Draft-150-MBit/sec-Zug aufzuspringen — zumal Edimax BR-6226N für 17,– EUR brutto bei Reichelt grade im Angebot waren. (Auch latent hackbare Boxen, linux-driven …) Jene lösten dann die betagten WRT-54G (nein, die wurden lange vor Existenz der “GL”-Modelle angeschafft und mit OpenWRT versehen) ab, in der Hoffnung auf bessere Verbindungen. Zugleich wurde damit dann das gute alte WEP-WLAN »UU Home« entsorgt; es wird ja bald schwierig, noch Geräte zu finden, die überhaupt noch das so-gut-wie-offene WEP unterstützen ;) Schade nur für die WLAN-basierte Ortung; aber ich bin sicher, die spionierenden Geräte von u. a. Apple und auch die ganzen Androiden werden die neue Situation schnell in den Datenbanken vermerken …
Tja. Nun habe ich also schnelle(re)s WLAN — aber die Probleme bleiben. Zudem hängt sich immer öfter der Router weg, dann routet er zwar noch mit wechselndem Paketverlust, im Usermode ist aber tote Hose (kein SSH-Login mehr, nicht mal das login auf der Console tat nach der Eingabe von “root” noch irgendwas). Quick- and dirty-Lösung: Fernschaltbare Steckdosenleiste vor den Router, bei Nichtantwort auf ssh-Verbindungen einen Power-Cycle initiieren. Das half … nicht wirklich, aber besser, als die bessere Hälfte dies händisch bei Entdeckung »Netz geht nicht« machen zu lassen …
Aber was nun tun? Im Keller laufen sowieso schon zwei Dockstar als Fileserver, und endlich sind die USB-Ethernet-Dongles angekommen — was also liegt näher, als einen Dockstar zum Router aufzubohren? Ich meine, hey, ein 08/15-Intel hat VDSL mit den beiden VLANs und den igmpproxy und das olsr-und-openvpn-Geraffel hinbekommen, wie schwer kann es sein?
Vorweg: ziemlich. Aua. Das war wieder einmal ein Griff in die volle … braune Brühe, in der ich dann gen Abend hin knietief watete. Denn so ein Router, der braucht so ziemlich alles, was ein Fileserver grade nicht braucht. Das fängt dann bei so Details wie vconfig und dem 8012q-Modul für’s VLANing langsam an, hört mit Details wie »das 100-MBit-USB-Dongle nutzt andere Treiber als das 1000er« nicht auf und gipfelt dann in der Notwendigkeit von »Advanced Router« (für verschiedenen Routingtabellen; einige Geräte, z. B. das Entertain-Böxchen, müssen über die T-VDSL-IP rausgehen statt über den meinen PI-Adressbereich bereitstellenden Tunnel) oder »Multicast Routing«, ohne das ipgmproxy nicht spielen mag.
Erschwerend kam hinzu, daß ich die ersten drei meiner Dockstars noch nach »Schema Holler« aufgesetzt hatte, d. h. in den freien Flashbereich des Standard-Dockstar wird ein USB-Boot-fähiges uBoot installiert, welches stumpf /boot/uImage vom ersten Laufwerk bootet. Dieses Setup hat den Vorteil, daß man weniger Flashen muß, zumal, wenn man wie hier im Stundentakt neue Kernel bäckt (diverse der Optionen sind im Kernel verankert); es hat aber leider, zumindes bei mir, den Nachteil, daß ein Reboot nicht möglich ist, beim Warmstart findet das neue uBoot zwar noch USB-Geräte, bei bzw. vor der Erkennung des USB-Storage-Geräte allerdings verabschiedet es sich sang- und klanglos — ohne Power-Cycle geht nichts :( Ein weiteres Detail, welches letztlich dazu führte, daß ich VLAN 7 und 8 über meine GS108T aus dem Keller ins Arbeitszimmer im 1. OG »legte«; ganz so mobil bin ich derzeit leider nicht und gleich wieder mit dem Powercycle-per-Steckdosenleiste-Holzhammer zu kommen, das erschien mir auch nicht zielführend.
Da meine »Radikaloperation«, bei der der Dockstar einen neuen Kernel als auch ein neues (UBIFS-) rootfs geflasht bekommt, dieses Rebootproblem nicht haben – wobei, daran, daß es mir jetzt erst aufgefallen ist, sieht man, wie stabil die Dockstar-Büchsen als NFS-Sever vorsichhinwerkeln … –, werde ich wohl doch meinen letzten »Spare«-Dockstar nach diesem Schema behandeln und nur Kernel/Module ändern auf das fertig (auf einer Box in Berlin Cross-) kompilierte 2.6.32.2 ink. Dockstar-Patches von Alexander Holler. So eine grün leuchtende LED ist einfach schicker als eine hektisch grün blinkende ;)
Schade, daß die Dockstar jetzt wieder im Bereich (jenseits) der 30,– EUR kostet; ich hätte für dieses kleine Wunderkiste sicher noch die eine oder andere Idee, um selbst nicht den Überblick zu verlieren, hier mal meine bisherige »Horrorshow« (aus Sicht von Seagate ;)):

  1. ds-1 ersetzte nlsug-1 (NSLU2) als Fileserver; derzeit auch »Zentralgestirn« (Router, DHCP-, DNS-, OpenVPN-Server).
    Peripherie derzeit: 4x USB-HDD, 1 USB-Ethernet

  2. ds-2 sammelte 3 weitere versprengte USB-HDD und serviert nun deren Daten ins LAN.
    Peripherie derzeit: 3x USB-HDD, 1 schaltbare Steckdosenleiste (SIS-PM)

  3. ds-3 wandert demnächst in den Keller als (HD-) VDR-Server und wird wohl 1-2 Scenic Xs mit insges. 1x DVB-S2, 2x DVB-S, 1x DVB-T ersetzen.
    Peripherie derzeit: 1x USB-HDD, 2x S2-3600, 1x S-2400 (planned)

  4. ds-4 steht im Office und malt bunte Smokeping-Graphen über die Netzanbindung …
    Peripherie derzeit: 1x USB-HDD

  5. ds-5 habe ich einem Kollegen als Spielwiese überlassen. Er macht darüber wohl IPv6-Experimente ;)
  6. ds-7 ist mein Router in Berlin (Alice-ADSL2, Alice-HSDPA, OLSR, OpenVPN, …), außerdem läuft FHEM drauf
    Peripherie derzeit: 1x USB-Stick als /dev/sda, 1x Huawei E620, 1x CUL

  7. ds-8 ist mein DVB-T-VDR in Berlin
    Peripherie derzeit: 1x USB-HDD, 1x MSI DIGIVOX Duo DVB-T

  8. ds-9 harrt noch einer Aufgabe.

BTW, über günstige (unter 26,–/Stück inkl. Versand) Bezugsquellen würde ich mich freuen als auch über Hinweise auf andere, änhliche Geräte; Seagate scheint mit dem »FreeAgent GoFlex« ja eine abgewandelte Form des Dockstar auf dem Markt gebracht zu haben, aber außer, daß da zwei Platten direkt reinpassen und dafür nur noch 1x USB rausgeführt wird, scheint es »nur« ein teurerer Dockstar zu sein?

Es wird Winter …

Oh ja, der Winter kommt. Und zwar mit ziemlich großen Schritten. Nachts ist es wirklich schon empfindlich kalt bei unter 5 Grad, da jagte man keinen Hund mehr vor die Tür (geschweige denn ginge mit ihm freiwillig Gassi), und auch tagsüber ist es frisch.
Auch wenn meine über FHEM und CUL ausgewerteten Meßfühler aus der

keine hochpräzisen Instrumente darstellen, bei paralleler Messung lag der Unterschied im Bereich von unter einem Grad. Insofern meine ich, feststellen zu können, daß durchaus auch jetzt eine unterschiedliche Temperaturkurve in Berlin gemalt wird, daß es in Berlin vermutlich durch die »Grundwärme der Großstadt« tatsächlich marginal wärmer ist in diesen kalten Nächten. Wobei ein Grad Celsius den Kohl nicht fett macht — aber irgendwie intereressant finde ich es doch ;)

Plug-and-Play

Hab’ den verschollenen USB-(Gigabit-)Ethernet-Adapter nochmal bestellt, auf den ersten Blick eine gute Wahl:

Oct 12 12:20:33 tmp-dockstar kernel: usb 1-1.4: new high speed USB device using orion-ehci and address 18
Oct 12 12:20:35 tmp-dockstar kernel: asix 1-1.4:1.0: eth1: register 'asix' at usb-orion-ehci.0-1.4, ASIX AX88178 USB 2.0 Ethernet, 00:22:75:XX:XX:XX
Oct 12 12:20:35 tmp-dockstar kernel: usbcore: registered new interface driver asix
tmp-dockstar:/usr/src/unstable-vdr# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:10:75:XX:XX:XX
inet addr:192.168.5.235 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::[...]/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17012676 errors:0 dropped:0 overruns:0 frame:0
TX packets:30088962 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2192292229 (2.0 GiB) TX bytes:1109421631 (1.0 GiB)
Interrupt:11
eth1 Link encap:Ethernet HWaddr 00:22:75:XX:XX:XX
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
[...]

Damit kann dann einer meiner Dockstars, dank des Adapters für den Festplattenanschluß (Reichelt USB ABU-ABU (Buchse-A auf Buchse-A) und COM 950 (Buchse-Mini- aus Stecker-A)) habe ich ja jeweils nun 4 nutzbare USB-Ports, auch als Router fungieren (eth0 ins LAN, eth1 hat dann auf .7 und .8 T-VDSL bzw. T-Entertain und auf .2 ‘nen Uplink zum Fallback-Router (3.5G)). Fraglich ist nur, ob igmpproxy sauber auf der ARM-Plattform rennt. Hmm, und ein neues Ziel für ‘nen CUPS-2-CAPT-Server brauche ich wohl, IIRC ist Canons Treibergedöns binary-only und nur für x86, nicht für armel, verfügbar :(

Dockstar als DVB-S2-VDR-Server

Nachdem mein DVB-T-VDR auf ‘nem Dockstar schon recht gut läuft, wollte ich diie beiden Intel-Pizzaschachteln (FSC Scenic Xs) im Keller ggf. auch durch einen Dockstar-VDR mit 2x DVB-S2 plus DVB-S ersetzen — da die Scenics nur 2 PCI-Slots haben, ist der Hardwareeinsatz für >2 DVB-S-Streams doch recht enorm, hinzukommt die umständliche Verwaltung (Server-Timer, Remote-OSD. Streamdev-Client — für vollständige Nutzung muß man dies alles mehrfach installieren auf dem Wohnzimmer-VDR-Frontend …).
Nach kurzer Vergewisserung, daß insbes. die Technotrend S2-3600 mittlerweile unterstütt werden, orderte ich also zweo davon sowie eine S-2400 beim DVB-Shop. Leider stellt die stetige Weiterentwicklung des 2.6er Kernels den geneigten Bastler mal wieder für lustige Fehlermeldungen, denn für die gewählte OS-Basis, Debian-Lenny mit Kernel 2.6.34 auf dem Dockstar tut’s ein aktuelles S2-Liplianin natürlich nicht …
Um es abzukürzen: mit »hg clone -r 14630 http://mercurial.intuxication.org/hg/s2-liplianin« bekommt man einen S2-Liplanin-Tree, der sauber auf dem Dockstar durchkompiliert und am Ende die benötigten Treiber liefert. VDR 1.7.16 habe ich vorher schon nativ auf dem Dockstar übersetzt, bis auf das Problem mit xineliboutput relativ einfach, wenn auch zeitaufwendig. Mittels w_scan eine channels.conf erzeugt, die remote.conf von einem anderen System übernommen (sonst ist das mit der Steuerung des VDRs durch vdr-sxfe eher Essig) und voilá, mit einer angeschlossenen S2-3600 rennt der VDR auf dem Dockstar — wie auch nicht anders erwartet.
Über die Performance kann ich noch nicht viel sagen, 9% CPU beim Ansehen eines DVB-S-Streams per vdr-sxfe über’s Netz klingt aber ganz gut. Potentielles Problem könnten konkurrierende Zugriffe auf dem USB werden, da sowohl die MPEG-Daten über USB reinkommen (und diese sind vom Timing her kritisch) als auch die Systemplatte (bei mir liegt da /var und /usr per binding-mount drauf) hier Bandbreite benötigt. Allerdings, auf meinem VDR in Berlin, der zeitweise auch auf einen Streamdev-Server im Netz zugriff und somit 3 parallele Aufnahmen anfertigen konnte (2x DVB-T via USB, 1x DVB-S via Streamdev), habe ich keine Probleme feststellen können.

Jedem Geruchsmolekül eines Furzes seine eigene IP-Adresse – IPv6 ist da

Ja, er ist ein bißchen unappetitlich, der Titel … aber so kommt es mir halt grade vor, als ich mir den Adressraum meines neuen Hurricane-Electric-IPv6-Tunnels zwecks Aufteilung auf meine drei Standorte mir anzeigen lasse …

wusel@bln:~$ sipcalc 2001:470:1f08:efe::2/64
-[ipv6 : 2001:470:1f08:efe::2/64] - 0
[IPV6 INFO]
Expanded Address - 2001:0470:1f08:0efe:0000:0000:0000:0002
Compressed address - 2001:470:1f08:efe::2
Subnet prefix (masked) - 2001:470:1f08:efe:0:0:0:0/64
Address ID (masked) - 0:0:0:0:0:0:0:2/64
Prefix address - ffff:ffff:ffff:ffff:0:0:0:0
Prefix length - 64
Address type - Aggregatable Global Unicast Addresses
Network range - 2001:0470:1f08:0efe:0000:0000:0000:0000 -
2001:0470:1f08:0efe:ffff:ffff:ffff:ffff
-

Gut, komische Zahlen, aber rechnen wir doch mal, das sind 65536[sup]

4

[/sup], also alleine schon vier Milliarden mal der gesamte IPv4-Addressraum (4.294.967.296, gut 4 Milliarden Adressen) oder, in Zahlen, 18.446.744.073.709.551.616 Adressen — nur für meinen Router‽
Aber IPv6 ist ja ein großer Adressraum, daher gibt es neben der etwas übertriebenen Adressmenge für den Punkt-zu-Punkt-Link auch die Möglichkeit, ein »echtes« Netz zu bekommen, das wäre also ein /48:

wusel@bln:~$ sipcalc 2001:470:9434::/48
-[ipv6 : 2001:470:9434::/48] - 0
[IPV6 INFO]
Expanded Address - 2001:0470:9434:0000:0000:0000:0000:0000
Compressed address - 2001:470:9434::
Subnet prefix (masked) - 2001:470:9434:0:0:0:0:0/48
Address ID (masked) - 0:0:0:0:0:0:0:0/48
Prefix address - ffff:ffff:ffff:0:0:0:0:0
Prefix length - 48
Address type - Aggregatable Global Unicast Addresses
Network range - 2001:0470:9434:0000:0000:0000:0000:0000 -
2001:0470:9434:ffff:ffff:ffff:ffff:ffff
-

Sofern ich mich also nicht verrechnet habe, habe ich damit nun neben den initialen 18.446.744.073.709.551.616 Adressen nun noch weitere 1.208.925.819.614.629.174.706.176 Adressen zusätzlich für meine Gerätschaften. 1.208.925.819 Billiarden Adressen, sehe ich das richtig‽
Und dabei bin ich noch nicht mal mit meinen zwei klassischen »Class-C« (IPv4 /24, also 256 Adressen jeweils) am Ende, und das, obwohl diverse Ex- wie aktuelle Kollegen Adressbereiche aus meinen PI-Bereichen nutzen …

Das WeTab ist nicht fertig …

… aber für mich ist das Thema nun durch: Spiegel Online hat das WePad WeTab getestet — ein erster Bericht, der meines Erachtens, gemessen am Preis des Gerätes, kaum hätte vernichtender ausfallen können.
Was immer die Macher in den letzten Monaten gebastelt haben – es drängt sich der Verdacht auf, daß der Wechsel des Linux-Unterbaus von Ubuntu auf Meego mehr als einen Manntag schluckte –, das, was initial ausgeliefert wurde, erscheint in etwa so konkurrenzlos grottig, wie es die erste Präsentation – als Film im Windows Mediaplayer – befürchten lies. Schade. Vor allem für all jene, die es tatsächlich unbesehen kauften …

Verlorener Posten

Tja, Sony. Wer hat denn angefangen, seine Kunden wie Kleinkinder zu behandeln und mit Sippenhaft zu belegen, ja, gefühlt zu enteignen? Jetzt juristisch gegen bestimmte Softwareentwickler vorzugehen, ist meines Erachtens kleinlich und peinlich.
Die Hardware ist meine, und ich werde sicher mit Freuden jede Software/Firmware installieren, die die, meines Erachtens widerrechtlich und willkürlich durch Sony entfernten, Funktionen (»OtherOS«) wiederherstellt. Firmware aus dubiosen Quellen, ggf. mit fragwürdigen Zusatzfunktionen, müßte ich nicht ausprobieren, wenn Sony die bei Kauf zugesicherten Eigenschaften nicht mich genötigt hätte, teilweise mit einem Firmware-Pflichtupdate aufzugeben — Sony, you simply get what you asked for. Reenable »OtherOS«, now!

VDR Infrastruktur …

Hachja. Ich kämpfe derzeit mit VDR 1.7.x auf dem DockStar, an sich ja nicht wirklich ein Problem, aber der Teufel steckt bekanntlich im Detail: aktuelle Versionen von vdr-plugin-xineliboutput (IMHO der Standard für die Integration von VDR in andere Programme) laufen augenscheinlich nicht auf der armel-Architektur, das Kompiilat terminiert mit SIGSEGV, Details siehe verlinkten Artikel auf vdr-portal.de.
Wer sachdienliche Hinweise hat: ich bin ganz Ohr ;)