Look what I have found... This is my very first shredzone, as it was online from 1998 to 2003. First it was hosted by my internet provider. Then, on April 15th 2000, I registered my own domain – shredzone.de – and moved my site to a professional hoster.

The site did not use a fancy content mangagement system, but consisted only of static HTML pages. It was built on my Amiga using a preprocessor called HSC, an acronym for HTML Sucks Completely. 😜 Some parts like the gallery or the download area were generated by accompanying ARexx scripts. It was incredibly easy to add content to the site. Basically it was just adding or changing a file, and then invoking smake to rebuild the affected parts of the site within seconds, including the navigation. It was a big advantage that I was going to miss badly later.

At that time I did not use CVS yet, so sadly all the past versions and changes have been lost. The only version I still have is the final one on my Amiga harddisk. I have found the project today, by a rather lucky accident. It was only the source code though, the final compiled version has got lost over the years. There is a Linux port of HSC, so basically I could rebuild the site on my Linux machine. But the ARexx parts require an Amiga environment, and porting them to Linux would have consumed too much time.

So I started an Amiga emulator and, thanks to the good shape of the project that the past Amiga me has left the present Linux me, I actually only needed to run smake to rebuild the entire homepage in just 3 minutes.

The requirement to run on an Amiga, was what later broke the neck of this homepage. When the Amiga platform died, I moved on to Linux, but I could not move my homepage with me. So, in 2003, I replaced it with a self-made content management system that was written in PHP and was called Akiko. It had some nice features, but on the other hand it was rather tedious to add new content. Because of that, I badly neglected my homepage in those years.

In 2010, Akiko was replaced by a self-made blog system that is written in Java and is named Cilla. Even after a major redesign in 2018, it is still in use today. 🙂

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 sandwich paper inside, so the LED light can be seen.

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

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.

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.

The season of long winter nights is coming, so I got myself an AdaFruit Circuit Playground Express for some home decoration.

My plan is to program it using CircuitPython, a MicroPython derivate that is adapted to the AdaFruit hardware.

CircuitPython must be installed to the Circuit Playground first, which turned out to be difficult with Fedora Linux in a first attempt. The troublemaker was the ModemManager, which is still installed by default. It detects the serial port of the AdaFruit device, and then hogs this resource because, well, it might be a modem. 🙄

My older readers certainly still remember what a modem is. 😉 But to make a long story short, almost no one is using a serial modem nowadays, so the ModemManager does not serve any useful purpose. However, it cannot be removed, because other important packages still depend on it. The only way is to stop it permanently:

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager

After that, I could finally install CircuitPython to the Circuit Playground. First I downloaded the matching uf2 file. After that, I connected the Playground via USB, and changed to the bootloader mode by pressing its reset button twice (like a double-click).

The Circuit Playground is now mounted as an USB drive called CPLAYBOOT. All there is to do now is to copy the uf2 file to this drive. The Playground automatically reboots after that. If everything went fine, it will come back as an USB drive called CIRCUITPY.

The next step is to install the AdaFruit libraries to that drive. I downloaded the latest library bundle that matched my CircuitPython version, and just unpacked it to the CIRCUITPY drive.

That's it... All there is to do now, is to open the code.py file in an editor and change the code. It is immediately executed when it is saved.

For a start, there are a lot of code examples for the Circuit Playground Express on the AdaFruit web site.