Wie schon geschildert, hatte mein altes Board im Windows Rechner ja das Problem, dass mit der Q8300 nur 2 GB Ram möglich waren – und das doch etwas wenig ist. Also musste ein neues Board her. Nach etwas rumklicken hatte ich mich dann für ein Asrock P45X3 Deluxe und 4 GB OCZ Speicher entschieden. Nach dem Einbau kam die erste Ernüchterung: Das Board zeigte auf dem Internen Debug-LED nur “4d” an, und bootete dann neu. Nach etwas rumsuchen war der Schuldige schnell identifiziert: Das Board und der Speicher mochten sich nicht. Also schnell in die Innenstadt geradelt, und zwei neue Speicherriegel gekauft, diesmal langsamer (DDR3-1333) und von Kingston. Diese gingen dann auch. Wundersamerweise gingen die OCZ Riegel dann auch, wenn man sie zusätzlich zu den Kingston Riegenl aufs Board steckt. Vermutlich haben die da mal wieder irgendwelchen Quatsch im SPD stehen. Aber gut, dann hab ich halt jetzt 8 GB.

Nun stellte sich aber gleich das nächste Problem: Mainboard tauschen ist unter Windows immer noch ein No-Go, dass ist in den letzten 20 Jahren auch irgendwie nicht besser geworden. Auf jeden Fall verabschiedete sich der Rehner beim Booten mit einer kryptischen Fehlermeldung in den Bluescreen (0x0CHastenichtgesehen). Neue Hoffnung kam aus, als beim nächsten Reboot der freundliche Reperaturassistent aufpopte, und mir anbot, mal flux das Problem zu beheben. Diese währte allerdings nicht lange, denn der Assistent verabschiedete sich ziemlich schnell mit “Unbekannter Fehler” im Nirvana – nicht ohne mir noch anzubieten, die Fehlermeldung doch an Microsoft zur Post Mortem Analyse zu schicken, und einen auf der etwas trostlosen Rettungskonsole zurückzulassen.

Nun gut, man kennt ja Windows schon eine ganze Weile, und weiss, dass der Fehler höchstwahrscheinlich durch einen fehlenden SATA-Treiber verursacht wird. Nur: Wie installiert man den nach? In der Rettungskonsole wird leider keine passende Option angeboten, und zur Windows Neuinstallation fehlte mir der passende DVD-Rohling.

Nach sehr langem Überlegen und rumprobieren bin ich auf die Idee gekommen, dass es evtl. die Möglichkeit gibt, einen generischen AHCI-Treiber zu verwenden, und so zumindest mal wider in die Lage zu kommen, den richtigen Treiber zu installieren.

AHCI aktiviert man unter Windows in der Registry, genauer gesagt unter

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci indem man den Wert “Start” auf den intuitiven Wert “0″ setzt.

Nun gut, aber wie editiert man von der Rettungskonsole aus die Registry? Netterweise wird zwar Regedit mitgeliefert, dieses editiert jedoch nur die Registry des Rettungs-Windows in der Ramdisk. Die Lösung ist die “Load Hive” (zu Deutsch: “Struktur Laden”) Option. Damit kann man Teilbäume der Registry der Windows Installation laden, editieren und später wieder exportieren. Allerdings: Wo zum Geier ist die Registry eigentlich gespeichert. Die Antwort:

c:\windows\system32\config

Dort befinden sich einige Dateien, welche die Unterhives von HKEY_LOCAL_MACHINE beinhalten. Wir laden also die Datei “SOFTWARE”. Nun kommt ein wenig intuitiver Dialog, der einen nach dem Namen des zu ladenden Hives fragt. Das ist schlichtweg falsch übersetzt, Regedit fragt nämlich eigenltlich, unter welchem Namen es das Ding einblenden soll. Gibt man da nun “FOO” ein, so findet man den Teilbaum unter HKEY_USER\FOO. Nun nimmt man die entsprechenden Einstellungen an HKEY_USER\FOO\CurrentControlSet01\Services\Msahci vor. Nun muss man den Teilbaum noch speichern, um die Änderungen zu persistieren. Hierzu klickt man auf HKEY_USER\FOO und wählt Datei->Struktur entfernen.

So, jetzt beim nächsten Reboot im Bios noch AHCI aktiviert, und schon hat man ein (fast) wieder funktionsfähiges – wenn auch Treiberloses – Windows.

Mythos:

Schaltet man die Atomkraftwerke ab, bleibt eine große Lücke zurück, die man (hier unterscheiden sich die einzelnen Argumentationen) entweder garnicht schliessen kann, und es wird dann irgendwann dunkel in der BRD oder (Argumentation 2) man muss dafür ganz viele schmutzige Kohlekraftwerke bauen.

Kommentar:

Klingt erstmal plausibel: Mit Hilfe von Kernspaltung kann man sehr viel Energie gewinnen. Fallen die AKWs weg, müssen diese natürlich ersetzt werden. (Oder halt entsprechend weniger Strom “verbraucht” werden).

Die Wahrheit:

Bei dieser Argumentation wird suggeriert, dass in der BRD Unmengen an Strom von den AKWs produziert wird. Dies ist jedoch nicht der Fall. Dazu schauen wir uns mal ein paar Zahlen an:

In Deutschland sind derzeit 17 Reaktorblöcke am Netz. Jeder dieser Reaktorblöcke hat eine maximale Nettoleistung zwischen 840 und 1410 Megawatt. Diese Rekatoren werden jedoch nicht immer auf voller Leistung gefahren und sind auch nicht immer “on-line”. Insbesondere wenn es im Sommer heiss wird, müssen AKWs immer wieder in ihrer Leistung gedrosselt werden, um eine Überhitzung von Gewässern, die zur Kühlung verwendet werden, zu vermeiden. Insgesamt ergibt sich daraus eine Verfügbarkeit, die irgendwo zwischen 70 und 80% liegt.

Auf den Strommix schlägt sich das dann folgendermaßen nieder:

Wie man sieht, hatte die Atomenergie im Jahre 2009 einen Anteil von 22,6% am Strommix in der BRD, also gerade mal etwas mehr als ein Fünftel. Natürlich ist es nicht schön, dass fast die Hälfte des Stroms aus Kohlekraftwerken kommt, allerdings geht es hierum im Moment garnicht.

Auf jeden Fall sollte klar sein, dass es keinesfalls unmöglich ist, die Kernkraft durch eine andere Technologie zu ersetzen.

Übrigens: Zählt man die Regenerativen Energien zusammen kommt man in dem Diagramm auf über 15%. Im Vergleich dazu: 1995 war es gerade mal ein Zehntel davon!

Es gibt also viele Möglichkeiten, die AKWs zu ersetzen:

a) Regenerative Energien auf einen Anteil von 37% Ausbauen (entspricht also etwas mehr als einer Verdoppelung der Anlagen).

b) Regenerative Energien auf einen Anteil von 27% ausbauen und 12% Energie einsparen oder die Gaskraftwerke um 12% ausbuaen.

c) Regenerative Energien so lassen wie sie sind, und 22,6% Energie einsparen.

Oder:

Regenerative Energien auf 75% ausbauen, und die Kohlekraftwerke gleich mit abschalten.

Mythos:

Aufgrund von immer mehr Computern und immer mehr Technologie steigt der Strombedarf von Jahr zu Jahr an. Atomenergie ist die einzige Technologie, die in der Lage ist, überhaupt genug Strom zu liefern.

Kommentar:

Dieses Argument wird immer wieder gerne gebracht, um zu begründen, warum sich nur mit Atomenergie der Strombedarf der BRD decken liese. Auf den ersten Blick erscheint das ja auch logisch, da wir immer mehr Geräte anschaffen, die elektrisch betrieben sind: Computer, Laptops, Spielekonsolen, Settop Boxen etc.

Die Wahrheit:

In Wirklichkeit ist es jedoch so, dass der Strombedarf der BRD seit über 30 Jahren nahezu konstant bei ca. 15 000 PJ liegt. Aufgrund von bestimmten Einflüßen wie dem Klima und z.B. der Wirtschaftskriese letztes Jahr schwankt der Bedarf immer wieder im einstelligen Prozentbereich. Eine deutliche Zunahme ist jedoch nicht erkennbar. Im Gegenteil: Im Vergleich zu 1980 hat der Strombedarf in den letzten Jahren sogar abgenommen!

Woher kommt das? Nun, zunächst einmal ist es so, dass die Privathaushalte gerade mal einen Anteil von ca. 27% am Strombedarf haben. Dazu kommt, dass die Spielekonsolen, Fernseher etc. eben gerade nicht die Großverbraucher im Haushalt sind. Dies sind nämlich eher Dinge wie Beleuchtung, Heizung, Elektroherd (Eine Stunde kochen mit 2 Herdplatten braucht in etwa soviel Strom wie 12 Stunden Computerbetrieb!) etc. Und da hat sich prinzipbedingt in den letzten 30 Jahren nicht so viel geändert (Bei der Umwandlung von elektrischer Energie in Wärmeenergie gibt es jetzt nicht soooo viel Einsparpotential).

Bei der Beleuchtung dürfte sich die zunehmende Verbreitung von Energiesparlampen positiv Auswirken. Und auch beim Fernseher dürfte die zunehmende Verbreitung der TFT-Technologie zu einer signifikanten Einsparung auswirken.

Wie auch immer: Die Aussage, dass der Strombedarf in der BRD jedes Jahr steigen würde gehört auf jeden Fall in das Reich der Legenden!

Aus aktuellem Anlass:

Diskussionen um die Laufzeitverlängerung von Atomkraftwerken – oder dem “Ausstieg aus dem Ausstieg”, wie es so schön heisst, werden ziemlich schnell sehr emotional. Um eins vorneweg klarzustellen: Ich bin bestimmt kein “Öko”. Wo es sinnvoll ist, versuche ich Umweltfreundliche Produkte zu kaufen, allerdings quäle ich mich auch nicht, und es muss nicht immer alles öko oder Bio sein.

Sinnvoll ist für mich z.B. dass unser Strom von Naturstrom kommt. Der ist nämlich immer noch billiger als der Tarif der Stadtwerke, der Laden ist kundenfreundlicher und der Strom kommt zu 100% aus regenerativen Energien. Ist doch eigentlich eine tolle Sache, oder?

Dieser Meinung ist leider nicht jeder. Um nochmal zur Atomenergie zu kommen: Hier werden leider immer wieder die selben dummen Argumente der Atomloby nachgeplappert, ohne sich selbst mal Gedanken zu machen, was daran wirklich dran ist. Ich möchte daher in einer kleinen Artikelserie die häufigsten Argumente aufführen und kurz dazu Stellung nehmen, warum ich diese für unsinnig halte.

Neulich musste ich feststellen, dass mein toller Intel Q8300 Quad-Core Prozessor keine Virtualisierungsunterstützung hat. Blöderweise braucht Virtualbox diese aber, um 64-Bit Gäste auszuführen.

Nachschlagen in den Intel-Datenblättern hat ergeben, dass nur das erste Stepping des Q8300 kein VT-X kann. Na super, da hab ich mir wohl beim Kauf vom Händler einen Ladenhüter andrehen lassen.

Na ja, wie auch immer: Eine neue CPU musste her. Nach etwas Suchen ist die Entscheidung auf eine Q9505 gefallen, die bei Mindfactory gerade im Angebot war. Die hat den netten Beieffekt, mehr Cache zu besitzen und sogar ein bisschen schneller zu sein.

Jetzt war ich allerdings in der Situation eine CPU (nämlich die Q8300) übrig zu haben. Mit Hinblick auf das baldige Erscheinen von StarCraft 2 war eine passende Verwendung schnell gefunden: Das Ding soll in den Windows-Rechner.

In diesem Rechner ist ein Asus P5W64-WS (Btw. das wahrscheinlich beste Mainboard, das ich je besessen habe) verbaut. Da der darauf verbaute Chipsatz offiziell jedoch nur 65nm CPUs unterstützt, die Q8300 jedoch in 45nm-Lithographie gefertigt ist, hatte ich zunächst Bedenken ob das so funktioniert. Aber probieren geht ja bekanntlich über studieren. Also schnell nochmal das aktuellste Bios (1101) geflashed, und schon kann’s losgehen.

Nach etwas runmfluchen beim Versuch, den CPU Lüfter wieder aufzubringen (Welcher Idiot hat sie eigentlich die Sockel-775 Lüfterbefestigungstechnik ausgedacht? Da hätte man sich AMD mal etwas abschauen können, die wissen nämlich, wie man das richtig macht), die erste Erleichterung: Der Rechner lies sich anschalten und läuft.

Blöderweise wird die CPU jedoch nur als 2.00 GHz anstatt mit 2.5 GHz erkannt. Also von Hand einstellen. Zum Glück bringt das P5W64 die passenden Übertaktungswerkzeuge mit.

Also:

Die Q8300 hat einen fest eingestellten Multiplikator von 7.5. Bei einem Zieltakt von 2.5 GHz ergibt sich damit ein Referenztakt von 333 MHz. Man muss allerdings aufpassen, dass man nicht versehentlich den FSB mit übertaktet, da sonst evtl. der Speicher nichtmehr mitspielt. Und ach ja: Die Lüftersteuerung muss man dannach wieder auf automatisch Stellen, sonst läuft die permanent im Düsenjägermodus.

Somit läuft der Q8300 nun stabil in meinem Spielerechner, und Starcraft 2 kann nächste Woche kommen.

Ach ja: Windows meldet einen Leistungsindex von 7.2 für die CPU.

Nachtrag: Gerüchten im Netz zu Folge lässt sich diese Konfiguration mit maximal 3GB Ram betreiben. Da mein Windows-Rechner aber eh nur 2 GB hat, ist das für mich voerst kein Problem. Beim Aufrüsten muss dann aber ggf. ein neues Board her.

Da ich da gerade zum x-ten mal drauf reingefallen bin:

Das udev der aktuellen Sysrescuecd zeigt nach dem Booten keine Devices für die LVMs an, obwohl diese korrekt erkannt wurden. Beheben lässt sich dies einfach, indem man die Volume Group einmal deaktiviert und dann wieder neuaktiviert:

vgchange -a n
vgchange -a y

Dann tauchen die LVMs wie gewohnt unter /dev/ auf.

Etwas schmunzeln musste ich ja gestern schon, als ich diesen Artikel bei Heise.de gelesen habe. Grinsen deswegen, weil in der Überschrift gleich zwei Namen auftauchen, an die ich unschöne Erinnerungen habe:

Zunächst mal ist da der Itanium – auch liebevoll Itanic genannt. Der Prozessor, der für den Tod der Alpha und des PA-Risc-Prozessor verantwortlich ist. Intel und HPs Plänen gemäß hätte der Itanium das 21te Jahrhundert der IT-Industrie einläuten sollten.

Von der sogenannten VLIW (Very Large Instruction Word) Architektur hatte man sich erhebliche Performancevorteile gegenüber einer Superskalaren CPU versprochen. Die Idee ist hierbei, dass nicht der Prozessor, sondern der Compiler entscheidet, welche Befehle gleichzeitig ausgeführt werden können. Nur hat dieser Ansatz nie so funktioniert, wie Intel sich das vorgestellt hat, einen Compiler, der den Optimalen Code für den Itanium erzeugt, gibt es bis heute nicht.

Darüber hinaus hat es Intel  jahrelang nicht geschafft, die eigene Roadmap für den Itanium einzuhalten. CPUs erschienen teilweise Jahre später als angekündigt, der Sprung über die GHz Grenze war langezeit nicht möglich. Die CPUs waren langsam, veraltet und stromfressend.

Der Todesstoß wurde dem Itanium jedoch von AMD, mit der Markteinführung des Opterons, versetzt. Mit der AMD-64 Architektur war ein 64 Bit-Prozessor zu einem Bruchteil des Preises eines Itaniums verfügbar, der zudem auch noch signifikant schneller war. Der eigentliche Vorteil von AMD-64 ist allerdings, dass der Prozessor nativ auch IA-32 (z.B. i386, Pentium)-Code ausführen kann. Dies kann der Itanium nämlich nur Mithilfe eines (langsamen) Emulators.

Die Firma Unisys ist andererseits auch ein nicht unumstrittener Player im IT-Feld. Natürlich erinner sich viele an die legendäre UNIVAC oder an die Erfindung von Perl (wobei sie dafür – meiner Meinung nach – eingesperrt gehörten). Zu den negativen Erinnerungen gehört jedoch das LZW-Patent, das jahrelang Anwender des GIF-Bildformates in Angst und Schrecken versetzte.

Das absolute Highlight war meiner Erinnrung nach jedoch eine Anti-UNIX, Anti-Linux Propagandakampagne, die Unisys zusammen mit Microsoft unter dem Titel “We have the way out!“, bei dem sich später herausstellte, dass es unter FreeBSD mit dem Apache Webserver lief. Na ja, war wohl nix. Das ist im übrigen auch meiner Meinung zum Itanium. Ich hoffe auf den schnellen Tod dieser Architektur.

Wie heißt es so schön: Was lange währt, wird endlich gut? Ich hoffe, selbiges trifft auch auf meine Studienarbeit zu, die nach fast einem Jahr Arbeit fertig geworden ist. Das ist schon ein tolles Gefühl, wenn man die Ergebnisse seiner Arbeit in gebundener Form in der Hand hält.

Im wesentlichen geht es in der Studienarbeit darum, wie erkannt werden kann, ob eine Webseite per HTTPS abrufbar ist. Aufgrund von Name-Based-Virtual-Hosting reicht es hierzu nicht aus, sich auf Port 443 zu verbinden, und zu hoffen, dass ein gültiges Zertifikat zurückkommt. In der Studienarbeit wurde daher ein Algorithmus entworfen, der auf Grundlage von Mustererkennungsverfahren die über HTTP abgerufene Webseite mit der über HTTPS abgerufenen vergleicht. Schwierig war hierbei vor allem, dass mittlerweile viele Webseiten dynamisch generiert werden, d.h. man kommt mit einem einfachen String-Vergleich nicht sonderlich weit. Hier kommt mein Algorithmus ins Spiel, der geschrieben wurde, um genau mit solchen Fällen umzugehen.

Studienarbeit: HTTPS Autodiscovery – Proaktive Erkennung von Sicherheitsverfahren.

Möchte man unter Linux die Partitionstabelle neu einlesen, ohne das System neu zu booten, so kann man dafür den Befehl partprobe verwenden. Dies ist z.B. sinnvoll, wenn man ein Raid Device auf einer ungenutzen Partition erstellen möchte, weil man hier den Partitionstyp auf Raid-autodetect ändern muss, weil man sonst die Fehlermeldung wie z.B. “mdadm: /dev/sda1 is too small: OK” erhält.

Im Rahmen meines Seminars “Netzsicherheit und Hackerarbwehr” ist mir ein Sicherheitsfeature im Linux Kernel begegenet, dem bisher noch relativ wenig Aufmerksamkeit gewidmet wurde. Das Feature heißt “Randomize VA Space”. Hierbei handelt es sich um Address-Space-Layout-Randomization (kurz ASLR). Bei jedem Start eines Programms, wird der Anfag des Stacks innerhalb des Address-Space (AS) dieses Programmes  nicht mehr wie früher statisch, sondern zufällig bestimmt. Bei IA-32 und X86_64 wird vom anfänglichen Stackpointer eine zufälliger Integer zwischen 0 und 2^13-1 abgezogen. Insgesamt gibt es also 8192 verschiedene Adressen, an denen sich der Stackpointer befinden kann.

Der Code hierfür ist architekturspezifisch und findet sich für IA-32 z.B. unter /usr/src/linux/arch/i386/kernel/process.c :

unsigned long arch_align_stack(unsigned long sp)
{
    if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
        sp -= get_random_int() % 8192;
    return sp & ~0xf;
}

Dies alleine bietet noch keinen ausreichenden Schutz gegen Exploits. Die Gründe dafür kann man in meiner Seminarausarbeitung nachlesen. Allerdings ist das schon recht lästig, insbesondere, wenn man nicht weiß, dass es so ein Feature gibt und man ewig nach dem Grund sucht, wieso der schöne Exploit, den man gerade geschrieben hat, dauenrd abstürzt.

Abschalten kann man das Feature übrigens mit dem Befehl:

sysctl kernel.randomize_va_space=0