Dev.Fedorado

Es wurde Zeit für einen neuen Linux-PC. Und da Intel in letzter Zeit mit Meltdown und mit Sicherheitslücken in der Management Engine keine allzu gute Figur macht, dachte ich mir, es ist wieder an der Zeit, AMD eine Chance zu geben.

Was ich haben möchte, ist ein Arbeitsrechner mit guter Rechenleistung und schnellem Massenspeicher. Die Grafikleistung ist sekundär, da ich nicht spiele. Wichtiger ist mir ein ruhiger Betrieb, was die Reduzierung von Abwärme durch einen Strom sparenden Prozessor beinhaltet.

Für meinen neuen Rechenknecht im Retro-Look entkernte ich ein Cooler Master Cavalier 3-Towergehäuse von 2004, das ich noch hier stehen hatte und einen AMD Athlon 64 mit üppigen 4 GB DDR2-RAM beherbergte. Nach der Renovierung besteht der Rechner jetzt aus:

• CPU: AMD Ryzen 5 2400G. Die eingebaute Vega 11-Grafikeinheit bringt bei Benchmark-Tests eine respektable Leistung und reicht für meine Zwecke locker aus. Zudem begnügt sich der Ryzen 5 mit 65 W TDP. Eine für diesen Einsatz eigentlich überdimensionierte AIO-Wasserkühlung sorgt dafür, dass die CPU-Cores auch längere Zeit im 3,9 GHz Turbo-Modus durchhalten, und lässt mir die Option für spätere Overclocking-Experimente.
• Mainboard: Asus Prime X470 Pro. Für diese Wahl gab es keinen besonderen Grund, außer dass ich in der Vergangenheit mit Asus-Boards gute Erfahrung gemacht habe. Für die Linux-Kompatibilität ist die Nennung des verwendeten Typs aber vielleicht interessant.
• SSD: Samsung 970 Pro, 512 GB, PCIe M.2. Massenspeicher sind die Komponenten, die im Rechnerleben erfahrungsgemäß als erstes ein Upgrade erfahren, weil sie zu klein oder zu langsam geworden sind. Also lieber gleich schon beim Neukauf klotzen statt kleckern. Das zögert das Upgrade ein wenig hinaus.
• RAM: 16 GB DDR4-3000, als Kit mit 2x 8 GB. Für meine Zwecke reicht das. Der Ryzen 5 unterstützt maximal DDR4-2933, so dass höher getaktete RAMs wenig Sinn machen. Da sollte man lieber mehr Geld für eine möglichst geringe CAS Latency ausgeben.

Für Linux gibt es hier gleich mehrere Herausforderungen. Die Vega-Grafikeinheit ist verhältnismäßig neu, dementsprechend neu ist auch der Support im Linux-Kernel. Zudem ist die SSD nicht per SATA, sondern per PCIe angebunden, was ebenfalls - zumindest theoretisch - zu Treiberproblemen führen kann.

Der Versuch, eine Fedora 28-Live CD im Cinnamon-Spin zu starten, funktionierte auch prompt nicht. Das System startet bis zur Anmeldemaske, aber man kommt einfach nicht darüber hinaus. Erst ein Start im minimalen VESA-Modus erlaubte es, eine reduzierte Cinnamon-Oberfläche zu erreichen und den Installer auszuführen.

Zumindest meine Sorge, die PCIe-SSD würde nicht erkannt werden, erwies sich danach als unbegründet. Der Installer erkannte die SSD und richtete problemlos und zügig das Fedora-System darauf ein.

Beim ersten Reboot startete Cinnamon aber weiterhin nur im reduzierten Modus ohne Compositing. Abhilfe brachte, den nomodeset Kernel-Parameter aus den Grub-Einstellungen zu entfernen. Nach einem weiteren Reboot stand dann die volle Grafikleistung zur Verfügung. Vermutlich hat das Live-Image einen zu alten Kernel, so dass das kommende Fedora 29 problemlos installierbar sein wird.

Von den anfänglichen Problemen mit der Grafik abgesehen, läuft das System rund. Netzwerk, Sound, SATA- und USB-Schnittstellen wurden von Linux erkannt und werden voll unterstützt. Selbst unter Last verhält es sich stabil, bisher hatte ich keine Freezes oder unerwarteten Abstürze.

Mein Ziel habe ich damit erreicht. Der neue PC bringt eine ordentliche Leistung und ist trotzdem leise, kühl und sparsam.

Zumindest vorübergehend. Sobald man versucht, eine aus OpenSCAD exportierte stl-Datei in Cura zu importieren, erscheint die Fehlermeldung "Ungültige Datei".

Der Grund dafür ist, dass Cura auf manchen Plattformen momentan Probleme hat, stl-Dateien im ASCII-Format zu lesen. Und OpenSCAD exportiert nur in ASCII-Format.

Als Workaround hilft ein Universal-Taschenmesser für stl-Dateien namens admesh. Neben etlichen anderen Transformationsmöglichkeiten konvertiert es eine ASCII-stl-Datei ins Binärformat:

admesh -b example-bin.stl example-ascii.stl

Diese lässt sich dann in Cura problemlos öffnen.

admesh ist im Fedora Repository verfügbar und kann (auf Wunsch inklusive einer GUI) einfach per dnf installiert werden:

sudo dnf install admesh admeshgui

Wieder einmal hatte ich Probleme mit meinem altgedienten Canon LiDE 20-Scanner. Diesmal wurde er zwar per USB erkannt, aber wenn ich etwas scannen wollte, erhielt ich nur Fehlermeldungen oder schwarze Seiten.

Der Grund liegt in den USB-Stromsparmaßnahmen moderner Linux-Kernel. Alte USB-Geräte haben ihre Probleme damit, einfach zwischendurch den Saft abgedreht zu bekommen.

Zum Glück kann man es bei Fedora leicht ausschalten:

echo -1 >/sys/module/usbcore/parameters/autosuspend

Der USB auto suspend ist dann für alle USB-Geräte abgeschaltet, die von jetzt an angeschlossen werden, also sollte man seinen Scanner erst danach einstecken. Beim nächsten Reboot ist der Effekt auch schon wieder vorbei.

Die Arduino-Plattform ist eine offene Entwicklungsplattform für kleine Hardwareprojekte, inklusive einer Entwicklungsumgebung und verschiedener günstiger Boards wie dem Arduino Uno. Wegen verschiedener Bugs ist die Installation der Entwicklungsumgebung auf einem System mit Fedora 15 leider nicht ganz trivial.

Die notwendigen Pakete befinden sich im Fedora-Repository. Zuerst installieren wir also die Arduino-IDE und stellen die Gruppenrechte her, die zum Zugriff auf die USB-Schnittstelle benötigt werden:

sudo yum install 'arduino*'
sudo usermod -a -G uucp,dialout,lock $USER

Neben der IDE werden der C-Compiler avr-gcc in Version 4.6.1-2 und die avr-libc in Version 1.7.0 installiert. Diese Version des Compilers wirft allerdings nur Fehlermeldungen. Ein Update steht schon bereit, liegt derzeit aber noch in fedora-testing und muss deshalb explizit installiert werden:

sudo yum --enablerepo=updates-testing update 'avr-*'

Danach ist der avr-gcc in Version 4.6.1-3 und die avr-libc in Version 1.7.1 installiert. Die IDE kann nun gestartet und die Sketches können kompiliert werden.

Allerdings bleibt noch ein Problem: durch eine zu aggressive Compiler-Optimierung funktioniert die delay()-Funktion unter Umständen nicht. So leuchtet bei dem Beispiel Blink die Test-LED dauerhaft, statt zu blinken. Die Ursache dafür lässt sich zum Beispiel durch einen Eingriff in eine Datei beheben. Folgender Patch führt diese Änderung aus:

sudo patch -d /usr/share/arduino/hardware/arduino/cores/arduino wiring.c << __END__
25a26
> #include <avr/delay.h>
106c107
< {
---
> {/*
114a116
> */ _delay_ms(ms);
__END__

Danach steht der Experimentierfreude nichts mehr im Wege!

Eine schöne Sache an der Android-Plattform ist, dass man auch unter Linux Apps entwickeln kann. Java und die Entwicklungsumgebung Eclipse steht als fertiges Paket zur Verfügung, und bei Google können die Entwicklertools kostenlos heruntergeladen werden.

Das Testen erfolgt entweder über einen Emulator, oder man geht gleich ans Eingemachte und testet seine Anwendung auf echter Hardware. Bevor das möglich ist, muss Fedora das Smartphone bekannt gemacht werden. Dazu wird mit Root-Rechten die Datei /etc/udev/rules.d/51-android.rules angelegt und mit folgendem Inhalt versehen:

SUBSYSTEM=="usb",SYSFS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666"

Unter idVendor wird die jeweilige Hersteller-ID des Smartphone-Herstellers eingetragen. Eine Tabelle der Vendor IDs gibt es ebenfalls bei Google. Wenn mehrere Smartphones verschiedener Hersteller zum Einsatz kommen, können entsprechend weitere Zeilen ergänzt werden.

Als nächstes muss auf dem Android-Phone das USB-Debugging aktiviert werden. Den Menüpunkt findet man unter Einstellungen → Anwendungen → Entwicklung → USB-Debugging aktivieren.

Wenn man nun seinen Androiden per USB anstöpselt und in dem Android-SDK das Kommando

platform-tools/adb devices

aufruft, sollte das Smartphone aufgelistet werden. Es steht dann als Zielplattform für die Entwicklung zur Verfügung.