Planet › ubuntuusers.de

Name	In x Auswertungen enthalten
Arch Linux	2806
Ubuntu	2799
Manjaro	2820
Linux Mint	2774
Debian	2972
Mageia	2849
Fedora	2791
openSuse	2933
elementary OS	2827
PCLinuxOS	2854
CentOS	2809
Puppy Linux	2763
Knoppix	2780
Gentoo Linux	2782
Antergos	2823
Bedrock Linux	2783
Tails	925
Zorin OS	2896
Xubuntu	2565
Lubuntu	2631
Kubuntu	2560
Slackware	2608
Ubuntu MATE	2508

Name	In x Auswertungen enthalten
Arch Linux	2806
Ubuntu	2799
Manjaro	2820
Linux Mint	2774
Debian	2972
Mageia	2849
Fedora	2791
openSuse	2933
elementary OS	2827
PCLinuxOS	2854
CentOS	2809
Puppy Linux	2763
Knoppix	2780
Gentoo Linux	2782
Antergos	2823
Bedrock Linux	2783
Tails	925
Zorin OS	2896
Xubuntu	2565
Lubuntu	2631
Kubuntu	2560
Slackware	2608
Ubuntu MATE	2508

Fryboyter 30. April 2015 23:56

Alias für Services unter systemd ¶

Manche Services unter systemd haben ziemlich umständliche Bezeichnungen. Systemd-networkd.service oder openvpn@vpn.service zum Beispiel. Um es sich beim Aktivieren, Deaktivieren oder Neustarten etwas einfacher zu machen, kann man hier zu einem Alias greifen. Nehmen wir mal openvpn@vpn.service als Beispiel.

Hier öffnet man einfach die Datei openvpn@vpn.service welche unter /etc/systemd/systemd/multi-user.target.wants/ liegt. Diese sollte wie folgt aussehen.

[Unit]
Description=OpenVPN connection to %i 

[Service]
Type=forking
ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config /etc/openvpn/%i.conf --da$ 
PIDFile=/run/openvpn@%i.pid 

[Install]
WantedBy=multi-user.target

Soll der Service auf den Alias vpn1 reagieren, muss man einfach unter [Install] Alias=vpn1.service hinzufügen. Wichtig ist hier, dass der Alias die gleiche Endung hat wie das Original. Also in dem Fall .service. Hier kann man auch mehrere Aliase angeben, welche man in die gleiche Zeile mit einem Lehrschritt getrennt eingibt.

Hat man die Datei nun entsprechend geändert und abgespeichert aktiviert man den Service mittels systemctl enable openvpn@vpn.service. Hiermit wird nun ein Symlink vpn1.service angelegt, welcher auf openvpn@vpn.service verweist. Von nun an kann dieser “Service” anstelle des Originals genutzt werden. Also beispielsweise systemctl status vpn1.service.

Permalink

Sören Hentzschel 30. April 2015 23:00

Mozilla bereitet standardmäßige Aktivierung der Multiprozessarchitektur für Firefox Developer Edition 40 vor ¶

Unter dem Namen Electrolysis, kurz: e10s, arbeitet Mozilla an einer Multiprozessarchitektur für Firefox. Die standardmäßige Aktivierung in der Developer Edition soll bereits in zwei Wochen erfolgen.

Die Multiprozessarchitektur für Firefox ist schon einige Zeit in Entwicklung. Anfang November erfolgte die standardmäßige Aktivierung in der Nightly-Version, allerdings noch spürbar weit von einer Fertigstellung entfernt. Seit dem hat sich sehr viel getan, so dass Mozilla nun kurz vor dem nächsten wichtigen Meilenstein steht: wenn in etwas mehr als zwei Wochen die Developer Edition von Firefox 40 erscheint, soll die neue Multiprozessarchitektur standardmäßig aktiviert sein. Auf der Roadmap stehen derzeit noch 27 Tickets, die Mozilla bis zum nächsten Aurora-Merge am 11. Mai schließen möchte.

Auch optisch deuten sich die Fortschritte an: ab der morgen erscheinenden Nightly-Version werden die Tabs bei aktivierter Multiprozessarchitektur nicht mehr unterstrichen sein. Stattdessen wird beim Herüberfahren mit der Maus über einen Tab ein ” – e10s” an den Seitentitel im Tooltip drangehängt. Außerdem gibt es ab morgen bei deaktivierter Multiprozessarchitektur nicht länger die Schaltfläche zum Öffnen eines e10s-Fensters im Firefox-Menü. Umgekehrt zum Öffnen eines Nicht-e10s-Fensters bei aktivierter Multiprozessarchitektur wird es weiterhin eine Menü-Schaltfläche zum Testen geben.

Wichtig: eine standardmäßige Aktivierung in der Developer Edition 40 ist nicht gleichzusetzen mit einer geplanten Veröffentlichung in der finalen Version von Firefox 40. Derzeit plant man mit Firefox Beta 41 und Firefox Final 42, aber dies sind Zielsetzungen und keine fixen Termine. Gleiches gilt natürlich auch für e10s in der Developer Edition 40, auch hier kann grundsätzlich noch etwas dazwischen kommen.

Update 06.05.2014: Die standardmäßige Aktivierung in der Developer Edition wird Mozilla aller Voraussicht nach in Version 41 vornehmen, in Version 40 wird die Aktivierung als Opt-In-Option angeboten. Geplant ist weiterhin die Aktivierung in Firefox Beta 41 oder Beta 42.

Permalink

Erfahrungen mit Ubuntu 30. April 2015 21:20

Zielverzeichnis für Datensicherung bei ejabberd ¶

Zur Datensicherung bei ejabbberd nimmt man einfach
das Tool ejabberdctl.
Folgender Befehl sichert die Datenbank:

ejabberdctl backup /tmp/jabberdaten

Wichtig ist es hier bei Ubuntu (12.04) das Verzeichnis /tmp zu nutzen.
Das Zielverzeichnis von der Datensicherung muss für den ejabberd Benutzer
beschreibbar sein. Das erreicht man am leichtesten mit dem tmp Verzeichnis.
Danach die Daten dort allerdings wegkopieren, da sie beim Neustart gelöscht werden...

Zum Zurücklesen benutzt man übrigends den Befehl:

ejabberdctl restore /tmp/jabberdaten

Permalink

(Mer)Curius 30. April 2015 17:53

Papierloses Büro mit Linux ¶

Das so genannte papierlose Büro ist der nächste heiße Trend seit Jahren, damit hat es was mit Linux auf dem Desktop gemein. Die Wahrscheinlichkeit, dass es sich im Beamtenland Deutschland flächendeckend durchsetzt, kann man wohl auch mit den Chancen von Linux auf dem Desktop vergleichen. Leider kann man auch nicht jedes Dokument scannen und wegschmeißen, einiges muss man in Papierform aufbewahren. Vieles aber auch nicht, weshalb mein Technik-Vorsatz für das Jahr 2015 die Umstellung auf weitestgehend papierlosen Bürobetrieb ist.

Empfehlungen sind da immer schwer zu geben. Während manche nur ein paar Rechnungen im Briefkasten finden, haben andere ein Home-Office und mancher Dokumentenmessie hat sogar noch die Strafzettel von 1995 fein säuberlich abgeheftet. Ausschlaggebend für meine Entscheidung war ein Umzug und gefühlte 200 Ordner, die von einem Keller in den nächsten gewandert sind. Für meinen nächsten Umzug möchte ich mir das gerne ersparen.

bortherads2100

Die Hardware

Ein Scanner mit Einzug ist natürlich Pflicht, aber auch hier ist das Angebot äußerst vielfältig und die Preisspanne reicht von wenigen hundert Euro bis zum Mond. Linux-Nutzer müssen nebenbei noch die Treibersituation überprüfen, die von vielen Herstellern ~~bewusst verschleiert~~ nicht eindeutig beschrieben wird. Hier auf dem Schreibtisch steht nun mit dem Brother ADS 2100 eher ein Einsteigergerät, aber das muss jeder selbst entscheiden. Ausschlaggebend für Brother waren (neben den guten Erfahrungen mit einem Drucker desselben Herstellers) die direkt vom Hersteller für Linux angebotenen Treiber.

Das Gerät gibt es mittlerweile in diversen Online-Shops für relativ schmales Geld und bietet alle Funktionen, die ich mir so wünsche:

Offizielle Linux / SANE Treiber
Duplex-Scanner
Ein ADF-Fach mit Platz für 50 Seiten
Keine Hochglanzoberflächen (außer die Oberseite der Klappe)
600 dpi Auflösung (mehr kann mein Drucker auch nicht)

Ganz einfach macht es Linux einem trotz Hersteller-Treiber mal wieder nicht. Neben den auf der Homepage von Brother angebotenen Treibern für SANE muss man noch die Regeln für udev anpassen, damit der Scanner auch für normale Nutzer zur Verfügung steht. Debian/Ubuntu Nutzer können dafür ein Paket von Brother nutzen, alle anderen müssen manuell die richtige Datei bearbeiten. Steht zwar alles auf der Homepage, aber wenn man das erste Mal einen Scanner unter Linux betreibt, ärgert man sich doch über die Komplexität. Das erinnert an die Drucker-Installation unter Linux im Jahr ~2005.

Nachdem man diese Hürde hinter sich gebracht hat, funktioniert der Brother ADS 2100 hervorragend mit Linux und lässt keine Wünsche offen. Selbst verknitterte oder ehemals zusammen getackerte Papiere scannt er ohne Problem ein. Lediglich die Lautstärke hatte ich im Vorfeld unterschätzt. Aber man scannt ja nicht den ganzen Tag.

Die Software

Für die Scan-Software gilt immer noch der Satz aus dem ubuntuusers-Wiki:

[zt_blockquotes author="ubuntuusers-Wiki - Artikel Scanner" author-link="http://wiki.ubuntuusers.de/Scanner" extra-class="blockquotes"]Leider sind Scannerprogramme unter Linux nicht vergleichbar zu den Programmen, die man unter Windows kennt. Es fehlen durchweg wichtige – professionelle – Funktionen (z.B. Entrastern oder Staub/Fleckenentfernung).[/zt_blockquotes]

Das KDE-Programm skanlite eignet sich eigentlich nur für Flachbettscanner, da es weder mehrseitige Scans unterstützt, noch im PDF-Format speichern kann. Das Programm ist allerdings wenigstens so eindeutig unzureichend, das man es gar nicht erst in die nähere Wahl nehmen muss. Der Klassiker unter den Scan-Programmen für Linux ist sicherlich XSane. Ein Programm, bei dem man versteht weshalb so viele Linux-Nutzer glauben, dass die Konsole immer besser als jede GUI ist. Jeder noch so kryptische Befehl ist einfacher zu handhaben, als die Oberfläche von XSane mit seinen perfekt versteckten Optionen und vielen Fenstern. Gnome-Nutzer können Simple Scan verwenden. Für den Regelbetrieb bietet es genug Optionen und ist hinreichend einfach zu bedienen.

Wer mehr Optionen benötigt, sollte sich gscan2pdf ansehen. Ein in Perl geschriebenes Programm mit Gtk-Oberfläche, das bei allen Distributionen in den Paketquellen zu finden sein dürfte. Unter Debian/Ubuntu lässt sich es einfach installieren:

$ sudo apt-get install –no-install-recommends gscan2pdf

Die empfohlenen Abhängigkeiten sollten vor allem KDE-Nutzer abschalten, da man sonst Gefahr läuft sich unnötigerweise eine halbe Gnome-Umgebung auf die Festplatte zu holen.

Für die OCR-Texterkennung sollte man zusätzlich noch die Tesseract Pakete installieren. Tesseract wird inzwischen federführend von Google entwickelt und bietet eine relativ gute Texterkennung, ohne die in einem papierlosen Büro nichts funktioniert.

$ sudo apt-get install tesseract-ocr tesseract-ocr-deu

Der Dialog von gscan2pdf lässt einen eigentlich alle nötigen Einstellungen treffen. Besonders beachten muss man die im Reiter Mode festgelegte Auflösung, die standardmäßig mit 200 dpi zu niedrig angesetzt ist.

Ablage und DMS

DMS (Dokumenten Management Systeme) gibt es wie Sand am Meer und auch für Linux ist das Angebot nicht schlecht. Je nach Papieraufkommen und Anzahl der zugreifenden Benutzer/Rechner muss es aber nicht immer ein DMS sein. Ein funktionierendes DMS ist natürlich erst einmal einer einfachen Ablage via Ordnerstruktur überlegen. Die Entscheidung für ein papierloses Büro ist aber eine Festlegung auf viele Jahre und kaum eine Software wird ewig entwickelt. Die Gefahr am Ende eine Datenbank zu haben, die man nicht mehr ohne weiteres lesen kann oder deren Exportfunktion zumindest verlustbehaftet ist, dürfte immens sein.

Hinzu kommt, dass moderne Betriebssysteme und Desktopumgebungen inzwischen sehr gute Suchfunktionen und Dateimanager haben. Eine gute Verschlagwortung der Dateien im Titel und eine wohl überlegte Ordnerstruktur, kann in Kombination mit einer Suche wie KDE’s Baloo ein DMS ersetzen. Die fehlenden Funktionen kompensiert die Gewissheit, dass die eigene Ordnerstruktur sich notfalls auch mit geringen Verlusten auf andere Systeme übertragen lässt.

Ein papierloses Büro erfordert natürlich umso mehr Aufmerksamkeit für Verschlüsselung des Systems, sowie der Backupmedien und über eine sinnvolle Backup-Verwaltung. Für letzteres würde ich zur Zeit BackInTime empfehlen. Das kann übrigens auch verschlüsselte Backups erstellen, allerdings nur mit EncFS, was wohl nicht allzu sicher ist.

Permalink

(Mer)Curius 30. April 2015 17:53

Literatur-Verwaltung unter Linux ¶

Wenn das Thema auf Literaturverwaltung & Co kommt, kann man eigentlich nur vom Einsatz von Linux abraten. Literaturverwaltung, Wissensmangement und alles was damit zusammen hängt gehört nicht zu den Stärken des Linux-Desktops. Man muss schon enorme anderweitige Vorteile durch den Einsatz von Linux erzielen, damit man die Abstriche in diesem Bereich in Kauf nimmt. Die beiden großen Platzhirsche des Bereiches, EndNote und Citavi, lassen sich nicht unter Linux einsetzen. Für Citavi gibt es zwar eine Wine-Lösung, basierend auf der älteren Version 3.x, aber das kann je nach Wine- und/oder Citavi Update auch wieder nicht funktionieren. Ein Zustand, der bei langfristigen Projekten nicht in Frage kommt. Zumal man sich von einer Lösung abhängig macht, da der Im- und Export der Daten immer verlustbehaftet ist.

Der geneigte Anhänger der Unix-Philosophie würde hier zwar mit Phrasen um sich werfen um die Diskussion im Keim zu ersticken (“Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen.“). Das Problem ist nur, dass man Citavi noch nicht mal mit drei Softwarelösungen unter Linux ersetzen kann. Nun aber genug der Worte über nicht vorhandene Software und Philosophien, deren aktuelle Auslegungen zum Ziel haben den Status quo zu zementieren.

Möglichkeiten der Literaturverwaltung unter Linux

Dadurch bleiben für den Linux-Desktop eigentlich nur zwei bzw. drei Lösungen übrig. Erstens webbasierte Lösungen, ggf. mit einem lokalen Client (z.B. Mendeley), zweitens Frontends für das BibTeX Format (z.B. JabRef oder KBibTeX) und drittens Zotero. Letzteres gibt es als Firefox-Addon oder als Standalone-Version. Alle Lösungen sind mit enormen Abstrichen gegenüber den führenden Windows-Produkten zu nutzen, aber eine dauerhafte Literaturverwaltung in einer virtualisierten Windows-Umgebung ist ebenfalls mit deutlichen Komfortverlusten verbunden und deshalb keine wirkliche Alternative.

Die für Linux vorhandenen Softewarelösungen haben alle Stärken und ~~viele~~ Schwächen:

Die mächtigste Lösung ist hier zur Zeit Zotero. Dieses kann Literatur verwalten, zugehörige Notizen sicher gruppieren und an Literaturtitel angehängte Dateien verwalten. Zudem gibt es eine Reihe von Addons (z.B. für Microsoft Office und LibreOffice) und Zitationsstilen, die eine schnelle Übernahme in das Office-Programm der Wahl ermöglichen.
Mendeley spielt seine Stärken hingegen eher in der PDF-Verwaltung aus. Durch die Synchronisation von Anmerkungen über den Webaccount, ist es vor allem für PDF-gestützte Arbeiten von großem Wert. Wer hingegen klassisch mit Büchern (das waren diese in Leinen gebundene Dinger, mit Papier dazwischen) und Kopien arbeitet, wird mit Mendeley kaum Freude haben.
Die klassischen BibTeX-Lösungen bieten am wenigsten Komfort und fokussieren sich primär auf die Verwaltung von Literaturtiteln. Der Programmumfang von JabRef (Java-basiert, plattformübergreifend) und KBibTex (KDE-Program) ist hier annähernd identisch. Dafür haben sie den Vorteil, dass sie anstelle einer kryptischen Datenbank ein lesbares Dateiformat ausgeben, dass hinreichend standardisiert ist. Gerade bei Projekten, die über viele Jahre gehen, ist das ein unschlagbares Argument. Man möchte ja nicht wie manch altgedienter Wissenschaftler enden, der erstmal seine virtualisierte Windows 95 Umgebung startet, wenn er die Literaturdatenbank durchsuchen will.

Synchronisation und Datenschutz

Die Welt war noch so einfach, als man nur einen PC hatte. Man hatte seine Literaturdatenbank zwar nicht immer dabei, aber dafür wenigstens auch nur eine Version selbiger. Den Rest erledigte man mit Papier und Stift und trug es bei Gelegenheit ein. Das kann man theoretisch auch heute noch so machen, aber in Zeiten, in denen man eine wachsende Anzahl an Endgeräten sein Eigen nennt, erwartet man etwas mehr von seiner Literaturverwaltung. Zumal, da die Übertragung von Titel mühevoll und zeitfressend ist. Dies ist übrigens ein Punkt, in dem auch Citavi nicht glänzt. Zwar kann man die Software auf mehreren Geräten installieren (oder portabel), aber man hat dennoch immer nur eine Datenbank, die man nach jedem Arbeitsvorgang übertragen muss. Eine automatische Cloudsynchronisation funktioniert aufgrund des automatischen Speichersystems nicht. Letztlich hat man dann immer genau auf dem Gerät, an dem man gerade sitzt keine aktuelle Datenbank.

Wo wir auch schon beim Thema wären. Die Lösung der Wahl ist meist eine Synchronisation über die Hersteller-eigene Cloud. So zumindest bei Zotero, EndNote und Mendeley. Das Problem ist hier offensichtlich. In einer gut gepflegten Literaturdatenbank besteht je nach Wissenschaftzweig annähernd die ganze Arbeitsleistung. Diese Daten in die Cloud zu schieben, ohne genau zu wissen was die Hersteller damit anfangen ist waghalsig. EndNote ist ein kommerzielles Produkt und lässt sich nach Lizenzen bezahlen, Zotero wird nach besser Open Source Manier an einer Universität entwickelt, aber z.B. Mendeley (oder andere Freemium-Produkte) gehört einem Verlag und muss irgendwann mal Geld erwirtschaften. Hier ist es wie bei vielen anderen Bereichen: Bezahlt man keine Euros, bezahlt man mit seinen Daten.

KBibTex

[zt_message_box type="info" extra-class="message-box"]Wer KBibTeX nutzen möchte, sollte sich entweder eine Distribution suchen, die nicht von Debian abhängt, oder gleich selbst kompilieren. Der Entwickler macht zwar nur kleine Versionssprünge 0.x, aber die Unterschiede zwischen 0.4 und 0.5 sind gewaltig. Leider hat das Debian Science Team es in zwei Jahren nicht geschafft, die Version anzupassen. OpenSUSE Nutzer können eine dauerhaft aktuelle Version über das KDE Extra Repo beziehen und Fedora-Anwender über die regulären Updates. CentOS/Scientific Linux/RHEL-Anwender müssen sich bei Fedora bedienen. Das sollte aber aufgrund der schmalen Abhängigkeiten kein Problem sein.[/zt_message_box]

An diesem Punkt kommt das gute (alte) BibTeX Format ins Spiel. Die Datei lässt sich Problemlos auf dem heimischen Cloudspeicher ablegen und darüber synchronisieren. Diese Lösung liegt so nah, wird aber oft nicht gesehen oder durch die Programme und ihre fixen Dateipfade torpediert. Insbesondere bei KBibTeX¹ lassen sich angehängte Dateipfade relativ zur Datenbank angeben, wodurch die Struktur (und integrierte Vorschau) auch bei größeren Umstrukturisierungsvorgängen erhalten bleibt. Die Dateibenennung bleibt zwar Handarbeit, aber ein bisschen händische Verwaltung schadet nicht, weil man dadurch die Kontrolle behält. Nichts ist ärgerlicherer, als eine undurchsichtige Ablagestruktur, die bei einem Ausfall des Programms vollkommen unverständlich ist (selbst wenn man die PDFs noch einzeln aufrufen kann).

Mit KBibTex lassen sich sich zudem verschiedene .bib Datenbanken einfach verwalten, was die komplexe Kategoriestruktur von Citavi wenigstens teilweise ersetzen kann. So lässt sich zwischen verschiedenen Datenbanken hin- und herwechseln und Literaturtitel beliebig verschieben.

Als KDE-Programm besteht KBibTex aus einer Reihe frei platzierbarer Elemente (Reference Preview, Document Preview, List of Values, List of Document etc. pp.)., die sich je nach Bildaufschirmformat und Auflösung beliebig anordnen lassen. Meiner Ansicht nach ist dies die einzige zeitgemäße Lösung, da ein Programm bei derselben Platzaufteilung einfach nicht gleichzeitig auf einem 24″ Monitor und einem Notebook mit mieser 1368er Auflösung gut funktionieren kann.

Mit KBibTeX bewegt man sich nach Jahren mit Citavi zwar gefühlt in der Literaturverwaltungs-Bronzezeit (Steinzeit waren die Karteikarten), aber wenigstens kann man sich damit trösten, ein Format zu verwenden, das einen voraussichtlich nicht in wenigen Jahren im Stich lässt oder vollständig von einer Firma abzuhängen. Wissensmanagement muss man leider anderswo betreiben, aber das sind halt die Limitierungen des Linux-Desktops mit denen man entweder leben kann, oder zu Windows / MacOSX wechseln muss.

Permalink

(Mer)Curius 30. April 2015 17:53

openSUSE 13.2 im Test ¶

Früher™ war der Release einer neuen Version von SUSE Linux / openSUSE eines der wichtigsten Ereignisse im Linux Kalendarium. Spätestens seit Ubuntu in der Öffentlichkeit synonym für Linux auf dem Desktop verwendet wird, hat die Distribution mit dem sympathischen Chamäleon als Logo die Position des Marktführers bei den benutzerfreundlichen Distributionen räumen müssen. Dennoch ist openSUSE gerade für KDE-Nutzer eine wichtige Distribution mit eine ganz eigenen Profil, deren Release einen Test verdient.

Ein Jahr Entwicklung

Die Entwicklung von openSUSE sollte eigentlich einem achtmonatigen Rhythmus folgen. Verschiebungen und Neustrukturierungen des Releaseablaufs sind bei openSUSE inwzischen aber mehr die Regel, denn die Ausnahme. Nachdem die Entwicklung von 11.2 fast 12 Monate dauerte, etablierte man den 8-Monats-Rythmus, den man exakt für sechs Versionen einhalten konnte. Die letzten beiden Releases 12.3 und 13.1 haben beide ein höchst positives Echo in der Community hervorgerufen.

Hinter den Kulissen gestaltete sich die Lage wohl aber nicht so entspannt. Die Projektleitung musste den einzelnen Teams zunehmend auf die Füße treten, damit Pakete für einen Release fertig gemacht wurden und einige Pakete waren gänzlich verwaist. Hier gibt es bis heute zwei unterschiedliche Darstellungen der Probleme. Während das Projekt von einer zu intensiven Mitarbeit und zu vielen Maintaintern in zu vielen Projekten spricht, sehen externe Beobachter eher einen Mangel an Mitarbeit und einige tote Projekte. Egal wo die Ursachen zu sehen sind, Anfang des Jahres wurde der Release von 13.2 auf unbestimmte Zeit vertagt. Erstmal sollte die Struktur von openSUSE grundlegend geprüft werden. Ein Rückzug der SUSE GmbH – nach diversen Übernahmen nun wieder formal eigenständig – aus der Betreuung des Community-Ablegers wurde als Gerücht gestreut.

Es hat sich einiges getan. Im Sommer wurde beschlossen aus dem bisherigen Factory-Zweig, ähnlich Debians Testing, eine Rolling Release Version von openSUSE zu machen. Tumbleweed wird im Gegenzug wohl eingestellt. Weitreichende Änderungsvorschläge, die vorsahen nur noch einen Basis-Release herauszugeben, der von den Nutzern um OBS-Zweige ergänzt werden würde, wurden scheinbar verworfen.

Nach nunmehr einem Jahr Entwicklung steht deshalb die Version 13.2 vor der Tür und verdient nach den ganzen Verwerfungen einen intensiven Test.

Der Installer

Die Installationsroutine wurde mit der neuen Version einer grundsätzlichen Überarbeitung unterzogen. OpenSUSE profitiert hier von den Entwicklungen in SUSE Linux Enterprise, dessen 12er-Release sich in der RC-Phase befindet. Meiner Meinung nach hat man hier äußerst gekonnt den Spagat zwischen einer sinnvollen Modernisierung und einer Beibehaltung bewährter Prinzipien hin bekommen.

Nach der obligatorischen Bestätigung der Lizenzen folgt bereits die erste Überraschung. Bei einer frischen Neuinstallation empfiehlt openSUSE eine Partitionierung mittels BtrFS, wobei die Home-Partition (sofern vorhanden)mit XFS partitioniert wird. Damit ist openSUSE die erste Mainstream-Distribution, die standardmäßig auf das seit Ewigkeiten als kommendes Dateisystem gehandelte BtrFS setzt.

dateisystemauswahl

Der Auswahldialog ist dabei bewusst einfach gehalten und bietet auch für Anfänger die notwendigen Optionen. Es ist mit wenigen Mausklicks möglich das gesamte System zu verschlüsseln, oder keine separate Homepartition anzulegen. Dennoch versucht openSUSE immer einen eigenen Weg zu gehen. Im Gegensatz zu Ubuntu setzt man eben nicht auf Optionsminimalismus um Einfachheit zu suggerieren, sondern bietet gesonderte Expertenoptionen, die einem die volle Hoheit über den Partitionierungsprozess geben.

partitionierung expertenmodus

Im nächsten Schritt bekommt man noch einmal die bekannte Zusammenfassung der gewählten Optionen präsentiert. Hier hat man nun die Gelegenheit die Zusammenstellung der Pakete grundlegend zu bearbeiten. Das ist eines der Alleinstellungsmerkmale von openSUSE und macht hochgradig individuelle Installationen möglich. Der Unterschied fällt nicht nur zu Ubuntu auf, das letztlich eine Kopie des Live-Systems auf die Festplatte spiegelt, sondern auch zu Debian. Denn Debian bietet einem nur die Auswahl mit oder ohne Desktop zu installieren. Individualisierte Systeme lassen sich nur über den Aufbau ausgehend von einem Minimalsystem realisieren.

detaillierte softwareauswahl

Für diesen Test habe ich die Auswahl unverändert übernommen, damit ein unverfälschter Blick auf die Standardkonfiguration von openSUSE entsteht. Ansonsten lohnt es sich aber insbesondere die patterns-Pakete gründlich zu prüfen. Dabei handelt es sich um die Meta-Pakete von openSUSE, vergleichbar den task-xxx bei Debian.

Software

Natürlich bringt openSUSE aktualisierte Software in allen Bereichen. Um Google zu füttern, könnte man hier von Kernel x.y und GCC z.x schreiben. Solche Buzzwords spare ich mir hier mal.

Wesentlich für den Desktop ist, dass openSUSE weiterhin eine nahezu perfekte Integration von KDE ausliefert. In der Installationsroutine ist KDE 4 vorausgewählt und wird – sofern man keine manuelle Änderung vornimmt – mit einem ausgewählten Softwarepaket installiert. Vorschauversionen von Plasma 5 und KF5 sind zwar in den Paketquellen enthalten, können aber sinnvollerweise nicht im Installationsvorgang ausgewählt werden. Hier hat openSUSE vom Debakel bei KDE 4 in openSUSE 11.0 gelernt.

KDE wird in doppelter Hinsicht als LTS Version ausgeliefert. Die KDE Workspaces (Plasma, KWin usw.) sind bereits seit vergangenem Jahr in Version 4.11 eingefroren und werden noch ca. ein Jahr mit Fehlerbehebungen versorgt. Die KDE Applications erschienen kürzlich noch einmal in Version 4.14 und sind nun ebenfalls als LTS Version eingefrorenen. Das KDE Projekt befindet sich somit im Übergang zu Version 5, openSUSE-Anwender kommen aber in Genuss einer in jeder Hinsicht bewährten und stabilen 4er Version, die noch einige Zeit gepflegt werden wird. Nachdem openSUSE vor einiger Zeit damit begonnen hat die strikte Beibehaltung der Releaseversion als Richtlinie aufzuweichen, werden Anwender nun auch in den Genuss von Fehlerbehebungsaktualisierungen kommen. In openSUSE 13.1 hat man beispielsweise bisher 12 Aktualisierungen für KWin nachgereicht, nichts spricht dagegen, dass es bei 13.2 anders verlaufen wird. Dies ist vor allem deshalb erfreulich, weil andere Distributionen wie Debian aufgrund strikter Paketrichtlinien lieber nichts nachreichen, oder wie Kubuntu nach ca. 6 Monaten das Interesse an einem Release verlieren und nur noch Sicherheitsaktualisierungen einspielen. Das mag jeweils seine Gründe haben, ist aber für den Nutzer ärgerlich, weil er auf alten Fehlern sitzen bleibt.

KDE ist wie immer um einige kleine Extras ergänzt. Das neue – nun wieder grüne – Design zieht sich durch den gesamten Desktop und auch sonst gibt es kleine nützliche Hilfen. Beispielsweise werden bei der Verkleinerung von Plasma-Leisten die Höhe in Pixel angegeben und das K-Menü ist übersichtlicher strukturiert, als dies von Haus aus der Fall ist. Alle Browser werden so beispielsweise in einer Kategorie Webbrowser gesammelt. Nachdem das KDE-Projekt keinen vernünftigen Browser ausliefern kann, greift man auf Firefox zurück. Hier hat openSUSE ein Addon implementiert, das die Nutzung der nativen KDE-Dialoge ermöglicht. Kubuntu hat dieses Addon als schmutzigen Hack betitelt und aus den Paketquellen verbannt. Das mag die sauberere Lösung sein, für den Nutzer wählt openSUSE aber den angenehmeren Weg.

opensuse standardansicht

Hervorstechend ist wie immer bei openSUSE die Liebe zum Detail. Während Debian und Kubuntu lediglich KDE in seiner mehr oder minder schönen Reinform ausliefern, wechselt openSUSE nicht nur den Desktophintergrund aus, sondern bietet auch ein eigenes Plasmatheme. In Version 13.2 wird die bekannte dunkle Variante um ein Light-Theme ergänzt, das zumindest mir optisch zusagt. Der klare Kontrast zwischen Theme und Systembereich-Icons ist zudem deutlich angenehmer als beim herkömmlichen Air Design.

Die vorinstallierte Software kann man als solide Mischung bezeichnen. Neben den Programmen der KDE Software Compilation (Kontact, Okular, Gwenview, Amarok usw.) zeigt sich openSUSE wenig dogmatisch, indem es auch GIMP und Firefox vorinstalliert. Ein wesentlicher Unterschied zu Kubuntu, das KDE oder zumindest Qt Software gnadenlos bevorzugt. Einige Punkte der Vorauswahl sind jedoch wenig durchdacht oder teilweise gnadenlos konservativ. So wird sowohl Kleopatra, als auch KGPG installiert, die sich in ihren Funktionen überschneiden. Anstelle des deutlich moderneren KDE-Telepathy liefert openSUSE immer noch Kopete aus. Zudem bindet man immer noch Kaffeine ein, dessen Entwicklung lange eingestellt ist und das normalerweise durch Dragonplayer ersetzt wird. Der langjährige openSUSE-Nutzer wird diese konservative Softwareauswahl jedoch vermutlich positiver bewerten.

Die Paketbenennung von openSUSE ist für einen langjährigen Debian-Nutzer allerdings etwas verwirrend. Pakete werden wohl konsequent wie upstream benannt, wohingegen Debian auf Vereinheitlichung setzt. Während bei Debian deshalb z.B. alle Administrationspakete für KDE mit kde-config-xyz beginnen, können diese in openSUSE synaptiks oder kde-gtk-config heißen. Das ist zwar letztlich Gewohnheit, aber Debians System wirkt konsistenter.

YaST und die Systemeinstellungen

Das Alleinstellungsmerkmal von openSUSE ist und bleibt YaST. Ein Verwaltungswerkzeug, das die Emotionen hoch kochen lässt. Dennoch bleibt es ein unerreichtes Stück Software, da YaST selbst komplexe Systemeinstellungen ohne Konsole ermöglicht. Das vermeintlich so benutzerfreundliche Ubuntu und auch Kubuntu sammeln ja lediglich in der Community vorhandene Einstellungswerkzeuge, die eine teils sehr unterschiedliche Qualität haben. So ist der Partitionierungsmanager bei Kubuntu 14.04 quasi unbrauchbar. YaST ist alt und sieht auch nicht ganz so aus, als ob es in einem Betriebssystem des Jahres 2014 seinen Platz gefunden hätte, aber die einzelnen Werkzeuge funktionieren zuverlässig.

Normalerweise benutze man die Konsole für größere Arbeiten am System, einfach weil sie zuverlässiger erscheint. OpenSUSE bzw. YaST führen einem immer wieder vor Augen, dass die grafischen Werkzeuge der anderen Distributionen lediglich unzureichend sind und die Konsole der GUI keineswegs per se überlegen ist.

yast

Umso unverständlicher bleibt es, dass openSUSE neben der großartigen Softwareverwaltung in YaST auch Apper/PackageKit eingebunden hat. Eine Doppelung die häufiger auftritt, so auch beim YaST-Druckermanager und dem KDE-Printmanager. Letztlich kann sich der Nutzer das bessere Werkzeug aussuchen, aber es verwirrt auch. OpenSUSE täte gut daran auf sein Herzstück zu vertrauen und es nicht hinter anderer – teilweise schlecht gepflegter – Software aus den Weiten der Community zu verstecken.

Fazit

OpenSUSE 13.2 ist ein in jeder Hinsicht gelungener Release, wenngleich es etwas überraschend ist, dass die Unterschiede zur Vorgängerversion nur marginal sind. Vor allem angesichts der heftigen Debatte der letzten Monate. Im Grunde genommen beschränken sich die Änderungen auf Versionsanhebungen in quasi allen Bereichen. Größere strukturelle Änderungen lassen sich bis dato nicht beobachten. Den konservativen Anwender wird es freuen.

Besonders für KDE-Anwender ist dies ein wichtiges Release. Es ermöglicht eine Weiterbenutzung von KDE 4 für die nächsten 18 Monate. Das ist kein Plädoyer gegen die Entwicklung rund um Plasma 5, aber solche Umbrüche gehen keineswegs reibungslos und manch einer wartet lieber ab, bis eine neue Version ein wenig gereift ist. Zumal sich abgesehen von Plasma 5 die Vorteile noch in engen Grenze halten. Zwar wird auch Kubuntu 14.04 LTS und voraussichtlich auch Debian 8.0 “Jessie” KDE 4 mittelfristig unterstützen, aber openSUSE hat mit 13.1 bewiesen, dass es unter Support nicht nur das Schließen von Sicherheitslücken versteht, sondern vom KDE Projekt angebotene Fehlerbehebungen langfristig zurückportiert.

Dank des openSUSE Build Service (OBS) kann man openSUSE 13.2 als Basisbetriebssystem verwenden und trotzdem in den Genuss aktueller Software kommen. Ubuntu bietet mit den PPA’s eine ähnliche Infrastruktur an, die OBS-Quellen sind jedoch subjektiv besser gepflegt und lassen sich einfacher verwalten. Schon alleine weil eine simple Suche in software.opensuse.org einen zur richtigen Stelle führt.

Zudem bleibt openSUSE seinem eigenen Weg treu. Man will eine einfache Distribution bieten, die sich auch an Anfänger richtet. Dabei möchte man aber nicht alle Einstellungsmöglichkeiten verstecken. Die neue Installationsroutine setzt dies vorbildlich um. Verwirrende und teilweise überholte Dialoge wurden abgeschafft. Experten ~~und solchen die sich dafür halten~~ hinter den entsprechenden Schaltflächen aber viele Einstellungsoptionen gelassen.

Eigentlich ist es unverständlich, das openSUSE mittlerweile eine so geringe Bedeutung unter den Linux-Distributionen hat.

Weiter:

Teil II.: openSUSE 13.1 im Langzeittest / Tipps & Tricks

Permalink

(Mer)Curius 30. April 2015 17:53

Debian 8.0 "Jessie" im KDE Test ¶

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 Lines von Juliette Taka BELIN unter Creative Commons Attribution; angepasst mit Releasedatum von Laura Arjona

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.

Änderungen:

15.07.2015: Credits für das Bild eingefügt.

Permalink

(Mer)Curius 30. April 2015 17:53

Ubuntu LTS nach 12 Monaten - Licht und Schatten beim treuen Tahr ¶

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

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.

Main
Universe
Restricted
Multiverse
Canonical Partner
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.

Permalink

(Mer)Curius 30. April 2015 17:53

Kommentar: Debians Installationsroutine ¶

Das von mir kürzlich erworbene Subnotebook macht mir immer noch sehr viel Freude. Das kann man von Kubuntu leider nicht behaupten. Nach dem Kauf musste ja schnell ein Betriebssystem installiert werden und mangels Ethernet-Port wurde es die 14.04er LTS. Neben kleinen Problemen, wie die nicht funktionierende Lautstärkesteuerung nervte mich der schlechte Pflegezustand der LTS jeden Nutzungstag ein wenig mehr. An allen Ecken und Enden finden sich Bugs, die teilweise schon seit Monaten/Jahren gemeldet sind und scheinbar keine Priorität genießen. Ganz besonders nervig ist der Akonadi-Bug, bei dem KOrganizer vollkommen unbegründet eingetragene Kalender vergisst, die sich erst durch einen Neustart wiederfinden lassen. Das brachte mich in den vergangenen Tagen an den Rand des Wahnsinn. Der Bug ist in neueren Akonadi/Kontact Versionen behoben, aber dem Kubuntu-Team scheint der Wille oder die Fähigkeit zu fehlen die Fehlerbehebung zurück zu portieren.

Neuere STS Releases kommen leider nicht in Frage. Das Subnotebook soll einfach nur funktionieren und mich nicht alle Nase lang alle paar Monate mit Distributionsupgrades nerven. Deshalb ja schließlich auch die Idee mit der LTS. OpenSUSE 13.2, das bei mir einen sehr guten Eindruck hinterlassen hat kommt aus selbigem Grund leider auch nicht in die nähere Auswahl. Also muss es wohl Debian werden. Das Release von Jessie steht kurz bevor und der Ersteindruck im vergangenen Jahr war nicht so übel. Das KDE Team ist dort zwar auch nicht mit Manpower oder durchweg weisen Entscheidungen gesegnet, aber immerhin liegt Kontact in Version 4.14 vor. Das man mal für einen blöden Bug einen Distributionswechsel vornimmt, kommt auch nicht so oft vor, aber bei einem zentralen Werkzeug für Kontact geht man über Leichen.

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Leider ist dem Notebook in der letzten Woche immer noch kein Ethnernet-Port gewachsen. Ein Netinstall fiel deshalb scheinbar flach. Debian bietet aber zum Glück mehr als genug Installationsmedien, die DVD 1 sollte das notwendigste abdecken. Seit Jessie kann man in der Installationsroutine auch die Desktopumgebung ohne schmutzige Tricks auswählen. Mal schauen was Debians KDE Team dem Nutzer so andient. Die Installationsroutine verrät schon mal, dass es ca. 1 300 Pakete werden. Also ein ähnlicher Umfang wie eine Kubuntu-Installation. Nach dem obligatorischen Neustart und einem Blick in die Paketliste, sowie des Startmenüs fällt es einem schwer die Zusammenstellung zu beschreiben. Genau genommen wäre eine subjektive Beschreibung hier gerade gefährdend für alle Altersgruppen.

Debians KDE Team ist wohl der Meinung, dass man drei Werkzeuge zur Drucker-Verwaltung braucht, Super-Karamba schön an KDE 3.5 erinnert, Kopete ein zeitgemäßerer IM-Client ist und kdesudo nicht schlecht wäre – obwohl Debian das von Haus aus nicht braucht.

Liebes Debian KDE Team. Apt-get ist ein super Werkzeug für die Paketverwaltung und Distributionsupgrades funktionieren bei Debian wirklich hervorragend. Scheinbar so gut, dass niemand in eurem Team in den letzten Jahren eine Neuinstallation vorgenommen hat. Jedenfalls nicht mit den normalen Installationsmedien und einer Standard-Installation. Anders kann man sich diesen Unfall nicht erklären.

Debian Netinstall ohne Ethernet Port

Mit dem System werde ich nicht glücklich. Alleine die Deinstallationsorgie braucht mehr Zeit, als eine frische Netinstallation in Anspruch nimmt. Wäre da nicht der fehlende Ethnernet-Port. Auf der Debian-Webseite versprechen die Debian-Maintainer allerdings, dass eine Netinstall (mit Einschränkungen) auch via WLAN möglich ist. Vielleicht hat sich seit den Zeiten von Lenny und KDE 3.5 doch was getan. Der Download geht bei knapp 200MB zum Glück auch schnell und selbst dd schafft es nicht sich an der Dateigröße zu verschlucken.

Die Überraschung folgt auf dem Fuße. Debians Installationsroutine (natürlich nach einbinden der unfreien firmware-Pakete) erkennt tatsächlich das WLAN und richtet es ein. Die Installation danach ist Routine, UEFI und LUKS/LVM werden zufriedenstellend eingerichtet. Bei der Task-Auswahl entscheidet man sich natürlich nur für eine Minimalinstallation. Das Softwaremuseum von oben will man schließlich kein zweites Mal auf der Festplatte sehen. #

Nach dem Neustart dann die Ernüchterung. Keine funktionierendes WLAN weit und breit. Also muss doch wpa_supplicant und ifup ran. Wenigstens ist beides in der Minimalinstallation enthalten.

Zuerst ermittelt man den WPA-PSK Hash:

§ wpa_passphrase <WLAN-SSID> <PASSPHRASE> # natürlich ohne die <>

Das Ergebnis trägt an in /etc/interfaces/network ein.

auto wlan0

iface wlan0 inet dhcp

wpa-ssid <Meine SSIS>

wpa-psk <Mein ermittelter Schlüssel>

Dann noch das WLAN aktivieren mit:

# ifup wlan0

Danach kann man wie gewohnt die notwendigen Pakete installieren. Sofern man auf den NetworkManager wechselt, muss man die Einträge in der network-Datei wieder entfernen.

Aktualisierungen:

28.06.2015: Fehler in der Ermittlung der PSK-Phrase behoben.

Permalink

(Mer)Curius 30. April 2015 17:53

Linux auf dem Lenovo IdeaPad U330p ¶

Die Laufzeit von Hardware verlängert sich seit einigen Jahren spürbar und das sehr zum Leidwesen der Hersteller. Der technische Fortschritt ist – abgesehen von den Hardcore-Gamern und Menschen die berufsbedingt viel Rechenleistung brauchen – nicht mehr so spürbar und die Anforderungen an Notebooks und PC’s sind in Zeiten von Smartphones und Tablets auch eher rückläufig. Alle paar Jahre braucht der Mensch aber doch mal ein neues Gerät – und sei es nur weil das alte plötzlich die Grätsche macht.

Weil genau letzteres eingetreten ist musste zudem sehr schnell ein neues her und das ohne langwierige Recherche. Klein und Leicht muss es sein, aber ein Display zwischen 13″ und 14″ sollte es dann schon haben. Da das Gerät zudem nur 1-2 Mal die Woche zum Einsatz kommt war das Budget ziemlich limitiert. Wer gibt schon 1 000 € für ein Gerät aus, an dem man lediglich max. 12 Stunden die Woche arbeitet. Das Ergebnis führte zum Lenovo IdeaPad U330p, das derzeit bei größeren Onlineshops für 499€ ohne Betriebssystem zu haben ist.

lenovou330p

Für die Zahlenfetischisten kurz die Eckdaten:

Intel Core i5 (Haswell) 1,6 Ghz (2,5 Ghz bei Turbo-Boost)
Intel HD 4400 Grafikkarte 4 GB RAM
13.3″, HD 1366×768 Display 5
00 GB SSHD

So ganz ohne vorherige Recherche war es natürlich spannend ob überhaupt und wenn ja wie gut Linux auf dem Gerät laufen würde. Aber dazu später mehr.

Die Hardware

Man könnte jetzt hier so ein peinliches interessantes Unboxing-Video machen. So, wow ich kann einen Karton auspacken und das Logo darauf ist so stylisch. Gut, ich bin keine 15 mehr und habe in meinem Leben schon so einige Kartons geöffnet, deshalb erspare ich euch das mal hier.

Das Subnotebook (ein Ultrabook ist es offiziell ja nicht) hat eine wirklich tolle Haptik. Der Displaydeckel, die Handballenauflage und die Unterseite sind aus Aluminium. Lediglich der Display-Rand ist aus Plastik (oder Polycarbonat, wie es heute im Herstellerdeutsch mancher Jubel-Blogs heißt…). Natürlich ist das ganze nicht “aus einem Aluminiumblock gefräst” wie mancher Fallobstsammler nun bemäkeln mag, aber die Verarbeitung ist für ein 500 € Gerät wirklich gut.

Die Tastatur hat einen relativ kurzen Hub, was natürlich der Bauart geschuldet ist. Ansonsten ist sie aber wirklich gut und gibt auch an keinem Punkt nach oder ähnliches. Längere Text würde ich zwar nicht auf diesem Gerät verfassen wollen, aber dafür ist es auch nicht angeschafft worden.

Das Display wurde in einigen Testberichten ziemlich heftig kritisiert. In der Tat ist es relativ dunkel und eine interessante Mischung aus Matt und Glänzend. Faktisch ist die Displayhelligkeit aber absolut ausreichend. Selbst im Zug bei voller seitlicher Sonneneinstrahlung lässt sich ein PDF problemlos lesen. Als Historiker arbeitet man ansonsten ja eh eher in Räumen, die sich weder durch zahlreiche künstliche Lichtquellen, noch durch viele Fenster auszeichnen. Auch hier wieder: Es ist ein 500 € Gerät. Will ich ein Retina-Display mit genug Beleuchtung um ein Zimmer damit auszuleuchten muss ich schon minimum 1 000 € auf den Tisch legen. Die Erwartungshaltung mancher Rezensenten und Kommentatoren scheint in Zeiten stetig fallender Preise jegliche Bodenhaftung verloren zu haben.

Positiv überrascht hat mich die 500 GB HDD mit 8 GB SSD Cache. Nennt sich SSHD. Natürlich kann das keine vollwertige SSD ersetzen, aber der Unterschied zu einer herkömmlichen HDD ist enorm.

Die Frage aller Fragen: Läuft Linux?

Laut Hersteller kommt das Lenovo IdeaPad U330p mit FreeDOS vorinstalliert, d.h. ohne Windows. Das war definitiv ein Grund für den Kauf, denn ungenutzte Windows-Lizenzen jeglicher Version liegen hier bereits genug herum. Interessante Überraschung: Es ist wirklich FreeDOS vorinstalliert. Das ist ja keineswegs selbstverständlich. Die Hersteller müssen zwar ein Betriebssystem angeben, manchmal findet sich dann aber nichts auf der Festplatte oder es ist irgendein Nischen-Linux vorinstalliert. Wegen FreeDOS ist im BIOS der Legacy-Modus eingestellt. Vor der Installation muss man hier deshalb noch auf UEFI umstellen. Lenovo baut zum Glück in seine Geräte einen kleinen Knopf an der linken Seite an, über den man bequem die BIOS-Einstellungen und die Startmedien aufrufen kann.

Installation

Nun musste eine Distribution her. Eigentlich hatte ich dafür Debian Jessie auserkoren aber das Ultrabook Subnotebook hat (leider) keinen Ethernet-Anschluss – was wieder einmal der Bauhöhe geschuldet ist. Also die DVD 1 von Debian heruntergeladen und auf einen Stick gezogen. Die Installation lief zwar soweit problemlos durch aber nach dem Start war der Stick nicht als Paketquelle eingerichtet und zentrale Pakete wie das GStreamer-Backend von Phonon befinden sich scheinbar nicht auf der ersten DVD. Meine Lebenszeit ist mir ehrlich gesagt zu schade, um sie mit den Absurditäten von Debian zu verbringen.

Also Kubuntu 14.04.1 LTS auf den Stick gezogen und installiert. Die Installation läuft problemlos durch und die Hardware wird vollständig erkannt und eingerichtet. WLAN Wirklich vollständig, keine Probleme? Vollkommen unmöglich wird mancher nun sagen. Linux ist schließlich als Frickelsystem verschrien. Gut, ein kleines Problem gibt es dann doch: Der WLAN Empfang des Gerätes ist nicht wirklich gut. Ein Problem mit dem gemäß den Testberichten wohl auch Windows-Nutzer zu kämpfen haben.

Alls Linux-Nutzer kann man sich wenigstens helfen. Erste Abhilfe schafft die Installation des 3.16er Kernel aus dem LTS Enablement Stack. Je nach Router und WLAN Einstellungen kann das schon reichen. Verbessern kann man die Empfangsstabilität noch, indem man den N-Modus im Notebook abschaltet.

N-Modus und Warteschlangenüberwachung lässt sich mit folgendem Eintrag abschalten:

echo “options iwlwifi 11n_disable=1 wd_disable=1″ | sudo tee /etc/modprobe.d/iwlwifi.conf

Danach neustarten und das WLAN sollte hinreichend stabil laufen. Wer natürlich im Westflügel des heimischen Anwesens sein Büro hat, während der Router in der Gesindeküche im Ostflügel steht, sollte sich evtl. nach einem anderen Notebook umsehen.

KDE SC Einstellungen

Die Intel HD 4400 ersetzt zwar keine dezidierte Grafikkarte, aber für den Einsatzzweck des Subnotebooks reicht es. Allerdings muss man noch einige Einstellungen in den Desktopeffekten einstellen, weil die Grafikkarte wesentlich mehr kann, als Kubuntu bei den Standardeinstellungen festlegt. Unter Systemeinstellungen | Arbeitsflächen-Effekte im Reiter Erweitert kann man den Composit-Typ auf OpenGL 3.1 verändern und das Qt-Grafiksystem auf nativ. Wer den aktuellen HWE Stack (X-Server 1.16) installiert hat, kann den Composit-Typ auch auf OpenGL 4.0 festlegen. Weil das für meine Einsatzzwecke aber keinen substanziellen Vorteil bringt, aber die Stacks immer nur 9 Monate Support erhalten, während die Originalpakete bis zum EOL von 14.04 unterstützt werden bleibe ich bei selbigen.

Unter Systemeinstellungen | Eingabegeräte | Touchpad hat KDE seit einiger Zeit eine wirklich gute grafische Touchpadverwaltung. Hier kann es sich lohnen das Touchpad beim tippen und bei einer angesteckten externen Maus automatisch abzuschalten.

Akku

Der Akku lässt einen bei eingeschaltetem WLAN, auf 60% gedimmtes Display und leichten Schreib- und Surftätigkeiten auch unter Linux 5-6 Stunden arbeiten.Die Leistungsaufnahme schwankt zwischen 5,7 und 9W und damit genau in dem Rahmen, der auch bei Tests mit Windows erreicht wurde. Besondere Einstellungen müssen mit Linux also nicht durchgeführt werden, zumal viele meiner Ansicht nach eher einen Placebo-Effekt haben.

Fazit

Das Lenovo IdeaPad U330p ist ein Subnotebook mit dem man nicht viel falsch machen kann. Obwohl der Kauf ohne vorherige Recherche durchgeführt wurde läuft eine aktuelle Linux-Distribution out of the Box. Da fragt man sich schon was manche immer für Hardware anschleppen um zu ihrem Frickelproblem zu kommen…

Update am 10.04.15: Eine Netinstallation von Debian lässt sich mit einigen Handgriffen auch ohne Ethernet-Port durchführen. Genaueres dazu steht hier: Kommentar: Debians Installationsroutine

Permalink

(Mer)Curius 30. April 2015 17:53

Qupzilla absichern ¶

Mozilla Firefox ist bei den meisten Linux-Distributionen noch immer als Standardbrowser gesetzt und hat in Deutschland allgemein noch einen sehr guten Ruf, wenngleich weltweit die Marktanteile zurückgehen. Mozilla als Organisation ist für ein freies Web unglaublich wichtig, keine größere Instanz setzt sich derart für freie Standards und ein offenes Web ein. Daran ändert auch die relative Abhängigkeit von Einnahmen durch die voreingestellten Suchanbieter nichts.

Firefox als Browser ist aber qualitativ allenfalls noch mittelmäßig. Das hat nichts mit Australis zu tun, eine Entwicklungsrichtung, die ich persönlich eher positiv bewerten würde. Firefox ist fehleranfällig, langsam und überladen. Er entwickelt sich nicht nur unter Linux zu einem Betriebssystem im Betriebssystem. Webapps, Addons, eine eigene Oberfläche als Markenzeichen. Der Nutzer soll den Browser nutzen, nicht das zugrunde liegende Betriebssystem. Viele Nutzer mögen dies ansprechend finden, der Erfolg von Google Chrome lässt sich möglicherweise durch eine ähnliche Entwicklungsrichtung erklären. Für Mozilla ist es deshalb vermutlich konsequent den Browser in diese Richtung auszubauen. Nutzer, die mit dem Browser aber nur ihre Webseiten öffnen möchten und RSS-Feeds, Mails und Kalender weiterhin mit darauf spezialisierten Programmen verwalten, geht diese Entwicklung in die falsche Richtung.

Zum Glück gibt es Alternativen und durch die Erhebung von WebKit zum freien quasi-standard stehen diese Alternativen den Marktführern kaum nach. Ein brauchbarer Qt-basierter Browser ist das “nächste heiße Ding” seitdem ich Linux verwende. Viele Projekte haben sich daran versucht, die meisten sind gescheitert oder siechen vor sich hin. Der neue Stern am Qt-Browser-Himmel ist Qupzilla. Ein Browser, der bei den meisten Linux-Distributionen in den Paketquellen zur Verfügung steht.

[zt_message_box type="danger" extra-class="message-box"]Ubuntu-Nutzer aufgepast: Qupzilla ist lediglich durch den Debian Sync-Prozess in den Paketquellen und wird nicht supportet. Das Programm ist deshalb unter Umständen nicht sicher! [/zt_message_box]

Die meisten Browser sind in den Standardeinstellungen leider ziemlich unsicher und posaunen viel über ihre Nutzer heraus. Erstaunlicherweise kann Qupzilla vieles was man bei Firefox mittels eines Addons nachrüsten muss von Haus aus. Allerdings muss an einigen kleinen Einstellungen gedreht werden:

Cookies abschalten

qupzilla cookieeinstellungen

Cookies sind durchaus sinnvolle Werkzeuge und wir benötigen sie um auf vielen Webseiten nicht jedes mal neu einloggen müssen. Leider wurden sie durch ihre nicht so nützlichen Eigenschaften regelrecht pervertiert. Cookies sind heute vor allem ein Mittel von Werbetreibenden und an Werbung interessierten Firmen um die Benutzer auf ihrem Weg im Netz zu verfolgen. Im Grunde genommen sind sie eine Technologie die derart in Verruf gekommen ist, dass sie nur noch ersetzt werden kann. Wie bei vielen “altbewährten” Sachen wird dies jedoch kaum geschehen. Der Nutzer kann sich nur wehren indem er die Speicherung von Cookies deaktiviert.

Da einige Webseiten jedoch penetrant die Speicherung von Cookies einfordern kann es sinnvoller sein Cookies beim Beenden des Browser zu löschen, anstatt ihre Speicherung komplett zu deaktivieren. Das setzt natürlich voraus, dass der Nutzer seine Sitzung ab und an (zumindest täglich) beendet. Das bedeutet leider, dass wir bei jeder Sitzung neu auf den Internetseiten unserer Wahl anmelden müssen. Da sich Qupzilla in KWallet und Gnome-Keyring integriert, lassen sich Nutzernamen und Passwörter jedoch leicht und sicher speichern, weshalb das kein größeres Problem darstellen dürfte. Sicherheit geht halt manchmal ein wenig zulasten des Komforts.

Do-Not-Track und Referrer abschalten

qupzilla privatsphaere

Do-Not-Track war eine nützliche Erfindung, die leider keinen durchschlagenden Erfolg hatte, vor allem weil sie auf freiwillige Implementierung angewiesen ist. Einige Seiten und Statistiktools wie Piwik berücksichtigten dies aber sehr wohl, weshalb eine Aktivierung nicht schädlich sein dürfte. Der Referrer, also die Übermittlung der zuvor besuchten Seite(n) sollte ebenfalls deaktiviert werden.

Werbung aussperren

Werbung ist heute oft gleichbedeutend mit Überwachung. Die Aussperrung von Werbung eine sicherheitstechnische Notwendigkeit. Nicht umsonst hat es dieser Punkt in das hevorragende Sicherheits 1×1 von ubuntuusers geschafft. Eine Adblock-Funktion ist in Qupzilla bereits von Haus implementiert und aktiviert. Eigentlich erstaunlich, dass eine eierlegende Wollmilchsau wie Firefox, das immer noch nicht bietet. Unter Extras | Adblock lassen sich die Filterregeln im Optionen Dropdown-Menü verwalten.

Permalink

(Mer)Curius 30. April 2015 17:53

Mythen Teil 1: Desktopumgebungen ¶

Die Linux-Welt ist voller, teils liebevoll gepflegter Mythen. In den Kommentarspalten der großen Nachrichtenportale dürfen diese weiter publiziert und damit am Leben erhalten werden. Teilweise liegt das auch daran, dass bei Linux jeder seine eigene Wahrheit ungestört von Daten und Fakten pflegen kann. Denn diese sind bei den Distributionen eher Mangelware. Während die großen Webstatistiksammler Betriebssysteme und Browser tracken und man somit auf dem Gebiet eine ungefähre Schätzung der Verteilung hat, liegen andere Zahlen im Nebel des (Kommentarspalten-)Krieges.

Eine dieser Mythen lautet (gerne mit dem Zusatz “in meinem Umfeld”): Die großen Desktopumgebungen, insbesondere GNOME, haben viele Nutzer verloren. Viele/die meisten Nutzer setzen nun Desktops ein, deren Entwickler “noch auf ihre Nutzer hören”. D.h. konservative Desktopumgebungen, die weitestgehend dem Windows 95-Modell folgen. Alles andere ist Bloatware oder unnützes, fehlerbehaftetes Zeug. Die Problematik ist sicherlich einzigartig in der IT-Welt, schließlich lassen andere Betriebssysteme wie MacOSX oder Windows ihren Nutzern keine Wahl. Lediglich bei Android mit seinen verschiedenen Launchern findet sich ein ähnliches Problem.

kde 3.5

„KDE 3.5 Releasebild“. Lizenziert unter GPL

Eine Antwort auf die Frage kennt wohl niemand. Die meisten Distributionen erheben weder die Zahl der Installationen, noch die auf den installierten Systemen vorhandenen Pakete. Eine Ausnahme bilden hier Debian und Ubuntu, die beide über den Popularity Contest die installierten Pakete abfragen. Während dieser bei Ubuntu nachträglich durch den Benutzer aktiviert werden muss, fragt Debian bereits in der Installationsroutine ob man an der Paketverwendungserfassung teilnehmen möchte. Damit ist zwar keine genaue Aussage über die Zahl der Installationen möglich, aber viel näher dürfte man in der Linux-Welt kaum an das Problem herankommen.

Debian

Die nackten Zahlen sehen wie folgt aus:

GNOME: 67.452
Xfce: 21.032
KDE: 17.302
LXDE: 8.169
MATE: 4.128
Cinnamon: 1.707

Unter Debian gibt es keine einheitlichen Metapakete für die Desktops, welche für die Installation zwingend nötig wären. Allerdings verfügen alle Desktopumgebungen mit Ausnahme von KDE über ein *session Paket, ohne das die Desktopumgebung nicht funktioniert. Für die Ermittlung der installierten Desktopumgebungen wurde deshalb primär auf dieses Paket zurückgegriffen. Das schließt Mehrfachinstallationen natürlich nicht aus.

Offensichtlich ist der hohe Anteil an GNOME-Installation, der sicherlich auch – aber nicht ausschließlich – aus der Rolle GNOME’s als Debian-Standarddesktop herrührt. MATE und Cinnamon sind erst mit dem kommenden Release Jessie ein offizieller Teil von Debian, weshalb hier noch ein Anstieg möglich bzw. wahrscheinlich ist.

Ubuntu

Die nackten Zahlen von Ubuntu sehen wie folgt aus:

Unity: 1.978.654
KDE: 254.939
Xfce: 125.568
LXDE: 25.122
Cinnamon: 3.831
GNOME: 1.040
MATE: 8

Ubuntu und seine Derivate verfügen über zentrale Metapakete *-desktop, welche der Einfachheit halber für die Anzahl der Installation herangezogen wurden. Mehrfachinstallationen oder nachinstallierte Desktops fallen somit zwar “unter den Tisch”, diese entsprechen aber auch nicht der Ubuntu-Vorgehensweise Derivate über die offiziellen Live-ISOs zu installieren.

Die Dominanz von Unity ist beachtlich, jedoch auch ein wenig überraschend. MATE ist erst ab 15.04 ein offizielles Derivat, Cinnamon nicht gar nicht eingeplant. Ubuntu GNOME hat scheinbar kaum Nutzer. Die Abfolge Unity, KDE, Xfce ist wenig überraschend.

Fazit

Die Zahlen sind weder repräsentativ für die Gesamtheit der Linux-Distributionen, noch für Debian oder Ubuntu. Die Teilnahme am popcon ist freiwillig und die Konfigurationsmöglichkeiten des Einzelnen quasi endlos und deshalb kaum präzise erfassbar. Der Linux-Desktop ist heterogen und die Aufspaltung von GNOME am Beginn der 3er Ära in GNOME 3, Unity, Cinnamon und MATE hat die Diversifikation vorangetrieben. Dennoch lässt sich nicht sagen, dass konservative Desktops bevorzugt werden, sie stellen noch nicht einmal die Mehrheit. Vielleicht gibt das dem ein oder anderen Kommentarspaltenkrieger, der für einen WM das Schwert Wort führt mal zu denken.

Permalink

(Mer)Curius 30. April 2015 17:53

Kommentar: PPA Archive ersetzen keine Backports ¶

Kürzlich musste ich einen PC mit Debian ausstatten. Zwar haben Debian und ich seit letztem Jahr unsere Differenzen aber manchmal bietet halt nur Debian das was man gerade benötigt – insbesondere wenn es sich dabei um besonders alte Versionen handelt. In meinem Fall war das der X-Server nicht neuer als Version 1.12, da in dem Computer eine sehr betagte NVIDIA Grafikkarte arbeitet, die den 96er-Legacy Treiber benötigt, der nur bis Version 1.12 funktioniert. Nouveau bringt das System leider eher zum ~~flattern~~ flackern als zum fliegen. Normalerweise nehme ich für solche Dinosaurier gerne CentOS 6, da es den Wartungsaufwand minimiert und GNOME 2 eine sehr ressourcensparende Oberfläche war. Leider hält RedHat zwar den Kernel stabil, aber der X-Server wird bei jedem Minorupdate aktualisiert. Der 96er Treiber hatte also irgendwann aufgehört zu funktionieren. Auch eine interessante Definition von Stable, aber das soll hier nicht das Thema sein.

Debian Wheezy ist nicht mehr das jüngste System. Der Release des Nachfolgers Jessie steht unmittelbar bevor (sofern man das bei Debian vorhersagen kann). Das ist grundsätzlich kein Problem. Nur Versionsfetischisten erfreuen sich an jedem Update. Gerade betagte Hardware wird meistens seit Jahren vom Kernel perfekt unterstützt, da kommt es auf ein paar Versionen nicht an. Leider gibt es immer einige Programme, bei denen man partout eine neue Version braucht. Sofern man LibreOffice benutzt gehört das zu diesen Kandidaten. Die verbesserten Importfilter für OOXML Dateien will man sich selten entgehen lassen.

Debian überrascht in dieser Sache überaus positiv. Unglaublich viele Pakete sind in nahezu aktueller Version in den Backports verfügbar und lassen sich auf einen stabilen Unterbau nachinstallieren. Das reicht bis zu ganzen Desktopumgebungen wie MATE. Zwar werden diese Backports nicht offiziell vom Sicherheitsteam betreut aber oft steht dahinter derselbe Maintainer wie beim Paket für die Distribution. Die Backports machen durch die Bank einen gut gepflegten Eindruck und wenn man sich nicht zu exzessiv bei ihnen bedient, dürfte es der Systemstabilität keinen Abbruch tun. Damit kommt Debian dem Ideal eines stabilen Unterbaus, bei aktuellen Anwendungen ziemlich nahe.

Ganz anders sieht die Situation bei Ubuntu aus, obwohl es mit der LTS-Variante ein ähnliches – wenn auch geplanteres – Releasemodell verfolgt wie Debian. Die Pakete im offiziellen Backportzweig sind weder besonders zahlreich, noch sonderlich aktuell. Wenn man bei Ubuntu auf aktuelle Software angewiesen ist, muss man eine Vielzahl von unterschiedlichen PPA’s in sein System einbinden. Dies ist besonders deshalb fatal, weil PPA’s hierfür nie konzipiert wurden. Hier wurde die Pflege des Backport-Zweiges offensichtlich zu Gunsten der PPA’s aufgegeben.

Nun könnte man meinen, dass das lediglich ein oberflächlicher Unterschied ist und letztlich zum selben Ergebnis führt, dem ist aber nicht so. Die “offizielle” Backports-Quelle von Debian und Ubuntu ist niedriger gepinnt, als die Standardquellen, weshalb man die Pakete gezielt aus den Backports anfordern muss. Es werden also ungefragt keine Pakete im Nachhinein aktualisiert. PPA’s sind standardmäßig normal gepinnt und aktualisieren alle Pakete, die in einer neueren Version im PPA vorhanden sind. So kann ein PPA, das vor Monaten mal wegen irgendwas hinzugefügt wurde unglaublichen Schaden anrichten – jedenfalls wenn man nicht genau hinschaut. LTS-Systeme installiert man aber um eben nicht bei jedem Update genau hinschauen zu müssen. Man ist ja nicht bei Arch oder Debian Sid. PPA’s sind zudem vollkommen inoffiziell und manchmal werden nicht immer genug überprüft. Ein Paket ist eben viel schneller im PPA, als auf dem Backport-Server. Dadurch geschehen eben auch mal Fehler, einfach weil Maintainer Menschen sind und diese nun mal Fehler machen. Im Sommer wurde beispielsweise im offiziellen Kubuntu-Backports PPA aus Versehen Plasma 5 hoch geladen. Wer im falschen Zeitfenster ein Update durchführte zerschoss sich sein komplettes LTS-System, sofern er nicht wegen der großen Zahl an Paketupdates stutzig geworden war. Bei der Backportquelle wäre das nicht passiert!

Auf die Spitze getrieben wird die Problematik, wenn man für Fehlerbehebungen auf PPA-Quellen verwiesen wird, weil es für die Betreuer zu kompliziert ist die Updates offiziell bei Ubuntu einzubringen.

Die PPA-Quellen haben einerseits vieles vereinfacht, weil die Anwender kaum noch Programme selbst kompilieren müssen. Der Vergleich mit Debian zeigt aber auch, dass einige sinnvolle Einrichtungen einer Distribution damit konterkariert wurden und die Systemstabilität darunter leiden kann. Für Systeme die massiv auf zurück portierte Anwendungen angewiesen sind kann deshalb der Einsatz von Debian fundamentale Vorteile bringen.

Permalink

(Mer)Curius 30. April 2015 17:53

openSUSE 13.2 im Langzeittest ¶

Testberichte gibt es beim Erscheinen neuer Linuxdistributionsversionen wie Sand am Meer. Meistens zieht der Blogger oder Redakteur schnell eine VM auf und lässt die Installation durchlaufen um danach ein paar Versionsnummern und eine subjektive Nutzungserfahrung in den Artikel zu schreiben. Sowas habe ich hier natürlich auch schon fabriziert. Die Stärken und Schwächen einer Distribution sieht man jedoch oft erst im Langzeittest (zumindest über eine Woche) auf realer Hardware. OpenSUSE 13.2 läuft nun seit fast 4 Wochen auf mehreren Systemen und es ist Zeit eine kurze Zwischenbilanz zu ziehen. Oberflächlich ähneln sich viele Distributionen, zumal wenn man immer auf dieselbe Desktopumgebung zurückgreift. Unter der Haube zeigen sich aber die Unterschiede – vor allem, wenn man sehr lange nur Debian und seine Derivate eingesetzt hat.

opensuse startscreen

Was ist wirklicher grüner beim Gecko

YaST ist das Alleinstellungsmerkmal von openSUSE und das vollkommen zurecht. Bei jeder neuen Version von openSUSE wird die erneute Optimierung von YaST erwähnt und inzwischen trägt das Früchte. YaST verhält sich auch unter schwächerer Hardware (Intel Celeron mit zwei Kernen 1,5 Ghz, 4 GB RAM, herkömmliche HDD) sehr reaktionsfreudig. Die verschiedenen YaST-Werkzeuge lassen einen bei der Administration des Systems nie im Stich und bieten einem ein umfangreiches Repertoire an Optionen an. Wer jahrelang bei jedem Partitionsvorgang mit dem KDE-Partitionsmanager zitterte, erlebt das als angenehme Abwechslung. das übersichtliche Verwalten von BtrFS-Snapshots mit YaST-Snapper oder das schnelle an- und abschalten von systemd-Diensten ist einfach angenehm. Den eiskalten Konsolenakrobaten holt das natürlich nicht hinterm Ofen hervor, aber wer gerne mit grafischen Programmen arbeitet, hat mit YaST ein echtes Argument für openSUSE – auch auf den zweiten Blick.

Die Abhängigkeitshölle und SUSE waren lange Zeit zwei Seiten derselben Medaille. Entsprechend vorsichtig ging ich an meine ersten Gehversuche mit RPM vor einigen Wochen. Vollkommen unnötig wie sich herausstellte. Zypper und das zugehörige YaST Frontend haben die Paketverwaltung selbst in schwierigen Situationen (Fremdarchitektur, verschiedene Paketquellen, objektiv unlösbare Abhängigkeitskonflikte) gut im Griff und schaffen es fast immer mindestens eine funktionsfähige Option anzubieten. Meiner Meinung nach ist zypper und RPM inzwischen sogar noch stabiler als APT und dpkg, denn langjährige Supporterfahrung bei Debian und seinen Derivaten lehren, dass APT insbesondere bei Multiarch oder (falschem) Pinning in die Knie gehen kann.

Ebenso ist die mangelhafte Multimediaunterstützung von openSUSE Schnee von gestern. Die Standardinstallation von openSUSE basiert auf gstreamer 1.0 und die zugehörigen Good, Bad und Ugly Plugins finden sich ähnlich wie bei Debian & Co in den Paketquellen. Packmann oder ähnliches sind nicht mehr vonnöten.

Die KDE-Integration ist weiterhin absolut vorbildlich. Damit ist weniger die allgemeine Paketierung und Anzahl von KDE-Programmen in openSUSE gemeint, denn das ist bei Kubuntu und Debian auch vollkommen in Ordnung, sondern viele kleine Extras, die einem das Leben einfacher machen. Die Pixelhöhe bei der Anpassung der Plasma-Leisten, die Unterkategorien im K-Menü, die individuellen Plasmathemes. All das gibt einem als KDE-Nutzer nicht mehr das Gefühl, das fünfte Rad am Distributionswagen zu sein, sondern eine wirkliche KDE-Distribution zu erhalten. Wer natürlich seine Software am liebsten so ausgeliefert bekommt, wie sie von Upstream entwickelt wurde, ist mit openSUSE falsch bedient. Das im laufenden Distributionszyklus die KDE-Integration der LibreOffice-Dialoge durch ein Update entfernt wird, weil es niemand bemerkt hat, so wie kürzlich bei Kubuntu 14.04 LTS geschehen, scheint bei openSUSE jedoch schwer vorstellbar.

Das Schriftbild ist eine komplexe Sache, jeder der mehrere Geräte sein Eigen nennt weiß, dass hier objektive Beobachtungen sehr schwierig sind. Dennoch würde ich behaupten, dass das Schriftbild unter KDE bei openSUSE im Durchschnitt besser ist, als bei anderen Distributionen. Hier wurde seit 12.3 viel Feinarbeit vorgenommen und die Einstellungen angepasst. Das kann aber je nach Displaygröße und -auflösung, sowie den individuellen Gewohnheiten und Sehfähigkeiten variieren.

Endet die Lobeshymne auch noch?

Ja tut sie! Einige Baustellen und aus debianoider Sicht ungewohnte Verhaltensmuster finden sich bei openSUSE.

Während Gnome und seine Forks keine Systemeinstellungen haben, die diesen Namen auch wirklich verdienen, hat KDE bereits eine Fülle von Einstellungsmöglichkeiten mit dem Anspruch das komplette System zu regulieren. YaST tritt hier teilweise in Konkurrenz zu diesen Einstellungen. Die YaST-Softwareverwaltung vs. Apper, YaST-Druckerverwaltung vs. KDE-Printmanager usw. usf. Bei einigen ist das vollkommen unproblematisch und man kann einfach beide Werkzeuge nebeneinander benutzen, bei anderen kann das zu unterwünschten Nebenffekten führen. Warum openSUSE hier nicht konsequent auf die eigene Verwaltungssuite setzt, wissen wohl nur die Entwickler. Zumal beispielsweise Apper keineswegs besser als die Softwareverwaltung von YaST ist oder weniger Fehler verursacht. Hier lohnt es sich ggf. schon bei der Installation einige Verwaltungswerkzeuge wegzulassen. So kann man z.B. Apper und PackageKit bei der Installation abwählen, da dies kein direkte Abhängigkeit von KDE ist.

RPM kennt seit kurzem auch so genannte weiche Abhängigkeiten, wobei openSUSE das schon länger implementiert hat. Diese sind ein Äquivalent zu den “recommends” bei Debian und seinen Derivaten. Das funktioniert noch nicht wirklich gut. So kann ein Update von udev-configure-printer einen halben Gnome-Desktop auf die Festplatte ziehen, wenn man nicht aufpasst. Ein vollkommen automatisiertes Update ist also keine gute Idee, wenn man auf ein halbwegs aufgeräumtes System wert legt.

OpenSUSE benennt die Pakete zudem konsequent nach den Upstream-Vorgaben, während Debian hier systematischer vorgeht. Das ist gerade anfangs verwirrend. Während z.B. alle KDE-Administrationswerkzeuge bei Debian nach dem Schema kde-config-xyz benannt werden, können diese bei openSUSE kde-gtk-style oder synaptiks heißen. Daran gewöhnt man sich aber sehr schnell. Deutlich angenehmer ist, dass openSUSE die Pakete nicht in tausend Unterpakete ~~atomisiert~~ zerlegt, weshalb es einfacher ist bei Drittpaketen die notwendigen Abhängigkeiten manuell zu installieren. Welchen Sinn es macht, ein Quellcodepaket in ~10 Pakete zu zerlegen, die sich durch ihre Abhängigkeiten alle gegenseitig anfordern, hat sich mir nie erschlossen.

Beim Punkt Paketquellen ist aber auch zu erwähnen, dass die Paketquellen von openSUSE nicht so umfangreich wie bei Debian & Co sind. Das hat Vor- und Nachteile: Die Programme, die sich in den openSUSE-Paketquellen finden (und das ist mehr als 99% der Anwender brauchen) sind gut gewartet und auf dem aktuellen Stand (das war nicht immer so!), aber wenn man Spezialprogramme benötigt muss man relativ schnell Drittquellen hinzufügen. Dafür gibt es bei openSUSE den OBS und dort findet sich wirklich alles. Hier ist eine durchdachte Priorisierung der Paketquellen sinnvoll, die sich natürlich in YaST bequem durchführen lässt. Auch einer dieser Pluspunkte. Wie sich das auf ein eventuelles Distributionsupgrade im nächsten Jahr auswirkt, muss man jedoch dann sehen. Transfererfahrungen mit Kubuntu und vielen PPA’s lassen einen da nicht zu sehr hoffen.

Schlusspunkt

Seit meiner Abkehr von Debian als Allzweckwaffe für Server, Desktop und Notebooks habe ich ein “Distributionshopping” hinter mir, das seit meiner Anfangszeit mit Linux seinesgleichen sucht. Hoffentlich endet der kleine Exkurs diesen Blogs in die Untiefen der Distributionsberichte nun hier.

Bleibt es nun bei openSUSE? Auf einigen Systemen vorerst ja, sofern zu den geschilderten Problemen keine gravierenden hinzutreten. Für andere Systeme ist openSUSE nicht die beste Wahl. Es hat eben nicht den universalen Debian-Ansatz. Anstelle einer Distribution auf allen Geräten, läuft nun auf jedem Gerät die Distribution, die am besten zu den Anforderungen passt. Für KDE und den Desktop erscheint mir openSUSE als gute Wahl, jedenfalls sofern keine Supportzeiten von ~5 Jahren gefordert sind.

Besonders interessant als KDE-Anwender ist der OBS. Denn dieser bietet vorläufig eine Antwort auf die Frage, wie man als KDE-Nutzer den Spagat zwischen eingefrorenem KDE SC 4 und aktueller Drittsoftware meistern soll, während Plasma 5 noch nicht ausgereift ist.

Anhang: Ein paar Tipps&Tricks

Partitionierung

OpenSUSE 13.2 nutzt von Haus aus Btrfs für die / Partition und XFS für /home. Auch wenn in den letzten Monaten damit keine Schwierigkeiten aufgetreten sind mag mancher konservative Anwender doch lieber das bewährte Ext4 einsetzen. Deshalb sollte man bei der Installation den Partitionierungsvorschlag nie einfach absegnen, sondern das Partitionierungssetup noch einmal manuell erstellen.

Hier kann man die Dateisysteme bestimmen und ggf. eine LVM-basierte Variante mit LUKS Verschlüsselung auswählen. Insbesondere bei letzterer Variante muss man in einem zweiten Schritt noch in die erweiterten Partitionseinstellungen.

Die openSUSE Installationsroutine hat nämlich den interessanten Fehler die /home Partition unnötig klein (50 GB) zu halten. Hier noch einmal die Größe ändern und entweder manuell eingeben oder die maximale Größe – je nach Bedarf.

Softwareauswahl

Die Standardsoftwareauswahl von openSUSE ist – gelinde gesagt- umfangreich. Hinzu kommt, dass sie tendenziell konservativ ist. So wird beispielsweise immer noch Kopete anstatt KDE-Telepathy installiert, obwohl letzteres natürlich auch in den Paketquellen liegt. Die Softwareauswahl sollte man deshalb nicht einfach abnicken, sondern noch einmal detailliert anschauen.

Je nach Bedarf empfehle ich insbesondere folgende Punkt anzusehen:

Die Metapakete (patterns-openSUSE-xyz) können deutlich minimiert werden. Wirklich essenzielle Pakete lassen sich hier gar nicht abwählen, von daher kann man da nur wenig falsch machen.
PackageKit ist meiner Ansicht nach überflüssig, da YaST eine hervorragende Paketverwaltung bietet und man zudem noch zypper in der Konsole hat. Kann also eigentlich auch weg.
KDE-Nutzer sollen zudem noch schauen was von Gtk/GNOME-Paketen installiert werden soll. Hier kann deutlich abgespeckt werden.

Empfohlene Abhängigkeiten

Nach der Installation sollte man die Installation empfohlener Abhängigkeiten unterbinden, da openSUSE sonst dazu neigt viel zu umfangreiche Abhängigkeiten nachzuinstallieren. Zwar kann diese Änderung dazu führen, dass man gelegentlich mal ein Sprachpaket (PROGRAMM-lang) manuell nachinstallieren muss. Man erspart sich aber sonst viel Arbeit, da die wirklich essenziellen Abhängigkeiten weiterhin installiert werden.

Empfohlene Abhängigkeiten deaktiviert man global in der hervorragend dokumentierten zypper-Konfiguration unter /etc/zypp/zypp.conf

Folgender Abschnitt muss dazu angepasst werden:

##
## Whether required packages are installed ONLY
## So recommended packages, language packages and packages which depend
## on hardware (modalias) will not be regarded.
##
## Valid values: boolean
## Default value: false
##
solver.onlyRequires = true

Tastatur

Die Hardwareerkennung von openSUSE funktioniert leider tückisch gut. Während alle anderen Distributionen die Existenz meiner Apple-Tastatur geflissentlich ignorieren und mir ein Windows-Layout vorgaukeln, erkennt openSUSE die Tastatur richtig. Blöd nur, wenn man ein @ im Passwort hat und sich fragt weshalb die Eingabe nicht funktioniert…

Zudem kann es passieren, dass openSUSE anfänglich ein englisches Tastaturlayout haben will. Hier hilft es in YaST noch einmal die Auswahl auf Deutsch zu stellen.

Bei Apple-Tastaturen kann es vorkommen, dass das System den Gang auf die Dritte Ebene (ALT+xyz) verweigert. Hier muss man in den KDE-Systemeinstellungen unter Eingabegeräte / Tastatur als “Tastatur-Modell” noch einmal das Apple Aluminium Keyboard (ISO) auswählen und ironischerweise unter Erweitert die Einstellungen für die Dritte Tastaturebene entfernen.

Softwarquellen

OpenSUSE bietet dank des BuildServices eine Vielzahl an Softwarequellen um das System mit aktualisierten Programmen zu versorgen und dennoch einen stabilen Unterbau zu behalten. Als KDE-Nutzer sollte man unbedingt KDE:Extra einbinden und für die Multimedia-Pakete Packman.

Das SUSE-Äquivalent zum Debian-Pinning sind die Prioritäten, wobei eine niedrigere Zahl eine höhere Priorität bedeutet. Davon sollte man auf jeden Fall Gebrauch machen um die System-Stabilität zu gewährleisten. Die Standard-Priorität ist 99. Die Paketquellen für Updates (Oss und Non-Oss) sollte man mit einer niedrigeren Zahl versehen (ich nehme immer 50) und die OBS-Paketquellen mit einer höheren (ggf. 120), damit von dort nur installiert was man explizit auswählt.

Automatische Updates

Sofern man PackageKit/Apper nicht mitinstalliert hat, benachrichtigt eines das System nicht automatisch über Updates. Mir persönlich ist das sowieso immer zu nervig und wenn man die empfohlenen Abhängigkeiten deaktiviert hat, droht auch keine “Abhängigkeitshölle” durch neue Aktualisieren. Mittels des Pakets yast2-online-update-configuration kann man openSUSE dazu bewegen die Updates vollkommen automatisch einzuspielen. Dann kann man sich auch voll auf die Arbeit mit dem System und nicht für das System konzentrieren.

Btrfs-Snapshots

Btrfs kennt vollautomatische System-Snapshots, die man bei openSUSE mittels des YaST-Snapper Moduls verwalten und auch via Grub starten kann – sofern mal ein Update nicht wie erwartet funktioniert hat. Direkt nach der Installation ist Snapper aber noch nicht konfiguriert und produziert deshalb einen Fehler. Man muss deshalb auf der Konsole nachhelfen. Bei einer Standard-Installation mit separater /home Partition und den normalen Subvolumes reicht folgender Befehl:

# snapper -c root create-config /

Danach macht das zugehörige YaST-Modul auch was es soll.

Permalink

(Mer)Curius 30. April 2015 17:53

Systemverschlüsselung mit Android ¶

Google arbeitet bereits seit längerem an einer Vollverschlüsselung für Android. Die Funktionen sind bereits seit einigen Versionen enthalten, aber nicht standardmäßig aktiviert. Mit Lollipop sollte sich das eigentlich ändern, aber scheinbar haben Google und die Smartphonehersteller hier nochmal einen Rückzieher gemacht

Das Problem ist möglicherweise, dass sie auf dm-crypt basierende Verschlüsselung für viele Anwender zu umständlich ist. Beim Anschalten des Gerätes wird erst das Passwort für die Betriebssystemverschlüsselung abgefragt, dann der SIM-Pin und dann nochmal die Geräteentsperrung. Datenschutzbewusste Nutzer sehen hier den Sicherheitsaspekt, viele normale Anwender sind einfach nur genervt.

Nun scheint Google einen neuen Anlauf zu unternehmen. Die bei Google angestellten Kernelentwickler Theodore Ts’o (Maintainer ext4) und Michael Halcrow (eCryptFS Autor) haben einen Patch vorgestellt, der eine Verschlüsselung der Dateien und Dateinamen für das ext4 Dateisystem vorsieht. Die Verzeichnisstruktur bleibt sichtbar.

Letzteres ist zwar ein Nachteil gegenüber eCryptFS und LUKS/dm-crypt, scheint aber für den vorgesehenen Einsatzzweck ausreichend. Hier geht es schließlich nur darum Daten vor dem Zugriff durch Unbefugte zu bewahren (z.B. bei Diebstahl des Mobilgerätes). Spannend wird sein ob die bisherige dm-crypt basierte Verschlüsselung ersatzlos gestrichen wird oder optional erhalten bleibt. Letzteres wäre vor allem für Anwender interessant, die den Sicherheitsaspekt höher gewichten als den Bedienkomfort.

Mal sehen was das kommende Android “M” bringen wird.

Quellen:

Permalink

(Mer)Curius 30. April 2015 17:53

Zwei-Faktor-Authentifizierung in Joomla aktivieren ¶

Die Zwei-Faktor-Authentifizierung ist inzwischen bei allen großen Internetdiensten etabliert. Dabei wird der Account gesichert durch eine Kombination zweier voneinander unabhängiger Komponenten. In der Regel sind dies ein Passwort und ein beispielsweise von der Authenticator-App auf dem Smartphone generierten Schlüssel. Dadurch wird der Zugriff auf den Account verhindert, selbst wenn das Kennwort geknackt wurde. Insbesondere für Dienste deren Kennwort man auswendig wissen will/muss ist das eine gute Möglichkeit der Absicherung. Ein Smartphone hat man schließlich (fast) immer dabei.

joomla zweifaktor

Während es also üblich ist sich bei Google, Dropbox oder Evernote mittels Zwei-Faktor-Authentifizerung anzumelden sind die eigenen Webseiten meist deutlich ungeschützter. Das liegt daran, dass viele Blog- und Content Management Systeme eine solche Funktion nicht von Haus aus mitbringen - und wer möchte die Absicherung des Administrator-Kontos schon einem Addon überlassen? Anders bei Joomla und wieder einer der Gründe für den Plattformwechsel von [Mer]Curius.

Die Funktion lässt sich denkbar einfach aktivieren. Einfach das entsprechende Plugin im Admin-CP unter Erweiterungen aktivieren und dann den Administratoraccount unter Benutzer im Reiter Zwei-Faktor-Authentifizierung absichern. Hier lässt sich die Verknüpfung mit jeder passenden Authentifikator-App durchführen.

Wichtig: Die angezeigten Einmal-Kennwörter sollte man unbedingt ausdrucken und sicher aufheben. Anders als bei Google & Co gibt es nicht die Möglichkeit sich SMS mit Einmalkennwörtern zuzusenden (so etwas muss schließlich auch bezahlt werden).

Danach muss man bei jedem Login den vom Smartphone generierten Key eingeben.

Permalink

(Mer)Curius 30. April 2015 17:53

KDE SC 4: Ein bisschen Frischluft schnappen ¶

KDE SC 4 ist eine sehr gute Desktopumgebung, vielleicht die beste die Linux zur Zeit zu bieten hat. Jedenfalls sofern man wert auf eine integrierte Desktopumgebung mit zugehörigen Programmen legt, das einem in jeder Hinsicht alle Freiheiten lässt. Außerdem ist KDE SC nach vielen Entwicklungsjahren inzwischen sehr ausgereift. Mit der Einführung von Baloo und Kontact 4.14 im Sommer 2014 wurden die größten Baustellen des Desktops noch rechtzeitig vor dem Entwicklungsende von KDE SC 4 angegangen. Wer keinen Wert auf große Neuerungen legt erhält mit Kubuntu 14.04 LTS und Debian 8.0 Jessie ein absolut stabiles Desktopsystem für die nächsten Jahre.

konqi plasma5 Konqi-Dev-Maskotchen von KDE.org unter CC-BY-SA 3.0Die neuen Entwicklungen rund um Plasma 5 werfen zwar ihre Schatten vorraus und werden dieser Tage mit Kubuntu 15.04 erstmals einer breiteren Öffentlichkeit zur Verfügung gestellt, sind aber weder ausgereift noch zum bisherigen Zeitpunkt wirklich konsistent. Das bedeutet nicht, dass die Entwicklung schlecht ist oder in die falsche Richtung geht. Das Designteam leistet z.B. großartiges. Man sollte außerdem nicht an altem festhalten, sonst endet man ähnlich lächerlich wie die KDE 3.5 Nostalgiker. Die Entwicklung von Open Source Programmen fördert nur leider immer etwas raue Umstellungsprozesse, da der Nutzer gleichzeitig auch Betatester ist - es gibt schließlich keine aufwändigen Betatests bis das Produkt der Öffentlichkeit präsentiert wird. Wenn man sich Kubuntu 15.04 ansieht merkt man, dass bisher nur wenig von den Ideen des VDG (Visual Design Group) in Plasma 5 eingeflossen sind und viele Programme noch nicht portiert wurden. KDE zeichnete sich immer durch ein besonders enge Integration der Programme aus, das fehlt dadurch zur Zeit noch. Gute Gründe um vorerst bei KDE SC 4 zu bleiben.

Leider sieht man der 4er Version an, das ihr Design in der Hochzeit der 3D Spielereien entwickelt und seitdem – in Erwartung der 5er Reihe – keiner großen Änderung unterzogen wurde. Während man früher also Fehler meldete und mit Abstürzen zu kämpfen hatte, besteht heute die Arbeit darin KDE ein Aussehen zu verpassen, das mit den anderen Desktopumgebungen mithalten kann. Der Artikel wird deshalb zeigen, wie man KDE SC 4 optisch an die geplante 5er Version angleicht, ohne gleich auf die neue Version wechseln zu müssen. Damit man es auch im Jahr 2015 noch mit dem Desktop aushält. Ich persönlich finde die Leistenanordnung von Unity sehr gut, weil sich dadurch wichtige Schaltflächen in der oberen linken Ecke befinden. Dies wird deshalb in das Tutorial einfließen, wer das nicht mag, kann den Teil ja überspringen.

KDE Plasma anpassen

Die Voreinstellung von Plasma ist immer noch sehr stark an das so genannte Windows 95 Modell angelehnt. Fensterleiste unten mit einigen Schnellstartern und einem Startmenü. Windows 8 hat gezeigt, dass viele Nutzer genau das von einer Desktopumgebung im Jahr 2014 erwarten – wieso auch immer. Der Vorteil von Plasma ist, dass man damit quasi jedes Desktopkonzept nachbilden kann. Um Plasma optisch an Ubuntus Unity anzupassen verlegt man die Fensterleiste an den oberen Bildschirmrand und verkleinert sie ein wenig. Die Fensterleiste selbst löscht man und ersetzt sie mit einem Abstandshalter.

leiste oben

Mit einem Rechtsklick auf den Desktop erstellt man über Kontrollleiste hinzufügen / Leere Kontrolleiste eine weitere Plasmaleiste. Diese legt man an den linken Rand und vergrößert sie so weit, bis sie direkt an die obere Leiste anschließt. In diese Leiste legt man ein K-Menü und die Symbolfensterleiste. Die Einstellungen der Symbolfensterleiste passe ich zudem immer noch wie folgt an, aber das ist Geschmacksacke:

symbolfensterleiste einstellungen

Als Theme kann man weiterhin Air verwenden oder auf ein anderes Thema wechseln. Das Breeze-Theme lässt sich leider nicht einfach rückportieren, weshalb man die freie Wahl aus den für Plasma 4 zur Verfügung stehenden Themes hat. Persönliche Empfehlung: Tilain oder Caledonia.

ergebnis

Oxygen durch Breeze ersetzen

In einer frischen Debian Installation sieht KDE SC 4.14 ziemlich ~~hässlich~~ altmodisch aus. Schattierungen und 3D Effekte überall. Dazu kommt die sandfarben-schlammgraue Oberfläche der Programme und die komischen Popupmenüs, die schon 2008 nicht optimal aussahen.

Anfangs arbeitete die VDG mit QtCurve, aber den QtCurve-Designs sieht man immer an, dass sie letztlich nur "zusammen geklickt" wurden durch eine Vorauswahl diverser Optionen. Deshalb ging man dazu über ein neues Design ohne QtCurve zu implementieren.

breeze

Die Installation von Breeze variiert von Distribution zu Distribution. OpenSUSE 13.2-Nutzer können Breeze in einer aktuellen Version direkt aus den Standardpaketquellen installieren. So einfach haben es Nutzer von Debian 8.0 Jessie und Kubuntu 14.04 LTS nicht. Hier muss manuell nach gearbeitet werden.

Eine Option besteht sicherlich darin, das Design aus dem Code heraus zu bauen. Das dauert vielen aber zu lange und .deb Pakete zu bauen ist alles andere als einfach für ungeübte Nutzer bin. Einfacher ist es sich einfach bei den Paketquellen von Kubuntu 15.04 zu bedienen.

Das zugehörige Paket heißt kde-style-breeze-qt4 und lässt sich als .deb Paket passend für die eigene Architektur herunterladen. Leider wurde eine Abhängigkeit auf die Qt 5 Version des Breeze Designs gesetzt (die eigentlich überflüssig ist), weshalb man eine ganze Abhängigkeitskette hin zu den neuen KDE Frameworks nach sich zieht.

Exkurs: Abhängigkeiten des Pakets modifizieren

[message_box title="Hinweis" type="error" close="yes|no"]Die folgende Anleitung wurde unter Kubuntu 14.04 und Debian “Jessie” 8.0 getestet. Alle anderen Versionen und Distributionen können ebenfalls funktionieren, müssen aber nicht.[/message_box]

Zuerst lädt man das zu bearbeitende Paket herunter, z.B. nach Downloads. Dort benötigen wir ein provisorisches Verzeichnis, sowie ein Verzeichnis mit dem Namen DEBIAN.

$ mkdir pkgtemp

$ mkdir pkgtemp/DEBIAN

Danach entpackt man das Paket in die beiden Verzeichnisse mit den folgenden beiden Befehlen:

$ dpkg -x <name-des-pakets>.deb pkgtemp

$ dpkg -e <name-des-pakets>.deb pktemp/DEBIAN

Im Verzeichnis pkgtemp/DEBIAN befindet sich eine Datei namens control. In dieser sind die Abhängigkeiten festgelegt. Dort löscht man die unnötige Abhängigkeit auf das Qt5 Paket (ist die letzte Abhängigkeit in der entsprechenden Zeile).

Depends: […] kde-style-breeze

Nun muss man das auseinander genommene Archiv wieder zusammen bauen.

$ dpkg -b pkgtemp breeze-qt4.deb

Dieses Paket lässt sich nun einfach installieren

$ sudo -i breeze-qt4.deb

Bei den anderen Paketen aus den Kubuntu-Quellen (breeze-icon-theme und breeze-cursor-theme) ist eine solche Nacharbeit zum Glück nicht notwendig und diese lassen sich einfach installieren.

In den Systemeinstellungen unter Erscheinungsbild von Anwendungen / Stil wählt man Breeze als Bedienelementestil aus. In den Einstellungen von Breeze kann man ganz nach dem eigenen Gechmack noch einige Optionen verändern

breeze einstellungen

Unter Farben sucht man unter Neue Farbschema herunterladen nach "Breeze" und importiert das Farbschema. Dasselbe kann man bei den Emoticons erledigen.

In den Systemeinstellungen unter Erscheinungsbild der Arbeitsfläche lässt sich das Mauszeiger-Thema auf Breeze umschalten. Das zugehörige Theme wurde entweder über das Kubuntu-Paket installiert oder muss ebenfalls heruntergeladen werden.

Login-Manager und KSplash anpassen

Manche Distributionen wie openSUSE oder Debian liefern angepasste Versionen des KDM/LightDM sowie KSplash-Designs aus. Sofern man mit dem Branding der Distribution zufrieden ist kann man sich diesen Schritt möglicherweise sparen. Andere Distributionen wie Kubuntu liefern zwar einen eigenen Plymouth-Startscreen aus, nutzen aber bei LightDM und KSplash das normale KDE-Branding. Hier ist eine Anpassung an Breeze ratsam, da dies sonst wie ein Bruch im Design wirkt.

Die Community ist bei Linux zum Glück nie untätig, weshalb es eine Portierung des Plasma 5 KSplash für KDE SC 4 gibt: KDE 5 Splash Screen

Dieses lädt man runter und entpackt es nach

/home/<benutzer>/.kde/share/ksplash/Themes

Das Verzeichnis ist möglicherweise anzulegen. Alternativ kann man dies auch automatisiert erledigen lassen unter Systemeinstellungen | Erscheinungsbild der Arbeitsfläche im Bereich Startbildschirm über den Button Neue Designs herunterladen und dort das obige Theme suchen.

Der gleiche Autor bietet auch ein KDM Design, das sich hier herunterladen lässt: Plasma 5 KDM Theme

Dieses muss man nun leider wirklich manuell installieren indem man es an folgendem Ort ablegt:

$ sudo mv plasma5/ /usr/share/kde4/apps/kdm/themes/

Im entsprechenden Systemeinstellungs-Modus lässt sich das Thema aktivieren.

LightDM lässt sich nicht so leicht aufhübschen. Hier kann man allenfalls das Hintergrundbild ändern. Dazu kopiert man am besten das Hintergrundbild des Splash-Screens nach

/usr/share/wallpapers/

Auf dieses Verzeichnis kann KSplash auch bei Systemverschlüsselung mittels eCryptFS zugreifen und das Wallpaper als Hintergrundbild verwenden. Die Lösung ist zwar etwas weniger elegant, als das KDM-Äquivalent aber hinreichend schön anzusehen.

Auf die Art bekommt KDE 4 einen leidlich modernen Look mit dem man es vorerst bis 2016 schaffen sollte, wenn KDE 5 halbwegs stabil ist.

Permalink

(Mer)Curius 30. April 2015 17:53

Debian 8.0 "Jessie" im KDE Test ¶

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 Lines von Juliette Taka BELIN unter Creative Commons Attribution; angepasst mit Releasedatum von Laura Arjona

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.

Änderungen:

15.07.2015: Credits für das Bild eingefügt.

Permalink

(Mer)Curius 30. April 2015 17:53

KDE SC 4: Ein bisschen Frischluft schnappen ¶

konqi admin plasma5 Konqi-Dev-Maskotchen von KDE.org | Lizenz CC-BY-SA 3.0KDE SC 4 ist eine sehr gute Desktopumgebung, vielleicht die beste die Linux zur Zeit zu bieten hat. Jedenfalls sofern man wert auf eine integrierte Desktopumgebung mit zugehörigen Programmen legt, das einem in jeder Hinsicht alle Freiheiten lässt. Außerdem ist KDE SC nach vielen Entwicklungsjahren inzwischen sehr ausgereift. Mit der Einführung von Baloo und Kontact 4.14 im Sommer 2014 wurden die größten Baustellen des Desktops noch rechtzeitig vor dem Entwicklungsende von KDE SC 4 angegangen. Wer keinen Wert auf große Neuerungen legt erhält mit Kubuntu 14.04 LTS und Debian 8.0 Jessie ein absolut stabiles Desktopsystem für die nächsten Jahre.

Die neuen Entwicklungen rund um Plasma 5 werfen zwar ihre Schatten vorraus und wurden mit Kubuntu 15.04 erstmals einer breiteren Öffentlichkeit zur Verfügung gestellt, sind aber weder ausgereift noch zum bisherigen Zeitpunkt wirklich konsistent. Das bedeutet nicht, dass die Entwicklung schlecht ist oder in die falsche Richtung geht. Das Designteam leistet z.B. großartiges. Man sollte außerdem nicht an altem festhalten, sonst endet man ähnlich lächerlich wie die KDE 3.5-Nostalgiker. Die Entwicklung von Open Source Programmen fördert nur leider immer etwas raue Umstellungsprozesse, da der Nutzer gleichzeitig auch Betatester ist - es gibt schließlich keine aufwändigen Betatests bis das Produkt der Öffentlichkeit präsentiert wird. Wenn man sich Kubuntu 15.04 ansieht merkt man, dass bisher nur wenig von den Ideen des VDG (Visual Design Group) in Plasma 5 eingeflossen sind und viele Programme noch nicht portiert wurden. KDE zeichnete sich immer durch ein besonders enge Integration der Programme aus, das fehlt dadurch zur Zeit noch. Gute Gründe um vorerst bei KDE SC 4 zu bleiben.

Leider sieht man der 4er Version an, dass ihr Design in der Hochzeit der 3D Spielereien entwickelt und seitdem – in Erwartung der 5er Reihe – keiner großen Änderung unterzogen wurde. Während man früher also Fehler meldete und mit Abstürzen zu kämpfen hatte, besteht heute die Arbeit darin KDE ein Aussehen zu verpassen, das mit den anderen Desktopumgebungen mithalten kann. Der Artikel wird deshalb zeigen, wie man KDE SC 4 optisch an die geplante 5er Version angleicht, ohne gleich auf die neue Version wechseln zu müssen. Damit man es auch im Jahr 2015 noch mit dem Desktop aushält. Ich persönlich finde die Leistenanordnung von Unity sehr gut, weil sich dadurch wichtige Schaltflächen in der oberen linken Ecke befinden. Dies wird deshalb in das Tutorial einfließen, wer das nicht mag, kann den Teil ja überspringen.

KDE Plasma an Unity anpassen

Die Voreinstellung von Plasma ist immer noch sehr stark an das so genannte Windows 95 Modell angelehnt. Fensterleiste unten mit einigen Schnellstartern und einem Startmenü. Windows 8 hat gezeigt, dass viele Nutzer genau das von einer Desktopumgebung im Jahr 2014 erwarten – wieso auch immer. Der Vorteil von Plasma ist, dass man damit quasi jedes Desktopkonzept nachbilden kann. Um Plasma optisch an Ubuntus Unity anzupassen verlegt man die Fensterleiste an den oberen Bildschirmrand und verkleinert sie ein wenig. Die Fensterleiste selbst löscht man und ersetzt sie mit einem Abstandshalter.

leiste oben

Mit einem Rechtsklick auf den Desktop erstellt man über Kontrollleiste hinzufügen | Leere Kontrolleiste eine weitere Plasmaleiste. Diese legt man an den linken Rand und vergrößert sie so weit, bis sie direkt an die obere Leiste anschließt. In diese Leiste legt man ein K-Menü und die Symbolfensterleiste. Die Einstellungen der Symbolfensterleiste passe ich zudem immer noch wie folgt an, aber das ist Geschmacksacke:

symbolfensterleiste einstellungen

Als Theme kann man weiterhin Air verwenden oder auf ein anderes Thema wechseln. Das neue dunkle Breeze-Plasma-Theme wurden inzwischen auf KDE Plasma 4 zurückportiert und kann in den Systemeinstellungen heruntergeladen werden. In Systemeinstellungen | Erscheinungsbild der Arbeitsfläche | Arbeitsflächen-Design sucht man über den Button Neue Designs herunterladen nach dem dunklen Breeze-Theme.

plasma theme

Nach dem auswählen sollte man sich einmal ab- und wieder anmelden um die Umstellung zu vollenden. Wichtig ist zudem den "Blur"-Effekt (Verwischen) in den Arbeitsflächeneffekten zu deaktiveren. Dieser benötigt sowieso unverhältnismäßig viel Leistung.

ergebnis

Oxygen durch Breeze ersetzen

In einer frischen Debian Installation sieht KDE SC 4.14 ziemlich ~~hässlich~~ altmodisch aus. Schattierungen und 3D Effekte überall. Dazu kommt die sandfarben-schlammgraue Oberfläche der Programme und die komischen Popupmenüs, die schon 2008 nicht optimal aussahen.

Anfangs arbeitete die VDG mit QtCurve, aber den QtCurve-Designs sieht man immer an, dass sie letztlich nur "zusammen geklickt" wurden durch eine Vorauswahl diverser Optionen. Deshalb ging man dazu über ein neues Design ohne QtCurve zu implementieren.

breeze

Die Installation von Breeze variiert von Distribution zu Distribution. OpenSUSE 13.2-Nutzer können Breeze in einer aktuellen Version direkt aus den Standardpaketquellen installieren. So einfach haben es Nutzer von Debian 8.0 "Jessie" und Kubuntu 14.04 LTS nicht. Hier muss manuell nach gearbeitet werden.

Eine Option besteht sicherlich darin, das Design aus dem Code heraus zu bauen. Das dauert vielen aber zu lange und .deb Pakete zu bauen ist alles andere als einfach für ungeübte Nutzer bin. Einfacher ist es sich einfach bei den Paketquellen von Kubuntu 15.04 bzw. Debian Testing "Stretch" zu bedienen.

Das zugehörige Paket heißt kde-style-breeze-qt4 und lässt sich als .deb Paket passend für die eigene Architektur herunterladen. Leider wurde bei Debian und Kubuntu eine Abhängigkeit auf die Qt 5 Version des Breeze Designs gesetzt (die eigentlich überflüssig ist), weshalb man eine ganze Abhängigkeitskette hin zu den neuen KDE Frameworks nach sich zieht.

Exkurs: Abhängigkeiten des Pakets modifizieren

Die folgende Anleitung wurde unter Kubuntu 14.04 und Debian “Jessie” 8.0 getestet. Alle anderen Versionen und Distributionen können ebenfalls funktionieren, müssen aber nicht.

Zuerst lädt man das zu bearbeitende Paket herunter, z.B. nach Downloads. Dort benötigen wir ein provisorisches Verzeichnis, sowie ein Verzeichnis mit dem Namen DEBIAN.

$ mkdir pkgtemp

$ mkdir pkgtemp/DEBIAN

Danach entpackt man das Paket in die beiden Verzeichnisse mit den folgenden beiden Befehlen:

$ dpkg -x <name-des-pakets>.deb pkgtemp

$ dpkg -e <name-des-pakets>.deb pktemp/DEBIAN

Im Verzeichnis pkgtemp/DEBIAN befindet sich eine Datei namens control. In dieser sind die Abhängigkeiten festgelegt. Dort löscht man die unnötige Abhängigkeit auf das Qt5 Paket (ist die letzte Abhängigkeit in der entsprechenden Zeile).

Depends: […] kde-style-breeze

Nun muss man das auseinander genommene Archiv wieder zusammen bauen.

$ dpkg -b pkgtemp breeze-qt4.deb

Dieses Paket lässt sich nun einfach installieren

$ sudo -i breeze-qt4.deb

Bei den anderen Paketen aus den Kubuntu bzw. Debian-Quellen (breeze-icon-theme und breeze-cursor-theme) ist eine solche Nacharbeit zum Glück nicht notwendig und diese lassen sich einfach installieren.

Debian

# dpkg -i breeze-icon-theme && dpkg -i breeze-cursor-theme

Kubuntu

$ sudo dpkg -i breeze-icon-theme && sudo dpkg -i breeze-cursor-theme

In den Systemeinstellungen unter Erscheinungsbild von Anwendungen / Stil wählt man Breeze als Bedienelementestil aus. In den Einstellungen von Breeze kann man ganz nach dem eigenen Gechmack noch einige Optionen verändern

breeze einstellungen

Unter Farben sucht man unter Neue Farbschema herunterladen nach "Breeze" und importiert das Farbschema. Dasselbe kann man bei den Emoticons erledigen.

In den Systemeinstellungen unter Erscheinungsbild der Arbeitsfläche lässt sich das Mauszeiger-Thema auf Breeze umschalten. Das zugehörige Theme wurde entweder über das Kubuntu-Paket installiert oder muss ebenfalls heruntergeladen werden.

Login-Manager und KSplash anpassen

Manche Distributionen wie openSUSE oder Debian liefern angepasste Versionen des KDM/LightDM sowie KSplash-Designs aus. Sofern man mit dem Branding der Distribution zufrieden ist kann man sich diesen Schritt möglicherweise sparen. Andere Distributionen wie Kubuntu liefern zwar einen eigenen Plymouth-Startscreen aus, nutzen aber bei LightDM und KSplash das normale KDE-Branding. Hier ist eine Anpassung an Breeze ratsam, da dies sonst wie ein Bruch im Design wirkt.

Die Community ist bei Linux zum Glück nie untätig, weshalb es eine Portierung des Plasma 5 KSplash für KDE SC 4 gibt: KDE 5 Splash Screen

Dieses lädt man runter und entpackt es nach

/home/<benutzer>/.kde/share/ksplash/Themes

Das Verzeichnis ist möglicherweise anzulegen. Alternativ kann man dies auch automatisiert erledigen lassen unter Systemeinstellungen | Erscheinungsbild der Arbeitsfläche im Bereich Startbildschirm über den Button Neue Designs herunterladen und dort das obige Theme suchen.

Der gleiche Autor bietet auch ein KDM Design, das sich hier herunterladen lässt: Plasma 5 KDM Theme

Dieses muss man nun leider wirklich manuell installieren indem man es an folgendem Ort ablegt:

$ sudo mv plasma5/ /usr/share/kde4/apps/kdm/themes/

Im entsprechenden Systemeinstellungs-Modus lässt sich das Thema aktivieren.

LightDM lässt sich nicht so leicht aufhübschen. Hier kann man allenfalls das Hintergrundbild ändern. Dazu kopiert man am besten das Hintergrundbild des Splash-Screens nach

/usr/share/wallpapers/

Auf dieses Verzeichnis kann KSplash auch bei Systemverschlüsselung mittels eCryptFS zugreifen und das Wallpaper als Hintergrundbild verwenden. Die Lösung ist zwar etwas weniger elegant, als das KDM-Äquivalent aber hinreichend schön anzusehen.

Auf die Art bekommt KDE 4 einen leidlich modernen Look mit dem man es vorerst bis 2016 schaffen sollte, wenn KDE 5 halbwegs stabil ist.

Aktualisierungen:

02. August 2015: Release von Debian Jessie berücksichtigt; Shortcodes aktualisiert.

20. Septemer 2015: Verweis auf Breeze-Plasma-Theme ergänzt.

Permalink

(Mer)Curius 30. April 2015 17:53

Kommentar: Debians Installationsroutine ¶

Das von mir kürzlich erworbene Subnotebook macht mir immer noch sehr viel Freude. Das kann man von Kubuntu leider nicht behaupten. Nach dem Kauf musste ja schnell ein Betriebssystem installiert werden und mangels Ethernet-Port wurde es die 14.04er LTS. Neben kleinen Problemen, wie die nicht funktionierende Lautstärkesteuerung nervte mich der schlechte Pflegezustand der LTS jeden Nutzungstag ein wenig mehr. An allen Ecken und Enden finden sich Bugs, die teilweise schon seit Monaten/Jahren gemeldet sind und scheinbar keine Priorität genießen. Ganz besonders nervig ist der Akonadi-Bug, bei dem KOrganizer vollkommen unbegründet eingetragene Kalender vergisst, die sich erst durch einen Neustart wiederfinden lassen. Das brachte mich in den vergangenen Tagen an den Rand des Wahnsinn. Der Bug ist in neueren Akonadi/Kontact Versionen behoben, aber dem Kubuntu-Team scheint der Wille oder die Fähigkeit zu fehlen die Fehlerbehebung zurück zu portieren.

Debian Lines, Juliette Taka BELIN Lizenz: Creative Commons Attribution 3.0 Lizenz: Creative Commons Attribution 3.0

Neuere STS Releases kommen leider nicht in Frage. Das Subnotebook soll einfach nur funktionieren und mich nicht alle Nase lang alle paar Monate mit Distributionsupgrades nerven. Deshalb ja schließlich auch die Idee mit der LTS. OpenSUSE 13.2, das bei mir einen sehr guten Eindruck hinterlassen hat kommt aus selbigem Grund leider auch nicht in die nähere Auswahl. Also muss es wohl Debian werden. Das Release von Jessie steht kurz bevor und der Ersteindruck im vergangenen Jahr war nicht so übel. Das KDE Team ist dort zwar auch nicht mit Manpower oder durchweg weisen Entscheidungen gesegnet, aber immerhin liegt Kontact in Version 4.14 vor. Das man mal für einen blöden Bug einen Distributionswechsel vornimmt, kommt auch nicht so oft vor, aber bei einem zentralen Werkzeug für Kontact geht man über Leichen.

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Leider ist dem Notebook in der letzten Woche immer noch kein Ethnernet-Port gewachsen. Ein Netinstall fiel deshalb scheinbar flach. Debian bietet aber zum Glück mehr als genug Installationsmedien, die DVD 1 sollte das notwendigste abdecken. Seit Jessie kann man in der Installationsroutine auch die Desktopumgebung ohne schmutzige Tricks auswählen. Mal schauen was Debians KDE Team dem Nutzer so andient. Die Installationsroutine verrät schon mal, dass es ca. 1 300 Pakete werden. Also ein ähnlicher Umfang wie eine Kubuntu-Installation. Nach dem obligatorischen Neustart und einem Blick in die Paketliste, sowie des Startmenüs fällt es einem schwer die Zusammenstellung zu beschreiben. Genau genommen wäre eine subjektive Beschreibung hier gerade gefährdend für alle Altersgruppen.

Debians KDE Team ist wohl der Meinung, dass man drei Werkzeuge zur Drucker-Verwaltung braucht, Super-Karamba schön an KDE 3.5 erinnert, Kopete ein zeitgemäßerer IM-Client ist und kdesudo nicht schlecht wäre – obwohl Debian das von Haus aus nicht braucht.

Liebes Debian KDE Team. Apt-get ist ein super Werkzeug für die Paketverwaltung und Distributionsupgrades funktionieren bei Debian wirklich hervorragend. Scheinbar so gut, dass niemand in eurem Team in den letzten Jahren eine Neuinstallation vorgenommen hat. Jedenfalls nicht mit den normalen Installationsmedien und einer Standard-Installation. Anders kann man sich diesen Unfall nicht erklären.

Debian Netinstall ohne Ethernet Port

Mit dem System werde ich nicht glücklich. Alleine die Deinstallationsorgie braucht mehr Zeit, als eine frische Netinstallation in Anspruch nimmt. Wäre da nicht der fehlende Ethnernet-Port. Auf der Debian-Webseite versprechen die Debian-Maintainer allerdings, dass eine Netinstall (mit Einschränkungen) auch via WLAN möglich ist. Vielleicht hat sich seit den Zeiten von Lenny und KDE 3.5 doch was getan. Der Download geht bei knapp 200MB zum Glück auch schnell und selbst dd schafft es nicht sich an der Dateigröße zu verschlucken.

Die Überraschung folgt auf dem Fuße. Debians Installationsroutine (natürlich nach einbinden der unfreien firmware-Pakete) erkennt tatsächlich das WLAN und richtet es ein. Die Installation danach ist Routine, UEFI und LUKS/LVM werden zufriedenstellend eingerichtet. Bei der Task-Auswahl entscheidet man sich natürlich nur für eine Minimalinstallation. Das Softwaremuseum von oben will man schließlich kein zweites Mal auf der Festplatte sehen. #

Nach dem Neustart dann die Ernüchterung. Keine funktionierendes WLAN weit und breit. Also muss doch wpa_supplicant und ifup ran. Wenigstens ist beides in der Minimalinstallation enthalten.

Zuerst ermittelt man den WPA-PSK Hash:

§ wpa_passphrase <WLAN-SSID> <PASSPHRASE> # natürlich ohne die <>

Das Ergebnis trägt an in /etc/interfaces/network ein.

auto wlan0

iface wlan0

inet dhcp

wpa-ssid <Meine SSID>

wpa-psk <Mein Passwort>

Dann noch das WLAN aktivieren mit:

# ifup wlan0

Danach kann man wie gewohnt die notwendigen Pakete installieren. Sofern man auf den NetworkManager wechselt, muss man die Einträge in der network-Datei wieder entfernen.

Aktualisierungen:

28.06.2015: Fehler in der Ermittlung der PSK-Phrase behoben.

Permalink

(Mer)Curius 30. April 2015 17:53

openSUSE 13.2 im Test ¶

Früher™ war der Release einer neuen Version von SUSE Linux / openSUSE eines der wichtigsten Ereignisse im Linux Kalendarium. Spätestens seit Ubuntu in der Öffentlichkeit synonym für Linux auf dem Desktop verwendet wird, hat die Distribution mit dem sympathischen Chamäleon als Logo die Position des Marktführers bei den benutzerfreundlichen Distributionen räumen müssen. Dennoch ist openSUSE gerade für KDE-Nutzer eine wichtige Distribution mit eine ganz eigenen Profil, deren Release einen Test verdient.

opensuse startscreen

Ein Jahr Entwicklung

Die Entwicklung von openSUSE sollte eigentlich einem achtmonatigen Rhythmus folgen. Verschiebungen und Neustrukturierungen des Releaseablaufs sind bei openSUSE inwzischen aber mehr die Regel, denn die Ausnahme. Nachdem die Entwicklung von 11.2 fast 12 Monate dauerte, etablierte man den 8-Monats-Rythmus, den man exakt für sechs Versionen einhalten konnte. Die letzten beiden Releases 12.3 und 13.1 haben beide ein höchst positives Echo in der Community hervorgerufen.

Hinter den Kulissen gestaltete sich die Lage wohl aber nicht so entspannt. Die Projektleitung musste den einzelnen Teams zunehmend auf die Füße treten, damit Pakete für einen Release fertig gemacht wurden und einige Pakete waren gänzlich verwaist. Hier gibt es bis heute zwei unterschiedliche Darstellungen der Probleme. Während das Projekt von einer zu intensiven Mitarbeit und zu vielen Maintaintern in zu vielen Projekten spricht, sehen externe Beobachter eher einen Mangel an Mitarbeit und einige tote Projekte. Egal wo die Ursachen zu sehen sind, Anfang des Jahres wurde der Release von 13.2 auf unbestimmte Zeit vertagt. Erstmal sollte die Struktur von openSUSE grundlegend geprüft werden. Ein Rückzug der SUSE GmbH – nach diversen Übernahmen nun wieder formal eigenständig – aus der Betreuung des Community-Ablegers wurde als Gerücht gestreut.

Es hat sich einiges getan. Im Sommer wurde beschlossen aus dem bisherigen Factory-Zweig, ähnlich Debians Testing, eine Rolling Release Version von openSUSE zu machen. Tumbleweed wird im Gegenzug wohl eingestellt. Weitreichende Änderungsvorschläge, die vorsahen nur noch einen Basis-Release herauszugeben, der von den Nutzern um OBS-Zweige ergänzt werden würde, wurden scheinbar verworfen.

Nach nunmehr einem Jahr Entwicklung steht deshalb die Version 13.2 vor der Tür und verdient nach den ganzen Verwerfungen einen intensiven Test.

Der Installer

Die Installationsroutine wurde mit der neuen Version einer grundsätzlichen Überarbeitung unterzogen. OpenSUSE profitiert hier von den Entwicklungen in SUSE Linux Enterprise, dessen 12er-Release sich in der RC-Phase befindet. Meiner Meinung nach hat man hier äußerst gekonnt den Spagat zwischen einer sinnvollen Modernisierung und einer Beibehaltung bewährter Prinzipien hin bekommen.

Nach der obligatorischen Bestätigung der Lizenzen folgt bereits die erste Überraschung. Bei einer frischen Neuinstallation empfiehlt openSUSE eine Partitionierung mittels BtrFS, wobei die Home-Partition (sofern vorhanden)mit XFS partitioniert wird. Damit ist openSUSE die erste Mainstream-Distribution, die standardmäßig auf das seit Ewigkeiten als kommendes Dateisystem gehandelte BtrFS setzt.

dateisystemauswahl

Der Auswahldialog ist dabei bewusst einfach gehalten und bietet auch für Anfänger die notwendigen Optionen. Es ist mit wenigen Mausklicks möglich das gesamte System zu verschlüsseln, oder keine separate Homepartition anzulegen. Dennoch versucht openSUSE immer einen eigenen Weg zu gehen. Im Gegensatz zu Ubuntu setzt man eben nicht auf Optionsminimalismus um Einfachheit zu suggerieren, sondern bietet gesonderte Expertenoptionen, die einem die volle Hoheit über den Partitionierungsprozess geben.

partitionierung expertenmodus

Im nächsten Schritt bekommt man noch einmal die bekannte Zusammenfassung der gewählten Optionen präsentiert. Hier hat man nun die Gelegenheit die Zusammenstellung der Pakete grundlegend zu bearbeiten. Das ist eines der Alleinstellungsmerkmale von openSUSE und macht hochgradig individuelle Installationen möglich. Der Unterschied fällt nicht nur zu Ubuntu auf, das letztlich eine Kopie des Live-Systems auf die Festplatte spiegelt, sondern auch zu Debian. Denn Debian bietet einem nur die Auswahl mit oder ohne Desktop zu installieren. Individualisierte Systeme lassen sich nur über den Aufbau ausgehend von einem Minimalsystem realisieren.

detaillierte softwareauswahl

Für diesen Test habe ich die Auswahl unverändert übernommen, damit ein unverfälschter Blick auf die Standardkonfiguration von openSUSE entsteht. Ansonsten lohnt es sich aber insbesondere die patterns-Pakete gründlich zu prüfen. Dabei handelt es sich um die Meta-Pakete von openSUSE, vergleichbar den task-xxx bei Debian.

Software

Natürlich bringt openSUSE aktualisierte Software in allen Bereichen. Um Google zu füttern, könnte man hier von Kernel x.y und GCC z.x schreiben. Solche Buzzwords spare ich mir hier mal.

Wesentlich für den Desktop ist, dass openSUSE weiterhin eine nahezu perfekte Integration von KDE ausliefert. In der Installationsroutine ist KDE 4 vorausgewählt und wird – sofern man keine manuelle Änderung vornimmt – mit einem ausgewählten Softwarepaket installiert. Vorschauversionen von Plasma 5 und KF5 sind zwar in den Paketquellen enthalten, können aber sinnvollerweise nicht im Installationsvorgang ausgewählt werden. Hier hat openSUSE vom Debakel bei KDE 4 in openSUSE 11.0 gelernt.

KDE wird in doppelter Hinsicht als LTS Version ausgeliefert. Die KDE Workspaces (Plasma, KWin usw.) sind bereits seit vergangenem Jahr in Version 4.11 eingefroren und werden noch ca. ein Jahr mit Fehlerbehebungen versorgt. Die KDE Applications erschienen kürzlich noch einmal in Version 4.14 und sind nun ebenfalls als LTS Version eingefrorenen. Das KDE Projekt befindet sich somit im Übergang zu Version 5, openSUSE-Anwender kommen aber in Genuss einer in jeder Hinsicht bewährten und stabilen 4er Version, die noch einige Zeit gepflegt werden wird. Nachdem openSUSE vor einiger Zeit damit begonnen hat die strikte Beibehaltung der Releaseversion als Richtlinie aufzuweichen, werden Anwender nun auch in den Genuss von Fehlerbehebungsaktualisierungen kommen. In openSUSE 13.1 hat man beispielsweise bisher 12 Aktualisierungen für KWin nachgereicht, nichts spricht dagegen, dass es bei 13.2 anders verlaufen wird. Dies ist vor allem deshalb erfreulich, weil andere Distributionen wie Debian aufgrund strikter Paketrichtlinien lieber nichts nachreichen, oder wie Kubuntu nach ca. 6 Monaten das Interesse an einem Release verlieren und nur noch Sicherheitsaktualisierungen einspielen. Das mag jeweils seine Gründe haben, ist aber für den Nutzer ärgerlich, weil er auf alten Fehlern sitzen bleibt.

KDE ist wie immer um einige kleine Extras ergänzt. Das neue – nun wieder grüne – Design zieht sich durch den gesamten Desktop und auch sonst gibt es kleine nützliche Hilfen. Beispielsweise werden bei der Verkleinerung von Plasma-Leisten die Höhe in Pixel angegeben und das K-Menü ist übersichtlicher strukturiert, als dies von Haus aus der Fall ist. Alle Browser werden so beispielsweise in einer Kategorie Webbrowser gesammelt. Nachdem das KDE-Projekt keinen vernünftigen Browser ausliefern kann, greift man auf Firefox zurück. Hier hat openSUSE ein Addon implementiert, das die Nutzung der nativen KDE-Dialoge ermöglicht. Kubuntu hat dieses Addon als schmutzigen Hack betitelt und aus den Paketquellen verbannt. Das mag die sauberere Lösung sein, für den Nutzer wählt openSUSE aber den angenehmeren Weg.

opensuse standardansicht

Hervorstechend ist wie immer bei openSUSE die Liebe zum Detail. Während Debian und Kubuntu lediglich KDE in seiner mehr oder minder schönen Reinform ausliefern, wechselt openSUSE nicht nur den Desktophintergrund aus, sondern bietet auch ein eigenes Plasmatheme. In Version 13.2 wird die bekannte dunkle Variante um ein Light-Theme ergänzt, das zumindest mir optisch zusagt. Der klare Kontrast zwischen Theme und Systembereich-Icons ist zudem deutlich angenehmer als beim herkömmlichen Air Design.

Die vorinstallierte Software kann man als solide Mischung bezeichnen. Neben den Programmen der KDE Software Compilation (Kontact, Okular, Gwenview, Amarok usw.) zeigt sich openSUSE wenig dogmatisch, indem es auch GIMP und Firefox vorinstalliert. Ein wesentlicher Unterschied zu Kubuntu, das KDE oder zumindest Qt Software gnadenlos bevorzugt. Einige Punkte der Vorauswahl sind jedoch wenig durchdacht oder teilweise gnadenlos konservativ. So wird sowohl Kleopatra, als auch KGPG installiert, die sich in ihren Funktionen überschneiden. Anstelle des deutlich moderneren KDE-Telepathy liefert openSUSE immer noch Kopete aus. Zudem bindet man immer noch Kaffeine ein, dessen Entwicklung lange eingestellt ist und das normalerweise durch Dragonplayer ersetzt wird. Der langjährige openSUSE-Nutzer wird diese konservative Softwareauswahl jedoch vermutlich positiver bewerten.

Die Paketbenennung von openSUSE ist für einen langjährigen Debian-Nutzer allerdings etwas verwirrend. Pakete werden wohl konsequent wie upstream benannt, wohingegen Debian auf Vereinheitlichung setzt. Während bei Debian deshalb z.B. alle Administrationspakete für KDE mit kde-config-xyz beginnen, können diese in openSUSE synaptiks oder kde-gtk-config heißen. Das ist zwar letztlich Gewohnheit, aber Debians System wirkt konsistenter.

YaST und die Systemeinstellungen

Das Alleinstellungsmerkmal von openSUSE ist und bleibt YaST. Ein Verwaltungswerkzeug, das die Emotionen hoch kochen lässt. Dennoch bleibt es ein unerreichtes Stück Software, da YaST selbst komplexe Systemeinstellungen ohne Konsole ermöglicht. Das vermeintlich so benutzerfreundliche Ubuntu und auch Kubuntu sammeln ja lediglich in der Community vorhandene Einstellungswerkzeuge, die eine teils sehr unterschiedliche Qualität haben. So ist der Partitionierungsmanager bei Kubuntu 14.04 quasi unbrauchbar. YaST ist alt und sieht auch nicht ganz so aus, als ob es in einem Betriebssystem des Jahres 2014 seinen Platz gefunden hätte, aber die einzelnen Werkzeuge funktionieren zuverlässig.

Normalerweise benutze man die Konsole für größere Arbeiten am System, einfach weil sie zuverlässiger erscheint. OpenSUSE bzw. YaST führen einem immer wieder vor Augen, dass die grafischen Werkzeuge der anderen Distributionen lediglich unzureichend sind und die Konsole der GUI keineswegs per se überlegen ist.

yast

Umso unverständlicher bleibt es, dass openSUSE neben der großartigen Softwareverwaltung in YaST auch Apper/PackageKit eingebunden hat. Eine Doppelung die häufiger auftritt, so auch beim YaST-Druckermanager und dem KDE-Printmanager. Letztlich kann sich der Nutzer das bessere Werkzeug aussuchen, aber es verwirrt auch. OpenSUSE täte gut daran auf sein Herzstück zu vertrauen und es nicht hinter anderer – teilweise schlecht gepflegter – Software aus den Weiten der Community zu verstecken.

Fazit

OpenSUSE 13.2 ist ein in jeder Hinsicht gelungener Release, wenngleich es etwas überraschend ist, dass die Unterschiede zur Vorgängerversion nur marginal sind. Vor allem angesichts der heftigen Debatte der letzten Monate. Im Grunde genommen beschränken sich die Änderungen auf Versionsanhebungen in quasi allen Bereichen. Größere strukturelle Änderungen lassen sich bis dato nicht beobachten. Den konservativen Anwender wird es freuen.

Besonders für KDE-Anwender ist dies ein wichtiges Release. Es ermöglicht eine Weiterbenutzung von KDE 4 für die nächsten 18 Monate. Das ist kein Plädoyer gegen die Entwicklung rund um Plasma 5, aber solche Umbrüche gehen keineswegs reibungslos und manch einer wartet lieber ab, bis eine neue Version ein wenig gereift ist. Zumal sich abgesehen von Plasma 5 die Vorteile noch in engen Grenze halten. Zwar wird auch Kubuntu 14.04 LTS und voraussichtlich auch Debian 8.0 “Jessie” KDE 4 mittelfristig unterstützen, aber openSUSE hat mit 13.1 bewiesen, dass es unter Support nicht nur das Schließen von Sicherheitslücken versteht, sondern vom KDE Projekt angebotene Fehlerbehebungen langfristig zurückportiert.

Dank des openSUSE Build Service (OBS) kann man openSUSE 13.2 als Basisbetriebssystem verwenden und trotzdem in den Genuss aktueller Software kommen. Ubuntu bietet mit den PPA’s eine ähnliche Infrastruktur an, die OBS-Quellen sind jedoch subjektiv besser gepflegt und lassen sich einfacher verwalten. Schon alleine weil eine simple Suche in software.opensuse.org einen zur richtigen Stelle führt.

Zudem bleibt openSUSE seinem eigenen Weg treu. Man will eine einfache Distribution bieten, die sich auch an Anfänger richtet. Dabei möchte man aber nicht alle Einstellungsmöglichkeiten verstecken. Die neue Installationsroutine setzt dies vorbildlich um. Verwirrende und teilweise überholte Dialoge wurden abgeschafft. Experten ~~und solchen die sich dafür halten~~ hinter den entsprechenden Schaltflächen aber viele Einstellungsoptionen gelassen.

Eigentlich ist es unverständlich, das openSUSE mittlerweile eine so geringe Bedeutung unter den Linux-Distributionen hat.

Weiter:

Teil II.: openSUSE 13.1 im Langzeittest / Tipps & Tricks

Permalink

(Mer)Curius 30. April 2015 17:53

Papierloses Büro mit Linux ¶

Das so genannte papierlose Büro ist der nächste heiße Trend seit Jahren, damit hat es was mit Linux auf dem Desktop gemein. Die Wahrscheinlichkeit, dass es sich im Beamtenland Deutschland flächendeckend durchsetzt, kann man wohl auch mit den Chancen von Linux auf dem Desktop vergleichen. Leider kann man auch nicht jedes Dokument scannen und wegschmeißen, einiges muss man in Papierform aufbewahren. Vieles aber auch nicht, weshalb mein Technik-Vorsatz für das Jahr 2015 die Umstellung auf weitestgehend papierlosen Bürobetrieb ist.

Empfehlungen sind da immer schwer zu geben. Während manche nur ein paar Rechnungen im Briefkasten finden, haben andere ein Home-Office und mancher Dokumentenmessie hat sogar noch die Strafzettel von 1995 fein säuberlich abgeheftet. Ausschlaggebend für meine Entscheidung war ein Umzug und gefühlte 200 Ordner, die von einem Keller in den nächsten gewandert sind. Für meinen nächsten Umzug möchte ich mir das gerne ersparen.

bortherads2100

Die Hardware

Ein Scanner mit Einzug ist natürlich Pflicht, aber auch hier ist das Angebot äußerst vielfältig und die Preisspanne reicht von wenigen hundert Euro bis zum Mond. Linux-Nutzer müssen nebenbei noch die Treibersituation überprüfen, die von vielen Herstellern ~~bewusst verschleiert~~ nicht eindeutig beschrieben wird. Hier auf dem Schreibtisch steht nun mit dem Brother ADS 2100 eher ein Einsteigergerät, aber das muss jeder selbst entscheiden. Ausschlaggebend für Brother waren (neben den guten Erfahrungen mit einem Drucker desselben Herstellers) die direkt vom Hersteller für Linux angebotenen Treiber.

Das Gerät gibt es mittlerweile in diversen Online-Shops für relativ schmales Geld und bietet alle Funktionen, die ich mir so wünsche:

Offizielle Linux / SANE Treiber
Duplex-Scanner
Ein ADF-Fach mit Platz für 50 Seiten
Keine Hochglanzoberflächen (außer die Oberseite der Klappe)
600 dpi Auflösung (mehr kann mein Drucker auch nicht)

Ganz einfach macht es Linux einem trotz Hersteller-Treiber mal wieder nicht. Neben den auf der Homepage von Brother angebotenen Treibern für SANE muss man noch die Regeln für udev anpassen, damit der Scanner auch für normale Nutzer zur Verfügung steht. Debian/Ubuntu Nutzer können dafür ein Paket von Brother nutzen, alle anderen müssen manuell die richtige Datei bearbeiten. Steht zwar alles auf der Homepage, aber wenn man das erste Mal einen Scanner unter Linux betreibt, ärgert man sich doch über die Komplexität. Das erinnert an die Drucker-Installation unter Linux im Jahr ~2005.

Nachdem man diese Hürde hinter sich gebracht hat, funktioniert der Brother ADS 2100 hervorragend mit Linux und lässt keine Wünsche offen. Selbst verknitterte oder ehemals zusammen getackerte Papiere scannt er ohne Problem ein. Lediglich die Lautstärke hatte ich im Vorfeld unterschätzt. Aber man scannt ja nicht den ganzen Tag.

Die Software

Für die Scan-Software gilt immer noch der Satz aus dem ubuntuusers-Wiki:

[zt_blockquotes author="ubuntuusers-Wiki - Artikel Scanner" author-link="http://wiki.ubuntuusers.de/Scanner" extra-class="blockquotes"]Leider sind Scannerprogramme unter Linux nicht vergleichbar zu den Programmen, die man unter Windows kennt. Es fehlen durchweg wichtige – professionelle – Funktionen (z.B. Entrastern oder Staub/Fleckenentfernung).[/zt_blockquotes]

Das KDE-Programm skanlite eignet sich eigentlich nur für Flachbettscanner, da es weder mehrseitige Scans unterstützt, noch im PDF-Format speichern kann. Das Programm ist allerdings wenigstens so eindeutig unzureichend, das man es gar nicht erst in die nähere Wahl nehmen muss. Der Klassiker unter den Scan-Programmen für Linux ist sicherlich XSane. Ein Programm, bei dem man versteht weshalb so viele Linux-Nutzer glauben, dass die Konsole immer besser als jede GUI ist. Jeder noch so kryptische Befehl ist einfacher zu handhaben, als die Oberfläche von XSane mit seinen perfekt versteckten Optionen und vielen Fenstern. Gnome-Nutzer können Simple Scan verwenden. Für den Regelbetrieb bietet es genug Optionen und ist hinreichend einfach zu bedienen.

Wer mehr Optionen benötigt, sollte sich gscan2pdf ansehen. Ein in Perl geschriebenes Programm mit Gtk-Oberfläche, das bei allen Distributionen in den Paketquellen zu finden sein dürfte. Unter Debian/Ubuntu lässt sich es einfach installieren:

$ sudo apt-get install –no-install-recommends gscan2pdf

Die empfohlenen Abhängigkeiten sollten vor allem KDE-Nutzer abschalten, da man sonst Gefahr läuft sich unnötigerweise eine halbe Gnome-Umgebung auf die Festplatte zu holen.

Für die OCR-Texterkennung sollte man zusätzlich noch die Tesseract Pakete installieren. Tesseract wird inzwischen federführend von Google entwickelt und bietet eine relativ gute Texterkennung, ohne die in einem papierlosen Büro nichts funktioniert.

$ sudo apt-get install tesseract-ocr tesseract-ocr-deu

Der Dialog von gscan2pdf lässt einen eigentlich alle nötigen Einstellungen treffen. Besonders beachten muss man die im Reiter Mode festgelegte Auflösung, die standardmäßig mit 200 dpi zu niedrig angesetzt ist.

Ablage und DMS

DMS (Dokumenten Management Systeme) gibt es wie Sand am Meer und auch für Linux ist das Angebot nicht schlecht. Je nach Papieraufkommen und Anzahl der zugreifenden Benutzer/Rechner muss es aber nicht immer ein DMS sein. Ein funktionierendes DMS ist natürlich erst einmal einer einfachen Ablage via Ordnerstruktur überlegen. Die Entscheidung für ein papierloses Büro ist aber eine Festlegung auf viele Jahre und kaum eine Software wird ewig entwickelt. Die Gefahr am Ende eine Datenbank zu haben, die man nicht mehr ohne weiteres lesen kann oder deren Exportfunktion zumindest verlustbehaftet ist, dürfte immens sein.

Hinzu kommt, dass moderne Betriebssysteme und Desktopumgebungen inzwischen sehr gute Suchfunktionen und Dateimanager haben. Eine gute Verschlagwortung der Dateien im Titel und eine wohl überlegte Ordnerstruktur, kann in Kombination mit einer Suche wie KDE’s Baloo ein DMS ersetzen. Die fehlenden Funktionen kompensiert die Gewissheit, dass die eigene Ordnerstruktur sich notfalls auch mit geringen Verlusten auf andere Systeme übertragen lässt.

Ein papierloses Büro erfordert natürlich umso mehr Aufmerksamkeit für Verschlüsselung des Systems, sowie der Backupmedien und über eine sinnvolle Backup-Verwaltung. Für letzteres würde ich zur Zeit BackInTime empfehlen. Das kann übrigens auch verschlüsselte Backups erstellen, allerdings nur mit EncFS, was wohl nicht allzu sicher ist.

Permalink

1. Mai 2015

30. April 2015

Die Hardware

Die Software

Ablage und DMS

Möglichkeiten der Literaturverwaltung unter Linux

Synchronisation und Datenschutz

KBibTex

Ein Jahr Entwicklung

Der Installer

Software

YaST und die Systemeinstellungen

Fazit

Debian Lines von Juliette Taka BELIN unter Creative Commons Attribution; angepasst mit Releasedatum von Laura Arjona

Installation

Änderungen und Versionen

Fazit

Die Lehre von den Paketquellen

Desktop-Derivate

Server

Unklare Paketzuordnung

Neue und alte Fehler

Fazit

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Debian Netinstall ohne Ethernet Port

Die Hardware

Die Frage aller Fragen: Läuft Linux?

Installation

KDE SC Einstellungen

Akku

Fazit

Cookies abschalten

Do-Not-Track und Referrer abschalten

Werbung aussperren

Debian

Ubuntu

Fazit

Was ist wirklicher grüner beim Gecko

Endet die Lobeshymne auch noch?

Schlusspunkt

Anhang: Ein paar Tipps&Tricks

Partitionierung

Softwareauswahl

Empfohlene Abhängigkeiten

Tastatur

Softwarquellen

Automatische Updates

Btrfs-Snapshots

KDE Plasma anpassen

Oxygen durch Breeze ersetzen

Exkurs: Abhängigkeiten des Pakets modifizieren

Login-Manager und KSplash anpassen

Debian Lines von Juliette Taka BELIN unter Creative Commons Attribution; angepasst mit Releasedatum von Laura Arjona

Installation

Änderungen und Versionen

Fazit

KDE Plasma an Unity anpassen

Oxygen durch Breeze ersetzen

Exkurs: Abhängigkeiten des Pakets modifizieren

Login-Manager und KSplash anpassen

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Debian Netinstall ohne Ethernet Port

Ein Jahr Entwicklung

Der Installer

Software

YaST und die Systemeinstellungen

Fazit

Die Hardware

Die Software

Ablage und DMS