Alps, Munich

Dev

Kompakt und leise

ASRock DeskMini A300 Kompakt, schnell und leise ist eine Herausforderung beim Selbstbau eines PCs. Meistens bekommt man nur zwei dieser Eigenschaften auf Kosten der dritten. Ich habe mich trotzdem an einen Versuch gewagt.

Das Ergebnis ist:

  • Gehäuse und Mainboard: Das ASRock DeskMini A300 ist ein Barebone, das kaum größer ist als ein ATX-Netzteil. Trotzdem hat es genug Platz für einen Prozessor mit AM4-Sockel und einer Verlustleistung von bis zu 65 Watt. Dazu passen zwei 2,5-Zoll-Festplatten und zwei M.2-SSDs hinein. WLAN gibt es optional dazu. Versorgt wird das Gerät mit einem externen 300W-Notebook-Netzteil.
  • Kühlung: Ich verzichtete auf den beigelegten Kühlkörper und baute ein Noctua NH-L9a-AM4 ein. Die Lüfter- und Kühlkörper-Lösung ist wie für dieses Gehäuse gemacht. Der Lüfter ist enorm leise. Selbst unter Last ist nur ein leises Rauschen zu hören, das überhaupt nicht stört.
  • CPU: Hier setzte ich auf einen AMD Ryzen 5 2400G, welcher sich bereits in meinem PC unter Linux bewährt hat. Mit 65 Watt TDP passt er in das Gehäuse und bietet mehr aus ausreichend Leistung für Office-Anwendungen, Video-Streaming und einfache Games.
  • RAM: 8 GB DDR4-2400 SO-DIMM als Kit mit 2x 4 GB. Für den gedachten Anwendungszweck reicht das. Bei einer Bestückung beider Slots mit Dual Rank-Modulen ist bei 2400 MHz Schluss, so dass der Kauf höher getakteter Speicherriegel nur Geld verschwendet hätte.
  • SSD: Als Festspeicher wurde eine vorhandene 2,5-Zoll SATA-SSD weiter verwendet.

Das System ließ sich zügig zusammenbauen. Problematisch war lediglich die Montage des Noctua-Kühlers. Dafür muss die vorhandene Halterung samt Bodenplatte entfernt werden. Anschließend wird Wärmeleitpaste auf die CPU aufgetragen, der Kühler daraufgelegt und von unten auf die beigelegte Bodenplatte geschraubt. Es erfordert schon ein wenig Geschick, den Kühlkörper dabei so wenig wie möglich zu bewegen, um die Wärmeleitpaste nicht zu verschmieren. SATA-Festplatten werden mit einem Spezialkabel mit dem Mainboard verbunden. Auch hier war es ein wenig Fummelei, den Spezialstecker auf das Mainboard zu stecken.

Bei einem ersten Test bootete ein Fedora 29-Livesystem auf der Maschine. Nachdem ich aber das BIOS auf die aktuelle Version 3.40 aktualisiert hatte, verweigerte das Livesystem selbst im Kompatibilitätsmodus den Dienst. Erst Fedora 30 (welches derzeit noch im Beta-Stadium ist) bootete problemlos und ließ sich ebenso leicht installieren.

Das System arbeitet unter Fedora 30 einwandfrei und stabil, selbst mit zwei angeschlossenen Monitoren. Beeindruckt hat mich vor allem der ruhige, nahezu lautlose Betrieb, der trotz dieser kompakten Abmessungen möglich ist. Darüber hinaus lässt sich ein solches System für einen verhältnismäßig günstigen Preis zusammenbauen. Es eignet sich bestens als kompakter Schreibtischrechner oder anspruchsvoller HTPC.

Fluido skin and Markdown syntax highlighting

doxia-module-markdown is a Maven plugin that enables Markdown in Maven documentations. In version 1.8, the developers have moved from Pegdown to Flexmark as Markdown parser. It's a good choice, as Flexmark is considerable faster and is still being maintained, while Pegdown officially reached its end of life in 2016.

However, with that switch, code blocks are not syntax highlighted any more. The reason is that the maven-fluido-skin uses code-prettify for syntax highlighting. It runs browser-side, highlighting all <pre> and <code> blocks selecting the prettyprint CSS class. This was true with Pegdown, but Flexmark selects a source class instead.

An obvious workaround is to use a small JavaScript snippet that adds a prettyprint class to all blocks selecting a source class, and then running prettyPrint() again. To do so, this block needs to be added to the <head> section of site.xml:

<head>
  <!-- Workaround for https://issues.apache.org/jira/browse/DOXIA-571 -->
  <![CDATA[<script type="text/javascript">
    $(document).ready(function () {
      $(".source").addClass("prettyprint");
      prettyPrint();
    });
  </script>]]>
</head>

It's hard to tell if this is a bug in doxia-module-markdown or in maven-fluido-skin. Also see my bug report at Apache's JIRA.


This was a Google Plus comment that I have now moved to my blog as Google Plus is going to be closed. Thanks to Clement Escoffier for the inspiration.

Circuit Playground Halloween Ghost

Just in time for Halloween 🎃, I made a ghost decoration that uses an Adafruit Circuit Playground Express.

The ceramic ghost is from a home decoration shop. I have put a little piece of sandwich paper inside, so the LED light can be seen through the ghost's mouth and eyes.

The MicroPython source shows a candle light effect. For the flame, a mystic cyan color is used, so the ghost appears really spooky. 👻

If you copy .wav files to the Circuit Playground, a random sound effect is played from time to time. I found nice free sound effects on soundbible.com that surely give everyone the chills. The sound files should be converted to mono and 16 kHz sampling rate, so they fit into the tiny Playground Express memory. The sound effects can be muted using the switch on the Playground, if they should become too annoying. 😉

Continue reading...
How acme4j handles POST-as-GET requests

In the latest ACME draft 15, Let's Encrypt introduced POST-as-GET requests. It is a breaking change that is not downward compatible to previous drafts.

This brought me into an uncomfortable position. While the Pebble server enforces the use of POST-as-GET, other servers don't support it yet, like the Let's Encrypt server. For this reason, acme4j needs to support both the pre-draft-15 GET requests and the post-draft-15 POST-as-GET requests. Luckily I have found a solution that is totally transparent to the user, at least as long as no other ACME server is used.

This is how acme4j v2.4 works:

  • If you connect to Boulder via an acme://letsencrypt.org URI, acme4j falls back to a compatibility mode that still sends GET requests. Let's Encrypt has announced a sunset date for GET requests on November 1st, 2019. You are safe to use acme4j v2.4 (and older versions) up to this date.
  • If you connect to a Pebble server via an acme://pebble URI, the new POST-as-GET requests are used.
  • If you connect to a different server implementation via http: or https: URI, acme4j sends POST-as-GET requests now. This is likely going to fail at runtime, if the server you connect to does not support draft-15 yet.
  • As a temporary workaround, you can add a postasget=false parameter to the server URI (e.g. https://localhost:14000/dir?postasget=false) to make acme4j enter the fallback mode and send GET requests again.

As soon as Let's Encrypt supports POST-as-GET on their production servers, I will remove the fallback mode from acme4j again. It just clutters the code, and I also have no proper way to test it after that.

Hint: Before updating acme4j, always have a look at the migration guide. It will show you where you can expect compatibility issues.

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.