Auf der Mailingliste arch-dev-public wird seit gestern die Ankündigung diskutiert, wie man das Ende von Arch für 32-Bit-Rechner kommunizieren möchte: Das im Februar anstehende ISO-Image wird das Letzte sein, das man noch zur Installation von Arch Linux auf einem solchen Rechnern verwenden kann. Alle neueren Images werden dann nur noch 64-Bit-Pakete erhalten. Bereits installierte 32-Bit-Systeme erhalten dann anschließend bis November dieses Jahres noch weiter Updates über die Paketverwaltung.

Das eigentliche Ende kommt dann im November 2017: Ab diesem Zeitpunkt müssen Paketbetreuer keine 32-Bit-Versionen ihrer Pakete mehr erstellen. Der Schritt beinhaltet essentielle Tools wie etwa Packprogramme oder Werkzeuge zur Paketverwaltung (also bspw. tar und pacman), somit wird dann die i686-Architektur von Arch offiziell aufgegeben… Spätestens dann sollte man seinen Rechner mit einem 64-Bit-Arch neu installieren (wenn es geht), oder auf eine Distribution umsteigen, die noch 32-Bit-Rechner unterstützt.

Title: i686 is dead, long live i686

Due to the decreasing popularity of i686 among the developers and the community, we have decided to phase out the support of this architecture.

The decision means that February ISO will be the last that allows to install 32 bit Arch Linux. The next 9 months are deprecation period, during which i686 will be still receiving upgraded packages. Starting from November 2017, packaging and repository tools will no longer require that from maintainers, effectively making i686 unsupported.

However, as there is still some interest in keeping i686 alive, we would like to encourage the community to make it happen with our guidance. Depending on the demand, an official channel and mailing list will be created for second tier architectures.

Trotz des offiziellen Aus von Arch für 32-Bit-Rechner, wird es wohl aber dennoch noch einen 32-Bit-Zweig der Distribution geben: Die Unterstützung dessen soll die Community übernehmen. Eine entsprechende Mailingliste und einen IRC-Channel dazu gibt es bereits. Über diesen soll die Arbeit koordiniert werden. Als Anwender finde ich es dennoch ein bisschen Schade: Arch ist eine Distribution, die sich wunderbar schlank aufsetzen lässt, von daher ideal für ältere Rechner, bei denen man nicht auf ein „Alte-Rechner-Linux“ zurückgreifen möchte.

Bei Arch Linux kümmert sich das aus der Arch-Community rekrutierte Arch CVE Monitoring Team darum diverse Quellen von Common Vulnerabilities and Exposures aka CVE-Meldungen im Auge zu behalten und gegebenenfalls Paketbetreuer zu informieren, dass ein Patch in eine bestehende Version eines Pakets integriert werden müsste. Diese Arbeit findet im Hintergrund statt, Einblicke in die Abläufe kann man über die Arch Secruity-Mailingliste oder #archlinux-security erhalten. Für einen Überblick über aktuelle Gefährdungen gibt es jedoch nun seit gestern den Arch Security Tracker (den Quellcode zur Seite findet man auf Github).

Die Seite listet zu jeder Version eines betroffenen Pakets die entsprechenden Meldungen mitsamt dem Gefährdungsgrad sowie dem aktuellen Status auf und zeigt, in welcher Version das Paket bereits gefixed wurde. Oft gibt es ein Arch Linux Security Advisory aka ASA mit zusätzlichen Informationen zur Sicherheitsschwachstelle in der Spalte ganz rechts. Sämtliche Meldungen sind miteinander verlinkt, sodass man sich schnell einen Überblick verschaffen kann.

Wer nun ein hochgefährdetes System betreibt (oder einfach so auf dem Laufenden bleiben möchte), sollte diese Meldungen fortlaufend im Auge behalten, allerdings gibt es noch keinen RSS-Feed der Seite — somit fällt es schwer neue Einträge zu verfolgen. Stattdessen kann man jedoch aber auch ein bestehendes System nach Paketen mit einer entsprechenden Warnung durchsuchen. Dazu dient arch-audit aus dem AUR, das ab der Version 0.1.6 auf die Einträge im Security Tracker zurückgreift.

$ pacaur -S arch-audit
$ arch-audit
Package lib32-libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package libusbmuxd is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package libwmf is affected by ["CVE-2016-9011", "CVE-2015-4696", "CVE-2015-4695", "CVE-2015-4588", "CVE-2015-0848", "CVE-2009-3546", "CVE-2009-1364", "CVE-2007-3477", "CVE-2007-3473", "CVE-2007-3472", "CVE-2007-2756", "CVE-2007-0455", "CVE-2006-3376"]. VULNERABLE!
Package openjpeg2 is affected by ["CVE-2016-9118", "CVE-2016-9117", "CVE-2016-9116", "CVE-2016-9115", "CVE-2016-9114", "CVE-2016-9113"]. VULNERABLE!
Package libimobiledevice is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package bzip2 is affected by ["CVE-2016-3189"]. VULNERABLE!
Package lib32-openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package jasper is affected by ["CVE-2016-8886"]. VULNERABLE!
Package gst-plugins-bad is affected by ["CVE-2016-9447", "CVE-2016-9446", "CVE-2016-9445"]. VULNERABLE!
$ arch-audit --upgradable
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!

Das Ausführen von arch-audit ohne irgendwelche Schalter gibt sämtliche auf dem System Pakete aus, zu denen eine Sicherheitswarnung herausgegeben wurde. Mit dem Schalter --upgradable reduziert man die Ausgabe auf Pakete, zu denen es bereits ein Update in den Paketquellen von Arch Linux gibt. Ein pacman -Syu spielt diese Updates allerdings nicht zwangsläufig sofort ein, da frisch veröffentlichte Updates in der Regel erst einmal in den Testing-Quellen stecken und erst noch freigegeben werden müssen.

Wer Arch Linux oder ein Arch-Derivat, das direkt auf den Arch-Quellen aufbaut, auf seinem Rechner einsetzt, der bemerkt seit gestern Abend, dass Update-Versuche mit pacman -Syu nicht mehr durchlaufen. Die Paketverwaltung stolpert am Versuch das Font-Paket ttf-dejavu, von dem unter anderen Gnome oder Inkscape abhängen, zu aktualisieren und bricht den kompletten Vorgang ab. Das System meldet, dass eine Reihe von Dateien im Ordner /etc/fonts/conf.d bereits im System existieren.

$ sudo pacman -Syu
[...]
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (43) archlinux-keyring-20161101-1  blender-17:2.78.a-2
            boost-libs-1.62.0-2  calibre-2.71.0-1  confuse-3.0-1
[...]
            source-highlight-3.1.8-10  ttf-dejavu-2.37-1  vim-8.0.0055-1
            vim-runtime-8.0.0055-1
[...]
(43/43) Prüfe auf Dateikonflikte                   [######################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans-mono.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-serif.conf existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Der Grund für diese Fehler, findet sich in dieser kleinen Änderung am genannten Paket: Anstatt die aufgeführten Dateien physisch in /etc/fonts/conf.d abzulegen, setzt die Paketverwaltung in Zukunft nur noch einen Symlink nach  /etc/fonts/conf.avail. Pacman kann diese Änderung allerdings nicht automatisch umsetzen, man muss die Installation stattdessen erzwingen. Die englische Arch-Seite hat dazu einen kurzen Beitrag in ihren News, im deutschsprachige Pendant fehlt ein entsprechender Hinweis jedoch noch. Nach dem erzwungenen Update, kann man die Paketverwaltung dann wieder ganz normal verwenden.

$ sudo pacman -S --force ttf-dejavu
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) ttf-dejavu-2.37-1

Gesamtgröße der installierten Pakete:  9,75 MiB
Größendifferenz der Aktualisierung:  0,57 MiB

:: Installation fortsetzen? [J/n] j
(1/1) Prüfe Schlüssel im Schlüsselring             [######################] 100%
(1/1) Überprüfe Paket-Integrität                   [######################] 100%
(1/1) Lade Paket-Dateien                           [######################] 100%
(1/1) Prüfe auf Dateikonflikte                     [######################] 100%
(1/1) Überprüfe verfügbaren Festplattenspeicher    [######################] 100%
:: Verarbeite Paketänderungen...
(1/1) Aktualisiere ttf-dejavu                      [######################] 100%

Deutschsprachige Linux-User haben es eigentlich sehr gut: Mit dem Wiki des Debianforums, dem Ubuntuusers-Wiki und dem Arch Linux Wiki gibt es mindestens drei sehr gut gepflegte Linux-Wikis, die auch mir immer wieder als sehr nützliche Informationsquelle dienen. Als Arch-User greife ich jedoch meist eher auf das englischsprachige Wiki der Distribution zurück, da dieses meist aktueller und vollständiger als die deutsche Ausgabe ist. Das Wiki lässt sich natürlich direkt im Browser aufrufen, doch mit dem Arch Wiki Viewer gibt es auch eine praktische Android-App, falls das eigene Arch-System mal streiken sollte. Als Alternative kann man sich das Arch Wiki jedoch auch als Terminal-Anwendung auf den Rechner laden, sodass man es auch Offline jederzeit aufrufen kann.

Für diese Aufgabe finden sich in den Paketquellen von Arch zwei praktische Anwendungen mit ähnlichen Namen: Arch-Wiki-Lite und Arch-Wiki-Man. Das erste Programm steckt im Community-Repository, kann also direkt mittels pacman aus den regulären Paketquellen von Arch installiert werden, für das Zweite muss man hingegen das Arch User Repository bemühen. Beiden Programmen gemein ist, dass sie das Arch-Wiki lokal verfügbar machen, inklusive Suchfunktion und übersichtlicher Darstellung der heruntergeladenen Artikel; es gibt aber sehr wohl ein paar kleine Unterschiede. Ebenso fehlt in bei beiden Anwendungen das deutschspachige Wiki, da dieses sein eigenes Ding auf einem eigenständigen System dreht.

Arch-Wiki-Lite, klein und schlank

Das Programm Arch-Wiki-Lite hat gerade erst ein paar kleine Updates erhalten, die der Anwendung unter anderem eine „grafische“ auf Ncurses basierende Oberfläche spendieren, allerdings auch nur bei den Suchergebnissen. Ansonsten kommt Arch-Wiki-Lite recht schlicht daher: Artikel zeigt das Programm beispielsweise nur mithilfe von less an, dabei geht ein Großteil der Formatierung der Wiki-Artikel verloren. Allerding kann man auf diese Art die Artikel bequem durchsuchen und diesen gut navigieren. Eine Suche stößt ihr etwa mit /systemctl an, mit einem kleinen [N] springt ihr zum nächsten Treffer, mit [Umschalt]+[N] zum vorherigen. Die Wikipedia hat eine schöne Übersicht zu den wichtigsten Kommandos von less.

### Arch-Wiki-Lite installieren:
$ sudo pacman -S arch-wiki-lite

### Lokales Wiki durchsuchen:
$ wiki-search suspend
$ wiki-search pulseaudio
### Hilfe aufrufen:
$ wiki-search --help

### Sprache umstellen:
$ wiki-search --lang
   2129 en
    525 zh-CN
    507 ru
[...]
$ export wiki_lang="zh-CN"

Arch-Wiki-Man, größer aber elegant

Im Gegensatz zu Arch-Wiki-Lite benötigt Arch-Wiki-Man aus dem AUR schon von Haus aus 62,23 MiB anstatt nur knapp über 16 MiB auf der Festplatte. Dazu kommt noch, dass die Anwendung mit Node.js und dem Node Package Manager zwei größere Pakete als Abhängigkeiten nach sich zieht. Somit baut das Programm schnell deutlich größer — was bei den heutigen Größen von Festplatten und SSDs ja keine so tragende Rolle mehr spielt. Die Übersicht über die Suchergebnisse verzichtet auf eine Ncurses-Oberfläche, dafür sieht man gleich einen kleinen Ausriss aus den gefundenen Ergebnissen. Zudem bereitet Arch-Wiki-Man die Seiten als Manpage auf, was in meinen Augen deutlich zur Lesbarkeit der Artikel beiträgt.

### Arch-Wiki-Man aus dem AUR installieren
### alternativ mit jedem anderen AUR-Helper:
$ pacaur -S arch-wiki-man

### Lokales Wiki durchsuchen:
$ awman apache                     ## Nur Artikel-Namen durchsuchen
$ awman -k "Apache configuration"  ## In kompletten Artikel suchen
### Hilfe aufrufen
$ awman --help

### Sprache umstellen:
$ awman --list-languages
arabic
bulgarian
catalan
chinesesim
[...]
$ awman systemd -l spanish

Wie viele andere Linux-Distributionen konzentriert auch Arch den Aufwand seine User mit Paketen zu versorgen nicht auf einen Rechner, sondern verteilt die Last über Mirrorserver auf zahlreiche Systeme, sodass jeder User schnell und zuverlässige sein System mit neuen Paketen erweitern oder aktualisieren kann. Diese Mirrorliste wird über das Paket pacman-mirrorlist ab und an aktualisiert, allerdings sollte man diese Liste generell ein wenig ausmisten und nach optimaler Erreichbarkeit sortieren. Dazu gibt es im im Arch-Wiki eine ausführliche Anleitung, die man auf die folgenden Kommandos reduzieren kann.

$ sudo -s
$ cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.backup
$ sed -i 's/^#Server/Server/' /etc/pacman.d/mirrorlist.backup
$ rankmirrors -n 6 /etc/pacman.d/mirrorlist.backup > /etc/pacman.d/mirrorlist
$ exit

Mit dem ersten „richtigen“ Befehl erstellt ihr eine Sicherung der aktuellen Mirror-Liste. Mit dem zweiten entfernt ihr dann sämtliche Kommentare aus der Liste und „aktiviert“ somit praktisch jeden Mirrorserver. Das letzte Kommando klappert die Liste ab und misst die Erreichbarkeit. Anschließend reduziert rankmirrors die Liste auf die besten 6 Mirrorserver und entsorgt den Rest. Man kann jedoch aber alternativ auch auf das kleine Tool fetchmirrors zurückgreifen, das seit zwei Wochen im AUR zu finden ist.

$ pacaur -S fetchmirrors
$ fetchmirrors

Fetchmirrors holt sich die aktuelle Mirrorliste aus dem Netz und bittet euch anschließend die für euch entsprechend zuständige Länderliste auszuwählen — Für Deutschland also die 12. Anschließend optimiert das Skript die Liste mittels rankmirrors und spielt die reduzierte Version ins System ein — dazu fordert das Programm kurz Root-Rechte an. So klappert die Arch-Paketverwaltung nur noch die für euch am besten erreichbaren Arch-Mirrors ab. Mittels pacman -Syu ruft ihr dann wie gewohnt die Paketquellen ab und spielt die neusten Updates ein. Sollte einer der Mirror irgendwann mal spürbar klemmen, führt ihr einfach nochmal fetchmirrors aus oder optimiert die Liste bei Bedarf nochmal per Hand.

Arch ist ja bekanntlich eine Rolling-Release-Distribution: Anders wie beispielsweise bei Debian, Fedora oder Ubuntu und Co. gibt es daher keine einzelnen Versionen, die Paketquellen werden stattdessen ständig mit neuen Versionen bestehender Programme oder kompletten Neuerscheinungen befüllt. Die Updates durchzuführen ist nun aber keine Pflicht. Es gibt durchaus einige Arch-User, die ihr System nur selten aktualisieren. Es gibt aber hin und wieder Änderungen, die das Einspielen der Updates zur Pflicht machen. Eine von diesen steht Ende April an.

Mit Pacman 5.0 wurde dem Paketmanager von Arch die Fähigkeit beigebracht Aktionen per Hooks auszuführen. Das bedeutet für Arch, dass beispielsweise bei der Installation von mehreren Fonts nicht x mal der Font-Cache generiert wird, sondern nur einmal am Ende der Installation. Ein anderer Anwendungsfall wäre etwa das Bauen von Kernelmodulen, das dann eben auch nur einmal angestoßen werden muss. Dies beschleunigt die Arbeit mit Pacman zum Teil erheblich. Diese Änderung bedingt nun aber, dass ihr euer Arch-System bis zum 23.04.2016 auf einen aktuellen Stand gebracht haben müsst.

The release of pacman-5.0 brought support for transactional hooks. These will allow us to (e.g.) run font cache updates a single time during an update rather than after each font package installation. This will both speed up the update process, but also reduce packaging burden for the Developers and Trusted Users. In order for the use of hooks to be started, we require all users to have updated to at least pacman-5.0.1 before 2016-04-23. Pacman-5.0.1 was released on 2016-02-23, so this will have given everyone two months to update their system.

Somit hat jeder Arch-User über zwei Monate Zeit gehabt seine Systeme zu aktualisieren. Wer nach diesem Tag noch Pacman mit einer Versionsnummer kleiner als 5.0.1 auf seinem Rechner hat, kann eventuell keine Pakete mehr installieren und demzufolge auch sein System nicht mehr aktualisieren. Solltet ihr Fragen zu dem Thema haben, könnt ihr euch beispielsweise an das deutschsprachige Arch-Forum wenden, dort gibt es einen entsprechenden Thread. Die Thematik gilt ebenso für Arch-Derivate wie Antergos, die direkt auf den Paketquellen von Arch Linux aufsetzen. Das beliebte Manjaro hingegen nutzt seine eigenen Quellen, allerdings wird das Pacman-Update vermutlich auch dort irgendwann zur Pflicht.

### Welche Pacman-Version ist auf dem Rechner installiert?
$ pacman -Qi pacman
Name : pacman
Version : 5.0.1-2
Beschreibung : A library-based package manager with dependency
support
Architektur : x86_64
$ pacman --version

 .--.                  Pacman v5.0.1 - libalpm v10.0.1
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2016 Pacman Development Team
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet
 '--'
                       Dieses Programm darf unter Bedingungen der GNU
                       General Public License frei weiterverbreitet werden
[...]

Die meisten Arch-User werden auf einem regelmäßig genutzten System die anlaufenden Updates sowieso mehr oder weniger regelmäßig einspielen und so nicht in die Verlegenheit kommen das Zeitfenster für das Pacman-Update zu verpassen. Es gibt allerdings auch viele User, die Arch auf einem kleiner Server oder etwa einem Raspberry Pi einsetzen, der irgendwo gut versteckt seine Arbeit still und heimlich verrichtet. Vergesst nicht diese Systeme mit dem Update zu versorgen.

Mal eine kleine Ankündigung für alle Nutzer von Arch Linux oder Arch-Derivaten wie Antergos oder Manjaro, die nicht die Arch Linux News lesen oder die Arch Linux Announcements als Mailingliste abonniert haben und daher nicht mitbekommen, dass viele Arch-Nutzer eventuell ein wenig Hand ans System anlegen müssen. Der Hintergrund ist das Update von GCC 5.2 auf die Version 5.3. Dieses Update macht es aufgrund der Umstellung auf eine „Dual-ABI“ erforderlich, dass sämtliche C++-Anwendung neu gebaut werden müssen. Bei aus den normalen Paketquellen installierten Programmen und Bibliotheken erledigen dies die Arch-Entwickler, sodass aktuell viele Updates bei Arch anstehen. Habt ihr allerdings Programme aus dem AUR oder manuell installiert, dann müsst ihr diese nochmal neu bauen.

Wer aktuell auf seinem Arch- oder Antergos-System anstehenden Updates installiert, dem wird mit Sicherheit auffallen, dass derzeit die Pakete zahlreicher Anwendungen ein Update bekommen, auch wenn diese Upstream gar keine Aktualisierung erfahren haben. Der Grund dafür liegt in dem eingangs angesprochenen Update auf GCC-5.3.0 mitsamt einer Dual-ABI libstdc++, das das Rekompilieren sämtlicher C++-Anwendungen erforderlich macht. Auf diesen Umstand weisen die Arch Linux News sowie aber auch das Antergos-Blog hin, entsprechende Arbeiten stehen auch bei anderen Arch-Derivaten wie etwa Manjaro an.

$ sudo pacman -Syyu
[...]
            frei0r-plugins-1.4-3  gcc-libs-multilib-5.3.0-2
            gcc-multilib-5.3.0-2  gimp-ufraw-0.22-4  git-2.6.4-1
[...]
            wireshark-gtk-2.0.0-2  zeromq-4.1.3-4

Gesamtgröße des Downloads:                 303,05 MiB
Gesamtgröße der zu installierenden Pakete:  1102,65 MiB
Größendifferenz der Aktualisierung:          1,19 MiB

Üblicherweise reicht die Installation der ganz normalen Arch-Updates aus, um das System auf die neue ABI umzustellen — Ihr müsst also keine Angst haben, euer System kaputtzumachen. Allerdings gibt es viele Arch-Nutzer, die auf Pakete aus den Arch-User-Repositories (kurz AUR) zurückgreifen. Damit diese weiter ohne Komplikationen funktionieren, müsst ihr diejenigen AUR-Pakete, die aus den C++-Quellcode gebaut wurden, noch einmal neu kompilieren. Nun könntet ihr sämtliche AUR-Pakete identifizieren und neu einspielen, mit folgendem Skript erspart ihr euch allerdings etwas Arbeit.

#!/bin/bash

while read pkg; do
    mapfile -t files < <(pacman -Qlq $pkg | grep -v /$) grep -Fq libstdc++.so.6 "${files[@]}" 2>/dev/null && echo $pkg
done < <(pacman -Qmq)

Übertragt den Inhalt des Skripts in einen Editor und speichert die Datei beispielsweise als /tmp/abi ab. Anschließend führt ihr das Skript mit bash /tmp/abi aus. Als Ergebnis erhaltet ihr eine Liste mit sämtlichen aus dem AUR installierten Anwendungen, die mit C++ gebaut wurden und somit nun aktualisiert werden müssen. Hier nutze ich pacaur als AUR-Helper, selbstverständlich funktioniert dies auch mit yaourt und Co. Bevor ihr mit dem Bauen beginnt, achtet bitte darauf, dass ihr sämtliche Pacman-Updates installiert habt, sonst macht die Aktion keinen Sinn.

$ bash /tmp/abi
aftershotpro
fritzing
google-chrome
[...]
obs-studio
$ pacaur -S aftershotpro fritzing google-chrome [...] obs-studio

//PS: Führt ihr das Skript nach dem Rekompilieren noch einmal neu aus, dann wird es wieder dasselbe Ergebnis ausspucken. Lasst euch davon nicht verwirren: Das Skript prüft nur, welche AUR-Pakete die libstdc++ nutzen, das ändern sich durch das erneute Bauen der Pakete nicht.

Arch Linux zu installieren ist nicht gerade ein einfaches Unterfangen. Man muss zum Meistern dieser zwar kein Linux-Superheld sein, doch ein wenig Erfahrung im Umgang mit der Konsole und Tools wie Fdisk oder einem Texteditor für das Terminal sollte schon vorhanden sein. Ansonsten gilt es sich einfach an die Anleitung für Einsteiger zu halten, das die deutsche Arch-Community immer weiter aktuell hält. Nicht desto trotz hält dieses Verfahren selbst erfahrene Arch-User auf. Dank Rolling-Release sollte man ein einmal aufgesetztes Arch-System eigentlich nie wieder neu installieren müssen, aber ab und an möchte man einfach nur mal schnell ein System mit Arch ausstatten.

Um sich dabei ein wenig Zeit zu sparen, konnte man auf Evo/Lution bauen. Dieses auf einem Arch basierenden Live-Linux konnte Arch über eine grafische Installationsroutine installieren, doch das dadurch recht starre Korsett wurde den Möglichkeiten von Arch nicht gerecht. Daher hat der Entwickler von Evo/Lution nun umgesattelt und steckt seine Energie in Architect Linux (Forum, GitHub oder Google+) beziehungsweise in das Architect Installation Framework. Dieses erlaubt mit einem textbasierten Setup die Installation von Arch, ohne dass man sich vorher durch mehrere Seiten Text wühlen müsste.

Architect bekommt ihr über Sourceforge als ganz gewöhnliche ISO-Datei (hier der Link zur jeweils aktuellen 64-Bit-Version) — auf der Sourceforge-Seite bekommt ihr Architect auch in einer Variante für 32-Bit-Systeme. Diese schreibt ihr wie andere Linux-Distributionen auf eine DVD oder besser gleich einen USB-Stick und bootet das Systems. Im Bootmanager habt ihr dann die Wahl zwischen den Punkten Boot Architect Linux und Boot existing OS, mit der ersten Option ladet ihr den Arch-Installer. Nach einer kurzen Initialisierung lädt Architect die letzte Version des Installer-Frameworks aus dem Netz und beginnt mit der Installation.

Bei der Auswahl der Sprache müsst ihr euch aktuell noch mit Englisch (oder einer Reihe anderer Sprachen) begnügen. Der Ticker für die Deutsche Übersetzung steht bei Transifex (einem Portal für die Übersetzung von Software) noch bei Null Prozent — hier bietet sich der Arch-Community daher schon mal ein Weg an, dem Projekt unter die Arme zu greifen. Ansonsten hangelt ihr euch von Punkt 1 bis 9 durch die Menüs. Wie üblich bereitet ihr zuerst die Partitionen auf, installiert und konfiguriert dann das Grundsystem, wählt einen Bootloader aus, spielt Treiber und Binary-Blogs für Grafikkarten oder WLAN-Adapter ein und wählt am Ende eine Desktopumgebung wie Gnome, KDE oder eine der anderen Spielarten zur Installation aus. Im letzten Schritt könnt ihr alle von Architect angelegten Konfigurationsdateien noch einmal ansehen und bearbeiten.

Wer jetzt nicht ganz grün hinter den Linux-Ohren ist, der bekommt Arch mit Architect recht schnell und ohne große Recherche installiert. Da der Installer allerdings nur wenig Beschreibungen, Hinweise oder gar Bilder gibt, werden Einsteiger auch mit Architect noch ein paar Hürden überwinden müssen — Mit ein wenig Recherche im Netz lassen sich diese aber in der Regel recht einfach lösen. Wer nun aber weiß welches Dateisystem, welcher Bootloader, welcher Displaymanager und welche Desktopumgenung auf der Platte landen soll, der spart mit Architect bei der Installation von Arch viel Zeit — ohne dass man bei der Wahl der Komponenten eingeschränkt wäre.

Es gibt viele Blogger, die können es kaum erwarten, immer wieder neue Hardware unter den Fingern zu haben. Von diesen mag ich mich nicht ganz ausnehmen, dennoch liebe ich auch meine bewährte Hardware. Dazu zählt aktuell mein treuer Dell Vostro V130. Mit seinem Intel-Core-i5-470UM, 4 GByte Arbeitsspeicher und einer umgerüsteten SSD schlägt sich der Laptop im Alltag nach wie vor spitze, allerdings lassen inzwischen die Verschleißteile kräftig nach. Der Lüfter macht gerne mächtig Radau und der Akku hält mit sehr viel gut zureden gerade noch eine halbe Stunde durch.

Es ist also dringend an der Zeit sich um das Gerät zu kümmern: Mit einem neuen Lüfter ist endlich wieder Ruhe im Karton. Ein neuer Akku sorgt wieder für 2 Stunden Strom und mit den richtigen Settings hält der Akku sogar knapp an die 3:30 Stunden. Es lohnt sich also ein wenig Zeit in Intels Stromspar-Analyse-Tool Powertop zu investieren. Dabei müsst ihr nicht gleich den Akku tauschen, auch Nutzer eines neuen Laptops profitieren von den durch Powertop empfohlenen Stromsparmaßnahmen.

Generell möchte ich hier jetzt keine große Umbauanleitung geben, da ihr speziell beim Dell Vostro vor keinen großen Problemen steht. Neue zum Vostro V130 kompatible Lüfter gibt es bei Ebay für weniger als 17 Euro und auch neue Akkus kosten nur knapp um die 50 Euro. Für wenig mehr als 65 Euro lässt sich das Notebook somit fast komplett generalüberholen. Bei meinen Bestellungen kam der Lüfter per Luftpost direkt aus China — ohne dass der Zoll sich über die Sendung mokierte. Der Akku wurde dagegen direkt aus Deutschland ausgeliefert.

Neuer Lüfter und Akku

Der Aufwand beim Umbau hält sich beim Vostro V130 in Grenzen: Mit einem konventionellen kleinen Phillips-Schraubendreher aka Kreuzschlitzschraubenzieher lassen sich sämtliche Schrauben auf der Rückseite und die zwei auf der schwarzen Hinterseite herausdrehen. Danach gilt es nur noch die Blende für den SD-Kartenslot rauszunehmen und den Rückendeckel zur Vorderseite hin abzuziehen. Lüfter und Akku lassen sich dann ebenso problemlos austauschen wie das Gerät öffnen, es müssen wieder nur ein paar simple Schrauben gelöst werden.

Direkt nach dem Umbau läuft der Lüfter wieder seidenweich und auch die Akkulaufzeit kann sich mit 2 Stunden wieder sehen lassen. Allerdings sind diese zwei Stunden beileibe nicht das Ende der Fahnenstange. Mit den richtigen Werkzeugen kitzelt ihr locker 50 Prozent mehr Laufzeit aus eurem Linux-Laptop, ohne dass ihr dabei allzu viel Aufwand treiben oder auf Komfort verzichten müsst. Die Akkulaufzeit meines frisch renovierten Dell Vostro V130 ließ sich von den besagten 2 Stunden auf knapp 3:15 Stunden steigern — es lohnt sich also ein wenig in die Thematik einzusteigen.

Akkulaufzeit mir Powertop optimieren

Die 2 Stunden Akkulaufzeit sind im Gegensatz zu den anfänglichen 20 bis 30 Minuten zwar toll, doch nach wie vor nicht wirklich überragend. Von dem integrierten 30 Wh/2700 mAh großen Akku kann man zwar keine Wunder erwarten, doch Dell spricht von über 4 Stunden Laufzeit und der Test bei Notebookcheck berichtet von einer Laufzeit von etwa 2:30 beim Surfen über WLAN beziehungsweise knapp 4:30 im Leerlauf bei geringster Bildschirmhelligkeit. Von daher ist es an der Zeit sich auch etwas mit dem Optimieren der Akkulaufzeit zu beschäftigen.

Dabei hilft euch das von Intel entwickelte Analysewerkzeug Powertop. Es reduziert selber nicht den Stromverbrauch, stattdessen analysiert Powertop das System bis ins letzte Detail und verrät die größten Stromschlucker abseits des Displays und anderer essentieller Funktionen. Doch damit nicht genug: Powertop spuckt gleich die passenden Kommandos aus, mit denen sich die hungrige Hardware ohne großen Einbußen an Komfort und Leistung bändigen lässt. Mit ein bisschen Geduld, lässt sich so die Akkulaufzeit des Laptops daher unter Linux wesentlich verbessern.

Powertop-Tipps unter Arch Linux umsetzen

Im ersten Schritt müsst ihr Powertop mitsamt dem Ethtool und dem Gnome Power Manger installieren. Der Power Manager ist nicht unbedingt von Nöten, allerdings zeigt er den Verlauf des Ladezustands schön übersichtlich als Graph an und liefert zudem zahlreiche andere Informationen zum Stromverbrauch des Systems unter Linux. Braucht ihr kein optisches Feedback eurer Aktion oder setzt ihr auf eine anderen Desktopumgebung als Gnome, dann lasst den Power Manager einfach weg und erspart euch so eventuell die Installation von zahlreichen Abhängigkeiten, die ihr sonst gar nicht braucht.

$ sudo pacman -S powertop ethtool
$ sudo pacman -S gnome-power-manager

Nun ruft ihr mit sudo powertop das Analysewerkzeug zum ersten mal aus einem Terminal heraus auf. In der Übersicht seht ihr ganz oben die aktuelle Entladungsrate in Watt und die von Powertop geschätzte restliche Akkulaufzeit. Merkt euch besonders die aktuelle Entladungsrate, denn die gilt es zum Verlängern der Akkulaufzeit abzusenken. Wichtig ist auch die Anzahl der Aufwachvorgänge/Sekunde. Je öfter der Prozessor aus dem Tiefschlaf geholt wird, desto weniger Zeit verbringt er im Stromsparmodus. Beobachtet beide Ausgaben mal eine Weile und notiert euch die Werte, ihr zieht sie am Ende der Aktion zum Vergleich heran.

### Powertop im Terminal aufrufen und testen
$ sudo powertop
### Powertop-Report erstellen und im Browser öffnen
$ sudo powertop --html=powertop-report.html
$ xdg-open powertop-report.html

Um im Inhalt der Ausgabe zu scrollen, drückt ihr einfach auf die Pfeiltasten eurer Tastatur. Per Tabulator-Taste wechselt ihr von der Übersicht, zum Leerlauf-Status, der Frequenz- und Gerät-Statistik sowie zu den Abstimmbaren Optionen. Hier ist besonders der letzte Punkt Abstimmbare Optionen von Interesse. Die Tabelle zeigt Rechts Systemeinstellungen, die sich auf den Stromverbrauch auswirken. Linksbündig sagt die Ausgabe „Gut“ oder „Schlecht“, ob der entsprechende Punkt bereits behoben ist. Wählt ihr mit den Pfeiltasten einen der schlechten Punkte an, könnt ihr mit oft mit [Eingabe] die entsprechenden Konfiguration optimieren. Die linke Spalte sollte dabei von Schlecht auf Gut wechseln.

Diese Änderung ist nun aber nicht permanent, sodass es sich an dieser Stelle gar nicht lohnt, weiter manuell einen Eintrag nach dem Anderen zu optimieren. Das ist aber auch gar nicht nötig, denn die Einstellungen lassen sich auch direkt im System vornehmen, sodass Powertop nichts mehr zu meckern hat. Erzeugt euch dazu wie im oberen Listing beschrieben einen Powertop-Report powertop-report.html und öffnet diesen im nächstbesten Browser. Auf der Powertop-Seite tippt ihr dann auf den Reiter Tuning. Er enthält gesammelt alle wichtigen Optionen die Akkulaufzeit zu verlängern.

Die Befehle aus dem PowerTop-Report müsstet ihr nun eigentlich direkt übernehmen können. Doch aber auch das macht einiges an Arbeit. Mit ein bisschen Shell-Magie lassen sich die Aufrufe zu wenigen Kommandos kombinieren, die ihr dann in ein extra Powertop-Skript packt, das ihr am Ende dann beim Start des Systems ausführen lässt. Erstellt dazu mit einem beliebigen Texteditor und Root-Rechten die Datei /usr/local/sbin/powertop.sh und fügt den Inhalt aus folgendem Listing ein.

#!/bin/bash
for i in /sys/class/scsi_host/host[012345]/link_power_management_policy; do echo min_power >$i; done
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';
echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';
echo '0' > '/proc/sys/kernel/nmi_watchdog';

## Runtime PM for PCI Device
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:00/0* -maxdepth 3 -name control); do
    echo auto > $i;
done
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:ff/0* -maxdepth 3 -name control); do
    echo auto > $i;
done

Achtet bitte darauf, dass ihr das Skript mit sehr hoher Wahrscheinlichkeit noch an euer System anpassen müsst. Orientiert euch dabei an den Ausgaben des Powertop-Reports oder an den Tipps des Ubuntuusers-Wiki. Meist werdet ihr in der ersten Zeile die Anzahl der SCSI-Hosts korrigieren („[012345]“), eventuell den Powersave-Modus des Intel-HDA-Soundchips rausnehmen oder auch die das Runtime Power Management anpassen müssen. Am Ende speichert ihr die Datei ab und beendet den Editor. Arbeitet ihr wie hier im Beispiel mit Nano, geschieht dies mit [Strg]+[O], [Eingabe] und [Strg]+[X]. Danach macht ihr das Skript noch mit chmod +x ausführbar, sonst fehlen Systemctl nachher die Rechte das Skript beim Booten zu starten.

$ sudo nano /usr/local/sbin/powertop.sh
$ sudo chmod +x /usr/local/sbin/powertop.sh

Wie schon erwähnt, benutzt Arch Linux Systemd als Init-System. Dieses sorgt unter anderem dafür, dass beim Booten die wichtigsten Prozesse in der richtigen Reihenfolge gestartet werden — an dieser Stelle unterscheidet sich der Vorgang noch von vielen Distributionen, die noch nicht auf Systemd aufbauen. Auch Powertop können wir in dieses System einklinken. Erstellt dafür wieder mit einem Editor und Root-Rechten die Datei /etc/systemd/system/powertop.service und fügt den folgenden Inhalt ein. Diesen müsst ihr dieses mal nicht anpassen. Die Datei sorgt dafür, Systemd das von euch erstellte Powertop-Skript beim Booten ausführen wird.

[Unit]
Description="PowerTop Tuning"
ConditionPathExists=/usr/local/sbin/powertop.sh

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
ExecStart=/usr/local/sbin/powertop.sh
ExecStop=exit

[Install]
WantedBy=multi-user.target

Nun könnt ihr eure Powertop-Optimierungen testen… ob ihr wirklich richtig steht, seht ihr wenn das Licht angeht. Ruft dazu mit systemctl start den powertop.service auf, mit systemctl status prüft ihr danach den Erfolg der Aktion nach. Auch ein Blick auf sudo powertop lohnt sich. Dort sollte der Tab Abstimmbare Optionen deutlich weniger mit „Schlecht“ markierte Einträge aufführen. Bei mir bleibt eigentlich nur noch das AutoSuspend für die USB-Geräte und der Wake-On-LAN-Status des im Laptop verbauten Ethernet-Adapters zurück.

$ sudo systemctl start powertop.service
$ systemctl status powertop.service
● powertop.service - "PowerTop Tuning config"
Loaded: loaded (/etc/systemd/system/powertop.service; enabled; vendor preset: disabled)
Active: active (exited) since Di 2015-06-02 12:11:49 CEST; 10min ago
Process: 319 ExecStart=/usr/local/sbin/powertop.sh (code=exited, status=0/SUCCESS)
Main PID: 319 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/powertop.service

Jun 02 12:11:49 estrellita systemd[1]: Starting "PowerTop Tuning"...
Jun 02 12:11:49 estrellita systemd[1]: Started "PowerTop Tuning".
$ sudo powertop

AutoSuspend für USB-Geräte solltet ihr generell vermeiden, da sonst Mäuse und andere USB-Geräte immer wieder aussetzen und um Wake-On-LAN kümmern wir uns im nächsten Schritt getrennt vom Powertop-Skript. Ein Laptop hängt selten per Kabel-Ethernet im Netzwerk und muss auch noch seltener per Wake-on-LAN über das Netzwerk geweckt bzw. gebootet werden. Es macht daher Sinn Wake-on-LAN zu deaktivieren, da die Funktion im Standby und Ruhezustand zusätzlichen Strom verbraucht. Unter Arch gibt es mehrere Wege Wake-on-LAN zu steuern, der einfachste geht über eine simple Udev-Regel, die ihr in Form der Datei /etc/udev/rules.d/70-disable_wol.rules mit folgendem Inhalt anlegt.

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*", RUN+="/usr/bin/ethtool -s %k wol d"

Funktioniert alles wie gewünscht, dann aktiviert mittels systemctl enable den Powertop-Booteintrag powertop.service und startet euren Rechner anschließend noch einmal neu durch. Habt ihr sauber gearbeitet, dann sollte Powertop kaum mehr einen Task mit „Schlecht“ kennzeichnen. Perfekt läuft es, wenn wirklich nur noch AutoSuspend für eure USB-Geräte als Verbesserungspotential übrig bleibt — diesen Punkt würde ich allerdings wie schon beschrieben nicht korrigieren. Damit solltet ihr nun eurem Linux-Laptop eine deutlich verbesserte Akkulaufzeit verpasst haben.

$ sudo systemctl enable powertop.service
$ sudo reboot

Bei meinem Dell Vostro V130 geht die Entladungsrate im Leerlauf bei aktiviertem WLAN und gleicher Helligkeit des Displays auf 9.10 W bis 9.30 W zurück. Damit verlängert sich im selben Zug auch die Akkulaufzeit von knapp über 2 Stunden auf locker mehr als 3 Stunden — ohne dass ich dabei an Komfort verliere oder irgendwelche Hardware-Komponenten nicht mehr funktionieren. Würde ich WLAN und Bluetooth abschalten sowie die Helligkeit des Displays auf ein erträgliches Minimum reduzieren, wären locker 4 Stunden Akkulaufzeit drinnen. Mehr verspricht Dell für das Gerät auch nicht in den technischen Spezifikationen.

Seitdem moderne Grafikkarten immer leistungsfähiger werden, ist es bei rechenintensiven Aufgaben eigentlich eine kräftige Ressourcenverschwendung nicht auf die Rechenpower der schnellen Grafikchips zurückzugreifen. Diese Idee greift schon länger OpenCL als Schnittstelle zwischen Haupt-, Grafik- und anderen digitalen Signalprozessoren für sogenannte uneinheitliche Parallelrechner auf. Von Apple, AMD, Intel und Nvidia entwickelt, unterstützen aktuelle Grafikchips diese Technik eigentlich auch unter Linux von Haus aus, nur muss natürlich auch die Software diese unterstützten. Mit einem Intel-Grafikchip im Rechner und Aftershot Pro als Raw-Bildbearbeitung lässt sich die Rechenzeit um mehr als 40 Prozent reduzieren.

Intels Implementierung von OpenCL fasst das Beignet Projekt zusammen. Für Beignet braucht es allerdings einen Rechner mit Chips aus der 3. Generation der Intel-Core-Prozessoren oder später, also mindestens einen Ivy Bridge als Hardware, oder eben noch aktuellere CPUs aus der Haswell- oder Broadwell- aka Rockwell-Reihe. Seid ihr euch über euren Rechner nicht im Klaren, dann lest mit cat /proc/cpuinfo den CPU-Namen aus und schlagt schnell in der Wikipedia nach, zu welcher Generation der Prozessor in eurem Computer gehört. Ich habe Beignet hier mit einem Intel Core i5-3470T mitsamt Intel HD Graphics 2500 aus der Ivy-Bridge-Klasse getestet. Mit einem Haswell werdet ihr in meinen Augen noch bessere Ergebnisse erzielen.

$ cat /proc/cpuinfo | grep name
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz

Beignet findet ihr seit Jessie in den Paketquellen von Debian. Bei Ubuntu gibt es OpenCL in Form von Beignet seit Trusty in den Paketquellen, allerdings nur in einer sehr alten Version. Wenn ihr unter Ubuntu mit Intels OpenCL-Implementation arbeiten möchtet, würde ich daher eher zu einem Ubuntu 15.04 „Vivid Vervet“ greifen. Bei Arch muss man sich um sowas natürlich keine Gedanken machen, allerdings muss man zur Installation von Beignet auf das Arch User Repository zurückgreifen. Dabei gilt es zu beachten, dass das Paket llvm aktuell nicht in den Abhängigkeiten aufgeführt wird. Ohne dieses bricht der Build-Prozess allerdings ab. Installiert daher das Paket vor der Installation von Beignet manuell.

### Beignet unter Arch Linux installieren
$ sudo pacman -S llvm
$ pacaur -S beignet clinfo
### Beignet unter Debian/Ubuntu installieren
$ sudo apt-get install beignet clinfo

Anschließend könnt ihr mit einem Aufruf von clinfo direkt testen, ob OpenCL auf eurem System nun auch funktioniert. Irgendwelche Einstellungen im Xserver oder andere Treiber sollten, zumindest auf Systemen mit Intel-Chipsätzen ohne eine dedizierte Grafikkarte, nicht nötig sein.

$ clinfo
Number of platforms 1
Platform Name Intel Gen OCL Driver
Platform Vendor Intel
Platform Version OpenCL 1.2 beignet 1.0.3
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd
Platform Extensions function suffix Intel
[...]

Das von Corel vertriebene RAW-Bildbearbeitungsprogramm AfterShot Pro unterstützt nun OpenCL schon seit mehreren Versionen. Die Ergebnisse des OpenCL-Turbos sind beachtlich. Tom’s Hardware hatte Mitte 2012 in einem ausführlichen Bericht eine Beschleunigung des Exports in das JPG-Format um den Faktor 2 ermittelt. Damals allerdings noch ohne Intel-Grafikkarten und nur mit AMD und Intel als Hardware.

Es lohnt sich daher einen Blick auf AfterShot zu werfen: Damit AfterShot auf OpenCL zurückgreift, müsst ihr im Programm unter Datei | Einstellungen | Hardware-Beschleunigung die Option OpenCL verwenden aktivieren und daraufhin das Programm neu starten. Führt AfterShot hier nicht eure Grafikkarte als OpenCL-Provider auf, dann hat etwas mit der Installation von Beignet nicht funktioniert. Bei Systemen mit anderen Grafikkarten müsst ihr euch selber in Richtung OpenCL und Nvidia oder AMD schlau machen.

Neben der Haupt-Einstellung müsst ihr unbedingt dem Schieberegler OpenCL-Nutzung Beachtung schenken. Mit diesem bestimmt ihr, wie stark AfterShot Pro bei der Berechnung der Bilddaten auf die Rechenfähigkeiten der Grafikkarte zurückgreifen soll: Mehr ist hier allerdings nicht immer von Vorteil, besonders bei Systemen mit Intel-Grafik. Zum Test sucht ihr euch am besten ein definiertes Set an RAW-Bildern heraus und exportiert dieses mit einem Druck auf [F] ins JPG-Format. AfterShot zeigt die Dauer des Vorgangs dann am Ende über ein kleines Popup an.

• Aus: 1:22,5 s
• Minimum: 58,5 s
• Niedrig: 1:29,6 s
• Standard: 1:27,2 s
• Hoch: 1:23,4 s

Notiert euch die Zeit, geht wieder in die Einstellung und stellt die OpenCL-Nutzung auf den nächsten Wert. Startet AfterShot daraufhin neu, ruft erneut den Export der selben Daten auf und notiert euch wieder das Ergebnis. Wiederholt den Vorgang nun so lange, bis ihr die optimalen Einstellungen ermittelt habt. Die Intel HD Graphics 2500 aus meinem Core i5 liefert das beste Ergebnis, wenn ich die OpenCL-Nutzung nach ganz links auf Minimum setze. Mit den anderen Settings wird AfterShot Pro auf meinem System eher langsamer als schneller. Es gilt die Fausregel: Je mehr Power eure Grafikkarte besitzt, desto höher solltet ihr den Regler ziehen können.

Gegenüber dedizierten Grafik-Chips von AMD oder Nvidia kommt Intels OpenCL-Implementation auf meinem „langsamen“ Core i5 mit Intel HD Graphics 2500 zwar nicht auf einen Geschwindigkeitszuwachs um Faktor 2, allerdings wird der Berechnungsvorgang dennoch deutlich schneller. Besonders weil die Installation von Beignet nicht wirklich viel Aufwand macht und in der Regel ohne Komplikationen gelingen sollte, lohnt sich der Beschäftigung mit dem Thema.