ubuntuusers.de

24. April 2015

Bei einer Ubuntu Linux-Version, die speziell für den langfristigen produktiven Einsatz bestimmt ist – einer sogenannten LTS-Version (Long Term Support) könnte man davon ausgehen, dass der Distributor Canonical die Aktualisierungen der Software-Pakete vor der Veröffentlichung sorgfältig überprüft.

In den meisten Fällen mag dies ja zutreffen, doch diese Woche wurde ich diesbezüglich eines Besseren belehrt.

Am Mittwoch wurden von der Aktualisierungsverwaltung in Ubuntu 14.04 LTS nämlich die folgenden zwei Sicherheitsupdates zur Aktualisierung vorgeschlagen:

  • openjdk-7-jre (7u75-2.5.4-1~trusty1, 7u79-2.5.5-0ubuntu0.14.04.2)
  • openjdk-7-jre-headless (7u75-2.5.4-1~trusty1, 7u79-2.5.5-0ubuntu0.14.04.2)

Ohne mir gross Gedanken über die Auswirkungen dieser „Fehlerkorrekturen“ für die freie Java-Implementierung OpenJDK zu machen, habe ich der Installation dieser beiden Updates zugestimmt; ein fataler Fehler, denn die böse Überraschung liess nicht lange auf sich warten.

Auf einmal liessen sich nämlich ausführbare Java-Dateien mit der Endung „.jar“ weder per Doppelklick noch per Rechtsklick über den Eintrag „Öffnen mit“ mehr starten. Stattdessen war das Archivverwaltungsprogramm File-Roller als Standardprogramm für jar-Dateien festgelegt, mit welchem sich jar-Dateien zwar öffnen aber Java-Programme natürlich nicht ausführen lassen.

jar Screenshot 1

Des Weiteren war der Eintrag „OpenJDK Java 7 Runtime“ aus den erweiterten „Öffnen mit“-Einträgen verschwunden.

jar Screenshot 2

Eine Neuinstallation von OpenJDK brachte leider nicht das gewünschte Resultat. Um sicherzustellen, dass die OpenJDK Java-Laufzeitumgebung ordungsgemäss installiert ist, habe ich also zunächst über das Terminal versucht, eine beliebige jar-Datei mit OpenJDK zu starten, was auch gelang:

java -jar Beispiel.jar

Demzufolge konnte davon ausgegangen werden, dass OpenJDK an sich einwandfrei funktionierte. Eine dauerhaft zufriedenstellende Lösung war das Ausführen der jar-Datei über die Kommandozeile für mich jedoch nicht.

Um jar-Dateien wieder automatisch per Doppelklick über die Java-Laufzeitumgebung auszuführen, galt es nun, den jar-Dateityp in Ubuntu wieder mit OpenJDK zu „verknüpfen“.

Im Forum von askubuntu.com bin ich auf einen interessanten Lösungsvorschlag aufmerksam geworden, welchen ich euch hier nicht vorenthalten möchte.

Man öffne mit Root-Rechten den Texteditor seiner Wahl (in meinem Fall beispielsweise den Texteditor „gedit“ der Gnome Desktop-Umgebung). Nachtrag, 25. April 2015: Besten Dank an den Leser canislupus, welcher mich darauf hingewiesen hat, dass dazu keine Root-Rechte notwendig sind.

Nun tragen wir in den Texteditor folgendes ein:

[Desktop Entry]
Name=OpenJDK Java 7 Runtime
Name[de]=OpenJDK Java 7 Laufzeitumgebung
Comment=OpenJDK Java 7 Runtime
Comment[de]=OpenJDK Java 7 Laufzeitumgebung
Exec=cautious-launcher %f /usr/bin/java -jar
Terminal=false
Type=Application
Icon=openjdk-7
MimeType=application/x-java-archive;application/java-archive;application/x-jar;
NoDisplay=false

Nun speichern wir die Datei im Verzeichnis ~/.local/share/applications unter dem Dateinamen openjdk-7-java.desktop ab und schliessen den Texteditor.

Das Auführen von jar-Dateien sollte danach wieder funktionieren, auch ohne Terminal.

jar Screenshot 3

Am 25. April, als am morgigen Samstag, wird Debian 8.0 "Jessie" die Freeze-Phase hinter sich lassen und damit offiziell das Licht der Welt erblicken. Die Debian Gemeinschaft wirft nur alle paar Jahre eine Veröffentlichung auf den Distributionsmarkt, weshalb eine fertige Version immer noch ein wichtiges Event ist. Anders als beispielsweise bei Ubuntu wo neue STS-Versionen eher pflichtschuldig zur Kenntnis genommen werden. Debian ist vielleicht die wichtigste aktiv entwickelte Distribution. Nicht unbedingt wegen ihrer direkten Verbreitung, sondern weil vermutlich die hälfte des Linux-Universums (Android ausgenommen!) direkt oder indirekt auf Debian basiert. Ein Test ist alleine deshalb sinnvoll, außerdem läuft Debian seit kurzem wieder auf einem meiner Produktivgeräte.

 

Obwohl es bei Debian mehr auf die “inneren Werte” ankommt, kann man eine Bewertung auch mal am “äußeren” beginnen lassen. Das neue Design von Debian ist dieses Mal wirklich gelungen. Grub, Plymouth und Loginscreen erstrahlen in einem neuen, frischen Gewand. Scheinbar sind die gruseligen Zeiten von Spacefun endgültig vorbei, als man sich allen ernstes Fragen musste welche Zielgruppe Debian hier ansprechen will.

Debian Release Picture

Installation

Die Installation erfolgt am besten über die Netinstall-ISO - jedenfalls sofern es die Bandbreite mitmacht. An der Installationsroutine hat sich kaum etwas getan. Schon aufgrund der wenigen Optionen ist sie ähnlich einfach wie die von Ubuntu – nur deutlich weniger auf eine hübsche Optik getrimmt. Die erste sichtbare Veränderung erscheint bei der Auswahl der Task-Pakete. Zwar ist GNOME als Standarddesktop vorausgewählt (und nicht wie zeitweise in der Testing-Phase Xfce) aber alle anderen Desktops lassen sich dezidiert auswählen und Gnome abwählen. Ein bisschen irritierend ist, dass man das Task-Desktop Paket ausgewählt lassen, aber trotzdem alle Desktops gleichzeitig abwählen kann. Umgekehrt lässt sich KDE SC als Desktop installieren, obwohl das allgemeine Desktoppaket abgewählt ist. Hier hat man (mal wieder) wenig auf die Usability geachtet.

Die sinnvollste Option bleibt aber Debian erst einmal ohne Desktop zu installieren und dann nach der Installation das System Stück für Stück aufzubauen. Dadurch entgeht man der teils unsinnigen Programm-Vorauswahl und kann sich das System passend für den eigenen Bedarf zusammen stellen. Natürlich verlangt dies ein wenig Kenntnis der notwendigen Programme - auch unterhalb der Oberfläche - aber Debians Zielgruppe liegt schließlich auch nicht bei den blutigen Linux-Anfängern.

Änderungen und Versionen

Die wohl wichtigste Änderung unter der Haube ist die Abkehr vom klassischen SysV-Init und der Wechsel auf systemd. Diese Entscheidung hat die Debian-Community gehörig polarisiert, aber die Debian-Maintainer hatten in einer Abstimmung genug Pragmatismus bewiesen und die blockierende Minderheit auf ihre Plätze verwiesen. Angeblich soll Debian nun geforkt werden, aber hier wurde außer einiger Pressearbeit scheinbar noch nicht viel geleistet.  Das könnte auch daran liegen, dass die Intergration von systemd inzwischen ziemlich gut funktioniert. Debian hat einige Mängel, aber das Init-System machte in diesem Test keine Probleme. Natürlich müssen einige alte Workarounds angepasst werden, aber das Leben geht weiter und wer Stillstand sucht ist in der IT falsch aufgehoben.

Die Versionen sind bei diesem Release jedoch verhältnismäßg aktuell. Der Kernel liegt in Version 3.16 vor, der z.B. auch im aktuellen HWE Stack von Ubuntu 14.04 LTS verwendet wird. KDE-Abwender bekommen eine Kombination aus KDE Workspaces 4.11, sowie Applications 4.12 und 4.14 präsentiert. Weshalb die Anwendungen nicht komplett auf 4.14 aktualisiert wurden bleibt ein Geheimnis des Debian-KDE-Teams. Die 4.14er Bugfixversion ist die 1, während man anderswo bereits in den Genuss von 4.14.3 kommt – mit all den Bugfixes die das mit sich bringt. Hier zeigt sich der harte Freeze-Prozess mit dem das Release Team eine zu lange Freeze-Phase vermeiden wollte und wohl leider auch das mangelnde Engagement des Debian-KDE-Teams. Denn andee Teams haben durchaus während der Freeze-Phase per Ausnahmegenehmigung noch Bugfixversionen nachgereicht.

Nachdem man den Init-Vorgang hinter sich hat, begrüßt einen KDM, dem Debian weiter die Treue hält. LightDM ist natürlich in den Paketquellen vorhanden. Optisch wird ansonsten ein Standard-KDE ausgeliefert. Bei der Softwarevorauswahl fragt man sich für wen die KDE-Maintainer diese Vorauswahl eigentlich treffen bzw. ob sie sich überhaupt mal konstruktiv damit auseinander gesetzt haben. Es wird wirklich alles installiert was bei drei nicht auf den Bäumen ist. Das task-kde-desktop Paket empfiehlt (und installiert damit standardmäßig auch) Iceweasel, Gimp und LibreOffice. Das kde-standard Paket installiert zusätzlich alles von Akregator bis SkanLite. Die Standardsoftwareauswahl ist auch bei anderen Distributionen nicht ideal, aber Debians Mischung ist eine interessante Zusammensetzung von “neuen” und “alten” Programmen, sowie Programmdoppelungen. Natürlich kann man fast alles aus den gewaltigen Debian-Paketquellen nachinstallieren, aber die Metapakete sollten doch eine gewinnbringende Vorauswahl für den Anwender bieten – ansonsten kann man sie sich gleich sparen. Das ist einer der ersten Punkte bei denen man Liebe zum Detail vermisst.

Der Hauptkritikpunkt bleibt die lieblose Integration der Desktopumgebungen, was sich besonders stark bei der KDE Software Compilation niederschlägt. Debian ist durch seine umfangreichen Paketquellen ein Baukasten mit dem man sich quasi jedes System, vom raspberry pi bis zur Workstation betreiben kann. Trotzdem wäre eine sinnvolle Vorauswahl einiger Programme nicht zu viel verlangt. Zumal wenn ein Desktopprojekt wie KDE konkurrierende Programme unter seinem Dach vereint.

Fazit

Debian liefert ein rundum stabiles Release aus, trotz des Streits um die Einführung von systemd im Vorfeld. KDE-Benutzer bekommen ein homogenes KDE SC 4 Release auf dem Höhepunkt seiner Entwicklung. Wer genug Geduld hat und eventuell auftretende Schwierigkeiten bei der Umstellung auf Plasma 5 vermeiden möchte bekommen mit Debian Jessie eine Distribution, die einem eine Umstellungsverzögerung für einige Jahre anbietet. Beim nächsten Debian-Release ca. 2017/18 wird Plasma 5 sicherlich ausgereift sein.

Am 25. April, als am morgigen Samstag, wird Debian 8.0 "Jessie" die Freeze-Phase hinter sich lassen und damit offiziell das Licht der Welt erblicken. Die Debian Gemeinschaft wirft nur alle paar Jahre eine Veröffentlichung auf den Distributionsmarkt, weshalb eine fertige Version immer noch ein wichtiges Event ist. Anders als beispielsweise bei Ubuntu wo neue STS-Versionen eher pflichtschuldig zur Kenntnis genommen werden. Debian ist vielleicht die wichtigste aktiv entwickelte Distribution. Nicht unbedingt wegen ihrer direkten Verbreitung, sondern weil vermutlich die hälfte des Linux-Universums (Android ausgenommen!) direkt oder indirekt auf Debian basiert. Ein Test ist alleine deshalb sinnvoll, außerdem läuft Debian seit kurzem wieder auf einem meiner Produktivgeräte.

Obwohl es bei Debian mehr auf die “inneren Werte” ankommt, kann man eine Bewertung auch mal am “äußeren” beginnen lassen. Das neue Design von Debian ist dieses Mal wirklich gelungen. Grub, Plymouth und Loginscreen erstrahlen in einem neuen, frischen Gewand. Scheinbar sind die gruseligen Zeiten von Spacefun endgültig vorbei, als man sich allen ernstes Fragen musste welche Zielgruppe Debian hier ansprechen will.

Debian Release Picture

Installation

Die Installation erfolgt am besten über die Netinstall-ISO - jedenfalls sofern es die Bandbreite mitmacht. An der Installationsroutine hat sich kaum etwas getan. Schon aufgrund der wenigen Optionen ist sie ähnlich einfach wie die von Ubuntu – nur deutlich weniger auf eine hübsche Optik getrimmt. Die erste sichtbare Veränderung erscheint bei der Auswahl der Task-Pakete. Zwar ist GNOME als Standarddesktop vorausgewählt (und nicht wie zeitweise in der Testing-Phase Xfce) aber alle anderen Desktops lassen sich dezidiert auswählen und Gnome abwählen. Ein bisschen irritierend ist, dass man das Task-Desktop Paket ausgewählt lassen, aber trotzdem alle Desktops gleichzeitig abwählen kann. Umgekehrt lässt sich KDE SC als Desktop installieren, obwohl das allgemeine Desktoppaket abgewählt ist. Hier hat man (mal wieder) wenig auf die Usability geachtet.

Die sinnvollste Option bleibt aber Debian erst einmal ohne Desktop zu installieren und dann nach der Installation das System Stück für Stück aufzubauen. Dadurch entgeht man der teils unsinnigen Programm-Vorauswahl und kann sich das System passend für den eigenen Bedarf zusammen stellen. Natürlich verlangt dies ein wenig Kenntnis der notwendigen Programme - auch unterhalb der Oberfläche - aber Debians Zielgruppe liegt schließlich auch nicht bei den blutigen Linux-Anfängern.

Änderungen und Versionen

Die wohl wichtigste Änderung unter der Haube ist die Abkehr vom klassischen SysV-Init und der Wechsel auf systemd. Diese Entscheidung hat die Debian-Community gehörig polarisiert, aber die Debian-Maintainer hatten in einer Abstimmung genug Pragmatismus bewiesen und die blockierende Minderheit auf ihre Plätze verwiesen. Angeblich soll Debian nun geforkt werden, aber hier wurde außer einiger Pressearbeit scheinbar noch nicht viel geleistet.  Das könnte auch daran liegen, dass die Intergration von systemd inzwischen ziemlich gut funktioniert. Debian hat einige Mängel, aber das Init-System machte in diesem Test keine Probleme. Natürlich müssen einige alte Workarounds angepasst werden, aber das Leben geht weiter und wer Stillstand sucht ist in der IT falsch aufgehoben.

Die Versionen sind bei diesem Release jedoch verhältnismäßg aktuell. Der Kernel liegt in Version 3.16 vor, der z.B. auch im aktuellen HWE Stack von Ubuntu 14.04 LTS verwendet wird. KDE-Abwender bekommen eine Kombination aus KDE Workspaces 4.11, sowie Applications 4.12 und 4.14 präsentiert. Weshalb die Anwendungen nicht komplett auf 4.14 aktualisiert wurden bleibt ein Geheimnis des Debian-KDE-Teams. Die 4.14er Bugfixversion ist die 1, während man anderswo bereits in den Genuss von 4.14.3 kommt – mit all den Bugfixes die das mit sich bringt. Hier zeigt sich der harte Freeze-Prozess mit dem das Release Team eine zu lange Freeze-Phase vermeiden wollte und wohl leider auch das mangelnde Engagement des Debian-KDE-Teams. Denn andee Teams haben durchaus während der Freeze-Phase per Ausnahmegenehmigung noch Bugfixversionen nachgereicht.

Nachdem man den Init-Vorgang hinter sich hat, begrüßt einen KDM, dem Debian weiter die Treue hält. LightDM ist natürlich in den Paketquellen vorhanden. Optisch wird ansonsten ein Standard-KDE ausgeliefert. Bei der Softwarevorauswahl fragt man sich für wen die KDE-Maintainer diese Vorauswahl eigentlich treffen bzw. ob sie sich überhaupt mal konstruktiv damit auseinander gesetzt haben. Es wird wirklich alles installiert was bei drei nicht auf den Bäumen ist. Das task-kde-desktop Paket empfiehlt (und installiert damit standardmäßig auch) Iceweasel, Gimp und LibreOffice. Das kde-standard Paket installiert zusätzlich alles von Akregator bis SkanLite. Die Standardsoftwareauswahl ist auch bei anderen Distributionen nicht ideal, aber Debians Mischung ist eine interessante Zusammensetzung von “neuen” und “alten” Programmen, sowie Programmdoppelungen. Natürlich kann man fast alles aus den gewaltigen Debian-Paketquellen nachinstallieren, aber die Metapakete sollten doch eine gewinnbringende Vorauswahl für den Anwender bieten – ansonsten kann man sie sich gleich sparen. Das ist einer der ersten Punkte bei denen man Liebe zum Detail vermisst.

Der Hauptkritikpunkt bleibt die lieblose Integration der Desktopumgebungen, was sich besonders stark bei der KDE Software Compilation niederschlägt. Debian ist durch seine umfangreichen Paketquellen ein Baukasten mit dem man sich quasi jedes System, vom raspberry pi bis zur Workstation betreiben kann. Trotzdem wäre eine sinnvolle Vorauswahl einiger Programme nicht zu viel verlangt. Zumal wenn ein Desktopprojekt wie KDE konkurrierende Programme unter seinem Dach vereint.

Fazit

Debian liefert ein rundum stabiles Release aus, trotz des Streits um die Einführung von systemd im Vorfeld. KDE-Benutzer bekommen ein homogenes KDE SC 4 Release auf dem Höhepunkt seiner Entwicklung. Wer genug Geduld hat und eventuell auftretende Schwierigkeiten bei der Umstellung auf Plasma 5 vermeiden möchte bekommen mit Debian Jessie eine Distribution, die einem eine Umstellungsverzögerung für einige Jahre anbietet. Beim nächsten Debian-Release ca. 2017/18 wird Plasma 5 sicherlich ausgereift sein.

Im Februar hat Ubuntu mit leichter Verzögerung das zweite Point-Release für die jüngste LTS Version 14.04 herausgebracht. Zuverlässig begann in den Foren der üblichen Verdächtigen der kleine Trollsport über den LTS-Status. Ubuntu mag nicht mehr die populärste Distribution sein, auf jeden Fall ist der Hype vorbei – Neuigkeiten scheinen aber noch zuverlässig für Diskussionsstoff zu sorgen.

Supportzyklen sind eine Modeerscheinung. Als Ubuntu aufkam revolutionierte es den Releaseprozess mit seiner strikten Orientierung an einem sechsmonatigen Releasezyklus. Andere Projekte wie Gnome und KDE folgten diesem Weg immer kürzerer und besser geplanten Releasezyklen und schließlich orientierten sich auch immer mehr Distributionen daran. Diese Modeerscheinung ist jedoch vorüber. Während jenseits des Linux-Tellerrandes die Systementwicklung deutlich beschleunigt wurde, orientieren sich immer mehr Linuxdistributionen am LTS-Modell.

Ubuntu Tux unter Creative Commons BY-NC-SA

Die Beispiele dafür sind zahlreich: Debian testet zur Zeit mit Squeeze einen LTS-Release nach Ablauf der Oldstable-Supportphase und Ubuntu hat alle Zwischenversionen zu Entwicklerversionen deklariert. RHEL und seine Derivate, sowie SUSE Enterprise sind sowieso ungeschlagen – jedenfalls was die Supportdauer betrifft. Jedoch tendieren auch die Communityableger der Enterprise-Distributionen zu längeren Releasezyklen. OpenSUSE veröffentlichte Version 13.2 fast ein Jahr nach 13.1, was der Version 12.3 annähernd zwei Jahre Support ermöglichte. Der Release von Fedora 21 verzögert sich auch permanent, was den Support von Version 20 andauernd verlängert.

Die Gründe für diese Entwicklung sind vielfältig. Bei einigen Projekten ist die Erkenntnis gereift, dass sich in einem sechsmonatigen Releasezyklus substanzielle Neuerungen in einer Distribution nicht hinreichend stabilisieren lassen, bei anderen wie Debian ist es die Forderung der Community nach längeren Supportzeiträumen und selteneren Distributionsupgrades. Natürlich gibt es auch weiterhin Distributionen, die den Versionsjunkies gerecht werden, allen voran Arch Linux, der Trend geht aber in eine andere Richtung.

Alle Distributionen stehen dabei vor demselben Dilemma. Während z.B. Microsoft wirklich nur das Betriebssystem und wenige integrierte Programme mit Fehlerbehebungen und Sicherheitsaktualisierungen versorgen muss, liefern die meisten Linuxdistributionen in ihren Paketquellen ein umfangreiches Programmreservoir aus, das für den gesamten Unterstützungszeitraum gepflegt werden muss. Die beiden großen Enterprise-Distributionen haben darauf mit einer Limitierung des Paketquellenumfangs reagiert. Auf die Spitze hat dies sicherlich SUSE getrieben, als es mit Version 12 auch KDE aus den Paketquellen verbannte. Allerdings ist subjektiv auch bei den Communitydistributionen Fedora und openSUSE die Anzahl der enthaltenen Programme ein wenig zusammen geschmolzen.

Debian mit seiner großen Entwicklergemeinschaft geht einen anderen Weg. Die Paketquellen wachsen nahezu mit jedem Release an. Ubuntu übernimmt diese durch seinen Releaseprozess und friert die Versionsstände ein.

Gerade letzteres hat in letzter Zeit zum Vorwurf geführt, dass Ubuntu unsicher sei. Der Vorwurf kam zuerst in der Trollzone (auch genannt Heise, Golem und Pro-Linux) auf, um dann in seriösere Foren vorzudringen.

Die Lehre von den Paketquellen

Während andere Distributionen in der Regel nur zwischen frei und unfrei unterscheiden und ihre Paketquellen derart strukturieren, gibt es bei Ubuntu eine Vielzahl von Bereichen.

  1. Main
  2. Universe
  3. Restricted
  4. Multiverse
  5. Canonical Partner
  6. Drittquellen / PPA’s

In Main befinden sich die Pakete, die direkt von Canonical – der Firma hinter Ubuntu – gewartet werden und die quasi zum “Enterprise-Umfang” (vergleichbar mit RHEL und SLES/D) gehören. Die Pakete in Canonical-Partner werden auch – wie der Name schon sagt – von Canonical bzw. ihren Partnern gepflegt, aber nicht offiziell supportet. Alles was sonst aus den Debian-Paketquellen synchronisiert wurde, findet sich in Universe. Aus grauer Vorzeit – als Kubuntu noch ein offiziell von Canonical unterstütztes Derivat war – hat sich der Mythos gehalten, dass in Universe nur die Reste liegen, die keinen Betreuer haben und die Pakete deshalb nicht gepflegt werden.

Desktop-Derivate

Das entspricht allerdings nicht der gegenwärtigen Faktenlage. Im Releaseprozess einer jeden LTS-Version legt das Ubuntu Technical Board fest welche Derivate einen offiziellen LTS Status erhalten. Hier wird noch mal differenziert in solche, die 5 Jahre unterstützt werden (z. Zt. Ubuntu und Kubuntu) und solche mit 3 Jahren Support. Die Derivate sind zwar lediglich Gemeinschaftsprojekte, allerdings unterscheiden sie sich als solche nicht von z.B. Debian oder openSUSE, die gemeinhin auch nicht als unsicher betrachtet werden.

Die einzige zuverlässige Information über den Support von Paketen liefert also die Auskunft folgender Zeile in einem beliebigen Terminalprogramm auf dem betroffenen System:

$ ubuntu-support-status show-all

Auf einer normalen Desktopinstallation dürfte die Zahl der nicht unterstützten Paketen bei 5-10% liegen. In diese Kategorie fallen jedoch auch Pakete die aus PPA’s installiert wurde, sowie Pakete aus dem Partner Verzeichnis, die faktisch durchaus unterstützt werden. Tatsächlich sinkt damit die Quote auf weniger als 2%. Das ist ein durchaus akzeptabler Wert und deutlich ehrlicher als die angebliche 100%-Unterstützung bei Debian. Wer daran zweifelt kann sich die offenen Sicherheitslücken bei z.B. Filezilla in Debian Wheezy ansehen. Wenn man auf einen sehr hohen Anteil nicht unterstützter Programme kommt, sollte man sich allerdings ggf. überlegen auf alternative Programme mit Support umzusteigen.

Server

Etwas anders sieht die Lage im Serverbereich aus. Einerseits ist hier das Angriffsrisiko besonders groß und andererseits liefert Ubuntu hier durch den Sychronisationsprozess mit Debian eine ganze Reihe von Programmen aus, die nur leidlich oder gar nicht gewartet werden. Die Spanne reicht hier von Drupal, über ownCloud bis WordPress. Während die meisten Desktopprogramme in einem halben Jahr keine sicherheitskritische Aktualisierung erhalten, sind diese hier an der Tagesordnung.

Das ist zweifelsohne ungünstig, aber von einem Serveradministrator kann erwartet werden, dass er sich mit der eingesetzten Linux-Distribution hinreichend auskennt um ihre Eigenheiten zu verstehen und ggf. die Programme eigenständig zu aktualisieren. Wer dies nicht kann, sollte seinen Server schleunigst abschalten. Hier ist die Verantwortung des Distributors gegenüber dem Nutzer völlig anders gelagert, als beim Privatanwender. Zumal das Problem eh selten akut wird, weil viele Administratoren die betroffene Software direkt von Upstream beziehen (wer will schon 5 Jahre dieselbe WordPress-Version einsetzen?).

Unklare Paketzuordnung

Unabhängig von der Desktop- oder Server-Sparte ist die Auswahl der supporteten und unsupporteten Pakete bzw. die Zuordnung nach main und universe für einen Außenstehenden in vielen Fällen nicht nachvollziehbar. Im Februar lief der 9-Monats-Zyklus ab, wichtige Pakete wie das verbreitete schweizer Taschenmesser für Multimediadateien VLC haben damit ihren Support verloren. Trotzdem finden sich im Changelog Aktualisierungen für Sicherheitslücken. Doch wie lange kann sich der Nutzer darauf verlassen?

VLC wirft ein Schlaglicht auf die interessante Zusammensetzung der unterstützen Pakete in Ubuntu. Neben den Basispaketen wie Kernel, X-Server und Kernbibliotheken des Systems gehören dazu auch Programme wie GIMP, die auf keinem Derivat standardmäßig vorinstalliert sind. Umgekehrt gehören verbreitete Virtualisierungslösungen wie Virtualbox offiziell nicht dazu, die Virtualbox-Scope für Unity hingegen schon. Mit VLC der plattformübergreifende, quasi-standard Multimedia-Player hingegen - wie bereits erwähnt - auch nicht.

Ein weiteres Problem stellen die mit jedem Point-Release auf den Installationsmedien ausgelieferten neuen Kernel und X-Server Versionen dar. Diese haben – anders als die ursprüngliche Version vom April 2014 – eine verkürzte Supportdauer von 9 Monaten. Leider werden sie danach nicht zuverlässig auf die nächste Version aktualisiert bzw. gefährden die Systemstabilität einer LTS-Version. Die Gratwanderung zwischen Unterstützung neuer Hardware und Systemstabilität wurde hier nicht besonders gut gemeistert.

Neue und alte Fehler

Hinzu kommt, dass Trusty in den vergangenen Monaten in einigen Bereichen schon nicht besonders glänzte. So wurde durch fehlerhafte Updates die Dialogintegration von LibreOffice in KDE kaputt (LP #1369673) gefixt, Digikam stürzt aufgrund eines Sqlite-Fehler zuverlässig ab (LP #1317449) und die Xmodmap wurde auch durch ein Update abgeschaltet. Bei Release bestehende gravierende Fehler wie die fehlerhafte Verschlüsselung mittels ecryptfs (Benutzerdaten verschlüsseln in der Installationsroutine) wurde lediglich durch engagierten Einsatz aus der Community behoben. (LP #953875).

Diese Fehler werden ergänzt durch die subjektive Wahrnehmung, dass die Bedeutung der vergangenen LTS-Version beim Ubuntu-Team nach 9 Monaten abnimmt. Die Weichen werden in Richtung 16.04 gestellt. Wichtige Funktionen nun in die STS Versionen eingebracht. Aktualisierungen für Trusty beziehen sich nun überwiegend auf Sicherheitslücken. Reine Fehlerbehebungen oder ein größeres Engagement für die LTS darf man wohl nur noch in seltenen Fällen erwarten.

Fazit

Ubuntus Paketquellenaufteilung in Main und Universe (sowie die anderen Bereiche) ist speziell, macht das System aber nicht per se unsicher - wie von Kritikern oft bemängelt wird. Die Probleme liegen eher in anderen Bereichen, welche die Nutzer aber ebenso betreffen. Ubuntu ist aufgrund der Verbreitung zudem deutlich mehr im Fokus, als so manche Nischendistribution, wo man den Paketbetreuern ebenfalls auf die Finger schauen muss. Ist Ubuntu in seiner Gesamtheit unsicherer als SUSE Enterprise oder RHEL? Möglicherweise ja, allerdings haben diese ein deutlich limitiertes Angebot an Paketen, was zu verstärktem Einsatz von Fremdquellen, wie z.B. EPEL führt. Diese bringen ganz andere Sicherheitsrisiken mit sich und können deshalb auch nicht als Königsweg bezeichnet werden.

Letztlich stehen alle großen Distributionen vor der Frage, wie man bei begrenzter Arbeitskraft ein stetig wachsendes Reservoir an Paketen über viele Jahre warten kann. Zumal Hilfe von Upstream nicht immer zu erwarten ist. Das bisherige LTS und STS System ist aber eher eine mittelmäßige Lösung und wird vermutlich mittelfristig ersetzt werden. Ubuntu Snappy Core, Ubuntu Phone und die allgemeine Entwicklungsrichtung um Docker & Co werfen ihre Schatten voraus.

Da ich zuhause noch einen alten Futro stehen habe, der als Mailserver dient wollte ich hier auch ein halbwegs aktuelles Ubuntu installiert haben.
Bisher lief 11.10 Server darauf. Was natürlich schon lange aus dem Support raus ist.

Daher habe ich mich entschieden die 12.04.5 auf dem Server zu installieren. Dies ist die letzte Version die man noch ohne PAE nutzen kann.
Allerdings waren hier auch Klimmzüge notwendig. Das normale Desktop oder Server Image funktioniert hier nicht. Nur das Mini-ISO wird noch als "non-PAE" Version angeboten.

Man findet es hier:
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/netboot/non-pae/mini.iso

Nachdem ich das Image auf dem USB Stick kopiert habe konnte ich die Installation durchführen, die allerdings mehr einer klassichen Debian Installation gleicht.

Da eine Ubuntu Installation auf einer nicht PAE Hardware sowieso eher im Mini-Server Bereich oder anderen Grenzbereichen stattfindet kann man hier auch auf eine klassische Desktop Version verzichten.

Wer kennt das nicht, man lädt eine Datei herunter und möchte die danach auf der Konsole entpacken. Doch wie war noch gleich der Befehl um ein *.tar.gz oder *.bzip Archiv zu entpacken ? Ich jedenfalls stehe immer wieder vor dem Problem und schaue mir dann meine alten Artikel an oder befrage das Suchmaschinenorakel. Doch es gibt kleine Hilfen. Perl-Skripte wie unp oder atool brauchen keine extra komplizierten Parameter zum entpacken. Als Voraussetzung muss Perl gegeben sein und die eigentlichen Entpacker Programme wie tar, bzip, gzip, usw. installiert sein.

So geht es leichter mit dem entpacken

Statt

tar –xzf Datei.tar.gz

muss für unp nur

unp Datei.tgz

bzw. für atool ein kleiner Parameter wie z.B.

atool –x Datei.tgz

angegeben werden. Die Tools erkennen dabei selbständig um was es sich für ein Format handelt.

Ich finde so etwas sollte unter Linux zum Standard gehören. Gerade Anfänger sind Konsolenscheu. Diese möchten sich dann nicht auch noch irgendwelche Parameter merken, nur um eine einfache Aufgabe durchzuführen.

Bei mir gehört unp ab jetzt zum Standard. Auch wenn das letzte Release (2002) schon wesentlich länger zurückliegt als bei atool (2012), ist es doch sehr hilfreich. Ich habe mich dafür entschieden da es zum entpacken ganz ohne Parameter auskommt und genau so gut wie atool funktioniert.

Kleine Helfer beim Entpacken ist zuerst erschienen auf André Hemkes.

23. April 2015

Ich nutze regelmäßig SSH-Verbindungen zu diversen Rechnern. Im LAN z. B. zu meinem Receiver oder zu meinem Quake-3-Arena-Server. Da letzterer im Internet erreichbar ist, läuft SSH nicht auf dem Standardport sondern auf einen anderen um Scriptkiddies zu blocken und somit die Logdateien sauber zu halten. Somit muss ich jedes mal, wenn ich mich mit dem Rechner verbinden will ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben. Oder den Befehl aus der Historie von ZSH herausfischen. Das muss doch auch besser funktionieren, oder? Ja tut es.

Hierzu legt man, falls nicht schon vorhanden, als erstes die Datei ~/.ssh/config auf dem Rechner mit dem man sich mit dem Server verbinden will an. Nun erstellt man in dieser folgenden Eintrag.

Host quake
Hostname 192.168.1.220
Port 1234
User quake
IdentityFile /home/$Benutzer/.ssh/quake

In der ersten Zeile geben wir den Namen der Verbindung an. Hier kann man frei wählen. Als nächstes geben wir die IP des Rechners an zu dem wir uns verbinden möchten. Der Port muss angegeben werden, wenn wir einen, vom Standard abweichenden, Port eingestellt haben. In der nächsten Zeile wird der Benutzer angegeben mit dem wir uns auf dem Rechner einloggen möchten. Sollte man anstelle von Passwörtern SSH-Keys nutzen und hat man mehrere unter ~/.ssh liegen gibt man am besten mit IdentityFile auch noch die richtige Schlüsseldatei an.

Nachdem man die Datei abgespeichert hat, braucht man nun nicht mehr ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben sondern es reicht ganz bequem ssh quake.

Scaleway beschreibt sich selbst als Anbieter von bare metal cloud server. Mit Cloud im eigentlichen Sinne hat es aber nichts zu tun. Statt einer Instanz in einer Cloud geteilter und ausfallsicherer Ressourcen sind es dedizierte kleine ARM-Server, die Scaleway für 10€ im Monat anbietet. Nachdem ich Dirk als Kommentar eine Beschreibung hinterlassen habe, die mir im Nachhinein zu unreflektiert positiv klang, musste ich mir den Dienst nun näher anschauen.

Der Server hat immerhin einen Quad-Core-Prozessor, laut cpuinfo ein Marvell PJ4Bv7 Processor rev 2 (v7l) mit 1332.01 Bogomips pro Kern. Das ist weniger als ein typischer Desktop-PC, aber für einen Heimserver okay. Dieser Heimserver steht dagegen in einem Rechenzentrum. Außerdem hat er Zugriff auf eine gar nicht mal so langsame Festplatte und 2GB Ram, was die typischen Probleme mit Heimservern umschifft. Dass der Prozessor ein ARM-Prozessor sollte auf einem Server heutzutage nicht mehr viel ausmachen, nach dem Raspberry Pi laufen die wichtigen Linux-Distributionen und Anwendungen dort meist ohne Probleme.

Wäre es aber nur das, wäre Scaleway die 10€ im Monat nicht wert. Für 10€ im Monat könnte ich auch bei Digitalocean bleiben - einem etablierten und beliebten Anbieter. Ein 10€-Droplet hat dort zwar nur mit 1GB Ram und einem Einkern-Prozessor in einer VM. Doch langsamer ist das nicht zwingend, bei garantierten Ressourcen kein echter Nachteil, und das fehlende GB Ram je nach Server-Anwendung nicht wichtig.

Daher versucht Scaleway, auch das Drumherum gut zu machen.

Beim Erstellen eines Servers sind mehrere Linux-Distribution auswählbar - und statt leerer Distributionen gibt es auch vorinstallierte Anwendungen. So kann z.B. Ghost oder Wordpress (auf Ubuntu laufend) durch die Vorauswahl direkt bei der Servererstellung ausgewählt werden. Die Oberfläche ist freundlich und übersichtlich, Serververwaltung und Netzwerkübersicht klar. Erstellten Servern können sogar zusätzliche Partitionen zugeordnet werden (2€ für 50GB), das sind also in irgendeiner Form Netzwerkplatten. Potentiell mächtig ist die Möglichkeit, Server über das lokale Netzwerk zu verbinden.

Es gibt außerdem eine API und Scaleways Infinite Storage System. API ist klar, damit können aus der Ferne die Server kontrolliert werden - der Dokumentation zufolge ist sie relativ mächtig. Das Infinite Storage System habe ich nicht ganz verstanden. Der FAQ zufolge können dort unendlich viele Daten hingeschoben werden, der Preisübersicht zufolge kostet das 0,02€ pro Monat und Gigabyte. Warum steht das nicht in der FAQ, und warum heißt es dort Objekt Storage? 0,02€ pro Monat und Gigabyte ohne Kosten für den Transfer wäre sogar billiger als tarsnap - allerdings bin ich mir wie gesagt nicht sicher, ob das vergleichbar ist.

Scaleway gegen Digitalocean

Einiges davon kann Digitalocean allerdings auch. Vorgefertigte Images für Distributionen und Anwendungen zuallererst, denn dort ist die Auswahl etwas größer. Eine API gibt es auch, und ohne sie je benutzt zu haben erscheint sie mir mindestens genauso mächtig. Und auch Droplets könnten im lokalen Netzwerk miteinander reden. Was Digitalocean nicht hat, das ist das Storage System. Und die Festplatte ist kleiner, 30 GB im 10€-Plan statt 50 GB. Ähnlich Ram, da stehen 1 GB gegen Storageways 2.

Um die Unterschiede zusammenzufassen:

Scaleway hat für Server momentan genau ein Angebot:

  1. Das kostet 10€ im Monat.
  2. Dafür bekommt man einen dedizierten kleinen Quad-Core-ARM Server in einem Datencenter mit 2GB Ram und 50 GB Speicher.
  3. Der hat unbegrenzt Traffic bei einer Anbindung mit 200Mbit/s
  4. Zusätzlich gibt es eine API, ein potentiell nettes Storage System und schließlich die Möglichkeit, einige wenige Anwendungen per Klick bei der Servererstellung zu installieren.
  5. Erreichbar ist der Server über eine deaktivierbare IPv4-Adresse.

Digitalocean dagegen hat mehrere Angebote:

  1. Ich vergleiche mit dem für 10$ im Monat
  2. Dafür bekommt man derzeit in einer VM einen Single-Core-Prozessor (aber x86_64), 1GB Ram und 30 GB Speicher auf einer wesentlich schneller angebundenen SSD.
  3. Traffic ist begrenzt auf 2 TB, Informationen zur Anbindung habe ich nicht gefunden.
  4. API und Anwendungen per Klick gibt es ebenfalls, nur mehr davon.
  5. Der Server hat eine IPv4-Adresse, kann aber auch Wunsch auch IPv6 bekommen.

In welchem Anwendungsfall wäre Scaleway besser? In meinen Augen dann, wenn man genau in den 10€-Slot fallen würde und die Quad-Core-Cpu nutzen kann. Denn dann bräuchte man bei Digitalocean wahrscheinlich mindestens das 20$-Angebot, für 2GB Ram, 3GB Traffic und eine Dual-Core-Cpu.

Bei allem darüber sind Digitaloceans größere Angebote wahrscheinlich netter, als die Arbeit auf mehrere Scaleway-Server zu verteilen.

Bei allem darunter ist Digitaloceans 5$ Angebot (512MB Ram, 20 GB Speicher, 1TB Transfer) verlockend, da zwar deutlich weniger, aber eben auch halb so teuer und wahrscheinlich ausreichend. Und klar: Für jeden, der einen Heimserver in der Cloud verlockend findet, ist ein solches kleines Droplet wahrscheinlich absolut ausreichend. Und jeder, dem ein solches kleines Droplet ausreicht, könnte auch gleich zu uberspace gehen.

Digitalocean ist übrigens ein Partner in Githubs Studentenprogramm, mit dem Studenten 100$ Credit bekommen, also 20 Monate den kleinsten Server umsonst nutzen könnten. Daher kenne ich sie auch. Immerhin noch 10€ umsonst gibt es bei Anmeldung durch einen Referral-Link wie diesem hier.

Fazit

Trotz der momentanen Überlegenheit von Digitalocean will ich deutlich machen: Scaleway hat Potential. Heimserver im Rechenzentrum sind eine gute Idee und eine mir willkommene Alternative zu Shared Hostern und gewöhnlicheren Cloudanbietern. Das Drumherum macht den Eindruck, als würde das in naher Zukunft wirklich komfortabel werden - derzeit fehlen noch 1-Klick-Images und Dokumentation, aber das dürfte sich geben. Auch die Oberfläche wirkt gut. Sie planen, später noch andere Servertypen anzubieten, auch das könnte nett sein - besonders, wenn sie damit Digitialocens 5$-Plan kontern.

Und hinter Scaleway steht iliad, was die Gruppe ist, deren Ableger free den französischen ISP-Markt schlicht mit dem besseren und günstigeren Angebot erobert hat. Das ist keine schlechte Referenz, und lässt für die Zukunft gutes erhoffen.

Update: Scaleway hat nun den Preis auf 2.99€ gesenkt

Spricht der Mailserver meiner Gegenstelle SSL oder nicht? Wer einen eigenen Mailserver betreibt, der sollte an die Information recht schnell heran kommen – wenigstens im Postfix Log wird protokolliert ob die Verbindung verschlüsselt war oder nicht.

Doch was wenn man mal schnell einen Test machen möchte oder vielleicht eine größere Liste von Domains hat, die geprüft werden muss?

Einzeiler mit openssl

Das geht recht einfach mit einem einfachen Einzeiler und openssl:

echo "QUIT" | openssl s_client -connect mx.example.com:25 -starttls smtp

Doch bitte Vorsicht! Es wird mit dem Mailserver in Kontakt getreten. Einfach die Domain anzugeben reicht nicht aus, ihr braucht den (oder einen der) Mailserver. Den Mailserver könnt ihr z.B. hiermit herausfinden:

root@heinz:~/# dig -t MX google.de

; <<>> DiG 9.7.0-P1 <<>> -t MX google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21899
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;google.de. IN MX

;; ANSWER SECTION:
google.de. 599 IN MX 40 alt3.aspmx.l.google.com.
google.de. 599 IN MX 50 alt4.aspmx.l.google.com.
google.de. 599 IN MX 10 aspmx.l.google.com.
google.de. 599 IN MX 20 alt1.aspmx.l.google.com.
google.de. 599 IN MX 30 alt2.aspmx.l.google.com.

;; AUTHORITY SECTION:
google.de. 65947 IN NS ns3.google.com.
google.de. 65947 IN NS ns1.google.com.
google.de. 65947 IN NS ns4.google.com.
google.de. 65947 IN NS ns2.google.com.

;; ADDITIONAL SECTION:
aspmx.l.google.com. 221 IN A 74.125.136.27
ns1.google.com. 260132 IN A 216.239.32.10
ns2.google.com. 3005 IN A 216.239.34.10
ns3.google.com. 4104 IN A 216.239.36.10
ns4.google.com. 6791 IN A 216.239.38.10

;; Query time: 32 msec

Entsprechend wäre „aspmx.l.google.com“ unser Freund – wobei man natpürlich auch die anderen nehmen könnte.

Ist es nun oder nicht?

Schaut euch den Output einfach an </div>
                <div class= Permalink

22. April 2015

Kleines Tool und doch so nützlich. Kennt ihr timeout?

Was es tut?

Genau was man erwarten würde. Mit timeout startet man einen Befehl, der nach einer Zeit X automatisch beendet wird – wenn er denn nicht vorher schon eh beendet wurde.

Beispiel

Ein völlig unsinniges Beispiel:

root@heinz:~/# timeout 10 sleep 15
Timeout: aborting command ``sleep'' with signal 9
Killed

Nützlich bspw. bei Befehlen, die keinen eigenen Parameter für einen Timeout haben.

20. April 2015

Etwas aus vim mit Tagbar oder mutt mit Sidebarpatch kopieren ist halt immer irgendwie kacke. Bei weechat gibts das gleiche Problem mit dem buffers Plugin und der nicklist.

Kreuz und quer Pipes und nicks drin. Nervt. Deshalb hier zwei kleine Aliases, die ich mir gebastelt hab.

/alias hidebars /bar hide nicklist ; /bar hide buffers
/alias showbars /bar show nicklist ; /bar show buffers

So ist’s für mich am Einfachsten irgendwelches Zeugs aus IRC zu kopieren.

  • /hidebars
  • Copy
  • /showbars

Firefox 37.0.2 ist das zweite außerplanmäßige Update für Firefox 37. Damit behebt Mozilla Grafikprobleme und schließt eine Sicherheitslücke.

Download Mozilla Firefox 37.0.2 für Windows, OS X und Linux

Mit Firefox 37.0.2 verbessert Mozilla die Stabilität in Zusammenspiel mit bestimmten Grafikkarten durch Blockieren der Hardware oder einzelner Features, was sich zuvor in einem schwarzen Videobild auf YouTube, Grafikfehlern auf Google Maps oder durch Abstürze bei Programmstart äußern konnte. Darüber hinaus behebt Mozilla mit dem Update eine Sicherheitslücke.

Suspend to Ram hat den kleinen nervigen Bug, dass die Festplattenparameter verloren gehen. Zumindest gilt das auf meinem System, bei dem ich den Standby-Modus via s2ram und damit uswsusp nachgerüstet habe. Bei mir sind die per hdparm gesetzten Parameter wichtig, denn darüber werden die sonst zu lauten Festplatten nach kurzer Inaktivität schlafen geschickt (hpdarm -S 24 …).

Die einfache Lösung ist, den s2ram-Befehl in ein Skript /usr/local/bin/standby zu wrappen, das nach dem Suspend hdparm ausführt:

#!/bin/sh
s2ram
hdparm -S 24 /dev/disk/by-uuid/AA38C5FE38C5C991
hdparm -S 24 /dev/disk/by-uuid/0be0233d-c885-4492-9e57-f81df851ca25

Dieses Skript per sudo ausführen, und 2 Minuten nach dem Start ist wieder Ruhe.

Dafür steht in meiner ~/.icewm/menu:

prog standby standby sudo /usr/local/bin/standby

Das Skript ist über sudo visudo freigeschaltet, sodass kein Passwort benötigt wird.

19. April 2015

Heute musste ich feststellen, dass ein Teil der Monitoring Software Shinken auf meinem Raspberry Pi nicht mehr lief. Genauer gesagt hat sich der Poller still und heimlich beendet und der Prozess war auch nicht mehr zu sehen. Nachdem ich den Dienst 

shinken-poller
wieder neu gestartet habe, war alles wieder gut. Das passiert zwar selten, aber zukünftig soll ein Script den Neustart des Dienstes übernehmen.

Folgendes Bash Script habe ich also (als root) angelegt und mit 

chmod u+x
ausführbar gemacht.
#!/bin/bash
MAIL_ADDRESS="foobar@example.org"

# check poller
if ! ps aux | grep -v grep | grep shinken-poller > /dev/null
then
        /usr/sbin/service shinken-poller restart > /dev/null
        MSG+="Shinken poller restarted\n"
fi

# check scheduler
if ! ps aux | grep -v grep | grep shinken-scheduler > /dev/null
then
        /usr/sbin/service shinken-scheduler restart > /dev/null
        MSG+="Shinken scheduler restarted\n"
fi

# send mail
if [ -n "$MSG" ]
then
        echo -e "$MSG" | mail -s 'Shinken watchdog' "$MAIL_ADDRESS"
fi

Mit 

crontab -e
schnell habe ich schnell folgenden Cronjob erstellt:
*/5 * * * * /usr/local/sbin/shinken-watchdog.sh

Sollte der Dienst neugestartet werden müssen, wird eine E-Mail an die angegebene E-Mail Adresse gesendet. Das Script ist zwar sehr simpel und nicht für alle denkbaren Zwecke geeignet, in diesem Falle ist es aber vollkommen ausreichend. Nur alle paar Monate passiert es, dass der Poller oder Scheduler sich beendet, aber ein einfacher Neustart hat auch bisher immer zum Erfolg geführt.

Mit der Ouya lassen sich jetzt auch richtige PC-Spiele bequem auf dem Sofa zocken. Die hardware-mäßig schmalbrüstige Android-Konsole streamt mit der App „Limelight“ einfach die Spiele vom Gaming PC auf den Fernseher. 

Zugegeben, ich war zu Anfang ein wenig enttäuscht von der Ouya. Die verfügbaren Spiele waren zum Teil krude schlecht. Das hat sich mittlerweile sehr gebessert. Es sind einige wirklich schöne Spiele verfügbar. An eine Xbox oder eine Playstation kann sie schon wegen der schwachen Hardware nicht heranreichen. Bislang diente das Gerät bei mir deswegen als Mediencenter: XBMC aka Kodi und die per sideload installierte App von Watchever sorgten für Unterhaltung.

Seit einiger Zeit gibt es nun die Limelight App und ich hatte jetzt erst die Gelegenheit die einmal auszuprobieren. Die App kann sich mit einem PC im Netzwerk verbinden, der über eine aktuelle NVidia-Grafikkarte und die Software GForce Experience verfügt. Alle Spiele, die diese Software auf dem PC findet, können dann auf die Ouya gestreamt werden.

Steam zum Beispiel ist bereits voll darauf ausgelegt und lässt sich im Konsolen-Modus starten und dann voll über den Controller bedienen. Die Spiele sind auf diesen Modus voreingestellt und arbeiten problemlos mit dem Controller zusammen. Testweise habe ich das letzte Tomb Raider und GRID angespielt. Bis auf die Tatsache, dass ich nicht besonders gut in Rennspielen bin, hat das hervorragend funktioniert. Ganz selten kommt die Übertragung ins Ruckeln. Bei der Steuerung habe ich nichts davon gemerkt, dass alle Eingaben und Ausgaben über ein WLAN liefen. Den ersten ernsthaften Test habe ich dann mit Brothers – A Tale of Two Sons durchgeführt und das Spiel gleich durchgespielt. Das hat perfekt funktioniert.

Wer einen PC mit NVidia-Grafikkarte hat und ein Android-Gerät, sollte sich Limelight einmal anschauen. Bei Youtube gibt es jede Menge Videos von Leuten, die aktuelle Games auf einem alten Smartphone spielen. Warum man den 19″ Monitor gegen einen 4″ Monitor eintauschen sollte, verstehe ich nicht. Auf der großen Glotze im Wohnzimmer aber macht es echt Spaß.

Video

Links

18. April 2015

Neues aus der Mozilla Design-Schmiede. Unter diesem Titel wird in regelmäßigen Abständen über aktuelle Mockups, Design-Experimente und Ähnliches berichtet. Manches davon wird in dieser oder ähnlicher Form sicher den Weg in ein Mozilla-Produkt finden, anderes wird vielleicht nie über den Status eines Entwurfes oder Experiments hinausgehen, viele Ideen entwickeln und verändern sich über die Zeit und diese Entwicklungen werden wir in dieser offenen Serie beobachten können. Heute geht es um das mögliche Design des kommenden Privatsphäre-Kontrollzentrums, welches das bisherige Identitätspanel ersetzen wird.

Bereits letzten Monat wurden auf diesem Blog Mozillas Pläne vorgestellt, das Identitätspanel von Firefox, welches Informationen zur Verschlüsselung und Identität der Webseite anzeigt, zu erweitern und dem Nutzer Optionen zur Steuerung der Privatsphäre in Zusammenhang mit der jeweiligen Webseite zu geben. Während die damals veröffentlichten Wireframes bereits eine Idee vom geplanten Funktionsumfang gegeben haben, gibt es nun erste echte Mockups, welche zeigen, wie das Ganze aussehen könnte. Wie immer gilt: kann, muss nicht. Anders gesagt: die Mockups zeigen die allerneusten Vorschläge von Firefox-Designer Stephen Horlander, bis zur Implementierung können sich Dinge auch noch ändern.

Kontrollzentrum v1:

Kontrollzentrum v2:

Distrochooser Logo

Etwas früher als geplant ersetzt der Linux Distribution Chooser 2 die bisherige Version. Die alte Version ist weiterhin unter http://distrochooser.0fury.de/ldc1/ erreichbar, wird jedoch nicht mehr aktualisiert.

Falls somit jemandem – warum auch immer – der alte Distrochooser eher zusagt, kann er diesen auch immer noch nutzen.

Der neue Distrochooser verlässt damit die Phase einer Vorschauversion und wechselt in das Stadium der Finalisierung.

Ich führe bereits jetzt diesen Schritt durch, weil mich das Feedback dazu verleitet hat. Viele Kritiken beziehen sich auf fehlende Distributionen oder Funktionswünsche, oftmals auch Trolling. Das reine Grundprinzip steht und kann nun auch verwendet werden.

Bitte beachtet, dass die Domain distrochooser2.0fury.de ab sofort nicht mehr genutzt wird und daher nicht mehr verlinkt werden soll. Alle Links sollten auf http://distrochooser.0fury.de laufen. „Falsche“ Links auf distrochooser2.0fury.de werden ab sofort auf http://distrochooser.0fury.de umgeleitet.

Mit dem Update sind heute Kubuntu, Lubuntu und Xubuntu im Distrochooser aufgenommen worden.

Rein technisch sind noch ein paar Neuerungen sowie die Überarbeitung der Matrix in Arbeit, seid also gespannt

Ein beliebtes Format in Blogs sind die täglichen Linksammlungen. Beim Landesblog zum Beispiel haben wir die Nordlinks. All das, was den Blogbetreibern den Tag über in die Quere gekommen ist, wird abends kommentiert ins Blog gestellt. Komplett manuell ist das eine nervige Tätigkeit. Es geht aber auch einfacher.

Nach dem Linux-Motto: „Für jede Aufgabe ein Tool“ teilen wir die Aufgaben beim Landesblog in das Sammeln und das Veröffentlichen auf:

  1. Wir sammeln die Links tagsüber per Delicious. Der Social Bookmark Dienst bietet alles, was man dafür benötigt: Ein Bookmarklet oder ein Plugin für den Browser oder Apps für das Smartphone. Was wir bei Delicious als Überschrift und Beschreibung speichert, landet hinterher so im Blog. Alle Beiträge müssen ein gemeinsames Schlagwort haben – sonst klappt es nicht mit dem Schritt 2. Ein weiterer Vorteil an dieser Lösung ist, dass alle Redaktions-Mitglieder mitsammeln können und wenn man will, kann man die Links direkt beim Sammeln schon twittern lassen oder bei Facebook posten.
  2. Zum Veröffentlichen ist natürlich WordPress gut geeignet. Dafür gibt es das Plugin „Delicious Curator„. Dem gibt man den Namen des Delicious-Accounts an, das Schlagwort, das übernommen werden soll und die maximale Anzahl Links. Dazu kann man einstellen, in welcher Form die Links übernommen werden soll. Wir haben dort eine einfache nummerierte Liste vorgesehen.
    Wenn wir nun abends den Link-Artikel schreiben wollen, gehen wir in die Administration des Plugins, wählen den Autor aus und klicken auf „Run Now“. Es legt dann einen Entwurf für einen neuen Artikel an, der die Liste der Links enthält. Der bekommt dann noch den Standard-Text hinten dran kopiert und eine individuelle Einleitung und dann wird der veröffentlicht.

Mit dieser Lösung arbeiten wir jetzt seit einem halben Jahr und es klappt ganz gut. Ein kleines Problem ist, dass die Benutzer Adminrechte haben müssen, um in die Verwaltung des Plugins zu kommen – es kann also nicht jeder posten.

Links

17. April 2015

Viele Linux Nutzer kennen das Problem. Die Auswahl der Distributionen ist groß und allesamt haben sie ihre Vor- und Nachteile und zeichnen sich durch Flexibilität, Stabilität oder Einfacheit aus. Nun habe ich mich auf meinem Desktop PC von Fedora verabschiedet und Arch Linux installiert. Warum?

Ich habe mich während meines Studiums für Fedora entschieden, nachdem ich mit Arch Linux hin und wieder ein paar Probleme beim Updaten hatte, die mir zu viel Zeit abverlangt haben. Sicherlich waren das keine unlösbaren Probleme, aber mir hat die Zeit dafür gefehlt. Inzwischen habe ich zwar nicht mehr Zeit, aber mehr Erfahrung, mit der ich die Probleme hoffentlich schneller lösen kann. Da ich inzwischen mit dem Studium fertig bin, kann ich auch mal einen Tag auf einen lauffähigen Rechner verzichten, sollte ich etwas verbocken.

Arch Linux ist ein Rolling Release, d.h. es gibt keine festen Versionen der Distribution, stattdessen werden Paketupdates und -upgrades kontinuierlich veröffentlicht. Änderungen in den Programmen erfordern dann manchmal manuelle Anpassungen am System. Fedora, welches ich aufgrund meiner häufigen Arbeit mit CentOS sehr schätze, veröffentlicht 1-2 Mal pro Jahr eine neue Version. Updates innerhalb einer Version sind i.d.R. immer problemlos einspielbar. Leider verhielt es sich mit den Upgrades (also z.B. von Fedora 19 auf 20, oder 20 auf 21) etwas anders. Nach den Upgrades war das System zwar immer noch lauffähig, es kamen aber immer ein paar kleine Probleme hinzu. Seit Monaten habe ich mich u.a. mit störenden USB Problemen (USB Speichergeräte konnten oft nicht gemountet werden) herumgeplagt, die ich einfach nicht zu lösen vermochte. In einer virtuellen Maschine habe ich mir dann eine Arch Linux Installation vorbereitet, die ich kürzlich dann auf meinen Desktop PC kopiert habe.

Da meine letzte Arch Linux Installation schon eine Weile her ist, habe ich mir noch einmal schnell die Anleitung für Einsteiger angesehen und konnte Arch Linux dann schnell und problemlos installieren. Zugegeben, Gnome 3 gefällt mir inzwischen sehr und deswegen habe ich es auch hier wieder installiert. Von meiner Fedora Installation habe ich natürlich vorher ein Backup gemacht, aus dem ich dann auch meine persönlichen Daten und ein paar Scripte zurückkopiert habe. Yaourt habe ich auch installiert, um an ein paar interessante Pakete aus dem Arch User Repsository zu kommen. Möchte man hin und wieder nachsehen, welche Pakete man aus dem AUR installiert hat, kann man sich mit Pacman die installierten Fremdpakete anzeigen lassen:

pacman -Qm

Außer der Installation von Firefox, Thunderbird, LibreOffice und ein wenig Kleinkram habe ich IPTables und das Monitoring konfiguriert, den User für das Rsnapshot Backup eingerichtet und die enorm riesigen Icons von Nautilus auf die kleine Listenansicht umkonfiguriert. Das hat ehrlich gesagt schon gereicht, was brauche ich mehr?

Wer auf der Suche nach der richtigen Distribution ist, sollte einen Blick auf den Distrochooser (oder wie ich ursprünglich sagen wollte: Distrochooser2) von 0fury.de werfen. Wer sich wirklich unsicher ist, kann ein paar Fragen beantworten und findet ein paar gute Hinweise für die richtige Distribution.

Ubuntu 15.04 in Ehren, aber wirklich zwingende Gründe, Abschied von Ubuntu 14.04 LTS zu nehmen, gibt es keine. Ganz anders sieht es mit Kubuntu 15.04 aus, das optisch dank Plasma 5 einen Riesensprung nach vorne macht und so schön wie nie zuvor aussieht.

Der Default-Desktop von Kubuntu 15.04
Der Default-Desktop von Kubuntu 15.04

Diese Version könnte Kubuntu zum Durchbruch verhelfen! Auf der Hit-Liste von <distrowatch.com> befindet sich Kubuntu momentan eher abgeschlagen hinter Ubuntu, Lubuntu und Xubuntu auf dem traurigen 31. Rang.

Der Kubuntu-Desktop wird von zwei Komponenten geprägt:

  • Einerseits natürlich die KDE Software Compilation in der aktuellen Version 4.14 inklusive der KDE Applications 14.12. Die KDE Software Compilation ist die Summe aller KDE-Programme, die den KDE-Desktop prägen, vom Dateimanager über das Terminal-Fenster bis hin zur Kontact-Suite zur Verwaltung von Mails, Terminen und Kontakten.
  • Andererseits Plasma in der Version 5.2. Plasma ist für das moderne Aussehen des Desktops verantwortlich.

Leseempfehlung: Werfen Sie einen Blick auf diesen detaillierten Artikel zur KDE-Nomenklatur!

Kubuntu 15.04 ist die erste populäre Linux-Distribution, die standardmäßig Plasma 5.2 verwendet. (Unter openSUSE 13.2 kann Plasma 5.2 unkompliziert nachinstalliert werden.)

Davon abgesehen übernimmt Kubuntu 15.04 natürlich auch die Basisänderungen in Ubuntu 15.04, insbesondere also die Umstellung des Init-Systems auf Systemd.

Ein Bild sagt mehr als 1000 Worte …

Installationsprogramm
Installationsprogramm
Terminal und Dateimanager
Terminal und Dateimanager
Das Panel und das Startmenü befinden sich normalerweise unten, ich finde diese Komponenten am linken Rand praktischer
Das Panel und das Startmenü befinden sich normalerweise unten, ich finde diese Komponenten am linken Rand praktischer
Systemeinstellungen
Systemeinstellungen

Update 21.5.2014

Mittlerweile habe ich Kubuntu 15.04 einen Monat im Einsatz auf meinem Arbeits-Notebook. Meine Erfahrungen habe ich hier zusammengefasst.

Während ich im Artikel „Automatische Installation von Sicherheitsupdates“ beschrieben habe, wie man Sicherheitsupdates unter Ubuntu automatisch installieren lassen kann, werde ich hier kurz beschreiben, wie das lokale Paketarchiv automatisch bereinigt werden kann.

In der Datei /etc/apt/apt.conf.d/10periodic gibt es unter anderem den folgenden Eintrag:

APT::Periodic::AutocleanInterval "0";

Dieser Wert gibt an, in welchem Intervall (in Tagen) das lokale Archiv der Paketquellen bereinigt werden soll. Dieser Wert steht standardmäßig auf „0“. Damit wird das Paketarchiv gar nicht automatisch bereinigt. Um dies zu ändern trägt man hier einfach einen Wert seiner Wahl ein. So lasse ich das Paketarchiv bspw. alle 28 Tage bereinigen:

APT::Periodic::AutocleanInterval "28";

Viele Grüße
Tronde

Ubuntu 15.04 »Vivid Vervet« ist fast fertig — Zeit also, einen Blick auf die neueste Ubuntu-Version zu werfen.

Ubuntu 15.04
Ubuntu 15.04

Systemd

Die Release Notes fassen die Neuerungen in Ubuntu 15.05 in einem Satz zusammen:

The general theme for 15.04 on the desktop is one of bug fixes and incremental quality improvements as well as a more significant change in the move to systemd as an init system.

Anders formuliert: Die einzig wirklich relevante Neuerung — abgesehen von den üblichen Bugfixes und Software-Updates — ist der nun erfolgte Umstieg auf Systemd in der Version 219. Systemd ist damit das neue Init-System von Ubuntu. Es löst Upstart ab, das nur noch gewartet wird. (Ubuntu 14.04 LTS hat ja noch eine Lebensdauer von 4 Jahren, und es verwendet Upstart.)

Tatsächlich ist der Umstieg auf Systemd noch sehr halbherzig. Sowohl die Systeminitialisierung als auch der Start von Systemdiensten (Dämonen) erfolgt überwiegend durch herkömmliche Init-V-Scripts, die Systemd dank seiner Kompatibilität zum Init-V-System ausführt. In /etc/init.d befinden sich nach einer Default-Installation + SSH 68 Scripts. (Zum Vergleich Fedora 21: ganze 4 Scripts!)

find /etc/init.d -executable | wc
  68

Versionsnummern

Basis           Desktop            Programmierung     Server
--------------  ------------------ --------------    --------------
Kernel    3.19  Gnome        3.14  bash       4.3    Apache    2.4
glibc     2.21  KDE          4.14  gcc        4.9    CUPS      2.0
X-Server  1.17  Firefox        37  Java       7/8    MySQL     5.6
GRUB      2.02  Gimp          2.8  PHP        5.6    OpenSSH   6.7
Systemd    219  LibreOffice   4.4  Python 2.7/3.4    qemu/KVM  2.2
                Thunderbird    31                    Postfix   2.11
                Unity         7.3                    Samba     4.1

Als Alternativ zu MySQL gibt es MariaDB-Pakete (universe-Paketquelle) in der Version 10.

Sonstiges

  • Die Live-System weist momentan einen Fehler auf. Wird beim Start der Eintrag Ubuntu ausprobieren gewählt, ist anschließend ein Login erforderlich. Der richtige Login-Name und das Passwort sind mir nicht bekannt. Sie können das Live-System daher nur zur unmittelbaren Installation verwenden (Startmenü Ubuntu installieren). Dieses Problem ist im Final Release behoben.
  • Bei meinen Tests in einer virtuellen Maschine (Virtual Box) endete die Installation mit diversen Squashfs errors. Nach dem Neustart funktionierte Ubuntu aber klaglos.

  • Nautilus ist nur noch per Menü bedienbar, alle in irgendeiner Form nützlichen Buttons wurden aus der Symbolleiste entfernt :-(

  • Menüs werden weiterhin nur angezeigt, wenn Sie Alt drücken oder die Maus in das Panel bewegen. Immerhin bietet Ubuntu jetzt aber die Möglichkeit an, Menüs ständig anzuzeigen. Dazu führen Sie in einem Terminal-Fenster das folgende Kommando aus:

    gsettings set com.canonical.Unity always-show-menus true

    Wenn Sie das Zentralmenü nicht glücklich macht, können Sie die Menüs auch direkt in der Fensterleiste anzeigen. Eine entsprechende Option finden Sie im Modul Darstellung der Systemeinstellungen.