Nouveau, Nvidia und Natty

Nachdem mein System unter Maverick plötzlich der Überzeugung war, dass meine CPU nicht mehr als 800Mhz kann – ich leide mit allen die auf einem solchen System KDE betreiben wollen – und alle Lösungsansätze nichts brachten, war mein nächster Schritt eine Neuinstallation der Beta 2 von Natty. Da ich mein home auf einer separaten Partition habe, war dies kein größeres Problem. Nur die gängigen Programme nachinstallieren und fertig. Immer wieder ein schönes Gefühl ein neues System mit den alten Einstellungen willkommen zu heißen.

Was mich direkt beim Start wunderte war der hübsche Ladescreen von Kubuntu. Farbverläufe, vernünftig aussehender Text…fremde Welten ;) Nach dem Start von KDE waren die Desktopeffekte bereits verfügbar, da wurde ich dann wirklich stutzig. Hat da Kubuntu evtl. heimlich schon den Nvidia-Treiber (habe eine Geforce 8600M GT) installiert? Muon angeworfen und mal gesucht. Es wurde der Nouveau Treiber installiert.

Generell finde ich es eine phantastische Idee eine freien Treiber dafür zu haben. Vielleicht sind sie dort etwas schneller und kooperativer als bei Nvidia selbst. Aber zu dem Thema kaputte Treiber, Verhalten von Herstellern und wie Entwickler von Fenstermanagern dagegen arbeiten, empfehle ich den Blog von Martin.

Also habe ich Nouveau mal einem subjektiven Test unterzogen: Flashvideo laufen fein.  Desktopeffekte sind sehr schnell, aber leider werden keine unterstützt die auf Shadern basieren (der Würfel, Wunderlampe, Gleiten, …). Portal mit Wine spielen? Keine Chance, da auch hier Shader verwendet werden. Aber generell war ich von der Performance sehr begeistert. Ein anderes Teammitglied berichtet aber beim Zusammenspiel von Nouveau und einer Geforce Quadro FX 570M vom genauen Gegenteil: Video ist ruckelig, Flash ebenfalls. Ich vermute dass dies am jüngeren Alter der Karte liegt und der Treiber für diese Karten noch nicht optimiert ist.

Kudos an die Entwickler und ich wünsche ihnen den langen Atem um den Treiber peu a peu zu verbessern. Bisher rennt Natty ohne große Probleme, außer das PolicyKit kaputt zu sein scheint, aber hey: man kann Pakete auch über ‘ne Konsole installieren.

Und zu guter Letzt: meine CPU taktet wieder artig.

Kontact 2, Akonadi und wie Android dazu passt…

Zu aller erst: dieser Blogpost ist nicht auf meinen Mist gewachsen, sondern wurde maßgeblich von diesem inspiriert. Seht es einfach als leicht eingedeutschte Version mit einer persönlichen Meinung. ;)

Ich benutzt KDE 4.6 inklusive Kontact 2. Dies hat noch viele Probleme (von denen die Entwickler wissen), aber die Thematik die ich hier beschreibe, hatte ich auch schon vorher: Akonadi tut einfach nicht das was es soll. :) Eigentlich stellt Akonadi, vereinfacht gesprochen, eine Zwischenschicht zwischen Anwendung und Informations- bzw Nachrichtenquellen (Mail, Kontakte, Kalender, Groupware, Lesezeichen, …) da. Dadurch ist es für einen Entwickler einfacher solche Quellen in sein Programm zu integrieren. Solche Abstraktionsschichten sind in KDE mittlerweile sehr verbreitet: Solid (für Hardware) und Phonon (für Ton) sind zwei Beispiele dafür.

Akonadi bindet diese Quelle über so genannte „Agents“ ein. Man konfiguriert diesen Agent, gibt seine Benutzerdaten für externe Dienste ein, feuert das Ganze ab und Kontact zeigt artig die Daten an.

Akonadi Agents

Akonadi Agents

So weit die Theorie. Für Mail funktioniert dies auch einwandfrei und die IMAP Unterstützung ist mittlerweile echt prima und vor allem schnell geworden. Danke liebe KDE PIM Entwickler.

Ich besitze ein Android Smartphone und nutze die Google Dienste wie Mail, (vorher befragte) Kontakte und Kalender  (ich weiß was ich da tue, also bitte keine Standpredigten über Datenschutz etc pp :-) ). Für diesen Fall gibt es ebenfalls zwei Akonadi Agents. Der eine versorgt Kontact mit den Daten der Kontakte, der andere vermittelt die Kalender. Leider funktionieren beide nicht bei mir. Ob das an meiner Config liegt, oder aber generell kaputt ist, kann ich nicht sagen.  Bei den Kalender tritt dazu noch ein zweites Problem auf: der Kalender-Agent (basiert auf libgcal, eine Bibliothek für die Kommunikation zwischen System und Google) unterstützt nur einen Kalender bei Google. Dieses ist den Entwicklern von libgcal bekannt. Dadurch ist es für mich, selbst wenn es funktionierte, leider unbrauchbar.

Aber im oben genannten Blog gibt es einen alternativen Ansatz – der DAV-Groupware Agent. Alternativer Ansatz ist eine schöne Beschreibung für einen hässlichen Würgaround. Bevor ihr es probiert: es ist relativ aufwändig und benötigt etwas Zeit. Nicht das es hinterher heißt, ich hätte euch nicht gewarnt. ;-) Dieser sollte auch in Versionen < Kontact 2.0 funktionieren. Um ihn nutzen zu können, öffnet man Kontact, geht auf die Kalender Ansicht und klickt mit der rechten Maustaste in das kleine Feld unten links. Dort gibt es dann den Menüpunkt „Add Kalender“.

Hinzufügen eines neuen Kalenders

Hinzufügen eines neuen Kalenders

Danach öffnet sich ein neues Fenster, welches alle verfügbaren Agents für Kalenderdaten anzeigt. Verwendet man nicht Kontact 2, so wählt man in diesem Fenster „Akonadi Ressource“. Ansonsten wählt man dort den Punkt „DAV-Groupware-Ressource“. Danach erscheint das Konfigurationsfenster dafür. Da die dort genannten Punkte alle nicht passend sind, schließt man das Fenster über „cancel“. Danach erscheint ein weiteres Fenster in den man seine Konfiguration manuell eingeben kann.

Konfiguration DAV

Konfiguration DAV

Im oberste Feld kann man den Namen des Kalenders angeben und in dem zweiten den Wert in dem synchronisiert werden soll. Anschließend klickt man auf „add“. Ein weiteres Fenster erscheint (nur zu Beruhigung: diesen Vorgang macht man nur ein einziges Mal): Die oberen Optionen bleiben wie sie sind (also CalDAV), in dem Feld dort gibt man unter „Remote URL“ die Adresse an. Um diese zu bekommen öffnet man die Website des Google Kalenders und geht folgenden Weg:  „Einstellungen“  → „Kalender-Einstellungen“ → „Kalender“ Reiter und klickt dort nun den Kalender an den man in Kontact haben möchte. Dort scrollt man ganz nach unten, bis zu dem Punkt „Kalenderadresse“. In dieser Zeile gibt es die „Kalender-ID“.

die Kalender-ID

die Kalender-ID

Diese kopiert man und wechselt zurück zum Konfigurationsmenü des Agents. Der Aufbau der Remote-URL sieht dann so aus:

https://www.google.com/calendar/dav/die_vorher_kopierte_Kalender-ID/events

In dem Feld „Username“ trägt man den vollständigen Benutzernamen für die Google Dienste ein, also beispielsweise Max.Mustermann@gmail.com, und klickt danach auf das Feld „fetch”. Nun erscheint eine Abfrage der digitalen Brieftasche, ob Kontact bzw Akondi auf Google zugreifen darf. Dies bestätigt man mit „ja“ (im Idealfall dauerhaft, da ansonsten die Abfrage bei jedem Sync wieder erscheint) und bestätigt danach den ganzen Dialog mit OK. Dieses, zugegeben, aufwändige Procedere wiederholt man nun gegebenenfalls auch für die anderen Kalender. Sind alle Kalender in der Liste enthalten, klickt man auf OK. Et voila: der bzw die Kalender erscheinen in Kontact.

Kontact mit mehreren Kalendern

Kontact mit mehreren Kalendern

Beim Erstellen eines neuen Termins kann man so nun auch komfortabel den Kalender angeben in den dieser eingetragen werden soll. Außerdem werden die Daten, wie bereits eingangs erwähnt laufend abgeglichen, also hat man sowohl in Kontact als auch auf dem Smartphone den selben Datenbestand.

Ich hoffe das sich die Situation rund um Akonadi und Google noch verbessert (scheint ein Google Summer of Code Projekt dafür zu geben) und diesen Vorgang wesentlich vereinfacht. Ich will im Idealfall nur meine Benutzerdaten eingeben, auswählen welche Kalender benutzt werden sollen und das Ganze mit OK bestätigen. Und keine endlosen Klickorgien veranstalten. (die, die mehr als zwei Kalender haben werden hinterher wissen was ich meine) ;)

Edit: Yahoo Kalender funktionieren auch. Einfach dieser englischen Anleitung folgen.

KDE 4.6 wurde von Golem getestet

Mittlerweile sollten die meisten von euch mitbekommen haben, dass KDE 4.6 veröffentlicht wurde. Auch mein geliebtes News-Portal Golem hat davon Wind bekommen.

Golem bestimmt meiner Meinung nach nicht durch erstklassigen Journalismus bzw. gut recherchierten Artikeln, aber der Artikel über KDE konterkariert ihren Anspruch  „IT-News für Profis” liefern zu wollen auf komische Art und Weise. Hier ein paar Punkte aus dem Artikel:

“Im Vordergrund steht der Compositing Manager, der zwar inzwischen mit zahlreichen Effekten aufwartet, beim Bildaufbau aber bisweilen langsam wirkt und zumindest auf Rechnern mit schwacher CPU und Grafikkarte den Benutzer dazu zwingt, auf den Augenschmaus zu verzichten.“

KDE und besonders KWin sind mittlerweile nicht dafür gemacht auf jedem Wald-und-Wiesen-PC zu funktionieren. Dafür sind einfach zu viele Techniken implementiert die Leistung brauchen. Und auch auf einer alten Geforce 4200 funktioniert das System gut. Diese Karte ist ca 5 Jahre alt. Benutzer mit älteren Rechnern würde ich zu LXDE raten. Ich weiß nicht mit welcher Hardware dort getestet wurde. Wäre schön gewesen wenn der Autor seine Konfiguration genannt hätte.

„Der Dateimanager Dolphin wurde mit einer lang ersehnten Funktion ausgestattet: der Spaltenansicht, die den Inhalt mehrerer Ordner einer Verzeichnishierarchie anzeigt.“

Diese Funktion ist dem Autor wohl seit der Version 4.0, mit der sie das erste Mal Einzug in KDE hielt, entgangen. :) Die Spalten wurden in 4.6 überarbeitet, aber die Funktion gibt es nun seit ca 3 Jahren.

„Dateien können von Dolphin auch ohne laufenden Nepomuk-Server inhaltlich durchsucht werden. Allerdings muss Nepomuk zuvor die Daten indiziert haben.“

Auch das ist leider falsch. Wird ein Begriff in die Suchleiste eingegeben, so erkennt das System ob der Ordner von Nepomuk indexiert wurde, oder nicht. Wurde er es, wird über Nepomuk gesucht. Wurde er es nicht, so wird „wie früher“ mittels KFind bzw richtiger kio_filenamesearch gesucht. Befindet man sich in einem solche nicht indexierten Ordner, so sind auch die Filter in der Seitenleiste nicht verfügbar.

 

Edit: Ich weiß nicht ob es an der Mail an die Golem Redaktion liegt, aber ist auch egal. Der Teil mit der Spaltenansicht in Dolphin wurde überarbeitet und korrigiert. Prima. :)

Nepomuk in KDE 4.6

Vor einigen Wochen habe ich in diesem Blogpost über die Funktionalität von Nepomuk berichtet und wie man es in der Praxis benutzt. Nun steht KDE 4.6 vor der Tür, das laut offiziellem Release Schedule am 26. Januar erscheinen soll. Pakete für Kubuntu folgen dann wie immer einige Tage später. Einige interessante Neuerungen werden im Feature Plan so beschrieben und ich versuche sie euch zu erklären:

Faceted browsing via Nepomuk:

Dies ist eine der von mir am meisten erwarteten Neuerungen. So sah die Oberfläche Dolphins für Nepomuk in 4.5 aus:

Suchergebnisse mit passenden Tags und Bewertung

Sie funktionierte zwar, aber war für mich irgendwie nicht intuitiv. Daran wurde nun gearbeitet und sieht folgendermaßen aus:

Die Aufteilung der verschiedenen Bereiche sind von mir vorgenommen wurde und sehen standardmäßig nicht so aus. Was auffällt ist die Leiste auf der rechten Seite. Mit dieser ist es in KDE 4.6 möglich nach bestimmten Schlagworten, Bewertungen etc zu suchen. Einfach ein Klick auf das Kästchen und schon erscheinen alle passenden Ergebnisse.

Über den eigentlichen Dateien gibt es die bekannte Suchleiste in der frei nach Text in den Dateien suchen lassen kann. Hier kann unterschieden werden ob nach Dateiname oder dem Inhalt einer Datei gesucht werden soll.

Aber das schönste von allem? Genau, die Suchergebnisse werden als Vorschau angezeigt. Ich bin begeistert. ;) Ein Feature das für mich eigentlich grundlegend ist, aber nun ja: gut Ding braucht Weile. Möchte man dieses Suchergebnis wieder als “virtuellen” Ordner speichern, so klingt man in einen freien Bereich in den Ergebnissen und wählt aus dem Kontextmenü den Eintrag “zu Orte hinzufügen”. Fertig. Mittels dieser Änderungen lässt sich wesentlich schneller durch die Datenbestände navigieren.

Searching support for non-indexed files:

Bisher war es so, das Strigi alle Dateien einmalig indexieren musste, damit Nepomuk sie später finden kann. Dies ist nun nicht mehr so. Nepomuk findet nun auch Dateien die nicht indexiert wurden. Dies dauert zwar länger als eine Suche im Index, liegt aber in der Natur der Sache. Der Zugriff auf “KFind” über das Menü in Dolphin ist nun nicht mehr vorgesehen, sondern alleine die Suche via Nepomuk. Sollte kein Eintrag “Suche” in der Werkzeugleiste von Dolphin zu finden sein, so muss man diesen manuell hinzufügen. Generell ist die Erfassung von Dateien durch Strigi wesentlich schneller geworden. Es dauert nur wenige Sekunden bis es eine Veränderungen an einer/mehreren Dateien ‘bemerkt’, diese neu indexiert und sie Nepomuk bereitstehen.

Provide Backup and Sync capabilities to Nepomuk:

Nichts ist ärgerlicher als geliebte bzw. wichtige Daten zu verlieren. Bisher war es nur umständlich möglich die Indexdatenbank von Nepomuk zu sichern. Wir erinnern uns: in dieser sind alle Schlagworte, Bewertungen, Kommentare, … gespeichert. Hat man seinen Datenbestand nun ausreichend getaggt, aber verliert diese Daten, wäre es eine mittlere Katastrophe diese wieder herzustellen. Genau deshalb wurde nun eine Backupfunktion in Nepomuk eingebaut:

Hier kann eine automatisierte Sicherung der Daten festgelegt werden. Tägliche, wöchentliche und monatliche Sicherungen können hier ausgewählt werden. Oder die Funktion komplett deaktivieren. Des Weiteren legt man die gewünschte Uhrzeit, den gewünschten Wochentag und wie viele Backups angelegt werden sollen,  hier fest. Man kann auch eine manuelle Sicherung vornehmen und das Backup zurückspielen.

Mir gefallen die vorgenommen Änderungen sehr und machen das Arbeiten mit “Nepi” wesentlich einfacher/komfortabler und bringen es eine Stufe weiter. Leute die es nicht mögen (Systemlast, weitere DB im System, kein persönlicher Nutzen, etc pp) haben wie immer die Möglichkeit es komplett auszuschalten und nicht zu nutzen. Niemand wird gezwungen, KFind funktioniert wie bisher.

Als nächster Schritt steht die Veröffentlichung von digiKam 2.0 im Januar an. Neben vielen Verbesserungen kommt eine Funktion ins Haus, die es noch einfacher macht. Es unterstützt Gesichtserkennung und soll in etwa so gut funktionieren wie Google Picasa. Mit dem riesigen Unterschied, das keine der Daten ins Internet gelangen. Würde ich dann auch nicht nutzen wollen, weil meine Daten auf meinem Rechner besser aufgehoben sind. Erkannte Gesichter können dann einem Namen zugeordnet werden und erscheinen dann als Schlagwort in Nepomuk. Ich bin gespannt wie gut das in der Praxis funktionieren wird.

Gtk unter KDE aufhübschen mittels oxygen-gtk

Eigentlich benutze ich schon immer QtCurve um GTK-Anwendungen unter KDE zeichnen zu lassen. Das funktioniert zwar, aber sieht nicht so toll aus und integriert sich optisch fast gar nicht.

Das fand wohl auch das Team rund um Oxygen (KDE Entwicklungsteam für Icons, Themes, Farben, …) und haben selbst eine Gtk-Engine namens oxygen-gtk geschrieben.

Man achte auf die unterschiedlichen Widgets, also Bildlaufleisten, Dropdown-Menüs usw. Das sieht schon viel eher nach einer vernünftigen Integration aus. :)

Um es benutzen zu können muss als erstes der Quellcode aus dem git heruntergeladen werden. Hier findet man es. Entweder macht man es manuell über den Button “download master as tar.gz”, oder man klont das Repository.

Anschließend entpacken und dem INSTALL File in dem Ordner folgen. Sollte es sich beim kompilieren beschweren, das GTK nicht gefunden wird, so hilft es das Paket libgtk2.0-dev zu installieren.

Ist es nun installiert kann man es in den “Systemeinstellungen -> Erscheinungsbild von Anwendungen -> GTK+–Erscheinungsbild” auswählen.

Openstreetmap und Microsoft

Openstreetmap ist eine Community die Geodaten sammelt. Diese können frei und kostenlos genutzt werden. Die bekannteste Verwendung ist die Erzeugung von Karten aus diesen Daten.

 

Ich bin ein großer Fan von Openstreetmap. Als ich vor ca. 3 Jahre zum ersten Mal von diesem Projekt hörte dachte ich nur: “Ja klar, wir latschen alle Straßen dieser Welt ab und erzeugen eine große Karte. Netter Plan, aber vielleicht etwas weit gegriffen”. Nun gut, ich habe mich definitiv getäuscht, mappe mittlerweile selbst und freue mich dass das Projekt immer weiter wächst. Die Karten sind in vielen Gebieten denen von Google Maps überlegen. Außerdem gibt es Spezialkarten für Radfahrer, Wanderer, Rollstuhlfahrer, usw.  Diese Zielgruppen kann Google nicht bedienen, da ihr Kartenbestand dies nicht abdeckt.

 

Als ich heute nun las, dass Microsoft OSM helfen möchte war ich eigentlich sehr begeistert (und das im Zusammenhang mit MS…wie die Zeiten sich ändern). Microsoft setzt schon seit einigen Wochen OSM als zusätzlichen Layer in Bing ein. Warum sie das tun ist relativ einfach: sie bekommen gutes Kartenmaterial gratis. Und ihr Engagement zielt darauf ab es noch besser werden zu lassen. Damit haben sie einen Wettbewerbsvorteil gegenüber Google und das mit verhältnismäßig geringem Aufwand. Evtl. ist es nur eine PR Nummer von ihnen. Wir werden sehen.

 

OSM benötigt drei Dinge dringend:

 

1. mehr Rechenleistung:

 

Das Rendern der Karten aus den Geodaten ist sehr rechenintensiv. Auch die Darstellung der Karte im Browser hängt des öfteren, weil die einzelnen Bildkacheln geladen werden müssen. Microsoft könnte zusätzliche Server zu Verfügung stellen.

 

2. Höheren Bekanntheitsgrad

 

Wikipedia ist quasi der Inbegriff der kollaborierten Zusammenarbeit. Und umso mehr Menschen das Projekt kennen, umso mehr potentielle Mitarbeiter ergeben sich. Auch das führt wieder zu einer besseren Datenbasis und besseren Karten. Außerdem wäre es schön, wenn neben der Adresse eines Arztes nicht nur der Link zu Google Maps, sondern auch zu OSM bzw Bing zu sehen wäre.

 

3. Einfacherer Zugang

 

Es gibt viele Ansätze das Hinzufügen von Geoinformationen und das Zeichnen der Karten zu vereinfachen. Dies ist schon deutlich einfacher geworden als früher, muss aber noch weiter geführt werden um möglichst vielen Menschen den Zugang zu ermöglichen. Microsoft möchte dieses durch neue Werkzeuge bieten. Auch hier wieder ein Gewinn für OSM.

 

Hoffen wir das Beste und happy mapping. :)

Geplante Downtime von ubuntuusers.de ab 21 Uhr

Kopie aus dem Ikhaya:

Da trotz der vielen Verbesserungen in den letzten Tagen weiterhin Probleme mit der Anbindung von Inyoka an die Webserver bestehen, werden heute Abend einige Konfigurationen umgestellt.

Speziell geht es um einen Umstieg von mod fcgi {en} auf mod wsgi {en} . Dies bedeutet einen Wechsel auf ein komplett anderes Modell der Anbindung von Inyoka an den Webserver. Dank „mod_wsgi“ stehen dem Webteam danach viele neue Funktionen zu Verfügung, die zur Prozessteuerung eingesetzt werden können.

Weiterhin werden die MySQL-Server von einem Logical Volume (LVM) auf ein anderes verschoben, damit in Zukunft mehr Speicherplatz für anfallende Daten verfügbar ist.

Eine statische Version des Wikis ist unter www.ubuntuwiki.de zu erreichen.

Aufgrund der größeren Umstellungen rechnet das Webteam daher mit einer Downtime von rund zwei Stunden. Dabei kann es durch eventuell auftretende Probleme zu weiteren Verzögerungen kommen und sich dadurch die Ausfallzeit verlängern. Die Arbeiten beginnen um 21 Uhr.

Das Webteam wünscht den Benutzern von ubuntuusers.de daher eine gute Nacht. Genießt das Fernsehprogramm, kuschelt mit der Freundin bzw dem Freund oder tut was ihr möchtet. Vielen Dank für eure Geduld. Wir sind bald wieder da.