Opensuse 11.2 Gnome Preview

Im November soll es endlich soweit sein. Opensuse 11.2 soll dann erscheinen und da es für mich dann soweit ist die alte 11.0 abzulösen, habe ich einmal in meiner Virtual Box getestet wie sich das so anfühlen wird.

Aufgeräumter ist es geworden und Eleganter. Das ist was zumindest nach der Installation aufffällt. Alles ist nun in einem einheitlichen mehr oder weniger eleganten schwarz-grünen Design gehalten. Gnome2.28 macht mir schon jetzt eine große Freude, da es übersichtlicher und noch nutzerfreundlicher geworden ist.

Während der Installation ist mir aufgefallen, dass man nun in Yast mit LVM eine vollverschlüsselte Festplatte anlegen kann. Das geht zwar bisher auch schon. Allerdings nur mit einem Workaround.

Standardmäßig bietet der Installer nun das ext4 Dateisystem an. Das ältere ext3 ist aber auch noch verfügbar.


Kleinere Fehler sind hier und da noch zu erkennen. So lässte sich der live-installer nicht dazu überreden zu starten. Dieser lässt sich nur durch die Eingabe von yast2 live-installer am Terminal starten. Ansonsten quitiert das grafische Tool auch nach der Installation den Dienst mit dem Fehler -S unbekannte Option und fällt zumindest in der Konsole wieder in das Ncurses-frontend zurück.
Ein weiterer nerviger hoffentlich Bug ist die ständige
Autentifiezierungfrage nach der Netzwerkkonfiguration und dem
automatsichen Update.
Die Softwareauswahl ist gelungen wenn natürlich wie immer wegen patentrechtlicher Probleme unvollständig was den Multimedia-Support angeht. Beagle ist standardmäßig deaktiviert. Hier haben die Nürnberger wohl mal auf die Nutzer gehört, die das ewige rumgekratze auf der Platte
nervig fanden. XChat und Pidgin halte ich allerdings für redundant.

Opensuse 11.2 sollte derzeit nicht für den Produktiven Gebrauch eingesetzt werden. Viele Packetdepots wie das Packman depot sind noch nicht vollständig und unterstützen die version 11.2 derzeit noch nicht.

Kreatives Chaos - gute Musik muss nichts kosten

Gute Dinge müssen nicht immer etwas kosten. Was wie ein alter Oma Spruch von Großmutter klingt, trifft auch für Musik zu. Creative Commons heißt die Lizens unter der die Künstler ihre Musik veröffentlichen, die vor allem eines wollen: Das man ihre Musik hört.
Frei Musik zum kostenlosen downlaod und hören, weiterverschenken oder als Mitbringsel für die nächste Party.

http://www.creative-chaos.org/
http://www.openmusiccontest.org/
http://phlow.net/
http://www.jamendo.com/de/

Viel Spaß beim Hören.

Ich habe TV geklotzt

Ich habe mal wieder in die große Propagandakiste geklotzt, die früher noch den Namen Fernsehen verdiente. Hachja früher *seufz* als man noch informiert und nicht für dumm verkauft wurde.
Das habe ich gesehen:

Ein Massenmord an unschuldigen Zivilisten in Afganistan wird Schulter zuckend mit den Worten "Wir drücken unser tiefsten bedauern aus" abgetan. Oma Käsekästchen denkt sich. naja wenn sie das bedauern, dann wird es schon in Ordnung gehen.

Wer wird Millionär 2.0. Aber wahrschinlich hierzulange eher bekannt unter 5 gegen Jauch. Oder sollte man es besser "Werd bloß kein Millionär" nennen. Ganz richtig. Geld gibts immer dann wenn der andere, nämlich Jauch die Antwort nicht kennt.

Die üblichen TV-Richter lassen wir mal und schicken sie gleich mit den Talkern und Angelika Kalwaas in die Ecke des schlechten Geschmacks. :)

Die beiden Bürgernahen Polizisten, Toto und Harry sind auch immer noch in. Weiß nicht, gabs die nicht sogar schon, als ich das letzte mal vor ein paar Jahren Fernsehen geschaut habe. Und nicht zuvergessen. Das übliche TV-Reportage-Gedöns über böse Buben und vermeintlich Krimennelle, damit Oma Käsekästchen sich denkt: "Herr Gott ist das alles Schlimm." Ja Schlimm ist groß geschrieben.

So jetzt ist die Kiste wieder aus und das ist auch gut so.

Git- Eine Kurze Übersicht zur lokalen Anwendung

Der Chaos Radio Express Podcast von Tim Pritlove hat mich dann doch mal dazu ermutigt Versionierung und Versionskontrolle durchzuführen und ein wenig mit Git herumzuspielen. Das Konzept überzeugt und ist so schwer auch nicht zu lernen wenn man mal die wesentlichen Gedanken verstanden hat.

Git Initialisieren

Ein Git-Repo ist Grunsätzlich nur ein Verzeichnis, welches mehrere Projektdateien (Texte und Binärdateien) und sogar weitere Unterverzeichnisse enthält und von Git überwacht wird.

Ein Verzeichnis als Git-Repo markieren:

:~> git init

Nun müssen Projektdateien bei Git registriert werden, damit Git Änderungen an diesen Dateien überwachen kann.

:~> git add [Projektverzeichnis/Projektdateien]

Anschlißend erstellt man sinniger Weise seinen ersten Commit, von diesem Ausgehend man weitere Commits erzeugt oder sogennante Branches des Hauptstamms Master erzeugt.

:~> git commit -m "initial commit on branch master"

Die bei Git registrierten Dateien haben einen genau dieser Zustände.

Committed: Veränderung wurde erfolgreich dem nächsten Commit hinzugefügt und gehört der nächsten Version an.

Staged: Das Veränderte Element ist für den nächsten Commit "markiert."

Modified: Eines der Elemente in dem Working Directory wurde geändert, aber noch nicht für den nächsten Commit markiert. Nicht markierte Verändeungen werden beim nächsten Commit nicht berücksichtigt.

Clean: Keines der Elemente wurde verändert.

Dabei ist das aktulle working Directory das Verzeichnis in dem Veränderungen gespeichert und Dateien hinzugefügt werden. Das Git Rerpo lagert die Metateien über die einzelenen Objekte in der Datenbank ab und erkennt die 4 Zustände.

Ein Vorhandenes Projekt Clonen

:~> git clone [Quelle] [Ziel]

Bei einem Clone wird das Komplette Repo der Quelladresse inkklusive aller Revisionen und Branches auf die Platte geholt. In diesem kann man nun Veränderung vornehmen, eigene neue Commits erstellen oder neu Branches anlegen und mergen.

Veränderungen anzeigen

:~> git log

Zeigt die History der einzelnen Commits an. Dabei steht der aktuellste Commit an oberster Stelle. Eine nützliche Option ist -p mit der mn sich die letzten veränderungen anschauen kann.

:~> git status

Gibt an welche Datei sich momentan in welchem Status begfindet. Und gibt an welche Dateien möglicherweise ins nächste Commit übernommen werden.

:~> git diff

Zeigt das Diff für geänderte Dateien an, die noch nicht gestaged sind. Mit der Option --staged kann man sich die Diffs für gestagete Dateien anzeigen lassen.

Staging Veränderte Dateien

:~> git add [Datei]

Fügt Element, wobei Element eine Datei oder ein ganzes Verzeichnis sein kann, zur Staging Area hinzu. Damit wird für den nächsten Commit markiert.

Sobald Dateien für den nächsten Commit gestaged sind kann man sie schließlich mittels

:~> git commit -m "bal bla"

ins nächste Commit überführen. Wobei natürlich "bla bla" eine sinnvolle Commitnachricht sein sollte.

Tagging

Sobald man ein neues Commit erstellt möchte man diesen vielleicht einen Namen Tag geben.

:~> git tag v0.1

erzeugt einen Tag mit dem Namen v0.1 auf dem aktuellen Commit. Es ist sinnvoll Tags zu verwenden. Um schnell und einfach bestimmte Veränderungen emittels

:~> git-show

sehen zu können Dabei ist es sinnvoll, gute Tags zu vergeben. Zum Beispiel git tag feature_xyz

Veränderungen Rückgängig machen

Wenn man sich mittels git status den aktuellen Zustand des aktuellen Commits anzeigen lässt, wird einem in der Regel auch mitgeteilt wie man verm,urkste Veränderungen wieder rückgängig machen kann.

• Gestagete Dateien als unstaged markieren: :~> git reset HEAD [Datei]
• Änderungen bei ungestagten Dateien rückgängig machen: :~> git checkout -- [Datei]

Push und Pull
Ist man der Meinung dass die Arbeit an dem Projekt soweit vorangeschritten ist, das man dieses nun mit dem ursprünglichen Repo wieder zusammenführen möchte kann man, sofern einem das Repo selber gehört und man die entsprechenden Rechte daran hat, es entweder von Origin nach Master pullen oder von Master nach Origin pushen.

:~> git pull Origin Master

:~> git push Origin Master

Branching und Merging

Der typische Workflow beim Branchen und Mergen im eigenen Repo sieht so aus. Man erstellt eienen neuen Branch.

:~> git branch fix-bug#1

und wechelt in diesen neuen Branch. (Checkout)

:~> git checkout fix-bug#1

Die Option -b des Subbefehls checkout ermöglicht es, diese beiden Schritte in einem Rutsch zu erledigen.

Macht ein paar Änderungen und macht in diesem Branch einen neuen Commit:

:~> git add [Datei/en]
:~> git commit -m "fixed bug #1"

Wichtig das Commit bezeiht sich nur auf den aktuellen Branch. In der Regel wird man nun tetsen ob man den Bug #1 wirklich repariert hat und das Programm bzw. das Projekt weiterhin wie bekannt stabil läuft. Ist alles OK wechselt man wieder in den Branch master

:~> git checkout master

und kann nun die Änderungen des Branch Branch fix-bug#1 mit dem Branch Master wiederzusammenführen (mergen)

:~> git merge fix-bug#1

und den Branch fix-bug#1 nun durch die Eingabe des Befehls

:~> git branch -d fix-bug#1

löschen.

Ins Detail:

http://progit.org/

git subbefehl --help

man git

man git-subbefehl


Dieser Artikel wird unter CC noncomercial Veröffentlicht

Exaile 0.3.0a3 holt mit großen Schritten auf

Vor einiger Zeit habe ich angefangen, mich für das Exaile Projekt zu interesseieren. Mit der 3. alpha von Exaile kommt das Projekt dem Komfort von Amarok 1.4.x erstaunlich nahe. 

Ins Auge fällt sofort die verbesserte Bedienbarkeit und die Intelligente Steuerung der Playlisten. Weiterhin sieht man nun im Panel ein Statussymbol, welches darüber informiert, ob der Player Pausiert- oder angehlaten wurde oder gerade abspielt.

Ähnlich wie bei Amarok kann man den Player mittels einfacher Module erweitern. Da er in Python entwickelt wurde, ist es auch vergeleichsweise einfacher seine eigenen Extensions zu schreiben.

Die Quellen könen von http://exaile.org/ heruntergeladen werden. Fertige Pakete für Opensuse 11.x findet man in meinem Repo: http://download.opensuse.org/repositories/home:/l1zard/