Love Locks at Pont des Arts

Google Earth Pro auf Fedora installieren

In dem Fedorablog, den ich ganz früher mal geschrieben hatte, hatte ich ein regelmäßig wiederkehrendes Thema: Die Installation von Google Earth. Lange Zeit war das echte Handarbeit, obwohl Google ein RPM-Paket bereitstellte.

Seitdem sind viele Jahre vergangen. Mittlerweile stellt Google die ehemals kostenpflichtige Pro-Version von Google Earth zum kostenlosen Download für Linux zur Verfügung. Und auch die Installation ist glücklicherweise kein Problem mehr. Es reicht schon, das RPM-Paket zu installieren:

sudo dnf install google-earth-pro-stable-current.x86_64.rpm

Auf deutschen und österreichischen Systemen¹ muss anschließend noch eine kleine manuelle Änderung vorgenommen werden. Der Grund dafür ist, dass die Google-Server bei der Ortssuche Geokoordinaten mit Dezimalpunkt ausliefern, das System aber das bei uns übliche Dezimalkomma erwartet und die Zahlen deshalb nicht verarbeiten kann. Die virtuelle Erdkugel dreht sich dann immer mitten auf den Atlantik statt auf die gewünschte Markierung.

Eine einfache Lösung ist, die Datei /opt/google/earth/pro/googleearth mit einem Texteditor zu bearbeiten (Root-Rechte erforderlich) und in der letzten Zeile der Datei ein LC_NUMERIC=us_US.UTF-8 einzufügen:

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH LC_NUMERIC=us_US.UTF-8 ./googleearth-bin "$@"

Danach sollte Google Earth Pro problemlos und stabil laufen.


¹) Nach meinen Recherchen verwendet ein Linux mit schweizerdeutscher Einstellung den Dezimalpunkt. Die Anpassung ist dann nicht nötig, schadet aber auch nicht.

Fedora 28 auf einem Ryzen 5

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 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.

#Advertisement? This blog is free of ads. All shown products have been paid by myself.
Sunday, August 12, 2018
Cura mag OpenSCAD nicht mehr

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
Fedora: SSD kurz und schmerzlos

Es gibt schon viele Artikel, wie man SSD-Festplatten richtig in Linux einbindet. Aber entweder sind sie unvollständig oder recht lange. Also, hier eine tl;dr-Fassung – SSD mit Fedora, kurz und schmerzlos.

Trimming

Wenn die SSD trimming kann (was mittlerweile bei ziemlich allen SSDs auf dem Markt der Fall ist), sollte es natürlich auch verwendet werden. Dadurch ermöglicht man wear levelling, gibt also der SSD die Möglichkeit, den Verschleiß der Speicherzellen zu verteilen.

In der /etc/fstab wird bei jedem Mountpoint, der auf eine SSD-Partition verweist, die Parameter discard angehängt. Eine gute Idee ist es außerdem, noatime hinzuzufügen, um die Schreibzugriffe auf die Platte zu reduzieren. Das sieht dann zum Beispiel so aus:

UUID=939446e3-9bb9-40a6-bf03-2d87bb8f5837 /                       ext4    discard,noatime        1 1
UUID=4f75261d-2e40-4e39-bf63-2a9c517fc73d /home                   ext4    discard,noatime        1 2
UUID=05db751b-5c2b-47da-8577-89ee30d90e56 swap                    swap    defaults        0 0

Das funktioniert mit reinen ext4- und btrfs-Partitionen sowie mit RAID-Partitionen. Wird LVM verwendet, muss in der /etc/lvm/lvm.conf zuerst bei der Option issue_discards eine 1 eingetragen und die initramfs mit sudo dracut -f neu gebaut werden. Bei LUKS-Partitionen ist ein Kniff notwendig, den ich weiter unten beschreiben werde. Swap-Partitionen trimmen immer, ein discard-Parameter ist nicht erforderlich.

Nach einem Neustart sollte man einmalig alle SSD-Partitionen von Hand trimmen:

sudo fstrim -v /
sudo fstrim -v /home

Man kann man das Trimmen außerdem automatisch wöchentlich vornehmen lassen:

sudo systemctl enable fstrim.timer

Eventuell kann man sich dann auch das discard in der /etc/fstab sparen, da es Löschoperationen verlagsamt.

LUKS-Partitionen

Verschlüsselte LUKS-Partitionen reichen von sich aus die Trimming-Kommandos nicht an die SSD weiter. Das hat auch einen guten Grund: Das Trimming erlaubt Rückschlüsse darauf, welche Teile der verschlüsselten Partition Daten enthalten und welche nicht. Das erleichtert einen gezielten Angriff auf die verschlüsselten Daten, zumindest theoretisch.

Um bei LUKS das Trimming einzuschalten, wird in der /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX die Kernel-Option rd.luks.options=discard angehängt und mit

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

die GRUB-Konfiguration neu gebaut.

Wenn es sich um ein Upgrade einer älteren Fedora-Installation handelt und nicht um eine Neuinstallation, muss eventuell auch in der /etc/crypttab an allen Einträgen außer der Swap-Partition die Option discard angehängt werden. Danach wird mit sudo dracut -f die initramfs neu gebaut. Da man bei einem Fehler schnell ein nicht mehr bootendes System hat, empfehle ich diesen Schritt nur erfahrenen Linux-Anwendern.

Ab dem nächsten Reboot steht Trimming dann auch auf LUKS-verschlüsselten Partitionen zur Verfügung.

I/O-Scheduler

Was bei mechanischen Festplatten wirklich Zeit kostet, ist das Positionieren des Schreib-Lesekopfes, weshalb Linux versucht, die Daten möglichst zu sammeln und zu gruppieren. Bei SSDs spielt es dagegen keine Rolle, wie fragmentiert die Daten sind. Aus dem Grund kann man das Gruppieren wegfallen lassen und sich über die gewonnene Performance freuen.

Dazu wird eine Datei /etc/udev/rules.d/40-ssd.rules mit folgendem Inhalt angelegt:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Beim nächsten Neustart verwenden SSD-Platten den noop-Scheduler, mechanische Festplatten weiterhin den für sie optimalen cfq.

Swappiness

SSDs können beliebig oft und schnell gelesen werden, verschleißen aber bei Schreibzugriffen. Swapping auf eine SSD-Partition ist zwar möglich, aber der Lebensdauer nicht sehr zuträglich. Folgende Zeilen in der /etc/sysctl.conf reduzieren das Auslagern auf die Swap-Partition auf ein Minimum.

vm.swappiness=1
vm.vfs_cache_pressure=50

Bei den heutigen Preisen selbst für üppige RAM-Ausstattung wäre es zumindest bei Desktop-Rechnern eine Überlegung wert, ob eine Swap-Partition überhaupt notwendig ist. Nachträglich kann eine Swap-Partition durch Auskommentieren der entsprechenden Zeile in der /etc/fstab deaktiviert werden.

Firefox-Cache

Firefox lagert seinen Cache in das Home-Verzeichnis aus, was eine zusätzliche Belastung für die SSD darstellt. Wer einen Rechner sein Eigen nennt, der mit üppig viel RAM gesegnet ist, kann auf das /tmp-Verzeichnis ausweichen, welches bei Fedora im Arbeitsspeicher statt auf der Festplatte liegt. Das geht leider nur über einen Eingriff in die Eingeweide des Browsers über die URL about:config.

Nach einer Bestätigung, dass man sich benehmen wird, wird mit der rechten Maustaste über Neu - String ein neuer String-Eintrag angelegt. Der Eigenschaftsname lautet browser.cache.disk.parent_directory, der String-Wert /tmp.

Danach muss der Firefox noch neu gestartet werden.

Alter USB-Scanner mag keinen Strom sparen

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.