Administrator's Blog

Eben las ich die für mich als Linuxfan freudige Nachricht, dass nach dem iPod (ipodlinux.org) auch das iPhone mit Linux läuft. Zwar läuft es nur sehr puristisch, d.h. keine Treiber für WLAN, den Touchscreen, Bluethooth usw. - aber es läuft immerhin, wie man auf dem Video sehen kann. Und dank Bootloader kann man jederzeit wieder auch die normale Apple-Firmware booten, ohne vorher technischen Aufwand betreiben zu müssen.

Generell ist es ziemlich cool, Linux auf alle möglichen technischen Plattformen zu portieren. Natürlich stellt sich die Frage nach dem Sinn, benutzbar wird wohl in diesem Fall auch nie richtig werden. Dazu ist die ursprüngliche Oberfläche einfach zu schön und ausgereift. Aber interessant ist es auf jeden Fall

In der Vergangenheit waren ja die Linux-Implementierungen auch manchmal deutlich besser als das Original. Man denke da nur an XBMC, das MediaCenter für die alte XBOX damals. Absolut traumhaftes Programm, welches ich samt XBOX heute noch im Einsatz habe Ohne XBMC wäre die alte Konsole wahrscheinlich schon längst im Keller gelandet.

Die iPhone-Variante scheint sich sogar recht einfach installieren zu lassen (Anleitung), allerdings werden wohl wichtige Teile des NOR-Speichers überschrieben, um den Boatloader zu installieren. Das vorher erstellte Backup sollte man daher unbedingt sicher verwahren. Mir ist das ehrlichgesagt zu heiss, da ich auch kein Gerät übrig habe derzeit. Es kommt übrigens Ubuntu 8.10 zum Einsatz, natürlich in ARM-Architektur entsprechend der ARM-CPU im iPhone.

Bin sehr gespannt, was da noch auf uns zukommt, Linux rocks on ...

Meinem neuen Mainboard (ich berichtete) von ASUS lag eine besonders tolle Software bei, die sich "EPU-6 Engine" nennt. Für was das EPU dort steht, habe ich noch nicht herausgefunden - Emergency Power Unit? Keine Ahnung ...

Aber immerhin spart man damit laut ASUS auf die Dauer jede Menge CO2 ein, schließlich liegt das ja derzeit voll im Trend, auch in der IT-Branche. So habe ich (angeblich) in wenigen Stunden 8,5g CO2 gespart. Wie das nun konkret ermittelt wird, bleibt wohl ASUS's Geheimnis. Das Tool kontrolliert dabei nahezu den kompletten PC inklusive Taktfrequenz und setzt die Werte auf Wunsch automatisch optimiert zum jeweiligen Systemzustand - zumindest in der Theorie.

Das funktioniert leider nicht wirklich. Eben habe ich eine größere Game-Installation durchgeführt und konnte dabei nicht mehr normal weiterarbeiten. Das System war dabei mehrfach für ca. 5 sec komplett tot, nichtmal die Maus bewegte sich mehr. Da der Fehler reproduzierbar und periodisch auftrat, deaktivierte ich das Tool kurzerhand. Und sieht da, nun läuft's wieder gewohnt schnell. Die Deinstallation war dann gleich der nächste Arbeitsschritt.

Sorry, aber in dem Fall muss ich wohl anders CO2 einsparen. PC-Systeme mit schlechter Performance gehen gar nicht.
Vielleicht fahr ich im Sommer dafür mal wieder mit dem Rad auf Arbeit ...

Für meinen mobilen Vaio-TZ samt integrierter UMTS-Karte nutze ich die HSDPA-"Flatrate" von T-Mobile, auch bekannt als web'n'walk. Dazu gibt's von T-Mobile ein recht informatives, wenn auch instabiles Tool zur Zugangs- und Trafficverwaltung. Erst wollte es unter Vista nicht richtig laufen, als Administrator gestartet tat es aber dann immerhin seinen Dienst. Besonders im Ausland war das immer ganz nett, so wusste man immer, wieviele Euro man bereits "verbrannt" hat - anders kann man das bei immernoch ~2 EUR pro MByte wohl nicht nennen. Außerdem sah man direkt, in welches Netz man sich einbucht und ob es sich um einen Partner von T-Mobile handelt.

Das Tool ist basiert seltsamerweise auf Shockwave Flash in Version 9. Und auch nur auf Version 9, wie ich nun weiss. Ein Kollege hatte mich bereits gewarnt, dass beim Update auf Shockwave 10 nix mehr geht, nun habe ich das direkt mal gemacht und kann dies bestätigen.

Ein Update gibt's offenbar nicht, selbst die Software findet man via Google kaum. Nur einen Link auf t-mobile.at - die dt. T-Mobile-Site erscheint gar nicht. So kann man entweder nur auf Shockwave 9 downgraden oder sich via DFÜ-Verbindung einwählen. Das funktioniert zwar prima, allerdings muss man dann auf die Statistiken etc. verzichten. Ein vergleichbares Tool habe ich jetzt auf die Schnelle nicht gefunden, wünschenswert wäre es aber.

Sehr interessiert verfolge ich seit einiger Zeit die Entwicklung von MySql-Cluster 6.4, also der nächsten Generation. Die aktuelle 6.3.19 läuft zwar sehr schnell und stabil, dennoch gibt es noch Raum für Verbesserung und Optimierung. So bringt die 6.4 endlich das online hinzufügen von Nodes mit sich, so dass man dazu nicht den ganzen Cluster stoppen muss. Das macht die Skalierung sehr viel handlicher und minimiert die Downtimes enorm. Außerdem werden endlich Threads unterstützt, so dass man aus einem Server mit mehreren CPU's bzw. Core's endlich sinnvoll auslasten kann. Aktuell langweilen sich sämtliche CPU's/Core's fast die ganze Zeit, während auf einem die Hauptlast liegt.

Im Blog eines Entwicklers der MySql-AB kann man nachlesen, dass 8 Core's dann wohl die Idealbesetzung sind. Ein Glück, dass ich damals Boards mit 2 CPU-Sockeln in den Nodes verbaut hab

Vielversprechend sind auch die Benchmark-Werte aus Jonas's Blog, so erreichte er gestern in Tests mit SCI-Karten stolze 1 mio. reads/s - auf einem Node! Man kann sich vorstellen, was so ein Cluster mit 64 oder gar 128 Nodes dann beantworten kann. In der Theorie dann sogar 100 mio+ reads/s. Angeblich will er mit TCP-Optimierungen dann auch via Ethernet solche Werte erreichen (1000 bzw. 10000 MBit/s). Würde mir natürlich sehr gefallen, denn in meinen 1HE-Kisten ist kein Platz mehr für SCI-Karten

Im Laufe der Zeit habe ich die verschiedensten Caching-Methoden ausprobiert, um irgendwelche Web-Applikationen zu beschleunigen. In der Regel will man damit Datenbanken entlasten, vor Allem wenn gleiche Query's tausendfach ausgeführt werden. Allerdings ist es in manchen Fällen so, dass der Aufwand den Nutzen nicht rechtfertigt bzw. sogar die Last durch das Caching höher ist, als durch die ursprünglichen Abfragen. Ich will hier mal am Beispie einer klassischen WebApp mit MySql-Backend ein paar Caching-Varianten samt meinen Erfahrungen darstellen. Zuerst einmal 2 Methoden, wie man mit MySql-Bordmitteln schon etwas erreichen kann:

Der MySql Query Cache speichert direkt auf dem MySql-Server die Ergebnisse einzelner Query's und liefert bei erneuter Abfrage nur das Ergebnis aus, ohne die Datenbank selbst erneut zu durchsuchen. Ganz abgesehen von den üblichen Limitierungen wie RAM und Anzahl der Query's im Cache ist das eigentliche Problem hier, dass nach JEDER Änderung in der entsprechenden Tabelle (INSERT/UPDATE) die Ergebnisse neu aus der Datenbank gelesen werden müssen (siehe z.B. hier). Somit fällt für mich der dieser Cache maximal unter "nice to have". Eine unter Last stehende Datenbank (in die meistens auch immer UPDATES oder INSERTS kommen) kann er aber wohl kaum entlasten ...

Eine weitere Alternative sind Tabellen vom Typ MEMORY. Leider unterstützt MEMORY keine BLOB- oder TEXT-Spalten, was sie z.B. für Volltextsuchen ungeeignet macht. Dennoch sind sie eine gute Alternative, wenn der DB-Server aufgrund vieler komplexer Abfragen sehr häufig auf die Festplatte zugreifen muss. Für Session-Tabellen beispielsweise ziemlich gut geeignet. Man sollte allerdings nicht vergessen, dass die Last nicht gänzlich vom DB-Server weggenommen wird, schließlich muss er die Anfragen weiterhin beantworten. Auch spielt natürlich der auf DB-Servern meist nur wenig vorhandene, freie RAM eine Rolle.

Caching-Methoden, die sich außerhalb des SQL-Servers abspielen:

Zuerst einmal gibt es natürlich Flatfiles, also einfache Textdateien, in denen man temporäre Daten als Cache ablegen kann. Bei kleinen Ergebnismengen, keiner hohen Last auf dem jeweiligen System und ausreichender Plattenkapazität kann auch dies einen Gewinn bringen. Allerdings ist es oft nicht sehr elegant zu bewerkstelligen, die alten Files zeitnah zu löschen bzw. vorhandene Files zu aktualisieren. Ein Cronjob kann da z.B. natürlich Abhilfe schaffen, man sollte aber die Limitierungen des jeweiligen Filesystems im Bezug auf maximale Ordner- und Datenanzahl nicht vergessen. Außerdem steigt die Load auf einem Server sehr schnell an, wenn diese Files sehr oft und zahlreich geöffnet/geschlossen werden. Auch ulimit kann hier eine Rolle spielen, sofern zu klein gesetzt.

Dann gibt es natürlich noch SQLite, was sich z.B. für kleinere Sachen als Auslagerung sehr gut eignet. Allerdings stößt man bei größeren Sachen schnell an die Filesystem-Grenzen, außerdem hatte ich in meinem Anwendungsfall mit recht hoher Last auf dem System zu kämpfen, wenn sehr viele Abfragen (nur SELECT's) auf die SQLite-DB's eingingen (Zugriff via PHP/PERL). Da war in diesem Fall sogar dann die Speicherung in Flatfiles effektiver. Außerdem hat man wieder das Problem mit der Wartung, denn man muss dafür sorgen, dass in den SQLite-DB's stets halbwegs aktuelle Informationen aus der MySql-DB liegen - je nach Notwendigkeit.

Nun kommen wir zu meinem klaren Favoriten memcached. Ich habe es selbst zigfach im Einsatz und bin einfach begeistert. Vor Allem die eingebaute TTL ist wunderbar, so muss man sich nicht darum kümmern, alte Einträge mühsam zu entfernen etc. Auch läuft memcached sehr stabil, verbraucht quasi null Rechenleistung und kann wunderbar hunderte Anfragen parallel bearbeiten. Ein besseres Caching-System kann man sich kaum wünschen. Allerding sollte man die Limitierung von maximal 1 MByte je Objekt beachten. In der Praxis stößt man aber nur sehr selten an diese Grenze. API's für die gängigen Scriptsprachen stehen bereit, so dass man seine WebApp damit recht einfach mit effektivem Caching versehen kann. Natürlich braucht man, je nach gewünschter TTL und Menge der Objekte entsprechend Server mit viel freiem RAM. Ansonsten ist memcached eine klare Empfehlung! Ein weiterer Vorteil ist, dass selbst bei einem Ausfall des memcached-Servers die Applikation weiterläuft, nur eben ohne Caching. Dank der Möglichkeit, memcached-Server verteilt aufzubauen, sollte das aber i.d.R. nicht vorkommen.

Natürlich macht es nicht in jedem Fall Sinn, einen Cache zu verwenden. Wenn man eine Website mit 20 Besuchern am Tag hat, kann man sich beispielsweise getrost lieber SEO widmen als Caching Auch bei sich permanent ändernden Anfragen/Ergebnismengen macht ein Cache wohl kein Sinn. Aber überall, wo sich Anfragen über einen recht kurzen Zeitraum zigfach gleichen und die Last auf der Datenbank recht hoch ist, macht ein Cache vielleicht durchaus Sinn. Wichtig ist auch, dass die Infrastruktur noch fähig sein sollte, auch ohne den Cache auszukommen (bzw. den Ausfall zu kompensieren), zumindest teil- oder zeitweise.

Eben habe ich gesehen, dass Spiegel Online (spiegel.de) endlich ordentliche RSS-Feed's zur Verfügung stellt. Wurde auch wirklich höchste Zeit, denn bisher waren nur simple Feeds mit den Titeln verfügbar. Nun sind, wie man es von einem aktuellen Feed erwarten kann, auch Bilder und die Anfangstexte der Artikel verfügbar. Außerdem ist es möglich, einzelne Ressorts als eigenen Feed zu abonnieren.

Wenn jetzt noch Heise den Newsticker auf ein reichhaltigeres RSS-Angebot ausbaut, ist meine kleine Onlinewelt wieder ein Stückchen schöner geworden. "Sage" im Browser, der "RSS-Reader" auf meinem iPhone oder auch "Lifearea" freuen sich zumindest über die neuen Feeds (das sind die Reader, die ich im Einsatz habe ...)

Am Wochenende wurde endlich das Telco-Release von MySql 5.1.29-RC mit NDB 6.3.19 freigegeben. Es wurden massenhaft Bugs behoben (Changelog), weswegen ich es heut direkt eingespielt habe. Das ist immer ein Akt, es müssen schließlich zuerst alle Management-Knoten, dann alle NDB-Knoten und zu guter letzt alle Server, wo mysqld rennt, auf den neuesten Stand gebracht werden. Besonders lange dauert jeweils der Neustart von ndbd auf den NDB-Knoten. Je nach Speicherauslastung und Config kann dieser Spaß schnell mal eine Stunde dauern - je Node! Das nennt sich dann "Rolling Restart" und erspart einem, das ganze Cluster herunterzufahren, was logischerweisee mit einer Downtime der Applikation verbunden wäre.

Auf jeden Fall habe ich die Chance mal genutzt, um ein kleines Benchmark beim kompilieren zu fahren. Ich habe also einfach mal die Zeit gemessen, wie lange make von mysql-5.1.29-ndb-6.3.19 dauert. Konfiguriert wurde jeweils --with-ndbcluster.

Da ich nur auf 2 verschiedenen Servertypen (QuadCore Xeon's und 2x Dualcore Opteron's pro Server, je AMD64-Architektur) kompiliert habe, fallen die Ergebnisse recht klein aus. Oben erst immer noch ein Teil von /proc/cpuinfo, danach die Ausgabe von time make:

model name : Dual-Core AMD Opteron(tm) Processor 2216 HE
cpu MHz : 2394.091
cache size : 1024 KB

real 12m28.244s
user 10m16.459s
sys 2m9.580s

und

model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
cpu MHz : 3166.775
cache size : 6144 KB

real 8m52.463s
user 6m56.326s
sys 1m17.081s

Wenig überraschend, dass der Xeon schneller fertig ist. Ich finde den Vorsprung von 1/4 aber doch schon beachtlich. Mal schauen, was dann die neuen AMD-CPU's so bringen werden (wenn verfügbar).

Auch für die hier verwendete Blog-Engine Serendipity (aka S9Y) gibt es ein Plugin, welches automatisch erkennt, wenn der User-Agent ein iPhone-Safari ist. Da ich die Wordpress-iPhone-Version sehr ansprechend finde, habe ich das nun auch mal für's Admin-Blog installiert. So richtig begeistert bin ich allerdings nicht, es sieht nämlich kaum anders aus als vorher Im Adminbereich ändert sich leider gar nichts, da gefällt die Wordpress-Application für's iPhone deutlich mehr.

Das Admin-Blog ist ja mit einem eher minimalistischen Skin ausgestattet, daher scheint die Optimierung recht wenig zu bringen. Wenigstens wird noch eine Mobile-Google-Sitemap erstellt und das Cachingverhalten wurde für mobile Endgeräte optimiert. Auch die Bilder werden wohl besser skaliert.

Nun weiss ich nicht so recht, ob ich das Plugin wieder rausschmeißen soll oder lieber drinlasse - Feedback ist daher erwünscht

Hier mal die Ansicht vorher mit dem normalen Skin auf dem iPhone:


Und hier nun die "optimierte" Version:

Wie hier versprochen gibt's nun endlich ein Bild von mir mit dem DAU-Orden auf der Brust. Natürlich für einen Admin normalerweise eher keine Auszeichnung, zu Darstellungszwecken allerdings kurzzeitig schonmal vertretbar

Dieses "Testexemplar" wurde mir freundlicherweise gratis zur Verfügung gestellt - vielen Dank nochmal an dieser Stelle.
Achja, wie findet ihr eigentlich das T-Shirt?

Keine Ahnung, womit ich das verdient hatte, aber gestern Nachmittag meinte das WinXP MCE auf meinem HTPC (den ich hier vorgestellt hatte), es müsste jetzt sofort nach dem Bootvorgang abstürzen und mir einen schwarzen Screen anzeigen. Ironischerweise hatte ich kurz vorher den neuesten Nvidia-Treiber für die 8800 GTS installiert.

Im abgesicherten Modus funktionierte es zwar, doch bekam ich es einfach nicht wieder im normalen Modus hin (trotz Deaktivierung aller Startprogramme, Treiber etc. pp). Lange Rede, kurzer Sinn - ich habe XP kurzerhand neu aufgesetzt. Das war leider ein etwas längerer Akt (3h), musste ich doch erst mühsam die ganzen Treiber wieder im Netz zusammensuchen, Service Pack 3 wieder aufspielen, MCE installieren und updaten usw. Insgesamt eine sehr nervige Aktion

Leider habe ich den Auto-Updater für mein internes Super-Multi-BluRay-LW (LG GGW-H20L) nirgends sim Netz gefunden, daher muss ich wohl kommende Firmware-Updates von Hand einspielen Das mit dem Auto-Update hatte bisher nämlich wunderbar geklappt. Oder ich warte, bis LG in der Supportwebsite das Ding endlich mal einfügt ... naja, das lässt sich verschmerzen.

Viel schlimmer ist die Tatsache, dass die IR-Fernbedienung wieder nicht funktioniert. Sie wird nichtmal vom System erkannt scheint mir. Media Center macht keinen Mucks, wenn ich die FB verwende. Auf der Website des Gehäuse-Vertrieblers "Inter-Tech" habe ich zwar glücklicherweise den Treiber für den USB-LCD-Touchscreen gefunden (der auch funktioniert), leider wird dort aber nirgends auch nur mit einem Wort die FB erwähnt ... mal schauen, ob die Kollegen von Inter-Tech auf meine Mail antworten, wo ich um Info's dazu gebeten hatte. Falls Irgendjemand die FB bei sich laufen hat, bitte ich freundlich um Rückmeldung

Hier nochmal ein Bild davon, wie man einen verschneiten Samstag auch spontan verbringen kann:
(ich müsste lügen wenn ich sagen würde, mir macht so ein Gebastel keinen Spaß )

Ich war schon verwundert, eine unserer Web-Applikationen konnte den XML-Kontodatencheck von ckonto.de nicht mehr erreichen. Jetzt weiss ich, dass der Grund dafür DDos-Angriffe auf die Nameserver von InternetX sind. Dazu gehört ja u.A. Schlund, wo die betreffende Zieldomain lag.

Auf Heise ist zu lesen, dass es 40.000 Hosts und rund 20GBit/s sind, die derzeit auf das Netz von InternetX hereiprasseln. Durch diverse Block-Regeln sind zwar derzeit die Server wieder erreichbar, teilweise aber nur sehr langsam. Auch golem.de war zwischenzeitlich nicht erreichbar - sehr zum Leidwesen der Trolle Insgesamt sind bis zu 2.3mio Domains betroffen, so viele hostet InternetX bzw. United Internet.

Mein Beileid gilt jedenfalls dem Admins, die den Spaß dort jetzt in den Griff bekommen müssen. Die Hotline ist zumindest kaum oder nur sehr schwer erreichbar, wie mir mitgeteilt wurde. Der Verursacher wird vermutlich auch nur sehr schwer ermitteln zu sein ...

Google-Analytics hat's vorgemacht, Piwik macht es als transparente OpenSource-Lösung nach. Ohne den Datenkraken Google im Hintergrund, ohne Limitierungen (die GA ja ohne AdWords-Account hat) und vor Allem ohne die vieldiskutierte Notwendigkeit, die Verwendung von GA in das Impressum der entsprechenden Seiten einzufügen. Außerdem ist man mit einer eigenen Lösung natürlich viel flexibler und kann, im Fall von Piwik dank OpenSource, selbst Anpassungen vornehmen. Die Entwickler scheinen irgendwie mit Wordpress im Zusammenhang zu stehen, zumindest erinnert Piwik oftmals an Wordpress (es gibt z.B. auch Plugin's und einen API-Key).

Die grafisch ansprechende Anzeige der Auswertungen erfolgt via Flash und gefällt. Die Statistiken werden entweder periodisch durch Useraufrufe generiert oder - bei High-Traffic-Sites - via Cron. Die Einbindung in die eigene Website erfolgt auch via JavaScript - wie beim "großen" Bruder von Google eben. Mehrere Websites werden durch verschiedene ID's auseinandergehalten - klappt prima. Außerdem kann man, wie auch von GA bekannt, Klickout's etc. tracken und den jeweiligen Seiten eigenen "actions" (quasi Namen) zuordnen. In einem Webshop könnte eine "action" z.B. die Artikelnummer oder der Artikelname sein. Das vereinfacht die Auswertung der Statistiken.

Ich nahm mir also einen sich langweilenden Linux-Server aus dem Regal (Quad-Opteron 2,8 GHz, 16GByte RAM, SATA-RAID 1) und setzte kurzerhand Apache (2.2), MySql (5.0 mit 8GByte KeyBuffer) und anschließend Piwik auf. Das geht erstaunlich problemlos und macht sogar richtig Spaß - das Setup ist ordentlich programmiert. Man ist ja in froher Erwartung auf die tollen Statistiken

An dieser Stelle sei allerdings erwähnt, dass ich Piwik mit einer High-Traffic-Site testen wollte (mehrere Mio. PI's/Tag) - schließlich sind dort die Stats wirklich relevant. Der JS-Code war auch schnell eingebunden und Piwik begann zu arbeiten. Anfangs blieb die Load auf dem Server auch deutlich unter 1.00, aber bereits nach wenigen Minuten stieg sie an. Erst machte der Apache ein paar Probleme, nachdem ich aber KeepAlive deaktiviert hatte, lief der ohne Probleme und konnte die mehreren 100 Requests/sec. problemlos abarbeiten.

Die Flut an SQL-Query's (200+/sec) war dann aber doch etwas zuviel des Guten. Viele INSERT's in MyISAM sind eigentlich kein Thema, aber es werden auch SELECT's ausgeführt, um eine User-Session (TTL: 30min) zu tracken. Bei mehreren 100k Einträgen in der Log-Table ging dann gar nichts mehr und ich musste Piwik leider wieder deaktivieren. In der Website sah man dann schon in der Browser-Statusbar "warte auf $piwik_host ...". Die Loadavg lag bei 20+!

In der nett moderierten Mailingliste (hier der Thread von mir) erfuhr ich dann, dass es derzeit kein automatisches Flushing der Tabellen gibt, nachdem die Stasistiken in die BLOB-Archive geschrieben wurden - das ist natürlich das KO-Kriterium für High-Traffic-Sites. Zumindest dann, wenn man nicht ein eigenes MySql-Cluster für Piwik aufsetzen möchte

Ich verfolge also die Entwicklung weiter, für Ende des Jahres wurde ein neues Release mit Flushing und besserer Performance angekündigt.
Hier noch ein Screenshot vom "Dashboard" (von der Piwik-Site):

Sich in der IT-Welt auszukennen ist nicht immer ein Segen. DAU's aller Geschlechter und Altersgruppen versuchen, dieses Wissen für Ihre Zwecke zu verwenden. Von defekter Hardware bis hin zu virenverseuchten Windows-Kisten soll man natürlich alles fixen, heilen und schneller machen. Wo neueste Spiele mangels guter Hardware ruckeln soll der "IT'ler" mal schnell durch ein paar coole Tricks (wie sie der DAU gern in der ComputerBild selbst schon gelesen hat ...) den heimsichen DAU-PC zu Höchleistungen verhelfen. Diese und andere Fälle kennt wohl jeder Admin, u.a. aus seinem Bekanntenkreis.

Ich habe wirklich Vieles probiert: Ignoranz, Freundlichkeit, Hinweise und sogar ein T-Shirt mit der Aufschrift "I will not fix your computer" (können DAU's eigentlich Englisch?) halfen nichts. Der DAU-Terror geht weiter. Wahrscheinlich bis an mein (IT-)Lebensende.

Eine weitere Waffe im Kampf gegen die DAU's bietet nun die Promex GmbH, nämlich den DAU-Orden. Damit z.B. zu Weihnachten beschenkt könnte dem DAU wieder einmal bewusst gemacht werden, dass er ein besonders guter DAU ist. Da dies natürlich kein wirkliches Lob ist, hoffe ich auf Rückgang der DAU-Anfragen

Falls nicht, hat man wenigstens ein nettes Fun-Gimmick verschenkt. Ich find's allemal lustig und freue mich schon auf meinen Test-Orden, der mir freundlicherweise zugestellt wird. Für die geneigte Leserschaft werde ich mich die Tage dann mit dem DAU-Orden fotografieren lassen und das Bild hier präsentieren, sozusagen als Admin im DAU-Pelz

So sieht der Orden dann aus:


PS: Als Leser des admin-blog.com ist man natürlich definitiv kein DAU - also keine Sorge, liebe Leser

Ich kann nicht genau sagen, wann sie es getan haben, aber sie haben die von mir mehrfach angemahnte XSS-Lücke (siehe auch hier) im Tchobo-Intershop endlich geschlossen. Ein Lob erspar ich mir an dieser Stelle, denn die Dauer bis zum Fix war mehr als peinlich. Wahrscheinlich war es nichtmal Tchibo selbst, sondern ein Intershop-Update. Wir werden es nie erfahren ...

Wenn ich mal ein paar Minuten Zeit und Lust habe, suche ich für die geneigte Leserschaft weitere XSS-Fundstücke - versprochen!

Als Fan von 3D-Shootern und neuester Technik beschloss ich, die 8800GT in meinem Shuttle XPC durch eine 280GX zu ersetzen. Der Kauf der GX war dabei noch die einfachste Übung, wie sich später herausstellte. Das XPC-Netzteil liefert immerhin 450W, was normalerweise wahrscheinlich sogar gereicht hätte (die Karte ist mit bis zu ~260W Eigenverbrauch angegeben).

Doch scheiterte der euphorisch angefangene Einbau bereits an der Tatsache, dass die Karte schlicht zu lang und zu dick ist - Mist! Erschwerend hinzu kommt, dass die GX280 gerne doppelt vom Netzteil mit Strom versorgt werden möchte, 1x mit einem 8-fach und 1x mit einem 6-fach-Stecker.

Da man im XPC das Netzteil aufgrung der eigensinnigen Bauform auch nicht einfach so austauschen kann, musste kurzerhand ein neues Gehäuse her. Und natürlich auch ein neues Netzteil, Mainboard und ein CPU-Kühler. Wir wollen ja klotzen, nicht kleckern

Nun steht also zu Hause unter dem Schreibtisch ein schickes, schwarzes "A+" - Gehäuse samt "be quiet!"-Netzteil mit 550W, in dem ein ASUS P5Q Pro Mainboard werkelt. Und natürlich hat dort auch die fette 280GX perfekt reingepasst. Aus dem Shuttle übernahm ich eigentlich nur die CPU (Core2Duo @ 3GHz), den RAM (2 GB Corsair) und die Festplatte. Als CPU-Kühler kommt ein echtes Monstrum (was die Größe angeht) mit dem tollen Namen "Scythe SCASM-1000 Andy Samurai Master" zum Einsatz. Den 120mm-Lüfter hört man kaum, sehr angenehm.

Ansonsten bin ich, bis auf die Lautstärke, sehr zufrieden mit der 280GX. Counterstrike-Source läuft laut "net_graph" mit nahezu permanet 299FPS trotz maximaler Einstellungen. FarCry 2 läuft ebenfalls sehr angenehm mit der Einstellung "ulrahoch" (Vista) - da kann man nicht meckern. Allerdings komm ich mir ohne Kopfhörer nach wenigen Minuten vor wie in einem Friseursalon, wo neben mir 3 ältere Damen mit dem Fön gestylt werden, was die Lautstärke angeht. Aber das ist wohl der Preis für die Performance ...

Hier mal noch 2 Bilder 8800GT vs 280GX, das "große" ist jeweils die 280GX: