Excel is one of the few programmes that believe to be more clever than the people using it. So as, when I try to enter a value span of, let’s say, “10-12″, meaning “ten to twelve” as in “ten to twelve hours to finish this task”, in a cell, Excel is pretty sure that I am meaning to say “10 December”. And, honestly, noone in a German-speaking country ever meant the tenth of december when writing “10-12″; that’s just not our way to write dates.

Anyway, Excel. While they do offer means of explicitly formatting a cell to a literal (what we developers would call “String”) value, my “10-12″ would transform to 40887. Which is, …, well, not what I was trying to enter into the cell at the first place.

Excel thus believes it is smarter than me. A user interface which is programmed to be better than the person using it. So is the iOS Autocorrect-Feature (“No, ye ain’t writin’ the right thing although you’ve tried to correct it twice”), and even Google (“No, ye ain’t typing the right words, so I am using my fuzzy search to display you some of the less relevant results instead”).

Why? Shouldn’t a programm be built to serve the user? Of course, that is hard to do. Respecting the fact, that, in Excel’s and Google’s and iOS’s native countries, they are probably behaving correctly – I guess it wouldn’t be such a hard thing to recognize that a user has replaced the 40887-Auto-Cell-Format-Value into the original text more than four times in only one spreadsheet? I mean, c’mon!

What am I trying to say with this entry? Not that Excel is a piece of crap (which it is, honestly, not; neither are Google ore iOS). But, your apps being so smart, why don’t you build a mechanism to identify whether or not your user is smart, and then adapt your UI and the application’s behaviour accordingly?

/*
 *i tried to find a witty comment for this method but i don't understand it anymore, honestly
 */

I do believe, and I must admit that I have somehow adopted this opinion from three great people (Matthias, Ben, Jochen) whom I have learned from, that well-written code requires less comment blocks than poorly elaborated code.

I mean, let’s quickly have a look at a line of code that is pretty common for our company’s coding conventions:

if( $objUser->isLoggedIn() ) {
    $objUser->redirectToProfilePage();
}

While, of course, one might argue whether or not it is useful to use type prefixes in a typeless language like PHP, one thing is still for sure:

No one mastering the english language will ever have any trouble understanding what is going on there. Obviously, some user is being checked for his login status and afterwards redirected to his profile page.

This is a result of smart method names. While it surely requires some extra typing work to create method names like “getUsersByFirstName” instead of “gubyfn”, think about it: Why would you ever want to get away from human language? I mean, seriously. Let’s re-write the example above in a “well-but-this-is-waaaaay-shorter”-Way, which I have seen in other agencies (and I have not worked with that many…):

if( $row->check() ) {
    $tP->r('prf');
}

(tP is, once you know it, a template processor, just to get it clear. r is a redirecting method.)

Would you have guessed what is happening there? No! The developer above would have needed to spend some extra time commenting wittily. In a best-case scenario this would’ve sounded like “Find out whether the User is logged in and, if so, redirect him to his profile page, which you will find in prf.php”.
But, in worst (and, rather likely, the actual) case, he’d write: “Check result and redirect”

Now, thank you. That does help, aight?

Always keep in mind that not everyone understands what the heck you are thinking about while writing the code. If you are anything like me, Unicorns and Rainbows might be it. So instead of trying to clarify your comments, why not accustom to write genuine human-readable code in the first place? Why not make your I-talk-to-people-Language your coding guidelines?

Here’s what I did to fix this bug:

I edited the os.js in c:\Dokumente und Einstellungen\{username}\Anwendungsdaten\Mozilla\Firefox\Profiles\{yourProfile}\extensions\flash_switcher@sephiroth.it\content\js so that it deletes the old flash plugin file prior to copying the selected one. You may download my Version of os.js here!

Obviously – this is happening on your own risk. Promise to create a backup of your old version first, and not to sue me if it kills your browser

I am just saying that this works for me in Firefox 3.6, Windows XP and 7, and version 2.0.2 and 2.0.3 of Flash Switcher

Nachdem ich in Teil 1 gezeigt habe, wie man einfache Get-Requests benutzt, um sein Gadget mit Inhalt zu versorgen, werde ich heute zum ersten Mal auf die Persistenzschicht zugreifen, die die API zur Verfügung stellt. Als Beispiel dient dabei ein “Pastebin”, also ein Textfeld, in das ich munter Sachen schreibe oder paste, die mir dann überall auf meiner iGoogle-Seite zur Verfügung stehen. Den fertigen Code für selbstversteher gibts natürlich auch.

1. Grundgerüst mit HTML

Wir fangen wieder an mit dem Grundgerüst. Das einzige, was wir hier an HTML brauchen, ist eine Textarea, das eine ID enthält. Diese wird mit ein wenig CSS-Code schön gemacht.

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs title="Pastemap" height="65">
    <Require feature="opensocial-0.8"/>
  </ModulePrefs>
  <Content type="html">
  <![CDATA[
    <style type="text/css">
      #pastearea {
        width: 100%; font-family: Arial, sans-serif;
        font-size: 12px; height: 60px;
      }
    </style>
    <textarea id="pastearea"></textarea>
  ]]>
  </Content>
</Module>

Wie ihr seht verlangt dieses Gadget wieder, dass die opensocial-0.8 API bereitgestellt wird. Außerdem habe ich dieses Mal eine Höhe von 65px vorgegeben, damit sich die Textarea wunderbar in den Container schmiegt.

Nun müssen wir als erstes zusehen, dass unsere Änderungen im Textfeld auch auf Googles Festplatten ankommt (ein Kollege sagte zynisch: “Interessanter wäre, wie man das verhindert!”). Versehen wir unsere Textarea also mit einem onchange-Event.

<textarea id="pastearea" onchange="updatePasteData()"></textarea>

2. Speichern

Wenn wir Änderungen im Textfeld vornehmen, wird also immer die Javascript-Funktion “updatePasteData()” aufgerufen.  Da diese noch nicht existiert, fügen wir, wie im ersten Teil, einen Script-Block am Anfang des Content-Knotens ein, der die folgende Funktion enthält:

function updatePasteData() {
  var pasteContent = document.getElementById("pastearea").value;
  var req = opensocial.newDataRequest();
  req.add(
    req.newUpdatePersonAppDataRequest("VIEWER",
                "pasteContent", pasteContent),
    "setPasteData");
  req.send();
}

Super, oder?

Als erstes wird eine Variable deklariert, die den aktuellen Inhalt der Textarea (der wir ja die ID #pastearea zugewiesen haben) enthält.

Danach erfolgt ein DataRequest nach der Form, wie alle möglichen Anfragen innerhalb der API vonstatten geht: Man erstellt sich ein generisches DataRequest-Object, fügt spezifische Requests hinzu (in meinem Falle einen AppData Request), und sendet ihn ab. Die ganze req.add-Geschichte läuft dabei wie folgt:

Die Methode ‘add’ der DataRequest-Klasse verlangt zwei Argumente, nämlich den eigentlichen, spezifischen Request, sowie einen Namen, unter dem man das Ergebnis des Requests in seinem DataResult-Object ansprechen möchte. Da wir in diesem Falle aber auf ein Result-Handling verzichten, schreibe ich dazu später mehr.

Interessant ist aber das spezifische Request-Object, welches ich als erstes Attribut übergebe. Dies ist nämlich vom Typen “UpdatePersonAppData”. Das tut – oh Wunder – nichts anderes, als Daten, die sowohl Personen- als auch Anwendungsbezogen sind, in die Persistenzschicht der API zu schreiben / aktualisieren. Das erste Argument gibt dabei die ID der Person, auf die diese Daten bezogen werden, an. Eine von zwei Spezial-Personen-IDs ist “VIEWER”, also ein abstrakte Bezeichnung für die Person, die gerade mit dem Gadget interagiert (die andere Spezial-ID ist “OWNER”, aber dazu an anderer Stelle mehr)

Als Zweites übergeben wir einen String als Namen für das Feld. Den brauchen wir, um später die Inhalte vernünftig zuordnen zu können. Stellt es euch vor, wie einen Key in einem benamten Array; oder, simpler aber falscher, als einer Art Variablennamen.

Der Dritter Parameter ist der Inhalt, der gespeichert werden soll. Das ist in diesem Fall ein String (der Inhalt der Textarea), darf aber auch z.B. ein Array oder gar ein komplexes Objekt sein.

Nachdem wir unseren Request hinzugefügt haben, schicken wir ihn einfach mit der Methode “send()” ab, und schon weiß Google, was wir gerade in unsere Textarea geschrieben haben.

3. Lesen

So ein Pastebin wäre natürlich unglaublich sinnlos, wenn man seine Inhalte nicht auch wieder auslesen könnte.

Ich will, dass beim Laden des Gadgets meine Inhalte vom Google-Server ausgelesen und in die Textarea eingefügt werden. Der erste Teil ist also, eine Aktion beim Laden des Gadgets anzustoßen. Wie das geht, haben wir schon im ersten Teil gesehen, nämlich:

gadgets.util.registerOnLoadHandler(getPersistantPasteData);

Diese Zeile kommt wie gehabt einfach ans Ende unseres Script-Blocks.

Was kann aber diese Funktion, getPersistantPasteData?

function getPersistantPasteData() {
  var idspec = opensocial.newIdSpec({ "userId" : "VIEWER",
                                      "groupId" : "SELF" });
  var req = opensocial.newDataRequest();
  req.add(
    req.newFetchPersonRequest("VIEWER"),
    "viewer");
  req.add(
    req.newFetchPersonAppDataRequest(idspec, "pasteContent"),
    "pastedata");

  req.send( pasteDataRetreiveHandler );
 }

Was an dieser Funktion jetzt wirklich neu ist, ist das sogenannte ID-Spektrum. Damit gebe ich einen Bereich vor, mit welchen IDs ich später arbeiten möchte. Da ich nur für mich selbst die Daten erfragen will, setze ich die User-ID auf die Pseudo-ID “VIEWER”, und die Gruppen-ID auf die Pseudo-ID “SELF”. Alternativ könnte man als zweiten Parameter auch dinge wie “FRIENDS” angeben, womit man die Daten aller Freunde des Viewers abfragen würde. Das ist mir aber momentan noch zu unheimlich.

Dass ich jetzt zwei mal mit der Add-Methode einen Request hinzufüge, hat gleich mehrere Gründe: Zum einen brauchen wir beide Informationen; zum anderen will ich für beide Requests nur einmal das Ergebnis behandeln müssen.

Warum brauchen wir beide Infos?

Der zweite Request ist wahrscheinlich einfacher erklärt: Er liefert uns die Daten, die wir in der Persistenzschicht unter dem Schlüssel “pasteContent” eingelagert haben, und zwar für alle im ID-Spektrum definierten User (Also derzeit nur der Viewer). In unserem Result-Objekt wird uns dieser Datensatz unter dem Schlüssel “pastedata” zur verfügung stellen. Soweit noch klar?

Der erste Request, der FetchPersonRequest nämlich, brauchen wir, damit wir endlich die echte ID des VIEWERs erfahren. Die Pseudo-ID wird nämlich unbrauchbar, wenn man sich mal die Datenstruktur ansieht, die so ein FetchPersonAppDataRequest zurückgibt:

0000123456789 = Object {

pasteData = 'Hallo, ich bin dein persönlicher Paste-Inhalt'

}

Allem voran geht also ein Object, das nach unserer ID benannt ist, welches wir also gleich in unserem Result-Handler ansprechen müssen. Und dazu brauchen wir die Viewer-ID. Aye?

Der Parameter, den ich der send()-Methode mitgebe, ist übrigens der Name der Result Handler Funktion.

4. Ergebnisbehandlung

Und eben dieser Result-Handler fehlt uns noch. Was müssen wir machen?

• Wir müssen gucken, ob der Request erfolgreich war oder nicht.
• Wir müssen an unsere Viewer-ID kommen
• Wir müssen wissen, welche Paste-Daten für diesen User gespeichert sind.

var viewerObject = null;
function pasteDataRetreiveHandler(response) {
  if (response.hadError()) {
    /* the fetch failed ... insert code to handle the error */
  } else {
    var viewer = response.get("viewer");
    viewerObject = viewer.getData();

    var data = response.get("pastedata").getData();
    var pasteData = data[viewerObject.getId()];
    document.getElementById("pastearea").innerHTML = pasteData.pasteContent;
  }
}

Argh. Viel Zeug.

Nun gut. Weil ich nicht bei jedem verdammten Request meinen Viewer abfragen möchte, deklariere ich eine Variable “viewerObject”, die uns zur ganzen Laufzeit zur Verfügung stehen soll. Dann beginnt die eigentliche Funktion.

Wie auch im HTTP-Request-Result-Handling aus Teil 1 wird der Result-Handler automatisch mit dem Response-Object gefüttert. Das überprüfe ich zunächst auf einen Fehler (z.B. wenn ich noch keine Daten gespeichert habe o.ä.). Ein Error Handling erspare ich uns allen an dieser Stelle.

Interessant wird jetzt aber, wie man mit den beiden unterschiedlichen, im gleichen Schritt ausgeführten Request-Typen umgeht: Die in Schritt 3 (funktion getPersistantPasteData) definierten Namen für die Requests kann ich jetzt nutzen, um gezielt die Informationen aus meinem Response-Object zu bekommen – und zwar mit einem einfachen get(“viewer”) für den “viewer”-Request. Das dadurch erstellte Objekt  ‘viewer’ ist aber auch nochmal ein wenig verschachtelt und zeigt uns erst mit Aufruf der Methode getData() seinen wahren Kern – ein Objekt vom Typen opensocial.Person, das Kernobjekt, das Alles-Monster des Social Networkings.

Um an den Inhalt des Ergebnisses meines zweiten Requests, “pastedata”, zu kommen, kürze ich die zwei Schritte ab und rufe direkt die getData() Methode auf, ohne vorher noch ein Hilfsobjekt zu behelligen.

Weiter Oben habe ich die Datenstruktur dieses Objekts beschrieben. Danach lassen sich auch die folgenden Zeilen erklären: ‘data’ ist das Objekt, viewerObject.getId() gibt mir den benötigten Schlüssel. Und auf der nächsten Ebene steht mein String mit dem Bezeichner ‘pasteContent’, den ich schließlich in meine Textarea pumpe.

Fertig. Doch recht einfach, oder?
Ach ja, und hier nochmal das fertige Listing.

In Teil 1 dieser Reihe zeige ich, wie man ein recht simples Gadget erstellt, das Inhalte per Request von einer dritten (nämlich normalerweise Deiner eigenen) Seite empfängt.

(Ach ja, und Leute, die das alles nicht lesen, sondern nur das Beispiel haben wollen, um selbst draus schlau zu werden, können sich auch den Ergebniscode im Ganzen ansehen.)

OpenSocial Gadgets sind kleine webbasierte Applikationen, die man in eine Reihe von Social Networks einbinden kann. Auf Facebook sind ähnliche Applikationen seit einiger Zeit sehr beliebt, studiVZ zieht am 07.12.2009 mit einer Implementierung des OpenSocial-Frameworks nach. Voraussetzung zur Entwickung solcher Gadgets sind solide Grundlagen über HTML, Javascript und AJAX, später ist sicherlich eine serverseitige Sprache wie PHP sinnvoll. Außerdem braucht ihr einen offen zugänglichen Webspace (der dann später auch die besagte serverseitige Sprache unterstützt).

1. Die Testumgebung

Irgendwo muss uns ja das OpenSocial-Framework zur Verfügung stehen, damit wir sinnvoll entwickeln und testen können. Hier bieten einige Social Networks, so auch StudiVZ, eigens eine Developer Sandbox an. Doch bis man sich dort angemeldet hat, dauert; und der Deploy erfolgt meines Wissens aufwändig als gepacktes Archiv auf irgendwelche studiVZ-Server.

Da kommt uns doch ganz gelegen, dass Google ein bisschen weniger restriktiv ist, und jeden alle möglichen Gadgets ganz einfach per Feed in seine iGoogle-Startseite einbinden lässt. Solltest du also noch keinen Google Account haben, ist jetzt der richtige Augenblick gekommen, dich zu registrieren und mit iGoogle, der anpassbaren Google Startseite vertraut zu machen. Ich warte hier so lange.

2. Der Aufbau

Bereit? Gut. Auch wenn ich es eigentlich überspringen wollte, eignet sich ein klassisches Hello-World-Beispiel doch recht gut, um den Aufbau eines jeden Gadgets zu zeigen. Das ist nämlich zunächst nichts anderes als eine XML-Datei:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs title="Mein erstes Gadget">
    <Require feature="dynamic-height" />
    <Require feature="opensocial-0.8"/>
  </ModulePrefs>
  <Content type="html">
    <![CDATA[
       <p>Hello World</p>
    ]]>
  </Content>
</Module>

Was da passiert? Ganz einfach!

Innerhalb des <Module>-Tags finden sich die Knoten <ModulePrefs> (“Moduleinstellungen”). Dort wird als Attribut der Name des Gadgets geliefert. Anschließend legen wir fest, dass das Gadget nur eingebettet werden darf auf Seiten, die uns das Feature “dynamic-height” sowie die “opensocial-0.8″-API bereitstellen.

Der Content mit dem darin enthaltenen CDATA-Block ist im Prinzip nichts anderes als der <Body>-Konten in HTML und wird später – wer hätte es gedacht – allen Inhalt und alles Javascript des Gadgets enthalten. Speichern wir das ganze doch mal auf unserem Webspace als “myfirstgadget.xml”.

Gadget-XML zur iGoogle-Seite hinzufügen

3. Der erste Test

In iGoogle siehst du oben rechts den Link “Gadgets hinzufügen”. Dahinter verbirgt sich eine Auswahlseite, die uns wiederum einen Link zum Hinzufügen von Gadgets oder Feeds via URL bereitstellt. Draufklicken, URL zum soeben erstellten XML hineinpasten, hinzufügen und gut is’.

Schau doch mal, was deine Startseite jetzt sagt! Buenos Dias, Mundo!

Und Mundo bist in diesem Falle du.

4. Requesting

Wir wollten ja ein Gadget bauen, das seinen Inhalt dynamisch per HTTP-Request erhält. Das klingt nach AJAX, ist es irgendwie auch. Passiert also in Javascript. Fügen wir also den folgenden Script-Block unter den öffnenden <Content>-Tag in unserem Beispiel ein:

<script type="text/javascript">
function init() {
    var params = {};
    params[gadgets.io.RequestParameters.CONTENT_TYPE]
                        = gadgets.io.ContentType.TEXT;
    params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 5;
    var requestUri = "http://www.example.org/apitest.php?random="
                        + Math.floor(Math.random()*11);
    gadgets.io.makeRequest(requestUri, testApiResultHandler, params);
}
function testApiResultHandler(data) {
    document.getElementById('articleText').innerHTML = data.text;
    gadgets.window.adjustHeight();
}
gadgets.util.registerOnLoadHandler(init);

</script>

Wieder einmal: Was passiert hier?

Erstens erstelle ich eine Funktion init(). Die ist für den eigentlichen Request zuständig. Wie aus der OpenSocial-API-Referenz ersichtlich, wird der HTTP-Request mit der gadgets.io-Klasse vollzogen und darf eine Zielurl, eine Callback-Funktion und Parameter als Argumente erhalten. Ein passende instanz der gadget-Klasse stellt mir das Framework übrigens automatisch bereit.

Bauen wir uns also zunächst die Parameter zusammen. Hinter den langen Konstantennamen, die dem params-Objekt als Keys mitgegeben werden, stehen gültige Schlüssel aus dem Optionenkatalog der gadgets.io-Klasse. Ich definiere also, dass ich als Content-Type für die Antwort meines Requests simplen Text erwarte.

Außerdem stelle ich klar, dass Google die Request-Antwort für maximal 5 Sekunden cachen darf. Dieser Wert ist für Developmentzwecke super, kann aber im Livebetrieb extrem serverauslastend wirken. Denkt daran! Das Framework gibt uns schon eine Spitzenmöglichkeit, einfach zu cachen, so sollte man sie auch benutzen.

In der requestUri-Variablen steht – welch Wunder – die Adresse, an die der Request gehen soll. Ich füge außerdem eine Zufallszahl als Get-Parameter an, sodass noch einmal das Caching wunderbar umgangen wird.

Schließlich rufe ich mit der makeRequest-Methode der gadgets.io-Klasse den tatsächlichen Request auf. Das erste und letzte Argument kennt ihr bereits, der zweite ist der Name der Callbackfunktion, also der Funktion, die aufgerufen wird, wenn der Request eine Antwort geliefert hat.

Die Zweite Funktion wird aufgerufen, nachdem wir eine Antwort auf unseren Request erhalten haben. Der Wert für “data” wird uns reingeschmissen und enthält das Result-Object – und das, ohne dass wir noch etwas dafür tun müssen!

Wir könnten “data” an dieser Stelle einmal im Firebug inspizieren – außer dem später benutzen Attribut “text” gibt es nämlich noch ein paar andere, wie den HTTP-Statuscode der Antwort und mehr. Doch dazu ein anderes Mal.

Jetzt injizieren wir nämlich erstmal die Response in unser DOM, nämlich in ein Element mit der ID “articleText”. Das solltet Ihr natürlich erstellen, zum Beispiel als <div> unterhalb des “Hello World!”-Containers. Als neuen Inhalt für dieses Element dient – wie gerade angedeutet – der Inhalt des “text”-Attributs von “data”.

Die letzte Zeile dieser Funktion greift wieder auf die gadgets-API zurück, um die Höhe des Gadgets (z.B. auf der iGoogle-Startseite) automatisch dem Inhalt anzupassen. Genau dafür brauchten wir nämlich auch die erste RequireFeature-Zeile im Grundgerüst.

Schnell den onLoadHandler definiert (ebenfalls aus der gadgets-API): Hier wird gesagt, dass die Funktion “init” aufgerufen werden soll, sobald das Gadget geladen wird.

Fertig. Wenn das zu schnell ging, könnt ihr euch das gesamte Listing nochmal ansehen.

5. Und Serverseitig?

Diejenigen, die schonmal mit AJAX-Technologien gearbeitet haben wird es kaum wundern – meine apitest.php, die der Request in meinem Beispiel aufruft, macht nichts anderes, als irgendwelchen Content auszugeben (z.B. in PHP per ‘echo’). Das bedeutet – statt auf eine .php-Datei zu requesten, könnten wir auch jede beliebige HTML-Datei oder was auch immer anfragen. Cool, aye? Ein Beispiel dazu wäre:

<?php echo "Schau, der Server spricht mit mir!"; ?>

6. Außerdem beachten

Irgendwie wird anscheinend doch mehr gecached, als man denkt. Daher nicht verzweifeln, wenn die neueste Änderung immer noch nicht zum richtigen Ergebnis geführt hat, sondern ein Käffchen kochen und danach nochmal auf F5 drücken

In Teil 2 speichere ich Daten, die ein Benutzer in meinem Gadget eingeben kann, um einen einfachen Notizzettel zu basteln.

So. Mein ASROCK ION 330 ist ja seit nunmehr 4 Tagen da. Nachdem ich am Dienstagabend Debian Lenny draufgespielt habe, gab es nun heute endlich die Grafiktreiber für den ION-Chipsatz installiert. Damit ihr nicht ähnlich wie ich ahnungslos und ohne Ansatz dasteht, gibt’s hier die Schritte, die mich zum Erfolg geführt haben:

0. Vorneweg

Vorweg sei gesagt, dass ich die Infos hauptsächlich aus den folgenden Quellen habe:

1.) http://desiato.tinyplanet.ca/~lsorense/debian/debian-nvidia-dri-howto.html
2.) http://wiki.debian.org/NvidiaGraphicsDrivers
3.) http://www.debianhelp.co.uk/nvidia.htm

Im Folgenden gibt’s also nur eine zusammengewürfelte Anleitung, die bei mir zum Erfolg geführt hat.

Edit vom 08.08.2009: Außerdem hat mich der Systemadministrator meines Vertrauens darauf hingewiesen, dass die Benutzung von proprietären Treibern den Linux-Kernel beeinflussen kann (und in diesem Fall auch tut) und es somit zu späteren Zeitpunkten schwierig machen kann, dein System zu debuggen oder schlichtweg das Ding zu installieren. Unter (Quelle 2) ist beschrieben, wie man die Treiberinstallation rückgängig macht.

0,5. Achja: Das NVIDIA-Install-Tool

Solltet Ihr euch die Treiber von nvidia.com heruntergeladen haben, vergesst sie. Sie bestehen in einer Datei, dessen Name mit “NVIDIA” anfängt und mit “.run” aufhört. Diese Datei macht viel Müll und führt sowieso zu nix. Sollte das trotzdem schon irgendwas bei euch gemacht haben, seid so gut und entfernt es wie unter (Quelle 1) beschrieben.

1. Die aptitude-Quellserverliste anpassen

Normalerweise kennt das Debian Installationsprogramm “apt” (oder aptitude) nach einer Standard Lenny-Installation keine Quellen, die Unfreie Software halten (z.B. Closed-Source). Das müssen wir jetzt ändern.

1. Öffne die Datei /etc/apt/sources.list (als root, versteht sich)
2. Schau nach, ob du die Wörter “non-free” UND “contrib” in einer der zahlreichen Zeilen erhaschen kannst
3. Wenn Nicht: Füge folgende zwei Zeilen ein:

    deb  ftp://download.xs4all.nl/pub/mirror/debian/ stable main non-free contrib
    deb-src ftp://download.xs4all.nl/pub/mirror/debian/ stable main non-free contrib

   Speichere und schließe die Datei

4. Sag apt(-itude), dass es seine neuen Listen holen soll:

   # aptitude update
   

2. Die relevanten Dateien herunterladen

Der Nvidia-Treiber läuft nur mit einem 2.4 oder 2.6-Kernel. Mit

# uname -a

findest du heraus, ob du den auch hast.

Jetzt laden wir die Pakete, die wir so brauchen, herunter:

# aptitude install nvidia-kernel-common module-assistant

Da wir ja einen Debian-Kernel verwenden, brauchen wir nun noch folgenden Befehl: (Für Leute mit eigenen Kernels: Ihr habt doch eh mehr Ahnung als ich )

# m-a -i prepare

3. Das Kernelmodul kompilieren und installieren

Geht mit den folgenden zwei Befehlen:

# m-a a-i -i -t -f nvidia-kernel
# depmod -a

4. Die eigentliche Installation

Danach installieren wir noch ein paar benötigte Pakete:

# apt-get install nvidia-glx nvidia-glx-dev xserver-xorg

5. Den XServer konfigurieren

Da ich eine frische Installation von Debian Lenny hatte, war meine /etc/X11/xorg.conf noch leer. Daher konnte ich bedenkenlos die gleich folgenden Schritte ausführen. Sollte Eure xorg.conf nicht leer sein, schaut doch bitte hier.

Für alle anderen gibt’s was Einfacheres, was laut (Quelle2) aber aus irgendeinem Grund nicht empfohlen wird. Anyway, bei mir hat diese Methode wunderbar geklappt:

Dazu brauchen wir das nvidia xorg-configuration tool:

# aptitude install nvidia-xconfig
# nvidia-xconfig

Dieser Befehl wird eine grundlegende xorg.conf-Datei anlegen, die man anschließend bearbeiten kann – wenn man will.
Nachdem ich herausgefunden habe, dass in der neuen xorg.conf die Zeile

Driver "nvidia"

schon vorhanden ist, habe ich festgestellt, dass ich die xorg.conf nicht mehr bearbeiten will. Aber: Jeder, wie er mag.

6. Den XServer neu starten

Gut, gut. Nachdem wir soweit sind, müssen wir den XServer neu starten. Das habe ich gemacht mit:

# /etc/init.d/gdm stop

, gewartet, dann

# /etc/init.d/gdm start

Wenn alles getan hat, sollte beim Start des XServers ein NVidia-Logo erscheinen. Dann: Bier öffnen, freuen.

Wenn nicht, kommt ihr zurück auf die Konsole… Doof. Dann die xorg.conf manuell zurücksetzen (entweder wieder komplett leer machen, oder aber euer Backup zurückspielen). Woran lag’s? Keine Ahnung! Sorry.

Einen letzten Test, ob die Harwarebeschleunigung tut, machen wir wie folgt:

# glxinfo |grep rendering

Viel Erfolg!
Lasst mir gerne einen Kommentar da, ob’s geklappt hat.

Logo des neuen Microsoft-OS garNIX

Steve Ballmer, CEO bei Microsoft, stellte heute das neue Microsoft-Betriebssystem garNIX vor. Es basiert auf einem UNIX-Kernel und ist in weiten teilen Open-Source.

Screenshots gibt es nach einem Klick auf “continued”

Der Geschäftsführer von Microsoft, Steve Ballmer, stellte heute das neue Betriebssystem Microsoft garNIX vor. Es soll, im gegensatz zum ebenfalls kurz vor dem Release stehenden Windows 7, eine Zielgruppe ansprechen, die auf eine möglichst einfache Oberfläche angewiesen ist, wie z.B. Rentner und PC-Neulinge ohne Vorkenntnisse. Das System ist denkbar schlicht gehalten, soll aber im Funktionsumfang mit Microsofts Flop-OS Vista mithalten können. Ballmer verspricht 99,9%ige Stabilität. Selbst nach einem möglichen Absturz soll die Oberfläche ohne weiteres auf den Stand vor dem Problem zurückgesetzt werden. Neben dem Namen, dem Konzept und dem Logo des neuen Betriebssystems zeigte Ballmer der informationshungrigen Presseschar außerdem einige Screenshots, die die Simplizität des Systems unterstreichen:

Login-Bildschirm

Startmenü

Konfigurationsmenü und Dateiexplorer