Lavender

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
Wo ist der Kommentarbereich?

Ich habe mich entschlossen, den Kommentarbereich zu entfernen und alle Kommentare zu löschen. Der Grund dafür ist die DSGVO, die ab dem 25. Mai 2018 wirksam wird.

Die Shredzone verwendet keine Cookies und kein Tracking, zeigt keine Werbung und lädt keine Bilder oder Scripte von fremden Servern nach. Ich habe kein Interesse daran, meinen Lesern hinterherzuschnüffeln, und habe deshalb alles so datensparsam wie möglich gestaltet.

Das einzige Problem war der Kommentarbereich. Dort sammelt man naturgemäß personenbezogene Daten, was wiederum einen Berg an Anforderungen und Pflichten nach sich zieht. Für einen Hobby-Blog, an dem ich keinen Cent verdiene, ist mir der Aufwand einfach zu groß.

Über eure Kommentare habe ich mich immer sehr gefreut. Schickt mir eure Anmerkungen, Lob und Kritik gerne weiter per E-Mail oder als Tweet.

Thursday, February 22, 2018
Wir bauen uns einen Feinstaubsensor

Das Projekt luftdaten.info bietet eine Bauanleitung für einen Feinstaubsensor an. Er ist günstig und auch mit wenig Elektronikkenntnissen leicht zusammenzubauen. Die Bauteile gibt es in verschiedenen Elektronikläden und mittlerweile sogar bei Amazon.

Der originale Bausatz benutzt zwei Kunststoffrohre als Gehäuse. Die sind preiswert und in jedem Baumarkt leicht zu bekommen, sehen allerdings nicht besonders ansprechend aus. Ich wählte stattdessen eine handelsübliche UV- und wetterfeste Außen-Abzweigdose als Gehäuse. Ein selbst konstruierter Rahmen aus dem 3D-Drucker wird dort hineingesetzt und die Elektronik darauf montiert.

Der Rahmen bringt bereits einen Windkanal für die angesaugte Luft mit, so dass im Gegensatz zur Originalanleitung kein Schlauch notwendig ist. Gitter vor den Luftöffnungen verhindern, dass Insekten in das Gehäuse kriechen können. Im Gegensatz zu manch anderer gedruckter Lösung ist der Feinstaubsensor außerdem wie vom Hersteller vorgeschrieben ausgerichtet und die Einsaugöffnung vor Licht geschützt.

Im Gegensatz zur Originalanleitung kommt man hier allerdings nicht darum herum, den Lötkolben in die Hand zu nehmen.

Read this article...