ubuntuusers.de

Dieser Artikel basiert auf der offiziellen ownCloud Dokumentation¹ und beschreibt die Einrichtung eines Thunderbird-Adressbuchs zur Synchronisation mit den ownCloud-Kontakten.

Menü zum CardDAV-Link

Neben dem Thunderbird-Mailclient wird die Erweiterung Lightning² benötigt. Wie man diese Erweiterung nutzt, um z.B. den ownCloud-Kalender mit Thunderbird zu synchronisieren, habe ich bereits an dieser Stelle beschrieben.

Um neben dem Kalender auch die Kontakte synchronisieren zu können, wird darüber hinaus der Sogo Connector³ benötigt. Am einfachsten installiert man diese Erweiterung, indem man einen Rechtsklick auf die Erweiterung ausführt und „Ziel speichern unter..“ aus dem Kontextmenü auswählt. In Thunderbird richtet man diese Erweiterung ein, indem man im Add-on Menü die Option „Add-on aus Datei installieren…“ auswählt.

Sind die beiden Erweiterungen erfolgreich installiert, kann das Adressbuch eingerichtet werden. Dazu öffnet man das Thunderbird-Adressbuch aus der Symbolleiste. Im sich öffnenden Fenster wählt man Datei->Neu->Remote-Adressbuch.

Der Verbindungsname kann frei gewählt werden. Bei URL wird der CardDAV-Link eingetragen, den man in den Einstellungen der ownCloud-Kontakte findet. Die Einstellungen verbergen sich hinter dem kleinen Zahnradsymbol.

Remote-Adressbuch-Einstellungen

Die weiteren Optionen können nach den persönlichen Vorlieben gewählt werden. Einzig den Haken bei „Nur lesbar“ sollte man nicht setzen, wenn man über Thunderbird auch neue Kontakte in der ownCloud anlegen möchte.

Fertig. Damit sind die ownCloud-Kontakte in den Mailclient integriert und lassen sich z.B. für die Autovervollständigung der E-Mail-Adressen in neuen Nachrichten nutzen.

Wenn Sie regelmäßig yum update ausführen, ist aus Ihrer CentOS-7-Installation schon seit geraumer Zeit CentOS 7.1 geworden. Nicht so fleißige Administratoren haben aber Pech: Wenn Sie einige Wochen lang kein Update durchgeführt haben, dann scheitert der Update-Versuch jetzt.

Der Grund: Eine Woche nach dem Update von CentOS 7 auf 7.1 wurden die Mirror-Verzeichnisse umgestellt, von 7.0.1406 auf 7.1.1503. Standardmäßig ist deltarpm aktiv, d.h. die Paketverwaltung versucht, nur Delta-Pakete herunterzuladen. Und das scheitert wegen der Versionsumstellung. Sie erhalten lauter HTTP Not Found Fehlermeldungen.

Abhilfe: Laden Sie die Datei /etc/yum.conf in einen Editor und fügen Sie die Zeile deltarpm=0 ein. Anschließend führt yum update zum Erfolg.

Einige steigen mithilfe des Raspberry Pi in die wunderbare Welt von Linux ein. Manche möchten auch komplett auf Linux umsteigen. In diesem Teil geht es um die Wahl der Distribution. Hier stelle ich euch einige vor.

Es gibt derzeit ungefähr 350 Linux-Distributionen, die meisten davon basieren auf Debian.

Ubuntu 14.04 LTS  „Trusty Tahr” & Ubuntu 15.04 „Vivid Vervet”

Ubuntu ist eine der bekannteste Linux-Distributionen welche auf Debian basiert und wird vorallem von Ein- und Umsteigern eingesetzt. Ubuntu 14.04 LTS „Trusty Tahr” ist eine Ubuntu-Version mit Langzeitunterstützung (eng. Long-Term Support, LTS) welche 5 Jahre (bis April 2019) lang Updates erhält. Andere Ubuntu-Version (z.B. Ubuntu 15.04) erhalten nur 9 Monate Updates. Für Ubuntu ist halbwegs aktuelle Hardware mit mindestens 2 GB RAM und einen Dualcore-Prozessor nötig.

Ubuntu 14.04 „Trusty Tahr”

Download Ubuntu

Lubuntu 14.04 LTS  „Trusty Tahr” & Lubuntu 15.04 „Vivid Vervet”

Lubuntu ist ein offizielles Ubuntu-Derivat mit dem sparsamen LXDE Desktop. Es ist sehr gut für alte Rechner mit wenig RAM (256 MB). Lubuntu 14.04 LTS erhält wie Ubuntu Updates bis April 2019. Unter Lubuntu finden sich schnell ehemalige Windows-Nutzer zurecht.

Lubuntu

Download Lubuntu

Xubuntu 14.04 LTS „Trusty Tahr” & Xubuntu 15.04 „Vivid Vervet”

Xubuntu ist ein weiteres offizielles Ubuntu Derivat. Es kommt mit der Desktopumgebung XFCE welche ebenfalls für ältere Rechner geeignet ist. Xubuntu benötigt mindestens 512 MB RAM. Es gilt als sehr anpassungsfähig.

Xubuntu

Download Xubuntu

Linux Mint 17.1 „Rebecca”

Linux Mint 17.1 basiert auf Ubuntu 14.04 LTS. Es ist seit einigen Jahren die beliebteste Linux Distribution. Dies liegt unter anderem daran das Linux Mint sehr viele Codecs mitbringt. Auch die mitgelieferte Software kann sich sehen lassen. Linux Mint erscheint seit Version 17 nur noch alle 2 Jahre und nutzt somit immer die aktuelle LTS Version von Ubuntu. Als Desktopumgebung kommt die Eigenentwicklung Cinnamon zum Einsatz. Für Linux Mint ist ebenfalls wie bei Ubuntu aktuellere Hardware und 2 GB RAM nötig.

Linux Mint 17.1 „Rebecca” Cinnamon

Download Linux Mint

Linux Mint Debian Edition

Linux Mint Debian Edition ist von der Ausstattung her gleich wie Linux Mint nur der Unterbau ist, wie es der Name auch schon verrät, Debian. Die aktuelle Version „Betsy” basiert auf Debian 8.0 „Jessie”. Linux Mint Debian Edition benötigt mindestens 1 GB RAM.

Linux Mint Debian Edition

Download Linux Mint Debian Edition

Ubuntu MATE

Ubuntu MATE ist ein weiteres Ubuntu-Derivat welches mit der MATE Desktopumgebung kommt. Es ist für ältere und neuere Hardware gut geeignet. 1 GB RAM und ein Dualcore-Prozessor sind von Vorteil.

Ubuntu MATE

Download Ubuntu MATE

Knoppix 7.4.2

Knoppix ist eine Linux-Distribution aus Deutschland deren Hauptanwendungsbereich im Live-Betrieb liegt. Es wird von Klaus Knopper entwickelt und gepflegt. Mit Knoppix kann man Linux vorab austesten ohne das etwas am vorhandenen System geändert wird. Knoppix versteht sich sehr gut mit alter Hardware. Es benutzt als Desktopumgebung LXDE. Der Unterbau ist ist eine Mischung aus Debian Testing und Stable.

Knoppix 7.4

Download Knoppix

Debian 8 LXDE

Debian ist die Mutter vieler Linux-Distributionen unter anderem auch Ubuntu, Raspbian & Bananian. Es bietet eine stabile Softwarebasis und ist deshalb sehr oft auf Servern anzutreffen. Debian 8 LXDE benötigt ebenfalls 256 MB RAM.

Debian 6 LXDE

Download Debian

Manjaro Linux XFCE

Manjaro basiert auf Arch Linux welches eigentlich nur für Profis geeignet. Es ist aber auch für Einsteiger geeignet da es einen eigenen Installer und ein Software-Center mitbringt. Beides gibt es unter Arch Linux nicht. Manjaro Linux gibt es mit den Desktopumgebungen KDE oder XFCE. Wie unter Arch Linux gibt es „Rolling Releases„.

Manjaro Linux XFCE

Download Manjaro Linux

Fazit:

Hier hab ihr nun einen kleinen Überblick zu einigen Linux-Distributionen bekommen. Es ist euch selbst überlassen ob ihr auf Linux umsteigt und welche Distribution ihr verwendet. Ich empfehle aber Distributionen mit LTS.

Im letzten Teil ging es um das Rebasen und das Einrichten und Nutzen von Remote-Repositorys. In diesem Teil wird es rein um GitHub und dessen Workflow gehen. Darunter fällt unter anderem das Erstellen eines Repositorys und wie man sich an Open-Source-Projekten auf GitHub beteiligen kann.

Dieses Tutorium besteht aus vier Teilen. Wem das Tutorium gefällt und mehr über Git lernen möchte, der kann sich das Buch „Versionsverwaltung mit Git“ für 29,99€ bestellen. In diesem Buch, was ich geschrieben habe, werden die Themen rund um Git noch deutlich ausführlicher behandelt.

Was ist GitHub?

Im dritten Teil dieses Tutoriums wurde zwar erläutert wie man mit Remote-Repositorys arbeitet, allerdings fehlte bislang eine sinnvolle Möglichkeit um Repositorys auf entfernt liegenden Servern zu lagern, die man über das öffentliche Internet erreichen kann. Eines der Dienste um dies zu erledigen ist GitHub.

GitHub besitzt sehr viele Funktionen die sich um das kollaborative Arbeiten an Projekten mit Git drehen. Darüber hinaus besitzt GitHub zwar noch einige weitere Dienste, dieser Teil des Tutorium dreht sich allerdings mehr um die grundsätzlichen Funktionen, die Git betreffen.

Hinweis: Da GitHub stetig weiterentwickelt wird, ändert sich auch die Web-Oberfläche. Die in diesem Artikel enthaltenen Screenshots könnten bereits nach wenigen Monaten veraltet sein.

Repository anlegen

Bei GitHub können Git-Repositorys angelegt werden. Bevor man sein erstes Repository anlegen kann, muss man sich zunächst registrieren. Der Funktionsumfang mit einem Standardkonto ist auf öffentliche Git-Repositorys beschränkt, das heißt vor allem, dass alle Dateien aus den Repositorys öffentlich und somit für jeden lesbar sind. Gegen Bezahlung kann man auch private Repositorys anlegen.

Nach der Registrierung und dem Einloggen findet man in der oberen Leiste in GitHub diverse Bedienelemente, darunter auch ein Knopf um ein neues Repository bzw. eine neue Organisation anzulegen. Eine Organisation ist an dieser Stelle noch nicht so wichtig, kurz gesagt, kann man Organisationen anlegen, damit eine Gruppe an Entwicklern sich die Rechte an Repositorys teilen können. Wenn man hingegen einen Account als normalen Nutzer besitzt, sind die Rechte standardmäßig auf die eigenen Repositorys für sich alleine beschränkt.

Wenn man nun ein Repository anlegen möchte, muss man dem Repository zunächst einen Namen vergeben. Optional ist hingegen eine kurze Beschreibung. Als zusätzliche Möglichkeit, kann man dem Repository direkt eine README-Datei hinzufügen lassen, ebenso wie eine “.gitignore”-Datei sowie eine Datei mit den Lizenz-Bestimmungen des Projektes im Repository.

Die “README”-Datei ist dafür da, um Informationen über das Projekt bzw. das Repository auf der Startseite des Repositorys darzustellen. GitHub stellt dies automatisch dar.

In diesem Tutorium wurde bislang noch nicht die Datei “.gitignore” behandelt. Innerhalb jedem Repositorys kann eine solche Datei anlegt werden. Alles was man dort einträgt, wird von Git schlicht ignoriert und somit nicht weiter beobachtet. Wenn man etwa an LaTeX-Dokumenten arbeitet, hat man bei jedem Kompilieren der TeX-Datei einige Dateien, die nicht direkt für das Projekt selbst relevant sind und somit auch eine Versionierung nicht notwendig ist. Diese Dateien kann man in der Datei “.gitignore” eintragen und Git zeigt diese Dateien in keinen der Befehle an. GitHub macht das Anlegen der Datei noch ein wenig komfortabler, da es sehr viele vordefinierte gitignore-Dateien anbietet, etwa für Java-, Android- oder TeX-Projekte.

Weiterhin kann man beim Anlegen eines Repositorys über GitHub eine Lizenz-Datei anlegen lassen. Dies ist wichtig, damit auch andere Leute von dem Inhalt des Repositorys profitieren können.

Wenn man nun einen Namen, eine Beschreibung sowie eine Lizenz-Datei ausgewählt hat und anschließend das Repository erzeugt, dann besitzt das Repository zu Beginn genau einem Commit mit der Commit-Message „Initial Commit“.

SSH-Key anlegen und hinzufügen

Bevor man das neu angelegte Repository klonen kann, muss man dem GitHub-Account noch einen SSH-Key hinzufügen. Sofern man auf dem lokalen Rechner noch kein SSH-Key erzeugt hat, muss zunächst ein Key anlegt werden.

Falls man nicht weiß, ob man schon mindestens einen SSH-Key besitzt, kann man den Inhalt vom Ordner “~/.ssh” überprüfen. Ein SSH-Key setzt sich aus zwei Dateien zusammen. Dies ist zum einen der private und zum anderen der öffentliche Schlüssel. Beispielsweise ist die Datei “id_rsa” der private Schlüssel, während “id_rsa.pub” öffentlicher Schlüsselteil ist.

Sofern man noch keinen SSH-Key angelegt hat, kann man das mit dem folgenden Befehl erledigen:

$ ssh-keygen -t rsa -C "mail@svij.org"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sujee/.ssh/id_rsa): /home/sujee/.ssh/id_github
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sujee/.ssh/id_github.
Your public key has been saved in /home/sujee/.ssh/id_github.pub.
The key fingerprint is:
SHA256:LFM8YkUe+ACh4+mH0GXZ4xAlWXT3zpHDEKdg/r9jBHI mail@svij.org
The key's randomart image is:
+---[RSA 2048]----+
|    =B+oB +..    |
|   ..=oB + * .   |
|  o = =o. . *    |
| o = + =ooEo o   |
|. +   + So..o    |
| o .   o   ..    |
|  o .      ..    |
|   .        o.   |
|           ...   |
+----[SHA256]-----+

Beim Ausführen des gelisteten Befehls werden interaktiv einige Fragen gestellt, die beantwortet werden sollten. Darunter den exakten Speicherort des Schlüssels, sowie ein Passwort. Man kann zwar auch einen Schlüssel ohne Passwort generieren, dies ist allerdings nicht empfehlenswert, da man sonst vollständigen Zugriff auf die Repositorys erhält, falls der private Schlüssel in falsche Hände gerät.

Nachdem nun das Schlüsselpaar generiert worden ist, muss nun der öffentliche Schlüssel in GitHub eintragen werden. Der öffentliche Schlüssel liegt in diesem Beispiel in “~/.ssh/id_github.pub”. In den GitHub-SSH-Einstellungen muss dann der Inhalt dieser Datei eingefügt werden.

Repository klonen

An dieser Stelle kann man das Repository erstmals klonen. Dazu braucht man die URL, um es über SSH zu klonen. Dies findet man entweder auf der GitHub-Repository-Seite oder man setzt es sich selbst zusammen, da es immer dem gleichen Schema folgt. In meinem Beispiel heißt das Repository „drunken-nemesis“ im Nutzer-Konto „svijee“. Das Repository findet sich daher unter https://github.com/svijee/drunken-nemesis. Unter der rechten Seitenleiste auf GitHub findet sich die URL zum Klonen via SSH, HTTPS oder Subversion. Relevant ist in der Regel nur das Klonen via SSH.

$ git clone git@github.com:svijee/drunken-nemesis.git
Klone nach 'drunken-nemesis'...
Enter passphrase for key '/home/sujee/.ssh/id_github': 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Empfange Objekte: 100% (3/3), Fertig.
Prüfe Konnektivität... Fertig.

Wenn man das Repository direkt klont, konfiguriert Git automatisch das geklonte Repository als das „origin“ Remote-Repository. Dies kann man nachvollziehen, wenn man in das Verzeichnis wechselt und dort die Remote-Repositorys auflistet.

$ cd drunken-nemesis
$ git remote -v
origin  git@github.com:svijee/drunken-nemesis.git (fetch)
origin  git@github.com:svijee/drunken-nemesis.git (push)

Anschließend kann man alle gewünschten Funktionen von Git nutzen, wie das Erstellen von Branches und Commits. Diese können dann anschließend gepusht werden, um die Änderungen über GitHub zur Verfügung zustellen. Die Änderungen lassen sich auch auf der Webseite von GitHub selbst ansehen, sodass man Repositorys nicht zwangsläufig klonen muss. Unter github.com/svijee/drunken-nemesis/commits/master finden sich etwa alle Commits die auf dem Branch “master” getätigt wurden. Ebenfalls kann man dort zwischen den Branches wechseln.

GitHub-Workflow

Das Besondere an GitHub ist, dass es nicht nur eine einfache Möglichkeit bietet eigene Git-Repositorys zu hosten, sondern auch, dass man mit wenigen Schritten Änderungen an Repositorys von anderen Personen oder Organisationen vorschlagen kann, die dann übernommen werden können.

Jedes GitHub-Repository lässt sich im Browser forken. Bei einem Fork spricht man von einer Abspaltung. Hin und wieder hört man bei größeren Open-Source-Projekten, das ein Fork entstanden ist. So ist die Büro-Suite LibreOffice ein Fork von OpenOffice.org, wo allerdings nicht die Änderungen zu OpenOffice.org zurückgeflossen sind. Bei GitHub hat ein Fork in der Regel eine etwas andere Bedeutung. In der Regel liegen die Zugriffsberechtigungen an einem Repository allein bei dem Besitzer des Repositorys. Über GitHub kann man nun Änderungen an einem Repository vorschlagen, dazu muss man den Fork-Button im Browser drücken. Dann wird eine Kopie (der Fork) des Repositorys erzeugt und im eigenen Account abgelegt. Dort besitzt man anschließend alle nötigen Schreibrechte. Wenn man also an dem Repository svijee/drunken-nemesis Änderungen vorschlagen möchte, erstellt GitHub nach dem Drücken des Fork-Buttons eine Kopie des Repositorys unter $DEINNAME/drunken-nemesis. GitHub zeigt selbst direkt auch an, dass es sich um einen Fork des Haupt-Repositorys handelt.

An dem Fork kann man nun wie gewünscht auf einem Branch die gewünschten Änderungen in Form von Commits durchführen. In der Regel bietet es sich an, dafür einen extra Branch anzulegen in dem man die Commits hinzufügt. Fehlen darf dafür natürlich kein Beispiel:

$ git clone git@github.com:$DEINUSERNAME/drunken-nemesis.git
$ cd drunken-nemesis

Anschließend kann man etwa eine Datei namens “README” mit beliebigen Inhalt hinzufügen, die anschließend commited werden kann.

$ git add README
$ git commit -m "README Datei hinzugefügt."

Zur Wiederholung: Wichtig ist an diesem Punkt, dass man nicht vergisst das Repository zu GitHub zu pushen. Da Git bekanntlich ein verteiltes Versionsverwaltungssystem ist, sind die Änderungen bis zu diesem Punkt nur lokal verfügbar. Daher muss man noch “git push” ausführen, um die Änderungen zu dem Remote-Repository auf GitHub zu übertragen.

Anschließend kann man über GitHub den sogenannten Pull-Request erstellen, in dem man die Änderungen die man gemacht hat, dem Haupt-Repository zur Übernahme vorschlägt. Bei jedem Repository, wo die Pull-Request-Funktion nicht abgeschaltet wurde, findet sich auf der Repository-Seite der Menüpunkt „Pull Requests“ auf der sich vorhandene, offene Pull-Requests befinden und auch neue angelegt werden können. Beim Anlegen müssen dann beide Branches, jeweils aus dem Quell- und Ziel-Repository, ausgewählt werden, die zunächst verglichen werden können. Sofern alle benötigten Änderungen in dem Pull-Request enthalten sind, kann der Request angelegt werden. Die Mitarbeiter an dem Haupt-Repository, an dem der Pull-Request gestellt wurde, können diesen Kommentieren oder direkt annehmen.

Arbeiten mit zwei Remote-Repositorys

Wenn man regelmäßig an einem Projekt über GitHub beiträgt, bietet sich eine lokale Konfiguration an, die das Arbeiten mit zwei Remote-Repositorys erleichtert. Dadurch, dass man letztendlich mit zwei Repositorys arbeitet, müssen beide korrekt verwaltet werden. So gibt es einmal das eigene Repository, in dem man Schreibrechte besitzt und das Repository des Projektes, wohin die Pull-Requests und auch anderen Änderungen des Projektes fließen. Man sollte daher immer beachten, dass man sein eigenes Repository auf dem eigenen Stand hält.

Wenn die oben aufgeführten Befehle ausgeführt hat, ist der eigene Fork als Remote-Repository “origin” konfiguriert. Dies sollte man genau so belassen, da man alle Branches in das eigene Repository pusht. Jetzt sollte man das Repository des Projektes ebenfalls als Remote-Repository hinzufügen, hier bietet es sich an, es “upstream” zu nennen, da es sich schließlich um das Upstream-Projekt handelt.

$ git remote add upstream git@github.com:svijee/drunken-nemesis.git

Jetzt ist zwar das Repository konfiguriert, allerdings sind die Änderungen noch nicht heruntergeladen. Dies kann man mit einem der beiden aufgeführten Befehle durchführen.

$ git remote update 
$ git fetch upstream 

Während der erste Befehl alle Remote-Repositorys herunterlädt, lädt letzterer Befehl nur das Remote “upstream” herunter. In der Regel ist es nun so, dass sich auf dem Upstream-Repository einiges tut, diese Änderungen müssten dann regelmäßig in das eigene Repository übernommen werden. Dazu sollte man regelmäßig “git remote update” ausführen und anschließend den Branch aus dem Remote-Repository in den Branch des eigenen Repositorys mergen. In diesem Beispiel, ist es der Branch “master” den man aktualisieren möchte.

$ git merge upstream/master

Sofern keine Änderungen auf dem Branch “master” im eigenen Repository sind, sollte der Merge problemlos funktionieren. Änderungen, die man dem Haupt-Repository beifügen will, sollte man daher immer in einem neuen Branch anlegen, um Merge-Konflikte zu vermeiden.

Häufig passiert es aber auch, dass man Pull-Requests anlegt, die zu einem späteren Zeitpunkt nicht mehr automatisch ohen Konflikte gemergt werden können. Als Einreicher von Pull-Requests sollte man also immer darauf achten, dass der Pull-Request ohne Konflikte gemergt werden kann. Da dies nicht immer möglich ist, müssen gegebenfalls Commits aus dem Entwicklungs-Branch des Haupt-Repositorys übernommen werden. Diese kann man entweder mit dem “git merge” Befehl mergen, schöner ist es allerdings, wenn man ein Rebase durchführt, der im dritten Teil dieses Tutoriums erläutert wurde.

Weitere Funktionen von GitHub

GitHub bietet nicht nur das Hosten von Repositorys an. Die Funktionen sind mittlerweile vielfältig und decken so gut wie alle Wünsche ab, die man für ein Software-Projekt haben kann. Darunter ein Ticket-System („Issues“) und ein Wiki. Beides ist direkt über das Repository zu erreichen. Daneben kann man auch statische Webseiten mit GitHub Pages hosten oder Gists als Lager für einzelne Dateien anlegen.

Alternativen

GitHub ist nicht die einzige Plattform, welche das Hosten von Repositorys mit sinnvollen Features erweitert um einfach und kollaborativ an Projekten zu arbeiten. So hat GitHub auch Nachteile, etwa steht es selbst nicht unter eine Open Source Lizenz und das Hosten von privaten, nicht öffentlichen Repositorys kostet Geld.

Als Alternative seien Gitlab und Bitbucket genannt, bei denen man auch private Repositorys mit einigen Begrenzungen kostenlos hosten kann. Gitlab kann man aber auch selbst auf eigenen Servern hosten, sodass man etwa für den Firmen-internen Gebrauch von Closed Source Software den Quellcode nicht auf fremde Server hochladen muss.

• Hier geht es zu Teil 1
• Hier geht es zu Teil 2
• Hier geht es zu Teil 3

Im letzten Teil ging es um das Rebasen und das Einrichten und Nutzen von Remote-Repositorys. In diesem Teil wird es rein um GitHub und dessen Workflow gehen. Darunter fällt unter anderem das Erstellen eines Repositorys und wie man sich an Open-Source-Projekten auf GitHub beteiligen kann.

Dieses Tutorium besteht aus vier Teilen. Wem das Tutorium gefällt und mehr über Git lernen möchte, der kann sich das Buch „Versionsverwaltung mit Git“ für 29,99€ bestellen. In diesem Buch, was ich geschrieben habe, werden die Themen rund um Git noch deutlich ausführlicher behandelt.

Was ist GitHub?

Im dritten Teil dieses Tutoriums wurde zwar erläutert wie man mit Remote-Repositorys arbeitet, allerdings fehlte bislang eine sinnvolle Möglichkeit um Repositorys auf entfernt liegenden Servern zu lagern, die man über das öffentliche Internet erreichen kann. Eines der Dienste um dies zu erledigen ist GitHub.

GitHub besitzt sehr viele Funktionen die sich um das kollaborative Arbeiten an Projekten mit Git drehen. Darüber hinaus besitzt GitHub zwar noch einige weitere Dienste, dieser Teil des Tutorium dreht sich allerdings mehr um die grundsätzlichen Funktionen, die Git betreffen.

Hinweis: Da GitHub stetig weiterentwickelt wird, ändert sich auch die Web-Oberfläche. Die in diesem Artikel enthaltenen Screenshots könnten bereits nach wenigen Monaten veraltet sein.

Repository anlegen

Bei GitHub können Git-Repositorys angelegt werden. Bevor man sein erstes Repository anlegen kann, muss man sich zunächst registrieren. Der Funktionsumfang mit einem Standardkonto ist auf öffentliche Git-Repositorys beschränkt, das heißt vor allem, dass alle Dateien aus den Repositorys öffentlich und somit für jeden lesbar sind. Gegen Bezahlung kann man auch private Repositorys anlegen.

Nach der Registrierung und dem Einloggen findet man in der oberen Leiste in GitHub diverse Bedienelemente, darunter auch ein Knopf um ein neues Repository bzw. eine neue Organisation anzulegen. Eine Organisation ist an dieser Stelle noch nicht so wichtig, kurz gesagt, kann man Organisationen anlegen, damit eine Gruppe an Entwicklern sich die Rechte an Repositorys teilen können. Wenn man hingegen einen Account als normalen Nutzer besitzt, sind die Rechte standardmäßig auf die eigenen Repositorys für sich alleine beschränkt.

Wenn man nun ein Repository anlegen möchte, muss man dem Repository zunächst einen Namen vergeben. Optional ist hingegen eine kurze Beschreibung. Als zusätzliche Möglichkeit, kann man dem Repository direkt eine README-Datei hinzufügen lassen, ebenso wie eine ".gitignore"-Datei sowie eine Datei mit den Lizenz-Bestimmungen des Projektes im Repository.

Die "README"-Datei ist dafür da, um Informationen über das Projekt bzw. das Repository auf der Startseite des Repositorys darzustellen. GitHub stellt dies automatisch dar.

In diesem Tutorium wurde bislang noch nicht die Datei ".gitignore" behandelt. Innerhalb jedem Repositorys kann eine solche Datei anlegt werden. Alles was man dort einträgt, wird von Git schlicht ignoriert und somit nicht weiter beobachtet. Wenn man etwa an LaTeX-Dokumenten arbeitet, hat man bei jedem Kompilieren der TeX-Datei einige Dateien, die nicht direkt für das Projekt selbst relevant sind und somit auch eine Versionierung nicht notwendig ist. Diese Dateien kann man in der Datei ".gitignore" eintragen und Git zeigt diese Dateien in keinen der Befehle an. GitHub macht das Anlegen der Datei noch ein wenig komfortabler, da es sehr viele vordefinierte gitignore-Dateien anbietet, etwa für Java-, Android- oder TeX-Projekte.

Weiterhin kann man beim Anlegen eines Repositorys über GitHub eine Lizenz-Datei anlegen lassen. Dies ist wichtig, damit auch andere Leute von dem Inhalt des Repositorys profitieren können.

Wenn man nun einen Namen, eine Beschreibung sowie eine Lizenz-Datei ausgewählt hat und anschließend das Repository erzeugt, dann besitzt das Repository zu Beginn genau einem Commit mit der Commit-Message „Initial Commit“.

SSH-Key anlegen und hinzufügen

Bevor man das neu angelegte Repository klonen kann, muss man dem GitHub-Account noch einen SSH-Key hinzufügen. Sofern man auf dem lokalen Rechner noch kein SSH-Key erzeugt hat, muss zunächst ein Key anlegt werden.

Falls man nicht weiß, ob man schon mindestens einen SSH-Key besitzt, kann man den Inhalt vom Ordner "~/.ssh" überprüfen. Ein SSH-Key setzt sich aus zwei Dateien zusammen. Dies ist zum einen der private und zum anderen der öffentliche Schlüssel. Beispielsweise ist die Datei "id_rsa" der private Schlüssel, während "id_rsa.pub" öffentlicher Schlüsselteil ist.

Sofern man noch keinen SSH-Key angelegt hat, kann man das mit dem folgenden Befehl erledigen:

$ ssh-keygen -t rsa -C "mail@svij.org"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sujee/.ssh/id_rsa): /home/sujee/.ssh/id_github
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sujee/.ssh/id_github.
Your public key has been saved in /home/sujee/.ssh/id_github.pub.
The key fingerprint is:
SHA256:LFM8YkUe+ACh4+mH0GXZ4xAlWXT3zpHDEKdg/r9jBHI mail@svij.org
The key's randomart image is:
+---[RSA 2048]----+
|    =B+oB +..    |
|   ..=oB + * .   |
|  o = =o. . *    |
| o = + =ooEo o   |
|. +   + So..o    |
| o .   o   ..    |
|  o .      ..    |
|   .        o.   |
|           ...   |
+----[SHA256]-----+

Beim Ausführen des gelisteten Befehls werden interaktiv einige Fragen gestellt, die beantwortet werden sollten. Darunter den exakten Speicherort des Schlüssels, sowie ein Passwort. Man kann zwar auch einen Schlüssel ohne Passwort generieren, dies ist allerdings nicht empfehlenswert, da man sonst vollständigen Zugriff auf die Repositorys erhält, falls der private Schlüssel in falsche Hände gerät.

Nachdem nun das Schlüsselpaar generiert worden ist, muss nun der öffentliche Schlüssel in GitHub eintragen werden. Der öffentliche Schlüssel liegt in diesem Beispiel in "~/.ssh/id_github.pub". In den GitHub-SSH-Einstellungen muss dann der Inhalt dieser Datei eingefügt werden.

Repository klonen

An dieser Stelle kann man das Repository erstmals klonen. Dazu braucht man die URL, um es über SSH zu klonen. Dies findet man entweder auf der GitHub-Repository-Seite oder man setzt es sich selbst zusammen, da es immer dem gleichen Schema folgt. In meinem Beispiel heißt das Repository „drunken-nemesis“ im Nutzer-Konto „svijee“. Das Repository findet sich daher unter https://github.com/svijee/drunken-nemesis. Unter der rechten Seitenleiste auf GitHub findet sich die URL zum Klonen via SSH, HTTPS oder Subversion. Relevant ist in der Regel nur das Klonen via SSH.

$ git clone git@github.com:svijee/drunken-nemesis.git
Klone nach 'drunken-nemesis'...
Enter passphrase for key '/home/sujee/.ssh/id_github': 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Empfange Objekte: 100% (3/3), Fertig.
Prüfe Konnektivität... Fertig.

Wenn man das Repository direkt klont, konfiguriert Git automatisch das geklonte Repository als das „origin“ Remote-Repository. Dies kann man nachvollziehen, wenn man in das Verzeichnis wechselt und dort die Remote-Repositorys auflistet.

$ cd drunken-nemesis
$ git remote -v
origin  git@github.com:svijee/drunken-nemesis.git (fetch)
origin  git@github.com:svijee/drunken-nemesis.git (push)

Anschließend kann man alle gewünschten Funktionen von Git nutzen, wie das Erstellen von Branches und Commits. Diese können dann anschließend gepusht werden, um die Änderungen über GitHub zur Verfügung zustellen. Die Änderungen lassen sich auch auf der Webseite von GitHub selbst ansehen, sodass man Repositorys nicht zwangsläufig klonen muss. Unter github.com/svijee/drunken-nemesis/commits/master finden sich etwa alle Commits die auf dem Branch "master" getätigt wurden. Ebenfalls kann man dort zwischen den Branches wechseln.

GitHub-Workflow

Das Besondere an GitHub ist, dass es nicht nur eine einfache Möglichkeit bietet eigene Git-Repositorys zu hosten, sondern auch, dass man mit wenigen Schritten Änderungen an Repositorys von anderen Personen oder Organisationen vorschlagen kann, die dann übernommen werden können.

Jedes GitHub-Repository lässt sich im Browser forken. Bei einem Fork spricht man von einer Abspaltung. Hin und wieder hört man bei größeren Open-Source-Projekten, das ein Fork entstanden ist. So ist die Büro-Suite LibreOffice ein Fork von OpenOffice.org, wo allerdings nicht die Änderungen zu OpenOffice.org zurückgeflossen sind. Bei GitHub hat ein Fork in der Regel eine etwas andere Bedeutung. In der Regel liegen die Zugriffsberechtigungen an einem Repository allein bei dem Besitzer des Repositorys. Über GitHub kann man nun Änderungen an einem Repository vorschlagen, dazu muss man den Fork-Button im Browser drücken. Dann wird eine Kopie (der Fork) des Repositorys erzeugt und im eigenen Account abgelegt. Dort besitzt man anschließend alle nötigen Schreibrechte. Wenn man also an dem Repository svijee/drunken-nemesis Änderungen vorschlagen möchte, erstellt GitHub nach dem Drücken des Fork-Buttons eine Kopie des Repositorys unter $DEINNAME/drunken-nemesis. GitHub zeigt selbst direkt auch an, dass es sich um einen Fork des Haupt-Repositorys handelt.

An dem Fork kann man nun wie gewünscht auf einem Branch die gewünschten Änderungen in Form von Commits durchführen. In der Regel bietet es sich an, dafür einen extra Branch anzulegen in dem man die Commits hinzufügt. Fehlen darf dafür natürlich kein Beispiel:

$ git clone git@github.com:$DEINUSERNAME/drunken-nemesis.git
$ cd drunken-nemesis

Anschließend kann man etwa eine Datei namens "README" mit beliebigen Inhalt hinzufügen, die anschließend commited werden kann.

$ git add README
$ git commit -m "README Datei hinzugefügt."

Zur Wiederholung: Wichtig ist an diesem Punkt, dass man nicht vergisst das Repository zu GitHub zu pushen. Da Git bekanntlich ein verteiltes Versionsverwaltungssystem ist, sind die Änderungen bis zu diesem Punkt nur lokal verfügbar. Daher muss man noch "git push" ausführen, um die Änderungen zu dem Remote-Repository auf GitHub zu übertragen.

Anschließend kann man über GitHub den sogenannten Pull-Request erstellen, in dem man die Änderungen die man gemacht hat, dem Haupt-Repository zur Übernahme vorschlägt. Bei jedem Repository, wo die Pull-Request-Funktion nicht abgeschaltet wurde, findet sich auf der Repository-Seite der Menüpunkt „Pull Requests“ auf der sich vorhandene, offene Pull-Requests befinden und auch neue angelegt werden können. Beim Anlegen müssen dann beide Branches, jeweils aus dem Quell- und Ziel-Repository, ausgewählt werden, die zunächst verglichen werden können. Sofern alle benötigten Änderungen in dem Pull-Request enthalten sind, kann der Request angelegt werden. Die Mitarbeiter an dem Haupt-Repository, an dem der Pull-Request gestellt wurde, können diesen Kommentieren oder direkt annehmen.

Arbeiten mit zwei Remote-Repositorys

Wenn man regelmäßig an einem Projekt über GitHub beiträgt, bietet sich eine lokale Konfiguration an, die das Arbeiten mit zwei Remote-Repositorys erleichtert. Dadurch, dass man letztendlich mit zwei Repositorys arbeitet, müssen beide korrekt verwaltet werden. So gibt es einmal das eigene Repository, in dem man Schreibrechte besitzt und das Repository des Projektes, wohin die Pull-Requests und auch anderen Änderungen des Projektes fließen. Man sollte daher immer beachten, dass man sein eigenes Repository auf dem eigenen Stand hält.

Wenn die oben aufgeführten Befehle ausgeführt hat, ist der eigene Fork als Remote-Repository "origin" konfiguriert. Dies sollte man genau so belassen, da man alle Branches in das eigene Repository pusht. Jetzt sollte man das Repository des Projektes ebenfalls als Remote-Repository hinzufügen, hier bietet es sich an, es "upstream" zu nennen, da es sich schließlich um das Upstream-Projekt handelt.

$ git remote add upstream git@github.com:svijee/drunken-nemesis.git

Jetzt ist zwar das Repository konfiguriert, allerdings sind die Änderungen noch nicht heruntergeladen. Dies kann man mit einem der beiden aufgeführten Befehle durchführen.

$ git remote update 
$ git fetch upstream

Während der erste Befehl alle Remote-Repositorys herunterlädt, lädt letzterer Befehl nur das Remote "upstream" herunter. In der Regel ist es nun so, dass sich auf dem Upstream-Repository einiges tut, diese Änderungen müssten dann regelmäßig in das eigene Repository übernommen werden. Dazu sollte man regelmäßig "git remote update" ausführen und anschließend den Branch aus dem Remote-Repository in den Branch des eigenen Repositorys mergen. In diesem Beispiel, ist es der Branch "master" den man aktualisieren möchte.

$ git merge upstream/master

Sofern keine Änderungen auf dem Branch "master" im eigenen Repository sind, sollte der Merge problemlos funktionieren. Änderungen, die man dem Haupt-Repository beifügen will, sollte man daher immer in einem neuen Branch anlegen, um Merge-Konflikte zu vermeiden.

Häufig passiert es aber auch, dass man Pull-Requests anlegt, die zu einem späteren Zeitpunkt nicht mehr automatisch ohen Konflikte gemergt werden können. Als Einreicher von Pull-Requests sollte man also immer darauf achten, dass der Pull-Request ohne Konflikte gemergt werden kann. Da dies nicht immer möglich ist, müssen gegebenfalls Commits aus dem Entwicklungs-Branch des Haupt-Repositorys übernommen werden. Diese kann man entweder mit dem "git merge" Befehl mergen, schöner ist es allerdings, wenn man ein Rebase durchführt, der im dritten Teil dieses Tutoriums erläutert wurde.

Weitere Funktionen von GitHub

GitHub bietet nicht nur das Hosten von Repositorys an. Die Funktionen sind mittlerweile vielfältig und decken so gut wie alle Wünsche ab, die man für ein Software-Projekt haben kann. Darunter ein Ticket-System („Issues“) und ein Wiki. Beides ist direkt über das Repository zu erreichen. Daneben kann man auch statische Webseiten mit GitHub Pages hosten oder Gists als Lager für einzelne Dateien anlegen.

Alternativen

GitHub ist nicht die einzige Plattform, welche das Hosten von Repositorys mit sinnvollen Features erweitert um einfach und kollaborativ an Projekten zu arbeiten. So hat GitHub auch Nachteile, etwa steht es selbst nicht unter eine Open Source Lizenz und das Hosten von privaten, nicht öffentlichen Repositorys kostet Geld.

Als Alternative seien Gitlab und Bitbucket genannt, bei denen man auch private Repositorys mit einigen Begrenzungen kostenlos hosten kann. Gitlab kann man aber auch selbst auf eigenen Servern hosten, sodass man etwa für den Firmen-internen Gebrauch von Closed Source Software den Quellcode nicht auf fremde Server hochladen muss.

• Hier geht es zu Teil 1
• Hier geht es zu Teil 2
• Hier geht es zu Teil 3

Im letzten Teil ging es um das Rebasen und das Einrichten und Nutzen von Remote-Repositorys. In diesem Teil wird es rein um GitHub und dessen Workflow gehen. Darunter fällt unter anderem das Erstellen eines Repositorys und wie man sich an Open-Source-Projekten auf GitHub beteiligen kann.

Dieses Tutorium besteht aus vier Teilen. Wem das Tutorium gefällt und mehr über Git lernen möchte, der kann sich das Buch „Versionsverwaltung mit Git“ für 29,99€ bestellen. In diesem Buch, was ich geschrieben habe, werden die Themen rund um Git noch deutlich ausführlicher behandelt.

Was ist GitHub?

Im dritten Teil dieses Tutoriums wurde zwar erläutert wie man mit Remote-Repositorys arbeitet, allerdings fehlte bislang eine sinnvolle Möglichkeit um Repositorys auf entfernt liegenden Servern zu lagern, die man über das öffentliche Internet erreichen kann. Eines der Dienste um dies zu erledigen ist GitHub.

GitHub besitzt sehr viele Funktionen die sich um das kollaborative Arbeiten an Projekten mit Git drehen. Darüber hinaus besitzt GitHub zwar noch einige weitere Dienste, dieser Teil des Tutorium dreht sich allerdings mehr um die grundsätzlichen Funktionen, die Git betreffen.

Hinweis: Da GitHub stetig weiterentwickelt wird, ändert sich auch die Web-Oberfläche. Die in diesem Artikel enthaltenen Screenshots könnten bereits nach wenigen Monaten veraltet sein.

Repository anlegen

Bei GitHub können Git-Repositorys angelegt werden. Bevor man sein erstes Repository anlegen kann, muss man sich zunächst registrieren. Der Funktionsumfang mit einem Standardkonto ist auf öffentliche Git-Repositorys beschränkt, das heißt vor allem, dass alle Dateien aus den Repositorys öffentlich und somit für jeden lesbar sind. Gegen Bezahlung kann man auch private Repositorys anlegen.

Nach der Registrierung und dem Einloggen findet man in der oberen Leiste in GitHub diverse Bedienelemente, darunter auch ein Knopf um ein neues Repository bzw. eine neue Organisation anzulegen. Eine Organisation ist an dieser Stelle noch nicht so wichtig, kurz gesagt, kann man Organisationen anlegen, damit eine Gruppe an Entwicklern sich die Rechte an Repositorys teilen können. Wenn man hingegen einen Account als normalen Nutzer besitzt, sind die Rechte standardmäßig auf die eigenen Repositorys für sich alleine beschränkt.

Wenn man nun ein Repository anlegen möchte, muss man dem Repository zunächst einen Namen vergeben. Optional ist hingegen eine kurze Beschreibung. Als zusätzliche Möglichkeit, kann man dem Repository direkt eine README-Datei hinzufügen lassen, ebenso wie eine ".gitignore"-Datei sowie eine Datei mit den Lizenz-Bestimmungen des Projektes im Repository.

Die "README"-Datei ist dafür da, um Informationen über das Projekt bzw. das Repository auf der Startseite des Repositorys darzustellen. GitHub stellt dies automatisch dar.

In diesem Tutorium wurde bislang noch nicht die Datei ".gitignore" behandelt. Innerhalb jedem Repositorys kann eine solche Datei anlegt werden. Alles was man dort einträgt, wird von Git schlicht ignoriert und somit nicht weiter beobachtet. Wenn man etwa an LaTeX-Dokumenten arbeitet, hat man bei jedem Kompilieren der TeX-Datei einige Dateien, die nicht direkt für das Projekt selbst relevant sind und somit auch eine Versionierung nicht notwendig ist. Diese Dateien kann man in der Datei ".gitignore" eintragen und Git zeigt diese Dateien in keinen der Befehle an. GitHub macht das Anlegen der Datei noch ein wenig komfortabler, da es sehr viele vordefinierte gitignore-Dateien anbietet, etwa für Java-, Android- oder TeX-Projekte.

Weiterhin kann man beim Anlegen eines Repositorys über GitHub eine Lizenz-Datei anlegen lassen. Dies ist wichtig, damit auch andere Leute von dem Inhalt des Repositorys profitieren können.

Wenn man nun einen Namen, eine Beschreibung sowie eine Lizenz-Datei ausgewählt hat und anschließend das Repository erzeugt, dann besitzt das Repository zu Beginn genau einem Commit mit der Commit-Message „Initial Commit“.

SSH-Key anlegen und hinzufügen

Bevor man das neu angelegte Repository klonen kann, muss man dem GitHub-Account noch einen SSH-Key hinzufügen. Sofern man auf dem lokalen Rechner noch kein SSH-Key erzeugt hat, muss zunächst ein Key anlegt werden.

Falls man nicht weiß, ob man schon mindestens einen SSH-Key besitzt, kann man den Inhalt vom Ordner "~/.ssh" überprüfen. Ein SSH-Key setzt sich aus zwei Dateien zusammen. Dies ist zum einen der private und zum anderen der öffentliche Schlüssel. Beispielsweise ist die Datei "id_rsa" der private Schlüssel, während "id_rsa.pub" öffentlicher Schlüsselteil ist.

Sofern man noch keinen SSH-Key angelegt hat, kann man das mit dem folgenden Befehl erledigen:

$ ssh-keygen -t rsa -C "mail@svij.org"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sujee/.ssh/id_rsa): /home/sujee/.ssh/id_github
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sujee/.ssh/id_github.
Your public key has been saved in /home/sujee/.ssh/id_github.pub.
The key fingerprint is:
SHA256:LFM8YkUe+ACh4+mH0GXZ4xAlWXT3zpHDEKdg/r9jBHI mail@svij.org
The key's randomart image is:
+---[RSA 2048]----+
|    =B+oB +..    |
|   ..=oB + * .   |
|  o = =o. . *    |
| o = + =ooEo o   |
|. +   + So..o    |
| o .   o   ..    |
|  o .      ..    |
|   .        o.   |
|           ...   |
+----[SHA256]-----+

Beim Ausführen des gelisteten Befehls werden interaktiv einige Fragen gestellt, die beantwortet werden sollten. Darunter den exakten Speicherort des Schlüssels, sowie ein Passwort. Man kann zwar auch einen Schlüssel ohne Passwort generieren, dies ist allerdings nicht empfehlenswert, da man sonst vollständigen Zugriff auf die Repositorys erhält, falls der private Schlüssel in falsche Hände gerät.

Nachdem nun das Schlüsselpaar generiert worden ist, muss nun der öffentliche Schlüssel in GitHub eintragen werden. Der öffentliche Schlüssel liegt in diesem Beispiel in "~/.ssh/id_github.pub". In den GitHub-SSH-Einstellungen muss dann der Inhalt dieser Datei eingefügt werden.

Repository klonen

An dieser Stelle kann man das Repository erstmals klonen. Dazu braucht man die URL, um es über SSH zu klonen. Dies findet man entweder auf der GitHub-Repository-Seite oder man setzt es sich selbst zusammen, da es immer dem gleichen Schema folgt. In meinem Beispiel heißt das Repository „drunken-nemesis“ im Nutzer-Konto „svijee“. Das Repository findet sich daher unter https://github.com/svijee/drunken-nemesis. Unter der rechten Seitenleiste auf GitHub findet sich die URL zum Klonen via SSH, HTTPS oder Subversion. Relevant ist in der Regel nur das Klonen via SSH.

$ git clone git@github.com:svijee/drunken-nemesis.git
Klone nach 'drunken-nemesis'...
Enter passphrase for key '/home/sujee/.ssh/id_github': 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Empfange Objekte: 100% (3/3), Fertig.
Prüfe Konnektivität... Fertig.

Wenn man das Repository direkt klont, konfiguriert Git automatisch das geklonte Repository als das „origin“ Remote-Repository. Dies kann man nachvollziehen, wenn man in das Verzeichnis wechselt und dort die Remote-Repositorys auflistet.

$ cd drunken-nemesis
$ git remote -v
origin  git@github.com:svijee/drunken-nemesis.git (fetch)
origin  git@github.com:svijee/drunken-nemesis.git (push)

Anschließend kann man alle gewünschten Funktionen von Git nutzen, wie das Erstellen von Branches und Commits. Diese können dann anschließend gepusht werden, um die Änderungen über GitHub zur Verfügung zustellen. Die Änderungen lassen sich auch auf der Webseite von GitHub selbst ansehen, sodass man Repositorys nicht zwangsläufig klonen muss. Unter github.com/svijee/drunken-nemesis/commits/master finden sich etwa alle Commits die auf dem Branch "master" getätigt wurden. Ebenfalls kann man dort zwischen den Branches wechseln.

GitHub-Workflow

Das Besondere an GitHub ist, dass es nicht nur eine einfache Möglichkeit bietet eigene Git-Repositorys zu hosten, sondern auch, dass man mit wenigen Schritten Änderungen an Repositorys von anderen Personen oder Organisationen vorschlagen kann, die dann übernommen werden können.

Jedes GitHub-Repository lässt sich im Browser forken. Bei einem Fork spricht man von einer Abspaltung. Hin und wieder hört man bei größeren Open-Source-Projekten, das ein Fork entstanden ist. So ist die Büro-Suite LibreOffice ein Fork von OpenOffice.org, wo allerdings nicht die Änderungen zu OpenOffice.org zurückgeflossen sind. Bei GitHub hat ein Fork in der Regel eine etwas andere Bedeutung. In der Regel liegen die Zugriffsberechtigungen an einem Repository allein bei dem Besitzer des Repositorys. Über GitHub kann man nun Änderungen an einem Repository vorschlagen, dazu muss man den Fork-Button im Browser drücken. Dann wird eine Kopie (der Fork) des Repositorys erzeugt und im eigenen Account abgelegt. Dort besitzt man anschließend alle nötigen Schreibrechte. Wenn man also an dem Repository svijee/drunken-nemesis Änderungen vorschlagen möchte, erstellt GitHub nach dem Drücken des Fork-Buttons eine Kopie des Repositorys unter $DEINNAME/drunken-nemesis. GitHub zeigt selbst direkt auch an, dass es sich um einen Fork des Haupt-Repositorys handelt.

An dem Fork kann man nun wie gewünscht auf einem Branch die gewünschten Änderungen in Form von Commits durchführen. In der Regel bietet es sich an, dafür einen extra Branch anzulegen in dem man die Commits hinzufügt. Fehlen darf dafür natürlich kein Beispiel:

$ git clone git@github.com:$DEINUSERNAME/drunken-nemesis.git
$ cd drunken-nemesis

Anschließend kann man etwa eine Datei namens "README" mit beliebigen Inhalt hinzufügen, die anschließend commited werden kann.

$ git add README
$ git commit -m "README Datei hinzugefügt."

Zur Wiederholung: Wichtig ist an diesem Punkt, dass man nicht vergisst das Repository zu GitHub zu pushen. Da Git bekanntlich ein verteiltes Versionsverwaltungssystem ist, sind die Änderungen bis zu diesem Punkt nur lokal verfügbar. Daher muss man noch "git push" ausführen, um die Änderungen zu dem Remote-Repository auf GitHub zu übertragen.

Anschließend kann man über GitHub den sogenannten Pull-Request erstellen, in dem man die Änderungen die man gemacht hat, dem Haupt-Repository zur Übernahme vorschlägt. Bei jedem Repository, wo die Pull-Request-Funktion nicht abgeschaltet wurde, findet sich auf der Repository-Seite der Menüpunkt „Pull Requests“ auf der sich vorhandene, offene Pull-Requests befinden und auch neue angelegt werden können. Beim Anlegen müssen dann beide Branches, jeweils aus dem Quell- und Ziel-Repository, ausgewählt werden, die zunächst verglichen werden können. Sofern alle benötigten Änderungen in dem Pull-Request enthalten sind, kann der Request angelegt werden. Die Mitarbeiter an dem Haupt-Repository, an dem der Pull-Request gestellt wurde, können diesen Kommentieren oder direkt annehmen.

Arbeiten mit zwei Remote-Repositorys

Wenn man regelmäßig an einem Projekt über GitHub beiträgt, bietet sich eine lokale Konfiguration an, die das Arbeiten mit zwei Remote-Repositorys erleichtert. Dadurch, dass man letztendlich mit zwei Repositorys arbeitet, müssen beide korrekt verwaltet werden. So gibt es einmal das eigene Repository, in dem man Schreibrechte besitzt und das Repository des Projektes, wohin die Pull-Requests und auch anderen Änderungen des Projektes fließen. Man sollte daher immer beachten, dass man sein eigenes Repository auf dem eigenen Stand hält.

Wenn die oben aufgeführten Befehle ausgeführt hat, ist der eigene Fork als Remote-Repository "origin" konfiguriert. Dies sollte man genau so belassen, da man alle Branches in das eigene Repository pusht. Jetzt sollte man das Repository des Projektes ebenfalls als Remote-Repository hinzufügen, hier bietet es sich an, es "upstream" zu nennen, da es sich schließlich um das Upstream-Projekt handelt.

$ git remote add upstream git@github.com:svijee/drunken-nemesis.git

Jetzt ist zwar das Repository konfiguriert, allerdings sind die Änderungen noch nicht heruntergeladen. Dies kann man mit einem der beiden aufgeführten Befehle durchführen.

$ git remote update 
$ git fetch upstream

Während der erste Befehl alle Remote-Repositorys herunterlädt, lädt letzterer Befehl nur das Remote "upstream" herunter. In der Regel ist es nun so, dass sich auf dem Upstream-Repository einiges tut, diese Änderungen müssten dann regelmäßig in das eigene Repository übernommen werden. Dazu sollte man regelmäßig "git remote update" ausführen und anschließend den Branch aus dem Remote-Repository in den Branch des eigenen Repositorys mergen. In diesem Beispiel, ist es der Branch "master" den man aktualisieren möchte.

$ git merge upstream/master

Sofern keine Änderungen auf dem Branch "master" im eigenen Repository sind, sollte der Merge problemlos funktionieren. Änderungen, die man dem Haupt-Repository beifügen will, sollte man daher immer in einem neuen Branch anlegen, um Merge-Konflikte zu vermeiden.

Häufig passiert es aber auch, dass man Pull-Requests anlegt, die zu einem späteren Zeitpunkt nicht mehr automatisch ohen Konflikte gemergt werden können. Als Einreicher von Pull-Requests sollte man also immer darauf achten, dass der Pull-Request ohne Konflikte gemergt werden kann. Da dies nicht immer möglich ist, müssen gegebenfalls Commits aus dem Entwicklungs-Branch des Haupt-Repositorys übernommen werden. Diese kann man entweder mit dem "git merge" Befehl mergen, schöner ist es allerdings, wenn man ein Rebase durchführt, der im dritten Teil dieses Tutoriums erläutert wurde.

Weitere Funktionen von GitHub

GitHub bietet nicht nur das Hosten von Repositorys an. Die Funktionen sind mittlerweile vielfältig und decken so gut wie alle Wünsche ab, die man für ein Software-Projekt haben kann. Darunter ein Ticket-System („Issues“) und ein Wiki. Beides ist direkt über das Repository zu erreichen. Daneben kann man auch statische Webseiten mit GitHub Pages hosten oder Gists als Lager für einzelne Dateien anlegen.

Alternativen

GitHub ist nicht die einzige Plattform, welche das Hosten von Repositorys mit sinnvollen Features erweitert um einfach und kollaborativ an Projekten zu arbeiten. So hat GitHub auch Nachteile, etwa steht es selbst nicht unter eine Open Source Lizenz und das Hosten von privaten, nicht öffentlichen Repositorys kostet Geld.

Als Alternative seien Gitlab und Bitbucket genannt, bei denen man auch private Repositorys mit einigen Begrenzungen kostenlos hosten kann. Gitlab kann man aber auch selbst auf eigenen Servern hosten, sodass man etwa für den Firmen-internen Gebrauch von Closed Source Software den Quellcode nicht auf fremde Server hochladen muss.

• Hier geht es zu Teil 1
• Hier geht es zu Teil 2
• Hier geht es zu Teil 3

Im letzten Teil ging es um das Rebasen und das Einrichten und Nutzen von Remote-Repositorys. In diesem Teil wird es rein um GitHub und dessen Workflow gehen. Darunter fällt unter anderem das Erstellen eines Repositorys und wie man sich an Open-Source-Projekten auf GitHub beteiligen kann.

Dieses Tutorium besteht aus vier Teilen. Wem das Tutorium gefällt und mehr über Git lernen möchte, der kann sich das Buch „Versionsverwaltung mit Git“ für 29,99€ bestellen. In diesem Buch, was ich geschrieben habe, werden die Themen rund um Git noch deutlich ausführlicher behandelt.

Was ist GitHub?

Im dritten Teil dieses Tutoriums wurde zwar erläutert wie man mit Remote-Repositorys arbeitet, allerdings fehlte bislang eine sinnvolle Möglichkeit um Repositorys auf entfernt liegenden Servern zu lagern, die man über das öffentliche Internet erreichen kann. Eines der Dienste um dies zu erledigen ist GitHub.

GitHub besitzt sehr viele Funktionen die sich um das kollaborative Arbeiten an Projekten mit Git drehen. Darüber hinaus besitzt GitHub zwar noch einige weitere Dienste, dieser Teil des Tutorium dreht sich allerdings mehr um die grundsätzlichen Funktionen, die Git betreffen.

Hinweis: Da GitHub stetig weiterentwickelt wird, ändert sich auch die Web-Oberfläche. Die in diesem Artikel enthaltenen Screenshots könnten bereits nach wenigen Monaten veraltet sein.

Repository anlegen

Bei GitHub können Git-Repositorys angelegt werden. Bevor man sein erstes Repository anlegen kann, muss man sich zunächst registrieren. Der Funktionsumfang mit einem Standardkonto ist auf öffentliche Git-Repositorys beschränkt, das heißt vor allem, dass alle Dateien aus den Repositorys öffentlich und somit für jeden lesbar sind. Gegen Bezahlung kann man auch private Repositorys anlegen.

Nach der Registrierung und dem Einloggen findet man in der oberen Leiste in GitHub diverse Bedienelemente, darunter auch ein Knopf um ein neues Repository bzw. eine neue Organisation anzulegen. Eine Organisation ist an dieser Stelle noch nicht so wichtig, kurz gesagt, kann man Organisationen anlegen, damit eine Gruppe an Entwicklern sich die Rechte an Repositorys teilen können. Wenn man hingegen einen Account als normalen Nutzer besitzt, sind die Rechte standardmäßig auf die eigenen Repositorys für sich alleine beschränkt.

Wenn man nun ein Repository anlegen möchte, muss man dem Repository zunächst einen Namen vergeben. Optional ist hingegen eine kurze Beschreibung. Als zusätzliche Möglichkeit, kann man dem Repository direkt eine README-Datei hinzufügen lassen, ebenso wie eine “.gitignore”-Datei sowie eine Datei mit den Lizenz-Bestimmungen des Projektes im Repository.

Die “README”-Datei ist dafür da, um Informationen über das Projekt bzw. das Repository auf der Startseite des Repositorys darzustellen. GitHub stellt dies automatisch dar.

In diesem Tutorium wurde bislang noch nicht die Datei “.gitignore” behandelt. Innerhalb jedem Repositorys kann eine solche Datei anlegt werden. Alles was man dort einträgt, wird von Git schlicht ignoriert und somit nicht weiter beobachtet. Wenn man etwa an LaTeX-Dokumenten arbeitet, hat man bei jedem Kompilieren der TeX-Datei einige Dateien, die nicht direkt für das Projekt selbst relevant sind und somit auch eine Versionierung nicht notwendig ist. Diese Dateien kann man in der Datei “.gitignore” eintragen und Git zeigt diese Dateien in keinen der Befehle an. GitHub macht das Anlegen der Datei noch ein wenig komfortabler, da es sehr viele vordefinierte gitignore-Dateien anbietet, etwa für Java-, Android- oder TeX-Projekte.

Weiterhin kann man beim Anlegen eines Repositorys über GitHub eine Lizenz-Datei anlegen lassen. Dies ist wichtig, damit auch andere Leute von dem Inhalt des Repositorys profitieren können.

Wenn man nun einen Namen, eine Beschreibung sowie eine Lizenz-Datei ausgewählt hat und anschließend das Repository erzeugt, dann besitzt das Repository zu Beginn genau einem Commit mit der Commit-Message „Initial Commit“.

SSH-Key anlegen und hinzufügen

Bevor man das neu angelegte Repository klonen kann, muss man dem GitHub-Account noch einen SSH-Key hinzufügen. Sofern man auf dem lokalen Rechner noch kein SSH-Key erzeugt hat, muss zunächst ein Key anlegt werden.

Falls man nicht weiß, ob man schon mindestens einen SSH-Key besitzt, kann man den Inhalt vom Ordner “~/.ssh” überprüfen. Ein SSH-Key setzt sich aus zwei Dateien zusammen. Dies ist zum einen der private und zum anderen der öffentliche Schlüssel. Beispielsweise ist die Datei “id_rsa” der private Schlüssel, während “id_rsa.pub” öffentlicher Schlüsselteil ist.

Sofern man noch keinen SSH-Key angelegt hat, kann man das mit dem folgenden Befehl erledigen:

$ ssh-keygen -t rsa -C "mail@svij.org"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sujee/.ssh/id_rsa): /home/sujee/.ssh/id_github
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sujee/.ssh/id_github.
Your public key has been saved in /home/sujee/.ssh/id_github.pub.
The key fingerprint is:
SHA256:LFM8YkUe+ACh4+mH0GXZ4xAlWXT3zpHDEKdg/r9jBHI mail@svij.org
The key's randomart image is:
+---[RSA 2048]----+
|    =B+oB +..    |
|   ..=oB + * .   |
|  o = =o. . *    |
| o = + =ooEo o   |
|. +   + So..o    |
| o .   o   ..    |
|  o .      ..    |
|   .        o.   |
|           ...   |
+----[SHA256]-----+

Beim Ausführen des gelisteten Befehls werden interaktiv einige Fragen gestellt, die beantwortet werden sollten. Darunter den exakten Speicherort des Schlüssels, sowie ein Passwort. Man kann zwar auch einen Schlüssel ohne Passwort generieren, dies ist allerdings nicht empfehlenswert, da man sonst vollständigen Zugriff auf die Repositorys erhält, falls der private Schlüssel in falsche Hände gerät.

Nachdem nun das Schlüsselpaar generiert worden ist, muss nun der öffentliche Schlüssel in GitHub eintragen werden. Der öffentliche Schlüssel liegt in diesem Beispiel in “~/.ssh/id_github.pub”. In den GitHub-SSH-Einstellungen muss dann der Inhalt dieser Datei eingefügt werden.

Repository klonen

An dieser Stelle kann man das Repository erstmals klonen. Dazu braucht man die URL, um es über SSH zu klonen. Dies findet man entweder auf der GitHub-Repository-Seite oder man setzt es sich selbst zusammen, da es immer dem gleichen Schema folgt. In meinem Beispiel heißt das Repository „drunken-nemesis“ im Nutzer-Konto „svijee“. Das Repository findet sich daher unter https://github.com/svijee/drunken-nemesis. Unter der rechten Seitenleiste auf GitHub findet sich die URL zum Klonen via SSH, HTTPS oder Subversion. Relevant ist in der Regel nur das Klonen via SSH.

$ git clone git@github.com:svijee/drunken-nemesis.git
Klone nach 'drunken-nemesis'...
Enter passphrase for key '/home/sujee/.ssh/id_github': 
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Empfange Objekte: 100% (3/3), Fertig.
Prüfe Konnektivität... Fertig.

Wenn man das Repository direkt klont, konfiguriert Git automatisch das geklonte Repository als das „origin“ Remote-Repository. Dies kann man nachvollziehen, wenn man in das Verzeichnis wechselt und dort die Remote-Repositorys auflistet.

$ cd drunken-nemesis
$ git remote -v
origin  git@github.com:svijee/drunken-nemesis.git (fetch)
origin  git@github.com:svijee/drunken-nemesis.git (push)

Anschließend kann man alle gewünschten Funktionen von Git nutzen, wie das Erstellen von Branches und Commits. Diese können dann anschließend gepusht werden, um die Änderungen über GitHub zur Verfügung zustellen. Die Änderungen lassen sich auch auf der Webseite von GitHub selbst ansehen, sodass man Repositorys nicht zwangsläufig klonen muss. Unter github.com/svijee/drunken-nemesis/commits/master finden sich etwa alle Commits die auf dem Branch “master” getätigt wurden. Ebenfalls kann man dort zwischen den Branches wechseln.

GitHub-Workflow

Das Besondere an GitHub ist, dass es nicht nur eine einfache Möglichkeit bietet eigene Git-Repositorys zu hosten, sondern auch, dass man mit wenigen Schritten Änderungen an Repositorys von anderen Personen oder Organisationen vorschlagen kann, die dann übernommen werden können.

Jedes GitHub-Repository lässt sich im Browser forken. Bei einem Fork spricht man von einer Abspaltung. Hin und wieder hört man bei größeren Open-Source-Projekten, das ein Fork entstanden ist. So ist die Büro-Suite LibreOffice ein Fork von OpenOffice.org, wo allerdings nicht die Änderungen zu OpenOffice.org zurückgeflossen sind. Bei GitHub hat ein Fork in der Regel eine etwas andere Bedeutung. In der Regel liegen die Zugriffsberechtigungen an einem Repository allein bei dem Besitzer des Repositorys. Über GitHub kann man nun Änderungen an einem Repository vorschlagen, dazu muss man den Fork-Button im Browser drücken. Dann wird eine Kopie (der Fork) des Repositorys erzeugt und im eigenen Account abgelegt. Dort besitzt man anschließend alle nötigen Schreibrechte. Wenn man also an dem Repository svijee/drunken-nemesis Änderungen vorschlagen möchte, erstellt GitHub nach dem Drücken des Fork-Buttons eine Kopie des Repositorys unter $DEINNAME/drunken-nemesis. GitHub zeigt selbst direkt auch an, dass es sich um einen Fork des Haupt-Repositorys handelt.

An dem Fork kann man nun wie gewünscht auf einem Branch die gewünschten Änderungen in Form von Commits durchführen. In der Regel bietet es sich an, dafür einen extra Branch anzulegen in dem man die Commits hinzufügt. Fehlen darf dafür natürlich kein Beispiel:

$ git clone git@github.com:$DEINUSERNAME/drunken-nemesis.git
$ cd drunken-nemesis

Anschließend kann man etwa eine Datei namens “README” mit beliebigen Inhalt hinzufügen, die anschließend commited werden kann.

$ git add README
$ git commit -m "README Datei hinzugefügt."

Zur Wiederholung: Wichtig ist an diesem Punkt, dass man nicht vergisst das Repository zu GitHub zu pushen. Da Git bekanntlich ein verteiltes Versionsverwaltungssystem ist, sind die Änderungen bis zu diesem Punkt nur lokal verfügbar. Daher muss man noch “git push” ausführen, um die Änderungen zu dem Remote-Repository auf GitHub zu übertragen.

Anschließend kann man über GitHub den sogenannten Pull-Request erstellen, in dem man die Änderungen die man gemacht hat, dem Haupt-Repository zur Übernahme vorschlägt. Bei jedem Repository, wo die Pull-Request-Funktion nicht abgeschaltet wurde, findet sich auf der Repository-Seite der Menüpunkt „Pull Requests“ auf der sich vorhandene, offene Pull-Requests befinden und auch neue angelegt werden können. Beim Anlegen müssen dann beide Branches, jeweils aus dem Quell- und Ziel-Repository, ausgewählt werden, die zunächst verglichen werden können. Sofern alle benötigten Änderungen in dem Pull-Request enthalten sind, kann der Request angelegt werden. Die Mitarbeiter an dem Haupt-Repository, an dem der Pull-Request gestellt wurde, können diesen Kommentieren oder direkt annehmen.

Arbeiten mit zwei Remote-Repositorys

Wenn man regelmäßig an einem Projekt über GitHub beiträgt, bietet sich eine lokale Konfiguration an, die das Arbeiten mit zwei Remote-Repositorys erleichtert. Dadurch, dass man letztendlich mit zwei Repositorys arbeitet, müssen beide korrekt verwaltet werden. So gibt es einmal das eigene Repository, in dem man Schreibrechte besitzt und das Repository des Projektes, wohin die Pull-Requests und auch anderen Änderungen des Projektes fließen. Man sollte daher immer beachten, dass man sein eigenes Repository auf dem eigenen Stand hält.

Wenn die oben aufgeführten Befehle ausgeführt hat, ist der eigene Fork als Remote-Repository “origin” konfiguriert. Dies sollte man genau so belassen, da man alle Branches in das eigene Repository pusht. Jetzt sollte man das Repository des Projektes ebenfalls als Remote-Repository hinzufügen, hier bietet es sich an, es “upstream” zu nennen, da es sich schließlich um das Upstream-Projekt handelt.

$ git remote add upstream git@github.com:svijee/drunken-nemesis.git

Jetzt ist zwar das Repository konfiguriert, allerdings sind die Änderungen noch nicht heruntergeladen. Dies kann man mit einem der beiden aufgeführten Befehle durchführen.

$ git remote update 
$ git fetch upstream 

Während der erste Befehl alle Remote-Repositorys herunterlädt, lädt letzterer Befehl nur das Remote “upstream” herunter. In der Regel ist es nun so, dass sich auf dem Upstream-Repository einiges tut, diese Änderungen müssten dann regelmäßig in das eigene Repository übernommen werden. Dazu sollte man regelmäßig “git remote update” ausführen und anschließend den Branch aus dem Remote-Repository in den Branch des eigenen Repositorys mergen. In diesem Beispiel, ist es der Branch “master” den man aktualisieren möchte.

$ git merge upstream/master

Sofern keine Änderungen auf dem Branch “master” im eigenen Repository sind, sollte der Merge problemlos funktionieren. Änderungen, die man dem Haupt-Repository beifügen will, sollte man daher immer in einem neuen Branch anlegen, um Merge-Konflikte zu vermeiden.

Häufig passiert es aber auch, dass man Pull-Requests anlegt, die zu einem späteren Zeitpunkt nicht mehr automatisch ohen Konflikte gemergt werden können. Als Einreicher von Pull-Requests sollte man also immer darauf achten, dass der Pull-Request ohne Konflikte gemergt werden kann. Da dies nicht immer möglich ist, müssen gegebenfalls Commits aus dem Entwicklungs-Branch des Haupt-Repositorys übernommen werden. Diese kann man entweder mit dem “git merge” Befehl mergen, schöner ist es allerdings, wenn man ein Rebase durchführt, der im dritten Teil dieses Tutoriums erläutert wurde.

Weitere Funktionen von GitHub

GitHub bietet nicht nur das Hosten von Repositorys an. Die Funktionen sind mittlerweile vielfältig und decken so gut wie alle Wünsche ab, die man für ein Software-Projekt haben kann. Darunter ein Ticket-System („Issues“) und ein Wiki. Beides ist direkt über das Repository zu erreichen. Daneben kann man auch statische Webseiten mit GitHub Pages hosten oder Gists als Lager für einzelne Dateien anlegen.

Alternativen

GitHub ist nicht die einzige Plattform, welche das Hosten von Repositorys mit sinnvollen Features erweitert um einfach und kollaborativ an Projekten zu arbeiten. So hat GitHub auch Nachteile, etwa steht es selbst nicht unter eine Open Source Lizenz und das Hosten von privaten, nicht öffentlichen Repositorys kostet Geld.

Als Alternative seien Gitlab und Bitbucket genannt, bei denen man auch private Repositorys mit einigen Begrenzungen kostenlos hosten kann. Gitlab kann man aber auch selbst auf eigenen Servern hosten, sodass man etwa für den Firmen-internen Gebrauch von Closed Source Software den Quellcode nicht auf fremde Server hochladen muss.

• Hier geht es zu Teil 1
• Hier geht es zu Teil 2
• Hier geht es zu Teil 3

Der Wochenrückblick lässt das Geschehen der vergangenen Woche rund um Ubuntu, Linux und Open Source Revue passieren.

Rund um Ubuntu

Ubuntu 15.10 heißt Wily Werewolf

In der Keynote des Ubuntu Online Summit hat Mark Shuttleworth den Namen der nächsten Ubuntu-Version 15.10 bekannt gegeben: Wily Werewolf („Gerissener Werwolf“) wird die Version heißen und vor allem den Punkt Konvergenz von Handy und Desktop soll weiter angegangen werden.

Mehr Informationen gibt es im Ikhaya-Artikel.

Weitere Quellen: OMG!Ubuntu!, Pro-Linux, heise open, Golem, Linux-Magazin

Xubuntu Core vorgestellt

Mit Xubuntu Core (das nichts mit Snappy und Ubuntu Core zu tun hat) hat das Xubuntu-Team eine Minimalversion ihres Betriebssystems vorgestellt. Über das bereitgestellte Image wird ein System mit Xfce und dem Look&Feel von Xubuntu installiert; Office, Mediaplayer und sonstige Anwendungen fehlen aber. Diese können je nach Bedarf nachinstalliert werden. Eine offizielle Version soll es ab Ubuntu 15.10 geben.

Quelle: Xubuntu-Blog, OMG!Ubuntu!, Pro-Linux

Ubuntu-Server mit networkd

Noch ist es nicht offiziell abgesegnet, aber für das kommende Ubuntu 15.10 denken die Ubuntu-Entwickler die testweise Integration von networkd in die Distribution an. networkd ist Teil des systemd-Projekts und sorgt für die Konfiguration der Netzwerkschnittstellen.

Quelle: Golem

Spielen unter Linux

Cyberpunk-RPG Dex veröffentlicht

Das Cyberpunkt-Action-Rollenspiel Dex wurde von Entwicklerstudio Dreadlocks Ltd. für Linux, MacOS X und Windows veröffentlicht. In dem seitwärtsscrollenden 2D-Spiel muss man gegen eine künstliche Intelligenz kämpfen, die sich über die Menschheit stellen will. Die Grafik ist sehr detailreich, aber thematisch ebenso düster gehalten. Das Spiel kann über Steam, aber auch DRM-frei, beispielsweise im Humble Store bezogen werden.

Quelle: LinuxGames

Humble Weekly Bundle: Surprise Attack

Das wöchentliche Humble-Bundle kann diesmal mit sieben Spielen für Linux, davon nur eines nicht DRM-frei, aufwarten. Wie immer kann man den Preis selbst wählen, den man bezahlen will. Ab einem US-Cent erhält man das Puzzle-Jump'n'Run Oscura: Lost Light, das Top-Down-Actionspiel Metrocide (nicht für Linux) und das Tower-Defense-RPG OTTTD {e}. Ab 6 US-Dollar gibt es das Strategiespiel A Druid's Duel, das Puzzlespiel Particulars und den Kampfroboter-Shooter Robocraft (nur über Steam als Early Access) dazu. Und ab 12 US-Dollar erhält man noch das Steampunk-Minigolf-Spiel Vertiginous Golf und Screencheat in doppelter Ausführung.

Um nginx installieren zu können wird zunächst ein Software Repository benötigt, welches unter dem Benutzer root hinzugefügt wird.
yum install epel-release

Im zweiten Schritt kann nginx installiert werden:
yum install nginx

Nach Abschluss der Installation kann der Dienst über systemctl start nginx.service gestartet werden. Damit der Zugriff per Browser möglich ist, muss der Port 80 in der Firewall geöffnet werden.

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --reload

Nun ist ein Aufruf per Browser über http://serverip möglich.

Damit nginx beim nächsten Systemstart mit gestartet wird, muss folgender Befehl ausgeführt werden:
systemctl enable nginx.service

Möchte man an dem default vhost(server block) ein paar Anpassungen vornehmen, so befindet sich die Standardkonfiguration in der Datei /etc/nginx/nginx.conf. Die html Dateien befinden sich in dem Verzeichnis /usr/share/nginx/html/.

Firefox 39 besitzt ein neues Feature, um CSS-Eigenschaften mit dem -webkit-Präfix zu emulieren und somit korrekt darzustellen. Dies gilt allerdings nicht für jede beliebige Webseite, sondern nur für eine kleine Auswahl an Webseiten, welche fix in Firefox hinterlegt ist und auch nicht verändert werden kann. Webentwickler müssen also auch weiterhin darauf achten, nicht nur für Webkit-Browser Code zu schreiben.

Sogenannte CSS Vendor-Präfixe sind, auch wenn die Idee dahinter gut sein mag, oftmals ein Problem. Nämlich dann, wenn Webentwickler die Browser, welche logischerweise die herstellerspezifischen Präfixe der anderen Browser nicht kennen, vergessen oder gar bewusst ignorieren. Die Folge sind Webseiten, welche in den einen Browsern gut aussehen, in anderen Browser aber nicht, obwohl es überhaupt keinen technischen Grund dafür gibt und diese Browser sehr wohl in der Lage wären, die entsprechende Webseite korrekt darzustellen.

Mozilla hat sich diesem Problem angenommen und so kann Firefox ab Version 39 einige Webkit-Eigenschaften emulieren, als wären sie für das Web geschrieben worden. Allerdings dürfen Webentwickler nun nicht auf die Idee kommen, jetzt erst Recht nur noch für Webkit zu entwickeln, denn nun kommt das Aber: es handelt sich dabei um keine grundsätzliche Fähigkeit von Firefox, was für das Web auch eher schlecht als recht wäre. Stattdessen hat Firefox eine Liste von Webseiten fest implementiert bekommen, welche auch nicht durch den Nutzer verändert werden kann, und diese Liste beinhaltet auch nur wenige Webseiten, vor allem aus China und Japan. Die Idee dahinter dürfte sein, ein paar relevante Webseiten mit großen Darstellungsproblemen für Firefox-Nutzer benutzbar zu machen, wenn es nur an herstellerspezifischem CSS scheitert. In erster Linie geht es dabei um Firefox für Android, weil es besonders auf den mobilen Sektor zutrifft, dass häufig nur für Webkit entwickelt wird. Da dieses Feature allerdings auf Gecko-Ebene implementiert worden ist, ist dies auch uneingeschränkt für die Desktop-Version wirksam, was auch Sinn ergibt, da Gecko auf dem Desktop möglichst das Gleiche darstellen sollte wie Gecko auf dem Smartphone. Das Ziel ist außerdem eine Liste, die so klein, nicht so groß wie möglich ist, denn die beste Lösung für das Web ist ohne jede Frage das Entwickeln von Webseiten, die in jedem Browser funktionieren. Die Emulation für jede beliebige Webseite wäre kontraproduktiv und würde ein vollkommen falsches Signal an die Webentwickler-Community senden. Die Einstellung in about:config, um die Emulation zu deaktivieren, heißt layout.css.unprefixing-service.enabled.

Ich glaube ich habe mich noch niemals bzgl. meiner privaten Situation mit Technik so wohl gefühlt wie bisher. Das Equipment, das OS. Macht Spaß und funktioniert.

Ein bisschen wie bei usesthis.com (wtf, wie langweilig ist bitte das Setup von Bruce Schneier?) beschreibe ich mal was ich so benutze.

MacBook Pro 13”

Seit Ende 2014 benutze ich ein MacBook. Mein Zweites. Zwischenzeitlich hatte ich ein Lenovo Thinkpad x201 was zwar seitens der Hardware super geil war, mir aber das mit dem Betriebssystem und alles zum Hals raushing. Hatte ich schon erwähnt das 2015 das Jahr von Linux auf dem Desktop ist?

All diese Dinge die bei OS X einfach so angenehm sind. Safari synchronisiert einfach alles zwischen iPhone und anderen MacBooks hin und her. Airmail2 als Mailclient ist großartig. Die Kalender & Adressbuch Synchronisation rockt. Nutze 1Password, Spotify und seit dem Switch von iPhoto zu Photos kann man das auch wieder benutzen. Ich mag es sehr wie alles sich integriert, funktioniert und man eigentlich nie irgendwas tun muss. Ganz besonders toll: Die iMessage/SMS/FaceTime vom Handy zum OS. Ich hätte nie gedacht, dass ich das so intensiv benutze. Mit iMessage beweist Apple auch noch, dass benutzerfreundliche Crypto nicht unmöglich ist. Die Meisten wissen es nichteinmal.

Genug Kuschelkurs, OS X Liebesschwüre gibts schon genug im Netz. Die uralte Software z.B. rsync oder OpenSSH ist ein echtes Unding. Auch iTunes. Ich benutze es einfach nicht. Es fehlt mir nicht.

OpenBSD CLI VM

Ich habe es mir angewöhnt alles was ich so für den Alltag brauche auf einer klein dimensionierten VM irgendwo im Internet zu hosten.

Das ist extrem praktisch, da ich egal wo ich bin, egal an welchem Rechner ich sitze immer alles da habe. Software die ich dort auf dem bei rootbsd gehosteten System nutze ist unter Anderem:

• ToDo: taskwarrior
• Wiki: cmddocs
• Bookmarks: bm
• IRC: weechat
• Mail: mutt
• AntiSpam: bogofilter
• Mail-Rules: imapfilter
• Journal: jrnl
• RSS: newsbeuter

Auf der Maschine befindet sich sonst nichts. Alles läuft unter meinem User, kein Daemon der lauscht, nichts. Gesichert wird die Kiste mittels tarsnap

Klar hat das auch Nachteile, ich kann auf meine Todoliste nicht zugreifen wenn ich nur mit dem iPhone bestückt im Supermarkt stehe, aber diesen Use-Case habe ich auch einfach nicht. Mit newsbeuter Urls im Browser öffnen ist auch bescheiden, daher muss ich dort immer klicken. Wenn jemand hierfür eine Lösung hat, immer her damit.

OpenBSD Server

Der Normal-Nerd hat natürlich auch Bedürfnisse Dinge zu hosten. Deshalb gibts eine zweite Maschine, die alle meine Dienste bereitstellt die ich so brauche, diverse PHP/MySQL Applikationen für den Eigengebrauch.

OpenBSD, brauche ich jetzt nicht erwähnen, ist dafür momentan so mein liebstes OS. Sicher per default. Die Devs hauen immer wieder allerhand nützliche Sachen wie lustiges Crypto für Ping oder seit neuestem privilege separated file

• Meine privaten git Repos mit gitolite
• der Blog
• Zwei Instanzen von nichtparasoup
• Isso Kommentarsystem
• MongoDB
• und diverse andere Websites

Demnächst kommst vielleicht noch etwas DNS hinzu, was ich dort hoste.

Dinge die mich Nerven gibt es auch hier. Nämlich die fehlende SNI Funktionalität bei httpd, relayd und libTLS. Somit muss ich bisher noch nginx für die Websites nutzen. Aber das ist nur eine Frage der Zeit.

Nachdem ich mein System mit Ubuntu 15.04 (Vivid Vervet) neu aufgesetzt, Banshee nachinstalliert und meine Musikbibliothek frisch importiert hatte, machte der Medienplayer leider ein paar Probleme. Was mir aufgefallen ist…

Problem #1 – Langsamer Start

Das Hauptproblem ist der (gelinde gesagt) langsame Start von Banshee. Es sieht zunächst so aus, als würde das Programm hängen bleiben. Das Fenster wird erst einmal komplett weiß, nach einer Weile dann ganz grau dargestellt. Es sieht so aus, als wäre die UI kaputt.
Tatsächlich ist es bei mir (ca. 115GB Daten) allerdings so, dass im Hintergrund drei Datenbank-Statements mit jeweils rund 20 Sekunden Verarbeitungszeit abgesetzt werden und Banshee sich daher erst nach etwa einer Minute meldet.

Interessant ist, dass Banshee in 15.04 in derselben Version vorliegt, wie noch unter meiner vorigen Installation mit Ubuntu 14.04.02 – nämlich in Version 2.6.2. Ausschlaggebend für die unperformante SQL-Ausführung scheint vielmehr eine Umstellung in SQLite3 zu sein, denn da ist nun anstatt der Version 3.8.2 die Version 3.8.7.4 aktiv.

Das Problem ist schon in verschiedenen Bugreports gemeldet worden, siehe z.B. Bug #1447956 bei Launchpad oder Bug #740879 im Gnome-Bugzilla. Wenn ihr auch betroffen sein solltet, meldet das doch bei Launchpad.

Ob das Problem bei euch genauso zum Tragen kommt, könnt ihr prüfen, indem ihr Banshee im Debug-SQL-Modus startet. Dazu startet ihr Banshee im Terminal folgendermaßen:

banshee --debug-sql >/tmp/dbgsql.log

Nachdem Banshee ansprechbar ist, könnt ihr die geschriebene Protokolldatei /tmp/dbgsql.log auf lang laufende SQLs analysieren. Mit folgendem grep könnt ihr beispielsweise die Zeilennummern herausbekommen, an denen SQL-Statements zu finden sind, die 1000ms und länger gedauert haben:

grep -n "[0-9]\{4,\}ms" /tmp/dbgsql.log

Bei mir sind so dann Statements wie dieses hier zu finden:

DELETE FROM CoreCache WHERE ModelID = 21;
INSERT INTO CoreCache (ModelID, ItemID) SELECT 21, CoreTracks.TrackID
FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks
WHERE CoreTracks.Year IN
(SELECT CoreTracks.Year FROM CoreTracks, CoreCache
WHERE CoreCache.ModelID = 83 AND
CoreCache.ItemID = CoreTracks.TrackID )
ORDER BY Year

Warum das Statement so viel Zeit benötigt, konnte ich leider nicht herausbekommen, zumal es beim Versuch auf der DB-Shell recht flott ausgeführt wurde.

Aus den Bugreports ist zu entnehmen, dass es mit der neuen 2.9er-Version vermutlich gelöst sein sollte – hier wurde ein Hinweis (UNLIKELY) an den Optimizer von SQLite eingebaut. Ich habe es mir aber bislang erspart, die Version zum Test selbst zu kompilieren. Außerdem ist auch jemand der Meinung, dass die Statements an sich nicht optimal aufgebaut sind und daher überarbeitet werden sollten.

Vor dem kompletten Neuimport der Musikbibliothek habe ich übrigens auch den Weg probiert, die Datenbank und die Covers einfach zu kopieren – mit demselben Ergebnis.

Problem #2 – Kein Menü

Das nächste Problem ist, dass Banshee kein Menü darstellt. Man hat über die UI also keinerlei Zugriff auf die Einstellungen oder beispielsweise den Import-Dialog.
Als kleinen Workaround kann man Banshee beim Start einen Parameter mitgeben, der den gewünschten Dialog direkt aufruft.

So öffnet folgender Aufruf z.B. direkt den Konfigurations-Dialog:

banshee --show-preferences

Und dieser hier den Import-Dialog:

banshee --show-import-media

Weitere Hinweise bekommt ihr mit:

banshee --help-ui

Der Fehler tritt übrigens unabhängig davon auf, ob die Menüs in der Titelleiste des Fensters oder in der Menüleiste (siehe Einstellungen → Darstellung in 15.04) dargestellt werden.
Für dieses Problem liegen ebenfalls schon Bugreports vor: siehe Bug #1450897 und Bug #1450197 bei Launchpad.

Problem #3 – Dateien umbenennen Import in Musiksammlung

Schließlich habe ich über diesen Workaround neue Musik in meine Bibliothek importiert. Dabei habe ich (wie hier beschrieben) Banshee so konfiguriert, dass es beim Import die Musikdateien in meinen Musikordner kopiert und dabei laut den Tags einheitlich umbenennt. Leider scheint das Ersetzen nicht so wie gewohnt zu funktionieren. Zumindest der optionale Part mit der CD-Nummer sieht im Ergebnis falsch aus.

Diesen Punkt werde ich mir allerdings erst dann noch einmal genau ansehen, wenn Banshee im aktuellen Ubuntu überhaupt zu gebrauchen ist.
Hoffentlich gibt es bald eine Lösung, denn, wie ich festgestellt habe, komme ich mit Rhythmbox nicht mehr ganz so gut klar…

Ein Beispiel: Ich tippe in ein Terminal apt-get instal icewm. Es müsste install heißen. Also muss ich mit den Pfeiltasten Buchstabe für Buchstabe zurückgehen und das l eintippen. Natürlich geht es besser.

Stattdessen könnte ich Alt+b drücken. Das setzt den Cursor ein Wort zurück. Mein Problem damit ist, dass ich es immer vergesse.

Im Gnome-Terminal auf meinem Laptop funktioniert auch Strg+Pfeiltaste, um wortweise nach links oder rechts zu gehen. Um das in meinem Desktop nachzurüsten, musste ich folgenden Code in die ~/.inputrc einfügen:

"\e[1;5C": forward-word
"\e[1;5D": backward-word

Seitdem funktioniert Strg+Pfeiltaste auch im xfce4-Terminal und im Terminator (via).

Thunderbird 38 wird nicht wie Firefox 38 am 12. Mai erscheinen. Das Thunderbird-Team benötigt weitere Zeit zum Beheben von Fehlern.

Thunderbird 38 wird der nächste große Thunderbird-Release nach Thunderbird 31 sein, entsprechend wichtig ist die Sicherstellung der Qualität. Stellvertretend für das Thunderbird-Team hat Kent James nun angekündigt, dass man Thunderbird 38 um ein paar Wochen verschieben und die neue Version von Mozillas E-Mail-Client nicht gemeinsam mit Firefox 38 am 12. Mai erscheinen wird. Ein definitiver Termin wurde nicht genannt, man geht derzeit aber davon aus, dass Thunderbird 38 um den 26. Mai herum erscheinen wird, was eine Verschiebung von zwei Wochen bedeuten würde.

Derzeit gibt es noch ein paar Fehler, die man vor Veröffentlichung beheben möchte. Außerdem sei die letzte Woche veröffentlichte Betaversion die erste Beta mit dem vollen Funktionsumfang, daher benötige man noch weitere Zeit zum Testen. Bis zur Veröffentlichung der finalen Version von Thunderbird 38 sind weitere Betaversionen geplant.

Mozilla möchte dem unverschlüsselten Web ein Ende setzen und hat entsprechende – langfristige – Pläne angekündigt, neue Webfeatures nur Webseiten mit verschlüsselter Datenübertragung zugänglich zu machen, insbesondere wenn diese Features die Privatsphäre oder Sicherheit tangieren.

Im offiziellen Security Blog hat Mozilla in Person von Firefox Security Lead Richard Barnes angekündigt, die Verbreitung von HTTPS durch Maßnahmen aktiv voranzutreiben zu wollen. Konkret schwebt Mozilla ein Zwei-Phasen-Plan vor, der erstens daraus besteht, einen Zeitpunkt festzulegen, ab welchem neue Webfeatures nur für HTTPS nutzende Webseiten zur Verfügung stehen, und zweitens schrittweise den Zugriff auf bestimmte Browserfunktionen, welche für die Sicherheit oder Privatsphäre der Nutzer relevant sind, für nicht-sichere Webseiten nicht länger zu ermöglichen.

Natürlich sind diese Pläne als langfristige Pläne zu verstehen und nicht als etwas, was sich bereits in den nächsten Wochen bemerkbar machen wird. Mit der Ankündigung sendet Mozilla zumindest ein klares Signal an Webseitenbetreiber und gibt diesen durch die frühe Information Zeit, sich mit dem Thema HTTPS zu befassen. Wahrscheinlich wird es Jahre dauern, ehe bestimmte Dinge, welche heute für HTTP nutzende Webseiten funktionieren, nur noch für HTTPS nutzende Webseiten funktionieren werden. Vor allem geht es in der ersten Phase erst einmal darum, neue Funktionen einzuschränken. Auch ist überhaupt erst noch zu definieren, was neu in diesem Kontext überhaupt bedeutet. So dürfte das Einschränken neuer CSS-Features in der Regel wohl eher wenig Sinn ergeben, anders als die Einschränkung des Zugriffs auf die Hardware, ähnlich wie Webseiten heute bereits beispielsweise auf die Kamera zugreifen können.

Wenn es um die Einschränkung bereits bestehender Features geht, dann wird man vor allem neben dem Sicherheitsgewinn auf der einen Seite die Kompatibilität auf der anderen Seite sehen müssen, so dass sich ein konkreter Zeitplan noch nicht absehen lässt.

Neben dem kompletten Verbieten bestimmter Funktionen für HTTP-Webseiten sind auch kleinere Einschränkungen möglich und werden sogar bereits praktiziert: So erlaubt Firefox auch jetzt schon für nicht-sichere Webseiten keine dauerhafte Erlaubnis für Kamera und Mikrofon.

In einer FAQ-PDF beantwortet Mozilla einige Fragen zu diesem Thema.

Anmerkung: In diesem Artikel wurde der Einfachheit halber HTTPS teilweise stellvertretend für verschlüsselte Verbindungen verwendet. Genau genommen wird es durch HSTS und upgrade-insecure-requests auch bei Umsetzung der Pläne noch möglich sein, das HTTP-URI-Schema zu verwenden und damit Zugriff auf alle Funktionen zu erhalten. In den allermeisten Fällen dürften verschlüsselte Verbindungen allerdings HTTPS bedeuten.

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument¹, dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon.

Es gibt Benutzer für die ist Linux gleich irgendeine bestimmte Distribution, der sie nie den Rücken kehren wollen oder gekehrt haben. Für mich ist die große Menge an Linux-Distributionen vor allem ein unerschöpflicher Pool an Möglichkeiten. Keine Distribution erfüllt meine Anforderungen auf jedem Gerät gleich gut, weshalb ich einfach viele parallel einsetze. Kubuntu schätzte ich lange wegen der besonders starken Fokussierung auf KDE, man lieferte sogar rekonq anstelle von Firefox aus. Die aktuelle LTS läuft wegen manigfaltiger Kritik jedoch nur in einer VM. An Debian schätze ich die Stabilität, so etwas benötigt man für Geräte, die man nur selten benutzt bzw. deren Wartungsaufwand man minimieren möchte. Es hat deshalb seinen Weg auf mein neues Subnotebook gefunden.

Mit openSUSE hat mein Linuxweg vor vielen Jahren begonnen. Ich gehöre allerdings nicht zu den Veteranen, die rund um das Millenium von SuSE 7.x zur Verzweiflung getrieben wurden. Meine erste richtige Berührung mit Linux bestand in der Installation von openSUSE 10.3. Somit bekam ich immerhin noch das letzte zucken der langsamsten Paketverwaltung aller Zeiten mit. OpenSUSE 11.0 war mit einige Zeit ein treuer Begleiter. Aber man soll die Vergangenheit ruhen lassen. Wer mal eine solche Installation in einer VM startet, dem vergehen schnell die rosigen Erinnerungen an vermeintlich goldene KDE 3.5-Zeiten. Der weitere Verlauf war ziemlich holprig. KDE in den jungen 4er Versionen eine Zumutung und so blieb Debian Lenny die letzte Heimstatt von KDE 3.5.

Im vergangenen November hat mich allerdings openSUSE 13.2 wieder richtig überzeugt. Es war genau die richtige Mischung aus Innovation und Bewährtem. Einerseits setzte man auf Btrf und XFS als Dateisysteme, andererseits bot man ein ausgereiftes KDE SC 4. Der Support des letzteres durch die openSUSE-Entwickler beeindruckt übrigens immer wieder. Konsequent aktualisierte man die ursprünglich in Version 4.14.3 ausgelieferten KDE-Pakete bis zur Version 14.12.3. Die zur LTS Version erklärten KDE-Workspaces und KDE-PIM erhalten demnächst noch die Aktualisierung auf 4.11.18 bzw. 4.14.7. Von derart konsequenten Fehlerbehebungen kann man bei Kubuntu und Debian nur träumen.

OpenSUSE hatte allerdings schon im Vorfeld des Releases von 13.2 Schwierigkeiten in der Organisationsstruktur. OpenSUSE 13.2 wurde deshalb vom Sommer auf den Herbst verschoben. Über die Hintergründe gibt es zwei verschiedene Versionen. Die einen behaupten, dass die Mitarbeit der Community an openSUSE mehr und mehr eingebrochen ist, weshalb immer mehr bei den Angestellten von SUSE hängen bleibt. Stephan Kulow, der lange Zeit Release-Manager von openSUSE war, sprach hingegen von zu viel Erfolg. Im speziellen würden zu viel Sourcecode aus unterschiedlichen Quellen openSUSE erreichen. Wenig thematisiert, aber nicht grundsätzlich bedeutungslos dürften auch die wechselnden Eigentümerverhältnisse der Mutterdistribution "SUSE Enterprise Linux" sein.¹ OpenSUSE war schließlich nie so unabhängig von den dortigen Entwicklungen wie Fedora von RedHat.

Wie die Ursachen auch ausgesehen haben, die Antwort war in jedem Fall ein höherer Grad an Automatisierung. Diese sollte durch automatisierte Tests im Rahmen von openQA und ein verstärkter Rückgriff auf das OBS-System erfolgen. Möglicherweise liegen hier auch die Ursachen für die, im Gegensatz zu anderen Distributionen, wirklich konsequenten Rückportierungen von Fehlerbehebungen. Wie dem auch sei: Aus reiner Anwendersicht war die Entwicklung erfolgreich. OpenSUSE 13.2 ist subjektiv betrachtet der beste Release, seit 11.0. Interessanterweise fallen beide Release in eine Übergangsphase von KDE, aber das nur am Rande. Eine weitere Veränderung betraf den Rolling Release-Zweig von openSUSE, genannt "Tumbleweed". Dieser wurde mit dem bisherigen Factory-Zweig fusioniert, mit dem Ziel ähnlich wie bei Debian eine funktionsfähige Testing-Version für openSUSE zu haben.²

Um den eigentlich Stablezweig wurde es jedoch sehr ruhig. Ein erste Milestone für die nächste Version steht ebenso aus, wie eine Roadmap oder dergleichen. Im Hintergrund wird wohl immer noch über Releasezyklen - gerüchtweise stehen 8 oder 12 Monate im Raum - und grundlegende Strukturen gerungen. Hinzu kommt, dass der Quellcode für SUSE Linux Enterprise auf das OBS überführt wird. Möglicherweise besteht die nächste Version aus einer Hybridversion von SLES/D und Factory. Schon Version 13.2 war bei wichtigen Grundsatzentscheidungen wie den Dateisystemen oder dem neuen Netzwerktool "wicked" nah bei SLES/D 12.

Es bleibt zu hoffen, dass sich openSUSE fängt und einen positiven Weg einschlagen kann. OpenSUSE hat immer einen etwas anderen Weg eingeschlagen, als der Debian/Ubuntu Mainstream, sowie die RedHat/Fedora/GNOME-Richtung.³

Quellen:

1: Heise open - SUSE und openSUSE: Keine Änderungen trotz Übernahme von Attachmate

2. Linux-Magazin - FOSDEM 2015: SLES Quellcode kommt in OBS, Factory ersetzt Tumbleweed

3. Linux-Magazin - OSC 13

Es gibt Benutzer für die ist Linux gleich irgendeine bestimmte Distribution, der sie nie den Rücken kehren wollen oder gekehrt haben. Für mich ist die große Menge an Linux-Distributionen vor allem ein unerschöpflicher Pool an Möglichkeiten. Keine Distribution erfüllt meine Anforderungen auf jedem Gerät gleich gut, weshalb ich einfach viele parallel einsetze. Kubuntu schätzte ich lange wegen der besonders starken Fokussierung auf KDE, man lieferte sogar rekonq anstelle von Firefox aus. Die aktuelle LTS läuft wegen manigfaltiger Kritik jedoch nur in einer VM. An Debian schätze ich die Stabilität, so etwas benötigt man für Geräte, die man nur selten benutzt bzw. deren Wartungsaufwand man minimieren möchte. Es hat deshalb seinen Weg auf mein neues Subnotebook gefunden.

Mit openSUSE hat mein Linuxweg vor vielen Jahren begonnen. Ich gehöre allerdings nicht zu den Veteranen, die rund um das Millenium von SuSE 7.x zur Verzweiflung getrieben wurden. Meine erste richtige Berührung mit Linux bestand in der Installation von openSUSE 10.3. Somit bekam ich immerhin noch das letzte zucken der langsamsten Paketverwaltung aller Zeiten mit. OpenSUSE 11.0 war mit einige Zeit ein treuer Begleiter. Aber man soll die Vergangenheit ruhen lassen. Wer mal eine solche Installation in einer VM startet, dem vergehen schnell die rosigen Erinnerungen an vermeintlich goldene KDE 3.5-Zeiten. Der weitere Verlauf war ziemlich holprig. KDE in den jungen 4er Versionen eine Zumutung und so blieb Debian Lenny die letzte Heimstatt von KDE 3.5.

Im vergangenen November hat mich allerdings openSUSE 13.2 wieder richtig überzeugt. Es war genau die richtige Mischung aus Innovation und Bewährtem. Einerseits setzte man auf Btrf und XFS als Dateisysteme, andererseits bot man ein ausgereiftes KDE SC 4. Der Support des letzteres durch die openSUSE-Entwickler beeindruckt übrigens immer wieder. Konsequent aktualisierte man die ursprünglich in Version 4.14.3 ausgelieferten KDE-Pakete bis zur Version 14.12.3. Die zur LTS Version erklärten KDE-Workspaces und KDE-PIM erhalten demnächst noch die Aktualisierung auf 4.11.18 bzw. 4.14.7. Von derart konsequenten Fehlerbehebungen kann man bei Kubuntu und Debian nur träumen.

OpenSUSE hatte allerdings schon im Vorfeld des Releases von 13.2 Schwierigkeiten in der Organisationsstruktur. OpenSUSE 13.2 wurde deshalb vom Sommer auf den Herbst verschoben. Über die Hintergründe gibt es zwei verschiedene Versionen. Die einen behaupten, dass die Mitarbeit der Community an openSUSE mehr und mehr eingebrochen ist, weshalb immer mehr bei den Angestellten von SUSE hängen bleibt. Stephan Kulow, der lange Zeit Release-Manager von openSUSE war, sprach hingegen von zu viel Erfolg. Im speziellen würden zu viel Sourcecode aus unterschiedlichen Quellen openSUSE erreichen. Wenig thematisiert, aber nicht grundsätzlich bedeutungslos dürften auch die wechselnden Eigentümerverhältnisse der Mutterdistribution "SUSE Enterprise Linux" sein.¹ OpenSUSE war schließlich nie so unabhängig von den dortigen Entwicklungen wie Fedora von RedHat.

Wie die Ursachen auch ausgesehen haben, die Antwort war in jedem Fall ein höherer Grad an Automatisierung. Diese sollte durch automatisierte Tests im Rahmen von openQA und ein verstärkter Rückgriff auf das OBS-System erfolgen. Möglicherweise liegen hier auch die Ursachen für die, im Gegensatz zu anderen Distributionen, wirklich konsequenten Rückportierungen von Fehlerbehebungen. Wie dem auch sei: Aus reiner Anwendersicht war die Entwicklung erfolgreich. OpenSUSE 13.2 ist subjektiv betrachtet der beste Release, seit 11.0. Interessanterweise fallen beide Release in eine Übergangsphase von KDE, aber das nur am Rande. Eine weitere Veränderung betraf den Rolling Release-Zweig von openSUSE, genannt "Tumbleweed". Dieser wurde mit dem bisherigen Factory-Zweig fusioniert, mit dem Ziel ähnlich wie bei Debian eine funktionsfähige Testing-Version für openSUSE zu haben.²

Um den eigentlich Stablezweig wurde es jedoch sehr ruhig. Ein erste Milestone für die nächste Version steht ebenso aus, wie eine Roadmap oder dergleichen. Im Hintergrund wird wohl immer noch über Releasezyklen - gerüchtweise stehen 8 oder 12 Monate im Raum - und grundlegende Strukturen gerungen. Hinzu kommt, dass der Quellcode für SUSE Linux Enterprise auf das OBS überführt wird. Möglicherweise besteht die nächste Version aus einer Hybridversion von SLES/D und Factory. Schon Version 13.2 war bei wichtigen Grundsatzentscheidungen wie den Dateisystemen oder dem neuen Netzwerktool "wicked" nah bei SLES/D 12.

Es bleibt zu hoffen, dass sich openSUSE fängt und einen positiven Weg einschlagen kann. OpenSUSE hat immer einen etwas anderen Weg eingeschlagen, als der Debian/Ubuntu Mainstream, sowie die RedHat/Fedora/GNOME-Richtung.³

Quellen:

1: Heise open - SUSE und openSUSE: Keine Änderungen trotz Übernahme von Attachmate

2. Linux-Magazin - FOSDEM 2015: SLES Quellcode kommt in OBS, Factory ersetzt Tumbleweed

3. Linux-Magazin - OSC 13

In der Diskussion zur Ankündigung eines neuen Release der Community Enterprise Distribution CentOS fragt ein Benutzer, welche Distribution die bessere Wahl für den Desktop wäre: CentOS oder Debian. Die Antwort in einem Beitrag lautet: Arch-Linux. So nachzulesen bei Heise Online. Das Ergebnis dieses netten Dialogs ist weniger, dass Arch-Linux sich wirklich gut als Langzeitdistribution eignet, sondern vielmehr, dass die unterschiedlichen Distributionsmodelle sich in den letzten Jahren weit voneinander entfernt haben. So weit, dass Nutzer des einen Modells die Anforderungen der Benutzer des anderen Modells kaum noch nachzollziehen können. Waren vor wenigen Jahren noch stabile Veröffentlichungen alle paar Monate üblich, gibt es heute Distributionen mit Laufzeiten von 10 Jahren auf der eine Seite und Rolling Release-Modell ohne offizielle Installationsroutine auf der anderen.

Während im Serverbereich Distributionen mit einer Supportdauer von mehreren Jahren weitverbreitet sind und eine hohe Akzeptanz genießen, wurden solche Distributionen für den Desktop lange Zeit nicht empfohlen. Zu alt sei die Hardwareunterstützung, zu veraltete Desktopumgebung und Programme. Diese Einstellung hat sich in den letzten Jahren deutlich verändert.

 Im Wesentlichen gibt es zur Zeit drei Releasemodelle für Distributionen:

1. Der "klassische" Release: Ein neuer Release erfolgt alle paar Monate (6-12), die Distribution wird für einen bestimmten - in Monaten gemessenen - Zeitraum unterstützt.
2. Der Langzeitsupport (LTS) Release: Ein neuer Release erfolgt alle paar Jahre, die Distribution wird für einen bestimmten - in Jahren gemessenen - Zeitraum unterstützt.
3. Das Rolling Release Modell: Kernel, Bibliotheken und Programme werden laufend aktualisiert. Ggf. werden Snapshots zur Installation zur Verfügung gestellt.

Anhänger des letzteren Distributionsmodels sind der Ansicht, dass ihnen diese Form langfristig weniger Arbeit bereitet. Größere Distributionsupgrades bleiben schließlich auf diese Weise aus. Der Ansatz vieler einfacher (und fortgeschrittener) Nutzer, dass jedes Update nervig ist und keine neue Version für diesen Aufwand mit äquivalenten Funktionen entschädigt, können sie nicht nachvollziehen. Die Tendenz in der Linuxwelt geht dennoch in die andere Richtung. Distributionen mit sehr langen Laufzeiten gibt es immer mehr und ihre Bedeutung - gemessen an der Nutzerzahl und medialer Aufmerksamkeit - steigt an. Im folgenden sollen deshalb einige präsentiert werden.

[message_box title="Langzeit-Distribution" type="info" close="no"]Der Begriff Langzeitdistribution ist nicht genau definiert. In der Regel werden darunter Distributionen mit einem Supportzeitraum von mehreren Jahren verstanden. Während openSUSE mit 18 Monaten Support herkömmlicherweise nicht als Langzeitdistribution gesehen wird, ist Debian mit ca. 3 Jahren Unterstützung klassischerweise unter den Langzeitdistribution eingeordnet. Das Auswahlkriterium dieses Beitrags sind deshalb 3 Jahre Unterstützung oder länger.[/message_box]

Inhalt

1. Debian
2. Ubuntu
3. RHEL/CentOS/Scientific Linux
4. SUSE Linux Enterprise Desktop
5. openSUSE Evergreen
6. Übersichtstabelle
7. Fazit

Bild: „Debian Jessie mit GNOME“ von Debian Project Lizenziert unter GPL1. Debian

Debian ist vielleicht "die" Long-Term-Support Distribution schlechthin. Abgesehen vom Unstable- und Testingzweig gibt es keine anderen Veröffentlichungen des Debian Projekts. Debian veröffentlicht nach keinem festen Zeitplan, bringt aber in der Regel alle zwei Jahre eine neue Version heraus. Diese wird bis zum erscheinen der nächsten Version unterstützt, plus weitere 12 Monate. Im vergangenen Jahr wurde zudem eine Verlängerung der Supportperiode eingeführt. Diese testweise für Debian 6.0 Squeeze eingerichtete LTS Version wird durch interessierte Firmen finanziert und beschränkt sich auf einen limitierten Paketumfang. Sofern das Projekt erfolgreich ist werden LTS-Versionen für Debian 7.0 und 8.0 folgen.

Vorteile von Debian:

1. Der Support erstreckt sich auf alle in den Paketen verfügbaren Programme.
2. Die Paketquellen decken fast das ganze Repertoire der freien Software ab.
3. Die Richtlinien sind sehr strikt. Es werden keine neuen Versionen in eine stabile Version eingepflegt.
4. In regelmäßigen Abständen werden neue Installationsmedien als Unterversionen (z.B. 7.x für Wheezy) herausgegeben. Neuinstallation werden dadurch viele Aktualisierungen erspart.
5. Über die offizielle Backportquelle lassen sich für viele Programme aktuellere Versionen einspielen. Diese entstammen dem aktuellen Testingzweig.
6. Distributionsupgrades zwischen den Versionen sind möglich.

Nachteile von Debian:

1. Der Supportzeitraum mit lediglich ca. 3 Jahren Support ist verhältnismäßig gering.
2. Neue Versionen erscheinen regelmäßig, sind aber nicht exakt planbar.
3. Gegen Ende des Supportzeitraumes kann die Unterstützung für einzelne Pakete eingestellt werden. Dies wird jedoch nicht klar kommuniziert.

Homepage: Debian | Deutsche Community: Debianforum

Screenshot Ubuntu 14.042. Ubuntu und die offiziellen Derivate

Ubuntu ist die möglicherweise am weitesten verbreitete Linux-Distribution und den meisten ein Begriff. Die Entscheidung LTS-Versionen einzuführen traf man bereits sehr früh in der Entwicklungsgeschichte von Ubuntu mit dem Release von Dapper Drake im Jahr 2006. Ursprünglich galt der Support für den Desktop nur drei Jahre, während die Serverpakete 5 Jahre unterstützt wurden. Diese Trennung wurde mit dem Release von 12.04 aufgehoben, seitdem werden Desktop- und Serverversion 5 Jahre unterstützt. Die Community-Derivate Kubuntu, Xubuntu, Lubuntu, Ubuntu GNOME und Ubuntu MATE bringen jeweils eigene LTS-Versionen heraus. Diese haben allerdings nur eine Laufzeit von 3 Jahren, mit Ausnahme von Kubuntu, das ebenfalls 5 Jahre unterstützt wird. Alle zwei Jahre erscheint im April eine neue LTS Version, dazwischen veröffentlichen die Ubuntu-Entwickler alle 6 Monate STS Versionen, die als Vorschau für interessiere Nutzer gedacht sind.

Die Ubuntu-Paketquellen sind in die Bereich main, universe und multiverse eingeteilt. In main liegen die offiziell von Canonical (der Firma hinter Ubuntu) betreuten Pakete, in universe die von der Community gepflegten Programme. Letztere kommen teilweise während des Entwicklungsprozesses durch einen Synchronisationsvorgang aus dem Debian Testing- oder Unstablezweig. Zu den Paketquellen siehe auch diesen Blogbeitrag.

Vorteile von Ubuntu:

1. Der Support wird für 5 Jahre garantiert.
2. Alle zwei Jahre erscheint planbar eine neue LTS Version
3. In regelmäßigen Abständen werden s.g. Pointreleases (z.B. 14.04.2) mit aktualisierter Hardwareunterstützung (Kernel und Grafikstack) veröffentlicht.
4. Über die Personal-Package-Archive (PPA) können aktualisierte Softwarepakete eingespielt werden.
5. Distributionsupgrades von einer LTS Version auf die folgende sind möglich.

Nachteile von Ubuntu:

1. Der LTS-Support wird lediglich für die Pakete in main garantiert. Die Pakete in universe können Unterstützung erhalten, dies wird aber nicht definitiv zugesichert.
2. Die Unity-Oberfläche hat Vorrang. Problemeder anderen Desktopoberflächen - sei es im Releasemangement oder während der Supportzeit - werden nachrangig behandelt.
3. Bei vielen eingebundenen PPA's können Upgrade zwischen den LTS-Versionen scheitern

Homepage: Ubuntu | Deutsche Community: ubuntuusers

„Screenshot RHEL 7 GNOME" von Strikerttd. Lizenziert unter CC BY-SA 3.03. Red Hat Enterprise Linux / CentOS / Scientific Linux

RedHat Enteprise Linux (RHEL) und die beiden, aus dessen Quellen gebauten, Community-Varianten CentOS und Scientific Linux stehen zur Zeit an der Spitze der LTS-Versionen - zumindest was die Supportdauer betrifft. Jede Version von RHEL und des auf Binärkompatibilität ausgelegten Ablegers CentOS durchläuft verschiedene Lebenszyklen, wird letztlich aber fast 10 Jahre mit Sicherheitsaktualisierungen versorgt.

Im Vergleich zu Debian oder Ubuntu haben RHEL und seine Ableger allerdings nur ein relativ eingeschränktes Paketangebot. Mit GNOME gibt es lediglich einen unterstützten Desktop und auch die restliche Software für den Desktopeinsatz ist stark auf Büroarbeitsplätze ausgerichtet. Zwar können die bestehenden Lücken durch externe Quellen kompensiert werden, dies läuft allerdings grundsätzlich dem LTS-Gedanken zuwider.

In relativ regelmäßigen Abständen bringt RedHat eine neue Minorversion (z.B. 7.1) der Distribution heraus. Bei dieser wird zwar der - extrem stark modifizierte - Kernel stabil gehalten, aber viele Softwarepakete bis hin zu X.Org aktualisiert. Dadurch funktioniert auch neuere Hardware noch mit einer vergleichsweise alten Distribution wie z.B: RHEL 6, das ursprünglich 2010 erschien und noch bis 2020 unterstützt wird.

Vorteile von RHEL und seinen Ablegern:

1. Extrem lang Supportdauer von bis zu 10 Jahren
2. Regelmäßige Minor-Releases passen die Version an aktuelle Hardware an.
3. RedHat pflegt die vorhandenen, nicht besonders zahlreichen, Pakete intensiv über die gesamte Lebensdauer.

Nachteile von RHEL und seinen Ablegern:

1. Das Softwareangebot ist sehr beschränkt.
2. Die Softwareversionen sind im eigentlichen Sinne nicht stabil, da mit jedem Minorrelease viele Programmversionen angehoben werden. (Kernel und Desktop ausgenommen)
3. Es sind keine Distributionsupgrades zwischen den Hauptversionen (6->7) möglich.

Homepage(s): RHEL / CentOS / Scientific Linux | Deutsche Community: N/A

4. SUSE Linux Enterprise Desktop

Der SUSE Linux Enterprise Desktop (SLED) ist das Gegenstück der traditionsreichen Firma SUSE auf Nürnberg zu RedHats RHEL. Im Gegensatz zu diesem gibt es aber keinen Community-Ableger und somit auch keine kostenfreie Version. Die genaue Supportdauer variiert innerhalb der Produktfamilie etwas, beläuft sich aber ebenfalls auf ca. 10 Jahre.

Vor einigen Jahren galt SUSE Linux noch als die KDE-Distribution, auch im Enterprise-Bereich. Diese Phase ist jedoch Geschichte und mit der gegenwärtigen Version 12 liefert die SUSE nur noch ein angepasstes GNOME 3 aus.

Die Version wurde bisher um s.g. "Service Packs" ergänzt, wie man sie aus der Windows-Welt kannte. Mit Version 12 wurden nun "Module" eingeführt, z.B. das Web and Scripting Module mit PHP, Python und Ruby on Rails. Die Laufzeit für diese einzelnen Module beträgt lediglich 1-3 Jahre, danach muss auf eine neue Modulversion aktualisiert werden. Dadurch ist es gerade im Serverbereich möglich wichtige Basistechnologien aktuell zu halten, die Distribution ist im eigentlichen sinne jedoch nicht mehr stabil, da sich die Versionen während der Lebenszeit ändern.

Vorteile von SLED:

1. Extrem lange Supportdauer
2. YaST
3. Durch Module bzw. bis Version 11 Service Packs können wichtige Pakete verhältnismäßig aktuell gehalten werden.

Nachteile von SLED:

1. Im eigentlichen Sinne keine stabile Distribution mehr.
2. Undurchsichtige Supportdauer
3. Keine planbaren Releasezyklen
4. Kein freier Community-Ableger

Homepage: SUSE Linux | Deutsche Community: N/A

Screenshot openSUSE 13.25. openSUSE Evergreen

OpenSUSE ist die freie Community-Version von SUSE, allerdings nicht binärkompatibel zu SLED. Die Distribution bildet ähnlich wie Fedora lediglich die Basis für die Enterprise Version. OpenSUSE hat traditionell recht lange Supportzeiträumen für eine reguläre Distribution. Die openSUSE-Community pflegt immer den aktuellen, plus den vorangegangenen Release. Bei der Veröffentlichung einer neuen Version wird die nun obsolete vorvorletzte Version noch zwei Monate gepflegt um den Nutzern den Übergang zu ermöglichen. Durch die seit einigen Jahren immer ausgedehnteren Zeiträume zwischen zwei Versionen kommen hier beachtliche Supportzeiträume zustande. OpenSUSE 13.1 wurde beispielsweise im November 2013 veröffentlicht und wird bis dato gepflegt, da Version 13.3 noch nicht angekündigt ist.

Aufgrund des fehlenden kostenlosen Ablegers der Enteprise-Distribution SLED gibt es das Community Projekt Evergreen für openSUSE, das den Supportzeitraum von openSUSE über das eigentliche Ende hinaus verlängert. Das Projekt wird maßgeblich gestützt durch Personen, die openSUSE beruflich einsetzen und in dieser Funktion abgekündigte Versionen pflegen. Durch das Projekt wird z.B. die Version 13.1 planmäßig bis 2016 unterstützt und erreicht damit dieselbe Supportdauer wie z.B. Debian.

Vorteile von openSUSE Evergreen:

1. Relativ umfangreiche Paketquellen
2. YaST
3. Paketversionen werden i.d.R. stabil gehlten

Nachteile von openSUSE Evergreen:

1. Supportzeitraum relativ kurz.
2. Genauer Umfang des Evergreen-Supports unklar
3. Distributionsupgrades nicht garantiert

Homepage: openSUSE | Deutsche Community: Linux Club

6. Übersichtstabelle

7. Fazit

Jede hier genannte Distribution hat Vor- und Nachteile. Welche Distribution sich am besten eignet hängt von vielen Faktoren ab. Die gewünschte Desktopumgebung (sofern ein Desktopeinsatz angestrebt wird), das Paketformat, der Unterstützungszeitraum und die Anzahl mitgelieferter Pakete können hier herangezogen werden. Dieser Artikel dient einer Übersicht über die verschiedenen Möglichkeiten, weil oftmals die Enterprise-Distributionen fälschlicherweise als untauglich für den Desktopeinsatz abgestempelt werden.

Aktualisierungen:

18.05.2015: Screenshots aktualisiert und Fehler ausgebessert.

25.05.2015: Bildbeschreibungen als Bildunterschriften eingefügt.

Der Wochenrückblick lässt das Geschehen der vergangenen Woche rund um Ubuntu, Linux und Open Source Revue passieren. Einige News sind schon etwas älter, da ich die vorhergehende Woche keine Zeit hatte.

Rund um Ubuntu

Ubuntu Online Summit vom 5.-7. Mai

Vom 5. bis 7. Mai findet der nächste Ubuntu Online Summit statt, bei dem u.a. die Entwicklung für Ubuntu 15.10 geplant wird. Tracks sind unter anderem Apps&Scopes, Cloud, Community, Convergence, Core und Show&Tell. Es fällt auf, dass es für die reine Ubuntu-Desktop-Entwicklung keinen Track mehr gibt.

Mehr Informationen gibt es im Ikhaya-Artikel.

Weitere Quellen: Ubuntu Insights

Unterstützung für Ubuntu 10.04 endete

Wie bereits Mitte März angekündigt wurde, endete am 30. April 2015 der Unterstützungszeitraum für Ubuntu 10.04 LTS. Benutzern dieser Version wird geraten, auf eine aktuelle LTS-Version wie Ubuntu 14.04 LTS zu aktualisieren, da 10.04 nicht mehr mit Sicherheitsupdates versorgt wird.

Mehr Informationen gibt es im Ikhaya-Artikel.

Ubuntu 15.04 veröffentlicht

Bereits vor anderthalb Wochen ist Ubuntu 15.04 „Vivid Vervet“ erschienen. Es handelt sich dabei um eine STS-Version, die nur neun Monate mit Sicherheitsupdates versorgt wird. Der Einsatz empfiehlt sich also nur für Nutzer, die bereits mit Ubuntu 15.10 wieder aktualisieren wollen.

Mehr Informationen gibt es im Ikhaya-Artikel.

Weitere Quellen: Pro-Linux, heise open, Linux Magazin

Ubuntu Desktop Next mit neuem Paketformat

Die nächste Ubuntu-Desktop-Next-Version (bereits heute mit Unity 8 und Displayserver Mir) soll ab der nächsten Version auf Snappy Personal basieren und damit das neue Paketformat nutzen, welches inkrementelle Updates und Rollbacks unterstützt. Daneben enthält das Paket alle notwendigen Daten, um Abhängigkeiten zu anderen Bibliotheken zu vermeiden.

Quellen: Pro-Linux, heise open, Golem, Linux Magazin

Neues rund um Linux

Debian 8 Jessie veröffentlicht

Das neueste Stable-Release von Debian hört auf den Namen „Jessie“. Besonderheit ist, dass systemd als Standard-Init-Dienst benutzt wird. Als Kernel wird Version 3.16 eingesetzt.

Mehr Informationen gibt es im Ikhaya-Artikel.

Weitere Quellen: heise open, Pro-Linux, Linux Magazin

Microsoft: Visual Studio Code für Linux

Nicht zu verwechseln mit Visual Studio, hat Microsoft letzte Woche den Editor Visual Studio Code für die Plattformen Windows, MacOS X und auch Linux veröffentlicht. Es handelt sich dabei nicht um eine komplette IDE, aber um ein Entwicklerwerkzeug mit Texteditor, Projektverwaltung, Syntax-Highlighting und Git-Anbindung. Visual Studio Code ist dabei kostenlos erhältlich, aber nicht Open Source.

Quelle: heise open

Full Circle Magazine #96 erschienen

Vorletzte Woche ist die neue Ausgabe des englischsprachigen Magazins Full Circle Magazine erschienen. Themen der 96. Ausgabe sind unter anderem Tutorials zu Python, LibreOffice, LaTeX, Inkscape, JavaScript und Arduino sowie Artikel zu verschlüsselter Datensicherung, Chromebook, Owncloud, dem Spiel Cities: Skylines und ein Review zum Dell Precicision m3800 DE.

Quelle: Full Circle Magazine Blog

Spielen unter Linux

The Banner Saga für Linux

Entwicklerstudio Stoic hat „The Banner Saga“ für Linux freigegeben, nachdem es bereits letztes Jahr für Windows und MacOS X erschienen ist. Das Rollenspiel hat dabei auch einen rundenstrategiebasierenden Teil. Erhältlich ist das Spiel bei so gut wie allen bekannten Spiele-Vertreibern für die Steam-Plattform, aber auch DRM-frei.

Quellen: Pro-Linux, Games4Linux

Age of Wonders III veröffentlicht

Bereits vor einigen Monaten angekündigt, hat Triumph Studios das Strategiespiel Age of Wonders III“ samt der Erweiterung „Eternal Lords“ für Linux veröffentlicht. Erhältlich ist das Spiel über Steam.

Quelle: Games4Linux

Broken Age Teil 2 fertig gestellt

Das von Tim Schäfer entwickelte Adventure „Broken Age“ ist mit Teil 2 nun komplett fertig entwickelt und kann als ganzes Werk durchgespielt werden. Teil 1 spielte sich bereits sehr gut und wartete mit einem Cliffhanger auf, der in Teil 2 sicherlich aufgelöst wird.

Quelle: Games4Linux

In der Logdatei meines Raspberry Pi tauchen nach jedem Start die Fehlermeldungen “EXT4-fs (mmcblk0p2): couldn’t mount as ext3 due to feature incompatibilitie” und “EXT4-fs (mmcblk0p2): couldn’t mount as ext2 due to feature incompatibilities” auf. Es funktioniert zwar alles aber es nervt. Vor allem weil mmcblk0p2 in dem Fall ext4 und nicht ext3 oder ext2 nutzt. Aber die Lösung ist recht einfach.

Einfach die Datei /boot/cmdline.txt öffnen und rootfstype=ext4 hinzufügen und abspeichern. Nach einem Neustart ist die Fehlermeldung verschwunden. Nebenwirkungen konnte ich auch noch keine feststellen.

Shitstorms als Internetphänomen sind seit einiger Zeit in aller Munde. Man könnte manchmal glauben, die Open Source Community hätte sie erfunden. Der Umgangston in den Foren und auf den Maillinglisten ist manchmal hart und liebevoll gepflegte Vorurteile und Mythen sind eine beliebte Argumentationshilfe. Diese sind zum Teil gegen andere Ökosysteme gerichtet, aber richtig schön wird die Debatte erst wenn es zu den internen Grabenkämpfen kommt. Bevor systemd die Aufmerksamkeit auf sich zog, war es meist die präferierte Desktopumgebung, die zuverlässig einen längeren Flame-War auslöste.

Die Desktop-Entwicklungen

Anfangs waren diese Debatten noch einfach. GNOME oder KDE, das war die Grundsatzfrage. Die IceWM Nutzer beteiligten sich schließlich kaum, sie wussten zu jeder Zeit, dass sie den Königsweg befolgten. Diese vergleichsweise übersichtliche Konfrontationslage wurde ca. 2008 aufgebrochen. Nun ging es auch um die Frage modern oder alt und bewährt bzw. anders gesagt: KDE 4 oder KDE 3.5. GNOME-Nutzer priesen da noch ihr evolutionäres Entwicklungsmodell.

Offizielles Releasebild KDE; Lizenz: GPL

Spätestens mit dem Release von GNOME 3 im Jahr 2011 brachen die alten Konfrontationsgräben vollständig auf. GNOME 3 schockierte viele GNOME-Nutzer durch sein vollkommen neues Bedienkonzept. Mit dem Release von Ubuntu 11.04 wechselte Canonical auf Unity, Linux Mint schickte im gleichen Jahr Cinnamon ins Rennen. Beide nutzen den GNOME 3-Unterbau, allerdings unter den Prämissen eines eigenen Bedienkonzepts. Auf die Spitze getrieben wurde diese Tendenz durch MATE - ein direkter Fork von GNOME 2 auf dem Höhepunkt seiner Entwicklung. Wie die anderen Abspaltungen vom GNOME-Projekt entstand MATE 2011. Während Unity und Cinnamon alleine durch die Verbreitung ihrer Distributionen Ubuntu und Mint eine verhältnismäßig sichere Existenz garantiert wurde, zeigte sich bei MATE das Linux-Community-Element. Anfangs verspottet und auf einem Niveau mit dem Trinity Desktop gesehen, machte sich MATE zu einem Siegeszug auf, in dessen Folge der Desktop in Fedora, openSUSE 13.2, Debian 7.0 (Backports) und nun auch in Ubuntu 15.04 Einzug hielt.

Ubuntu MATE 15.04 mit Plank Dock

Die Diskussionen wurden durch diese Entwicklung zunehmend unübersichtlich. Vereinfacht gesagt: Anwender moderner Desktopkonzepte wie GNOME 3 und KDE SC 4 gegen die konservativen Nutzer, sowie alle gegen GNOME 3. Hauptargument bei den Nutzern von LXDE, MATE und Xfce: Die Entwickler haben die Nutzer vergessen und entwickeln nur noch für sich. Die Nutzer wollen keine Veränderungen, sondern das Windows 95-Prinzip.

Der Debian Popularity Contest

Mit diesem Thema wurde sich bereits im ersten Teil der Artikel-Miniserie befasst. Im Kommentar wurde nun darauf hingewiesen, dass nur ein Vergleich über einen größeren Zeitraum wirklich aussagekräftig wäre. Vollkommen richtig! Problematisch bleibt die Datengrundlage. Lediglich Ubuntu und Debian erfassen (freiwillig) die installierten Pakete der Nutzer. Einen Vergleich über einen längeren Zeitraum erlaubt leider nur die Debian-Popcon Seite (sollte dem anders sein, bitte im Kommentarfeld schreiben). Debian ist nicht präsentativ, aber es ist eine der größten Distributionen und hat neben Arch Linux und Gentoo potenziell die erfahrensten Nutzer. Wenn eine Benutzer-Community nicht die vorgekauten Konfigurationen schluckt, die ihnen von den Maintainern vorgegeben werden, dann ist sie bei diesen Projekten zu finden.

Dabei darf natürlich nicht verschwiegen werden, dass Debian GNOME als Standarddesktop ausliefert, aber nur deshalb die mangelnde Verbreitung anderer Desktops zu begründen ist weder bewiesen, noch wahrscheinlich. Vor allem nicht hinsichtlich der Debian-Zielgruppe. Im Grunde genommen ist das nur eine Abwandlung des Linux vs. Windows-Arguments.

Die Erhebung der Daten ist etwas kompliziert, da es keine einheitlich benannten Kernpakete gibt, die über alle Desktopgrenzen hinweg ihre Gültigkeit hätten. Für GNOME, Xfce, MATE und LXDE gibt es s.g. session-Pakete, ohne die der Desktop nicht funktioniert. Bei KDE ist aufgrund der permanenten Umbenennungen seitens der Entwickler und Debian-Maintainer kein solches Session-Paket über viele Jahre verfügbar. Hier muss auf den Loginmanager KDM zurückgegriffen werden. Ein Vergleich mit dem aktuell substanziellen kde-baseapps-bin Paket ergibt aber, dass damit fast alle KDE-Installation erfasst werden können.

Fazit

Seit Etablierung der session-Pakete 2007/2008 hat es über die Veröffentlichungen von GNOME 3 und KDE SC 4 hinweg keine gravierenden Verschiebungen der Benutzerzahlen gegeben, weder prozentual, noch in den einzelnen Installationen. Die Zahl der Desktopumgebungen ist zweifelsohne angestiegen und GNOME 3 hat ebenso wie KDE SC 4 Federn gelassen, weil durch die große Anzahl an Alternativen viele Nutzer sich eine besser passende Umgebung gesucht haben. Nichtsdestotrotz sind diese Alternativen im Nischenbereich geblieben und ihre Nutzer können keineswegs behaupten die neue Mehrheit zu repräsentieren.

Shitstorms als Internetphänomen sind seit einiger Zeit in aller Munde. Man könnte manchmal glauben, die Open Source Community hätte sie erfunden. Der Umgangston in den Foren und auf den Maillinglisten ist manchmal hart und liebevoll gepflegte Vorurteile und Mythen sind eine beliebte Argumentationshilfe. Diese sind zum Teil gegen andere Ökosysteme gerichtet, aber richtig schön wird die Debatte erst wenn es zu den internen Grabenkämpfen kommt. Bevor systemd die Aufmerksamkeit auf sich zog, war es meist die präferierte Desktopumgebung, die zuverlässig einen längeren Flame-War auslöste.

Offizielles Releasebild KDE; Lizenz: GPL

Die Desktop-Entwicklungen

Anfangs waren diese Debatten noch einfach. GNOME oder KDE, das war die Grundsatzfrage. Die IceWM Nutzer beteiligten sich schließlich kaum, sie wussten zu jeder Zeit, dass sie den Königsweg befolgten. Diese vergleichsweise übersichtliche Konfrontationslage wurde ca. 2008 aufgebrochen. Nun ging es auch um die Frage modern oder alt und bewährt bzw. anders gesagt: KDE 4 oder KDE 3.5. GNOME-Nutzer priesen da noch ihr evolutionäres Entwicklungsmodell.

Spätestens mit dem Release von GNOME 3 im Jahr 2011 brachen die alten Konfrontationsgräben vollständig auf. GNOME 3 schockierte viele GNOME-Nutzer durch sein vollkommen neues Bedienkonzept. Mit dem Release von Ubuntu 11.04 wechselte Canonical auf Unity, Linux Mint schickte im gleichen Jahr Cinnamon ins Rennen. Beide nutzen den GNOME 3-Unterbau, allerdings unter den Prämissen eines eigenen Bedienkonzepts. Auf die Spitze getrieben wurde diese Tendenz durch MATE - ein direkter Fork von GNOME 2 auf dem Höhepunkt seiner Entwicklung. Wie die anderen Abspaltungen vom GNOME-Projekt entstand MATE 2011. Während Unity und Cinnamon alleine durch die Verbreitung ihrer Distributionen Ubuntu und Mint eine verhältnismäßig sichere Existenz garantiert wurde, zeigte sich bei MATE das Linux-Community-Element. Anfangs verspottet und auf einem Niveau mit dem Trinity Desktop gesehen, machte sich MATE zu einem Siegeszug auf, in dessen Folge der Desktop in Fedora, openSUSE 13.2, Debian 7.0 (Backports) und nun auch in Ubuntu 15.04 Einzug hielt.

Ubuntu MATE 15.04 mit Plank Dock

Die Diskussionen wurden durch diese Entwicklung zunehmend unübersichtlich. Vereinfacht gesagt: Anwender moderner Desktopkonzepte wie GNOME 3 und KDE SC 4 gegen die konservativen Nutzer, sowie alle gegen GNOME 3. Hauptargument bei den Nutzern von LXDE, MATE und Xfce: Die Entwickler haben die Nutzer vergessen und entwickeln nur noch für sich. Die Nutzer wollen keine Veränderungen, sondern das Windows 95-Prinzip.

Der Debian Popularity Contest

Mit diesem Thema wurde sich bereits im ersten Teil der Artikel-Miniserie befasst. Im Kommentar wurde nun darauf hingewiesen, dass nur ein Vergleich über einen größeren Zeitraum wirklich aussagekräftig wäre. Vollkommen richtig! Problematisch bleibt die Datengrundlage. Lediglich Ubuntu und Debian erfassen (freiwillig) die installierten Pakete der Nutzer. Einen Vergleich über einen längeren Zeitraum erlaubt leider nur die Debian-Popcon Seite (sollte dem anders sein, bitte im Kommentarfeld schreiben). Debian ist nicht präsentativ, aber es ist eine der größten Distributionen und hat neben Arch Linux und Gentoo potenziell die erfahrensten Nutzer. Wenn eine Benutzer-Community nicht die vorgekauten Konfigurationen schluckt, die ihnen von den Maintainern vorgegeben werden, dann ist sie bei diesen Projekten zu finden.

Dabei darf natürlich nicht verschwiegen werden, dass Debian GNOME als Standarddesktop ausliefert, aber nur deshalb die mangelnde Verbreitung anderer Desktops zu begründen ist weder bewiesen, noch wahrscheinlich. Vor allem nicht hinsichtlich der Debian-Zielgruppe. Im Grunde genommen ist das nur eine Abwandlung des Linux vs. Windows-Arguments.

Die Erhebung der Daten ist etwas kompliziert, da es keine einheitlich benannten Kernpakete gibt, die über alle Desktopgrenzen hinweg ihre Gültigkeit hätten. Für GNOME, Xfce, MATE und LXDE gibt es s.g. session-Pakete, ohne die der Desktop nicht funktioniert. Bei KDE ist aufgrund der permanenten Umbenennungen seitens der Entwickler und Debian-Maintainer kein solches Session-Paket über viele Jahre verfügbar. Hier muss auf den Loginmanager KDM zurückgegriffen werden. Ein Vergleich mit dem aktuell substanziellen kde-baseapps-bin Paket ergibt aber, dass damit fast alle KDE-Installation erfasst werden können.

Fazit

Seit Etablierung der session-Pakete 2007/2008 hat es über die Veröffentlichungen von GNOME 3 und KDE SC 4 hinweg keine gravierenden Verschiebungen der Benutzerzahlen gegeben, weder prozentual, noch in den einzelnen Installationen. Die Zahl der Desktopumgebungen ist zweifelsohne angestiegen und GNOME 3 hat ebenso wie KDE SC 4 Federn gelassen, weil durch die große Anzahl an Alternativen viele Nutzer sich eine besser passende Umgebung gesucht haben. Nichtsdestotrotz sind diese Alternativen im Nischenbereich geblieben und ihre Nutzer können keineswegs behaupten die neue Mehrheit zu repräsentieren.

Heute ist die Maiausgabe von freiesMagazin erschienen und bringt viele spannende Artikel aus den Bereichen Linux und Open Source mit.

Inhalt der Ausgabe 05/2015

• Der April im Kernelrückblick
• Einführung in LilyPond 2.18.2
• Impress.js-basierte Präsentationen mit Hovercraft
• Gesundheit am PC
• Rezension: Linux-Server für Einsteiger
• Rezension: C Programming in Easy Steps
• Rezension: Vorgehensmuster für Software-Architektur
• Rezension: Apps entwickeln mit Android Studio – Video Training
• Leserbriefe und Veranstaltungen

Downloads

• PDF-Version (1023 KB)
• EPUB-Version mit Bildern (245 KB)
• EPUB-Version ohne Bilder (66 KB)
• HTML-Version mit Bildern (325 KB)
• HTML-Version ohne Bilder (134 KB)

Unter der Adresse http://freiesmagazin.de/mobil/ findet man immer die aktuelle und alle bisher erschienenen HTML- und EPUB-Ausgaben. Auf der Magazin-Seite können die letzten drei Ausgaben von freiesMagazin abgerufen werden, ältere Ausgaben findet man im Archiv.

Kontakt

Wer jeden Monat an die neue Ausgabe erinnert werden will, kann auch den RSS-Feed abonnieren. Leserbriefe mit Lob, Kritik, Anregungen oder Fragen und neue Artikelvorschläge können an die Redaktion geschickt werden.

Im folgenden Video wird die Auslosung des Freifunk-Router-Gewinnspiels vorgenommen. Herzlichen Glückwunsch dem Gewinner!