Auch die Rennrad Routen waren super geplant und zum Großteil komplett ohne Autoverkehr. Es war ein wirklich gelungener Urlaub 🥰

Hier ein paar der schönsten Bilder:

In letzter Zeit, hat es mich aber dann mal wieder in den Fingern gejuckt und ich habe ein bisschen was angepasst. Im wesentlichen sind das zwei Dinge:

1. Die komplette Seite wird nun statisch generiert.
2. Es gibt einen neuen Bereich "Stream".

Die Inhalte des Blogs pflege ich in Markdown Dateien. Für jeden Artikel lege ich einfach eine neue Markdown-Datei an und fülle sie mit Inhalt. Bisher wurde draus dann dynamisch, bei jeder Anfrage, das entsprechende HTML erzeugt und an den Besucher ausgeliefert. Nun ist das "rendern" von Markdown nicht besonders rechenaufwändig und ich hätte es auch einfach so lassen können, aber mir ist aufgefallen, dass die Seite eigentlich keine dynamischen Elemente im eigentlichen Sinne hat, und ich die entsprechenden HTML Inhalte auch schon im Voraus generieren kann. Der Webserver muss dann nur noch die entsprechende HTML Datei ausliefern und fertig. PHP (damit ist die Software gebaut) wird nun nur noch benötigt um die HTML Dateien zu generieren. Die fertigen Inhalte werden direkt vom Nginx ausgeliefert.

Netter Nebeneffekt: Die Response-Time der Seite ist nochmal um ein klein wenig schneller geworden.

Die zweite Anpassung ist inhaltlicher Natur. Es gibt nun einen neuen Bereich: Stream

Hier möchte ich unsortiert, unbürokratisch und chaotisch alles rein packen, was keinen eigenen Blog-Artikel verdient. In erster Linie werden das vermutlich einzelne Fotos, hin und wieder aber auch mal ein kurzer Text sein. Im Gegensatz zum Blog, gibt es hier keine "Detail-Seite" - alles was es zu sehen und zu lesen gibt, ist direkt auf der Stream Seite zu finden. Ein Art Instagram Ersatz quasi. Das ist jedenfalls der Plan.

Ob das tatsächlich so klappt, und ob ich mich dazu motivieren kann tatsächlich regelmäßig etwas hinzuzufügen, wird die Zeit zeigen ;)

Hin- und Rückreise mit dem Radkoffer haben ohne größere Probleme geklappt. Ich habe in diesem Jahr vier schöne Routen abgefahren, dich ich euch hier verlinkt habe.

• Tag 1: Formentor und Co
• Tag 2: Sa Calobra und Col de Femenia
• Tag 3: Sineu Velodrom und Randa
• Tag 4: Soller und Puig Major

Zudem ein paar Fotos:

• Cap de Formentor
• Petra
• Puig de Randa
• Sa Calobra, Puig Major, Coll de Soller, Col de Femania
• Sant Salvador
• und einiges mehr...

Absolute Empfehlung. Hier ein paar Impressionen:

Zur besseren Verständlichkeit werde ich in diesem Artikel die folgenden Beispieldaten bzw. Tabellen verwenden:

Table shirts
+----+----------+
| id | motive   |
+----+----------+
|  1 | Homer    |
|  2 | Marge    |
|  3 | Bart     |
+----+----------+

Table colors
+----+----------+
| id | color    |
+----+----------+
|  1 | Red      |
|  2 | Blue     |
|  4 | Green    |
|  8 | Black    |
+----+----------+

Wir haben eine Tabelle mit T-Shirts und eine weitere Tabelle mit den Farben. Jedes Shirt kann in verschiedenen Farben erhältlich sein, aber nicht jedes Shirt ist in jeder Farbe erhältlich. Daher müssen wir eine neue Tabelle erstellen, um zu speichern, welches Shirt in welcher Farbe erhältlich ist. Diese würde wahrscheinlich so aussehen:

Table: shirts_x_colors
+----------+------------+
| shirt_id | color_id   |
+----------+------------+
|        1 |          1 |
|        1 |          4 |
|        2 |          2 |
|        2 |          8 |
|        3 |          2 |
+----------+------------+

Diese Tabelle gibt uns nun Auskunft darüber, welches Shirt in welcher Farbe erhältlich ist - zum Beispiel ist das Shirt "Marge" in Rot und Schwarz erhältlich. Wenn wir eine Liste aller Shirts und verfügbaren Farben haben möchten, müssten wir 3 Tabellen berücksichtigen z.B. GROUP_CONCAT verwenden, um eine kommaseparierte Liste der Farben zu erhalten. Etwas wie:

SELECT shirts.motive, GROUP_CONCAT(colors.color)
FROM shirts
JOIN shirts_x_colors ON shirts.id = shirts_x_colors.shirt_id
JOIN colors ON shirts_x_colors.color_id = colors.id
GROUP BY shirts.id

Solche Abfragen können schnell langsam werden, vor allem wenn wir berücksichtigen, dass Shirts wahrscheinlich nicht nur eine Farbe haben, sondern auch unterschiedliche Größen, Materialien usw.

Verwendung von Bitmasks

Bitmasken können dazu beitragen, diese Art von Abfragen zu verbessern. Die IDs in der Tabelle "colors" sind daher nicht einfach aufsteigende Ganzzahlen, sondern nur Zahlen, die Zweierpotenzen (1,2,4,8,16,32,...) sind. Wir können nun unsere Tabelle "shirts" wie folgt erweitern:

Table shirts
+----+----------+--------+
| id | motive   | colors |
+----+----------+--------+
|  1 | Homer    |      5 |
|  2 | Marge    |     10 |
|  3 | Bart     |      2 |
+----+----------+--------+

Ich habe einfach eine neue Spalte namens "colors" hinzugefügt, die die Summe aller verfügbaren Farb-IDs für jedes Shirt enthält - zum Beispiel ist das Shirt "Homer" in Rot (1) und Grün (4) erhältlich, also ist "colors" 1 + 4 = 5. Das Schöne an Bitmasken ist, dass diese Summe immer eindeutig ist - das bedeutet, dass wir nur aufgrund dieser Summe wissen, in welchen Farben ein Shirt erhältlich ist.

Hier ist ein Beispielcode, der die Summe unserer IDs zurück in die einzelnen Werte umwandelt:

function reverseBitmask($bitmask)
{
    $bin = decbin($bitmask);
    $total = strlen($bin);
    $stock = [];
    for ($i = 0; $i < $total; $i++) {
        if ($bin{$i} != 0) {
            $bin_2 = str_pad($bin{$i}, $total - $i, 0);
            array_push($stock, bindec($bin_2));
        }
    }
    return $stock;
}

print_r(reverseBitmask(5));

Es gibt aber noch andere Vorteile: Was ist, wenn wir z.B. alle Shirts suchen möchten, die in Rot oder Grün erhältlich sind? Das können wir mit einer einzigen Abfrage tun. Die Summe der Rot- und Grün-IDs wäre 5, also sieht unsere Abfrage so aus:

SELECT * FROM shirts WHERE colors & 5 > 0;

Dies würde eine Liste aller Shirts zurückgeben, die entweder in Rot oder Grün erhältlich sind.

Aber Vorsicht: Die obige Abfrage kann keinen MySQL-Index nutzen. In Bezug auf die Performance kann es daher besser sein, eine einfache IN(x,y,z)-Abfrage zu verwenden.

Fazit

Die Verwendung von Bitmasken kann dazu beitragen, die Performance von SQL-Abfragen in einigen Fällen zu verbessern. Natürlich muss sorgfältig geprüft werden, ob diese Technik im gegebenen Fall nützlich ist. Wenn z.B. die Liste der Attribute (z.B. Farben) sehr lang werden kann, würde ich die Verwendung von Bitmasken nicht empfehlen. Außerdem muss klar sein, dass redundante Daten in Ihrer Datenbank gespeichert werden, wenn die Struktur einer Datenbank wie im Beispiel oben angepasst wird.

Die Verwendung von Bitmasken ist kein Allheilmittel zur Lösung von Performance-Problemen in Datenbanken, kann jedoch in einigen Fällen helfen - und ich hoffe, mit diesem Artikel ein grundlegendes Verständnis dafür vermittelt zu haben, wie Bitmasken funktionieren.

Happy coding!

Hinweis: Diesen Artikel hatte ich (auf Englisch) bereits 2016 auf einer anderen Website veröffentlicht.

Aber: Wie so oft, gibt es vom Hersteller keine Software für den Linux Desktop. Natürlich kann ich die Lampe einfach mit dem Smartphone steuern - das war mir aber zu friemelig. Und sind wir mal ehrlich: Irgendeine weitere Electron App, um eine Lampe an oder aus zu schalten, ist auch nicht unbedingt notwendig.

Daher habe ich mir ein einfaches Shell-Script gebastelt mit dem ich die Lampe nun steuern kann. Selbstverständlich für jenden zugänglich in einem GitHub Repository.

• Lampe an: ./keylights -h=elgato-key-light-air-12ab.local on
• Lampe aus: ./keylights -h=elgato-key-light-air-12ab.local off
• heller: ./keylights -h=elgato-key-light-air-12ab.local b+
• dunkler: ./keylights -h=elgato-key-light-air-12ab.local b-

Selbsterklärend, denke ich.

Mit so einem Script, einem Bash-Alias und/oder einem Keybinding ist das steuern der Elgato Key Light Air auch unter Linux sehr einfach möglich.

Genau bekomme ich nicht mehr zusammen, welche Geräte ich alle benutzt habe. Auf jenden Fall dabei waren ein T42, ein X200, ein T400 und ein T440s. Die meiste Zeit war ich mit den Geräten sehr zufrieden. Die Langlebigkeit, Wartbarkeit und die grundsätzlich hohe Verarbeitungsqualität der Thinkpads genießen nicht umsonst einen regelrechten Kultstatus. Nachdem das T440s nun jedoch auch schon etwas in die Jahre gekommen ist, wurde es Zeit für ein neues Notebook.

Die Qual der Wahl

Ich nutze seit Jahren nun Linux auf meinen Rechnern. Bei der Auswahl neuer Hardware versuche ich daher primär auf die Linux-Unterstützung zu achten. Das schränkt die Möglichkeiten oft schon ziemlich ein. Zwar ist es mittlerweile durchaus so, dass Linux auf fast jedem Gerät grundsätzlich funktioniert, der Teufel steckt aber oft im Detail:

• Wird das Wlan-Modul unterstützt?
• Funktionieren die Funktionstasten?
• Funktionieren Webcam und Mikrofon?
• Gibt es eine Lösung für die Lüftersteuerung?
• Sind Treiber für die GPU verfügbar?
• u.s.w.

Man kann sich nun ein paar Notebooks aussuchen und versuchen alle diese Fragen zu klären. Das ist aber ein ziemlich großer Aufwand und nicht immer auch tatsächlich möglich. Gerade bei sehr neuen Geräten sind diese Information oft noch schwer zu finden. Ich habe mich daher bei meiner Auswahl auf ein paar wenige Geräte beschränkt, die bereits vom Hersteller (meist optional) mit Linux ausgeliefert werden. In meinen Fall waren das:

• diverse Thinkpads
• Die DELL XPS Serie
• Geräte von Tuxedo/Schenker

Warum nicht wieder ein Thinkpad?

Thinkpads sind sicherlich noch immer eine gute Wahl, wenn man eine Notebook mit gutem Linux Support sucht. Aber die Unterschiede zu anderen Herstellern sind immer geringer geworden. Meiner Meinung nach unterscheiden sich die Top-Modelle hier nur noch sehr wenig voneinander. Es lohnt sicht also auch mal über den Tellerrand zu schauen.

Zusätzlich gabe es 1-2 Dinge die mich an den Thinkpads gestört haben:

• Ein nerviges Tastaturlayout mit "Fn"-Key unten links (statt CTRL).
• Kaum Konfiguraationsmöglichkeiten (z.B. beim Arbeitsspeicher).

Für das InfinityBook S 14 habe ich mich dann letztendlich aufgrund folgender Kriterien entschieden:

1. Preis/Leistung
   Mit einer vergleichbaren Konfiguration war Tuxedo schlicht etwas günstiger als Dell oder Lenovo.
2. Anschlüsse/Ausstattung
   Das InfinityBook hat mit 1x Thunderbold/USB-C, 2x USB-A und einem HDMI deutlich mehr Anschlussmöglichkeiten als z.B. das XPS 13. Ausserdem bekommt man hier satte 40GB RAM!
3. Linux-Support
   Alle 3 Hersteller bieten Geräte mit vorinstalliertem Linux Betriebssystem an. Tuxedo hat sich jedoch auf den Vertrieb von Linux-Hardware spezialisiert und bietet daher noch ein paar nette Details. Dazu später mehr.

Der erste Eindruck

Das Notebook wird schlicht, aber ausreichend verpackt geliefert. Es liegen eine gedruckte Bedienungsanleitung sowie ein USB-Stick mit einem Tool zur Linux Neuinstallation bei. Zusätzlich einige Goodies.

Das Notebook macht einen sehr soliden Eindruck. Die Tastatur hat kaum Flex und der Deckel scheint ausreichend stabil befestigt. Die Verarbeitungsqualität ist vollkommen in Ordnung.

Das Gerät kam, wie bestellt, mit der hauseigenen Linux Version "Tuxedo OS" vorinstalliert. Für Linux-Anfänger absolut perfekt. Aufklappen und loslegen, keine Konfiguration irgendwelcher Hardware nötig. Soweit ich das beurteilen konnte, ist TuxedoOS eine auf Ubuntu basierende Distribution mit der Budgie Desktop-Umgebung. Abseits von einigen Layout-Anpassungen (Wallpaper, Farben, ...) sah das System sehr "standardmäßig" aus. Sprich: Keine unnötige Hersteller-Bloatware.

Linux Installation

Da meine bevorzugte Linux Distribution Xubuntu nicht zu verfügbaren Varianten bei Tuxedo gehört, war hier zunächst eine Neuinstallation nötig. Aber seien wir ehrlich: Eine frische Installation mit Vollverschlüsselung gehört sowieso zum Prozedere bei neuer Hardware. So konnte ich auch direkt testen was alles zu tun ist, um die Hardware auch einem neuen System wieder ans Laufen zu bringen.

Und ich muss sagen: An dieser Stelle kann Tuxedo wirklich punkten und lässt das Entwickler-Herz etwas schneller schlagen. Nachdem das Basissystem installiert ist, bietet Tuxedo ein Shell-Script in einem Repository auf Github an, um fehlende Treiber und Ähnliches nachzuinstallieren. Das spart eine Menge arbeit und funktioniert tadellos. Der Vollständigkeit halber sei Folgendes erwähnt:

• Ich habe das Script minimal angepasst, da ich einige der zu installierenden Pakte nicht benötige.
• Das Script ersetzt die Standard-Paketquellen der Ubuntu-Installation durch Quellen auf einem Tuxedo-Server. Dadurch werden Updates automatisch eingespielt, aber aus Datenschutzgründen ist das evtl. nicht für Jeden die optimale Lösung.

Disclaimer & Fazit

Dieser Artikel ist natürlich nicht von Tuxedo gesponsort und beinhaltet auch keine Affiliate-Links. Das Notebook wurde von meinem Arbeitgeber bezahlt. (Übrigens: Wenn du auch eins möchtest, schau doch mal in unsere Stellenanzeigen!)

Ich habe das Gerät erst seit ein paar Tagen im Einsatz, daher ist das hier nur ein erster Eindruck. Bis jetzt bin ich allerdings zufrieden mit meiner Entscheidung den Lenovo Kosmos zu verlassen. Ich werde versuchen den Artikel in ein paar Wochen/Monaten mit "Langzeit-Erfahungen" zu aktualisieren.

Halde Hoheward (Herten/Recklinghausen)

Zoom Erlebniswelt (Gelsenkirchen)

Tiger & Turtle (Duisburg)

Landschaftspark Nord (Duisburg)

Am nächsten Tag setzten wir die Segeln in Richtung Hooge. Niemand von uns war vorher schonmal auf einer Hallig - und so war Hooge genau das richtige Ziel. Bei meist tollem Segelwetter kamen wir rechtzeitig an und mussten noch einige Zeit vom dem Sperrtor warten, bevor es dann mit dem lezten bischen "Hochwasser" in den Hafen ging.
Hooge ist wirklich sehenswert und ein tolles Naturparadies. Ich empfehle jedem der die Chance hat sich das einmal anzuschauen.

Sonntags ging es dann zurück von der Hallig in Richtung Husum. Zwar haben wir es nicht mehr im Tageslicht zurück in den Hafen geschafft, es war jedoch noch genug Wasser da um mit unseren 60cm Tiefgang (minimum) einzulaufen.

Auch wenn das Revier um die nordfriesischen Inseln segeltechnisch nicht das Optimum ist, ist die Landschaft und Natur mit dem Wattenmeer extrem schön. Eine klare Empfehlung!

Trotz mäßigem Wetters und Corona war es überigens überraschen voll. Liegt vermutlich an den Sommerferien.

Ein paar Blüten konnte ich aber dennoch knipsen :)

Hinweis: Ich habe eine ganze Menge technische Details und Erklärungen mit aufgenommen. Daher ist der Artikel etwas länger geworden. Also schnappt euch eine Mate bevor ihr anfangt zu lesen.

Ein kurzes Intro in die (damalige) Warez Szene

Für das Verständnis dieses Textes ist es nötig eine paar Grundbegriffe aus der Warez Szene der 1990er und 2000er Jahre zu kennen. Ich fasse das hier nur grob zusammen um den Text nicht zu lang werden zu lassen. Einen guten Einstieg bietet außerdem die englische Wikipedia in diesem Artikel: Nuke (warez)

In der Warez Szene werden Filme, Computerspiele, Musik, etc. von Release groups veröffentlicht. Jede einzelne Veröffentlichung nennt man ein Release. In der Regel werden die Releases auf einen FTP Server geladen. Ein solcher Server wird als Site bezeichnet. Große Teile der Kommunikation innerhalb der Szene finden im IRC Netzwerk statt. Zu jedem neun Release gibt es eine "Ankündigung" in einem speziell dafür bereitgestellten IRC channel. Diese speziellen Chat-Räume werden Pre channel genannt. Zusätzlich werden alle Releases in einer Datenbank gesammelt, der sog. Pre database oder kurz PreDB.

In einer PreDB werden neben Titel und Zeitpunkt der Veröffentlichung noch ein paar zusätzliche Informationen gespeichert. Dazu gehören die Release group, die Größe (Anzahl der Dateien + Größe in MB/GB), eine Kategorie oder Section sowie ein Genre. Auch die Information ob und wieso ein Release zurückgezogen wurde wird ggf. in der PreDB gespeichert.

Zusätzlich zu diesen Information stellen die meisten Release groups eine NFO Datei zu jeden Release bereit. Dabei handelt es sich um eine kleine Textdateien die genauere Information zum Release beinhalten. Einen gewissen Kultstatus genießen diese Dateien weil sie häufig das "Logo" der Group in Form von ASCII Art beinhalten.

Betrieb einer PreDB/NFO Webseite

Nach dieser Einleitung ist es hoffentlich nun etwas einfacher zu verstehen worum es beim Betrieb einer PreDB Website geht. Ich habe eine Datenbank mit (mehr oder weniger) allen Releases online bereitgestellt. Diese Datenbank wurde ständig aktualisiert und war durchsuchbar. Zusätzlich wurden (sofern verfügbar) die NFO Dateien zu den jeweiligen Releases angezeigt.

An dieser Stelle vielleicht noch ein wichtiger Hinweis: Auf der Webseite (und auch auf allen anderen PreDB Seiten) werden nie Downloads der eigentlichen Releases angeboten. Das ist eine komplett andere Baustelle.

Releases aus Pre Chans sammeln

Um die Datenbank ständig aktuell zu halten war es nötig die neuesten Releases aus den Pre Chans zu sammeln. Die Channel selbst, sowie die Bots in den Channels, sind allerdings relativ "fragil". Mal wird ein Channel geschlossen, mal ist ein Bot down. Der ein oder andere erinnert sich sicherlich auch noch an die sog. Net-Splits im IRC. Die können ebenfalls dafür sorgen, dass man die Nachrichten aus einem Channel nicht mitbekommt.
Daher wurde mir schnell klar, dass es notwendig ist die Releases aus verschiedenen Pre Channels gleichzeitig zu sammeln.

Ein Teil des Projekts war somit ein "IRC Bot" bzw. ein Script welches ständig in mehreren Pre Chans anwesend war, und dort die geposteten Releases gesammelt hat. Zu den Herausforderungen in diesem Bereich gehörte es sicherlich die geposteten Releases vom Rest der Kommunikation im Channel sauber zu trennen.
Dazu hatte ich pro Channel ein (oder mehrere) reguläre Ausdrücke welche die Release-Announcements filterten. Zusätzlich wurden nur Releases in die Datenbank aufgenommen, die in mindestens zwei Pre Chans unabhängig voneinander gepostet wurden.
Das bedeutete im Umkehrschluss jedoch auch, dass das komplette System nur funktionierte wenn mein Bot in mindestens zwei Pre Chans anwesend war. Daher habe ich den Bot in der Regel in 3-5 unterschiedlichen Channels lauschen lassen.

In einigen der Pre Channels war sämtliche Kommunikation verschlüsselt. Nur wem das aktuelle Passwort für den Kanal bekannt war konnte die Nachrichten lesen. Daher musste ich in den IRC Bot verschiedene Crypto-Alogorithmen implementieren - und je nach Channel aktivieren.

Grundsätzlich war das Aktualisieren der Datenbank mit neuen Releases eine eher einfache Aufgabe. Wesentlich schwieriger, war da schon das Sammeln der NFO Dateien.

Die ständige Jagd nach NFO Dateien

Einige der Pre Chans haben zu jedem Release auch eine NFO Datei bereitgestellt, sobald diese verfügbar war. Diese Channels waren jedoch wesentlich seltener als diejenigen in denen nur die Releases an sich gepostet wurden.
Primär habe ich die NFO Dateien damals zwar über diese Channels, und den im vorherigen Abschnitt erwähnten IRC Bot, gesammelt - es konnte aber nicht schaden auch noch andere Quellen zu nutzen.
Zwei dieser Quellen möchte ich hier erwähnen, weil sie aus meiner heutigen Sicht technisch ziemlich kreativ waren:

Der Usenet NFO Crawler

Viele der Releases incl. der NFO Dateien, landen früher oder später im Usenet. Daher kam ich auf die Idee "einfach" die Binary-Groups nach NFO Dateien zu durchsuchen, und diese dann den Releases in der Datenbank zuzuordnen.

Dazu eine extrem verkürzte und technisch sehr unsaubere Erklärung des Usenets:

Das Usenet ist im Prinzip nichts anderes als ein großes Forum in dem Textbeiträge geschrieben werden. Die Themen sind in verschiedene Gruppen (usenet groups) unterteilt. In jede Gruppe können Textbeiträge mit einem Subject und dem eigentlich Text geschrieben werden. Wenn man Texte lesen möchte schaut man sich zunächst die Titel/Subjects in einer Gruppe an, und kann dann entscheiden welche Texte man aufrufen möchten. Heute vielleicht am ehesten vergleichbar mit reddit.

Irgendwann kamen findige Hacker auf die Idee, dass Binärdateien im Prinzip auch nur Text sind, und man diesen Text natürlich auch im Usenet posten kann. Newsgroups in denen ausschließlich Binärdateien gepostet werden nennt man Binary-Groups.
Die Dateien werden dazu einfach in hunderte Teile zerlegt und dann in einzelne Beiträge geschrieben. Über die Subjects können diese später wieder zu einer Datei zusammengefügt werden.
Eine wesentlich ausführlichere Erklärung findet sich in der Wikipedia: Usenet (Binary Content)

Wie findet man aber nun NFO Dateien in diesen zig-tausenden Binärtext-Beiträgen?

Auch dafür habe ich wieder einen Bot programmiert. Dieser ging permanent alle neu geposteten Beiträge in verschiedenen Binary-Groups durch, und versuchte zunächst zu identifizieren ob es sich um ein Scene-Release handelt. Dazu wurde das Subject jedes einzelnen Beitrags mit eine Liste von regulären Ausdrücken angeglichen. Wenn es hier einen Treffer gab, bestand eine hohe Wahrscheinlichkeit für eine Scene-Release. Der so gefundene Name wurde dann mit allen Releases in der Pre-Datenbank abgeglichen. Gab es auch hier einen Treffer war ein Release gefunden. Schlussendlich wurde nun noch geprüft ob es sich um eine NFO Datei handelt. Nur dann wurde der Inhalt des Beitrags (in diesem Fall also die NFO Datei) gespeichert, und dem Release in der Datenbank zugeordnet.

Auf dem Screenshot sieht man einen Ausschnitt aus der Tabelle in der die Regulären Ausdrücke für die verschiedenen Binary-Groups gespeichert waren.

Der Png2Nfo Crawler

Verschiedene Quellen stellten NFO Dateien nicht im Textformat sondern als PNG Bilder zur Verfügung. Zum einen gibt es dann keine Probleme bei der Darstellung, und zum anderen sollte so die Weiterverbreitung der ursprünglichen NFO Dateien unterbunden werden.

Um also weitere Quellen für NFO Dateien nutzen zu können habe ich mir überlegt, dass es gut wäre aus PNG Dateien "einfach" wieder den ursprünglichen Text zu generieren. (Das berüchtigte "Entwicker-Einfach" ;))

Das es möglich ist aus den PNG Dateien wieder Text zu generieren ist zwei wesentlich Eingenschaften des "ASCII Art" zu verdanken:

1. Es werden nur Zeichen aus dem ASCII-Zeichensatz verwendet, was die Anzahl der nutzbaren Zeichen auf ca. 240 begrenzt.
2. Zur Darstellung der Dateien werden nichtproportionale Schriften verwendet, wodurch jedes Zeichen im resultierenden Bild die gleiche Höhe und Breite hat.

Um nun aus den PNG Dateien wieder Textdateien zu erstellen, ging ich folgendermaßen vor:

• Zunächst wurden einige der NFO-PNGs in viele kleine PNGs aufgeteilt, die jeweils ein Zeichen beinhalteten. In Handarbeit mussten, für jede Schriftart, diese ca. 240 Bilder einmal den jeweiligen ASCII Zeichen zugeordnet werden. Zusätzlich wurde für jedes Bild mit einem Zeichen ein Hash-Wert berechnet. Daraus entstand dann eine Tabelle die jedem ASCII-Zeichen in Bildform (via Hashwert) einen ASCII-Wert zuordnen konnte.
• Anschließend konnte ich mit einer simplen Software beliebige PNG Dateien in die jeweiligen einzelnen Zeichen zerlegen, daraus einen Hash-Wert bilden und über die Tabelle die jeweilige Nummer im ASCII Zeichensatz bestimmen.
• Schließlich wurden die so bestimmen ASCII Zeichen in eine Datei gespeichert und die "ursprüngliche" NFO Datei war rekonstruiert.

Hinweis am Rande: Heutzutage würde man das vermutlich Machine-Learning nennen. ;)

Technik und Performance der Webseite

Eigentlich alle Teile des Projekts habe ich mit PHP umgesetzt. Die Daten lagen in einer MySQL Datenbank.
An einigen Stellen musste ich jedoch von einer Standard PHP/MySQL Anwendung abweichen um eine vernünftige Performance gewährleisten zu können.

Ich habe dieses Projekt als reines Hobby betrieben - weil ich es technisch interessant fand. Dadurch war ich bei der Auswahl der Hardware natürlich etwas eingeschränkt. Je billiger desto besser ;) Oder umgekehrt: Je performanter die Software, desto geringer die Kosten. Zusätzlich war ein 20€ VServer (oder Ähnliches) vor 10 Jahren natürlich lange nicht so leistungsstark wie heute.

Die Release-Datenbank umfasste etwa 4,5 Millionen Einträge. Dazu etwa 400.000 NFO Dateien und eine wenig "Nuke History". Insgesamt war die Datenbank ca. 1GB groß. Heute würde ich die Tabellen vermutlich einfach in den RAM laden und die Seite wäre wunderbar schnell. Vor 10 Jahren, und mit wenig Budget, war das etwas komplizierter.

Sphinx als Suchserver

Um die Datenbank performant durchsuchbar zu machen und das Navigieren durch die Releases (mit verschiedenen Filtern) zu beschleunigen, habe ich neben den MySQL Indexen einen Sphinx Suchserver aufgesetzt. Dieser erzeugte weitere Indexe aus den Daten in der MySQL DB, welche ich dann in PHP verwenden konnte. So konnte ich z.B. bei Paginieren durch eine bestimmte Kategorie von Releases, zunächst die Primärschlüssel der betreffenden Releases aus dem Sphinx-Index anfragen, um dann ein wesentlich performanteres Query auf die MySQL Datenbank fahren zu können.

Gearman und Redis für Usenet Crawler

In den Binary-Gruppen des Usenets kommen tausende neue Beiträge pro Minute hinzu. Selbst nur die Header der neuen Beiträge periodisch zu crawlen, ist mit einem einfachen single threaded PHP Script nicht möglich. Daher habe ich hier auf Gearman gesetzt. Damit kann man relativ einfach "Worker" erstellen, welchen dann parallel an einer Aufgabe arbeiten können. (Ich habe dazu vor Jahren schon mal etwas geschrieben)
Für die Koordination und Kommunikation der Worker habe ich eine Redis Datenbank eingesetzt, was auch recht gut funktionierte.

Abschließende Worte

Nach wie vor finde ich die Technik und Organisation der Warez Szene faszinierend. Relativ einfache und über viele Jahre erprobte Software und Protokolle (IRC, FTP, Usenet, ASCII, ...) wurden und werden hier seit vielen Jahren erfolgreich eingesetzt.
Während der Zeit in der ich dieses Projekt betrieben habe, habe ich technisch extrem viel gelernt. Ich musste mich mit verschieden Protokollen auseinandersetzt, diverse Bots programmieren, performante Software schreiben und vieles mehr. Kurzum: Es hat extrem viel Spass gemacht!

Aufgehört habe ich irgendwann weil es extrem viel "Arbeit" ist hier am Ball zu bleiben. Die ständige Suche nach Pre-Chans, NFO Quellen, u.s.w. nimmt eine Menge Zeit in Anspruch. Man muss in den entsprechenden IRC Channels mitlesen und mit den Leuten in Kontakt bleiben um auf dem "Stand der Dinge" zu bleiben. Die komplette Szene ist zwar einerseits recht "konstant", anderseits aber auch sehr schnelllebig.

Damit schließe ich diesen Text, den ich schon lange einmal schreiben wollte.

Hach ja... Good old times...

Hitze im Dachgeschoss

Seit einiger Zeit wohne ich in Köln in einer Wohnung im obersten Stockwerk. Südseite mit viel Glas sowie ein schwarzes Flachdach sorgen dafür, dass es im Sommer quasi unerträglich heiß wird – erzählt jeder der schon einmal in einer Dachgeschosswohnung gelebt hat. Aber ist das wirklich so? Hat mich mal interessiert, und so kam ich auf die Idee die Temperatur in meiner Wohnung einfach automatisiert zu messen und aufzuzeichnen.

Ich habe nun ein Jahr lang Daten gesammelt und daher nun dieser Jahresrückblick - bzw. eine kleine Auswertung.

Umsetzung

Zunächst habe ich mir überlegt wie man die Temperatur am besten messen und aufzeichnen kann. Natürlich kann man hierfür fertige Gerät wie z.B. eine Netatmo Wetterstation oder Ähnliches kaufen, das fand ich aber zu langweilig und zu teuer. Daher habe ich mich für den DIY Ansatz entschieden und das Ganze mit einem Raspberry Pi Zero W und einem DHT22 Sensor selbst zu basteln.

Die Umsetzung ist extrem simpel und auf diversen Seiten im Netz ausführlich erklärt: Hier ein Beispiel.

Grob zusammengefasst werden 3 der 4 Pins des Sensors mit den den entsprechenden GPIO Ein- und Ausgängen des Raspberry Pies verbunden und die Hardware Seite des Projekts ist fertig. Der Sensor wird glücklicherweise bereits mit entsprechenden Widerständen etc. fertig geliefert.

Software-seitig habe ich die bekannte WiringPi Bibliothek verwendet um Daten der Sensoren auszulesen. Für den DHT22 Sensor gibt es auch hier bereits fertige Lösungen: https://github.com/technion/lol_dht22

Um die Daten nun regelmäßig automatisch auszulesen und zu speichern habe ich mich für Munin entschieden. Dieses Tool nutze ich bereits an vielen anderen Stellen um Servermetriken zentral zu sammeln. Das entsprechende Plugin für die Munin-Node ist in ein paar Zeilen Shell-Script schnell gemacht:

#!/bin/sh

case $1 in
 config)
 cat <<'EOM'
graph_title Temperature
graph_vlabel Celsius
graph_category AM2302
temperature.label Celsius
temperature.label Temperature
temperature.draw AREASTACK
temperature.colour 00FF00
EOM
 exit 0;;
esac

printf "temperature.value "
/usr/local/bin/loldht 7 | grep -i "temperature" | cut -d ' ' -f7

Damit die Daten der Munin-Node regelmäßig von einem zentralen Server angefragt und verarbeitet werden können, muss der Raspberry-Pi irgendwie mit dem Netz verbunden sein. Daher habe ich mir hier für die „W“ Variante des Zeros entschieden.

Den kompletten Aufbau habe ich dann in einem Blumentopf „versteckt“ und so im Raum platziert, dass er nicht direkt hinter einem Fenster in der direkten Sonneneinstrahlung steht.

Auswertung

Nun habe ich ein Jahr lang Temperaturdaten gesammelt. Alle 5 Minuten wurde die aktuelle Raumtemperatur ausgelesen und gespeichert. Daraus habe ich dann jeweils eine Tages-Durchschnittstemperatur errechnet. Diese Daten sieht man auf folgendem Graph:

Nun wollte ich natürlich wissen ob diese Daten ansatzweise korrekt sind und habe Sie daher mit entsprechenden Graphen aus anderen Quellen verglichen:

Der Graph des DWD zeigt ebenfalls tägliche Mittelwerte der Lufttemperatur in Köln. Auf dem Graph von wetter.com sind die Temperaturen nach Min. und Max. Werten getrennt.

Natürlich vergleiche ich hier nun Innen- mit Außentemperaturen, aber der grundsätzlich gleiche Verlauf der Temperatur über das Jahr hinweg ist schön zu erkennen. Besonders gut zu sehen sind die „heißen“ Phasen in diesem Jahr jeweils zu Ende er Monate April, Juni, Juli und August.

Ebenfalls sehr interessant ist die Tatsache, dass die durchschnittliche Temperatur in meiner Wohnung eher dem Graphen mit den maximalen Temperaturen von wetter.com, als den Durschnittstemperaturen des DWD entspricht ;)

Der heißeste Tag des Jahres in meiner Wohnung war übrigens der 26.07.2019 mit einer durchschnittlichen Temperatur von 31,94°C. Dieser fällt genau in den Bereich mit den höchsten Temperaturen der beiden anderen Graphen.

Ich denke also, dass meine Daten halbwegs in Ordnung sind und die ursprüngliche Frage schön beantworten: Ja, in einer Dachgeschosswohnung ist es im Sommer sehr warm, besonders in den Monaten Juni – September. Hier sinkt die durschn. Temperatur kaum noch unter 25°C.

Im nächsten Jahr gibt es dann vielleicht eine Detailauswertung der heissesten Tage oder andere Rekorde. Bis dahin:

Einen guten Rutsch ins neue Jahr.

Leider war es extrem kalt. Daher sind die Fotos eher hastig als mit der nötigen Ruhen entstanden. Hier trozdem ein kleiner Eindruck:

Ich denke für dieses Jahr war es das dann auch mit den Sportevents und ich werde meinem Körper eine Erholungspause gönnen. Im nächsten Jahr geht es dann weiter. Vielleicht ist ja mal wieder ein Halbmarathon drin ;)

Am 21. September 2019 bin ich beim Run of Colours hier in Köln mitgelaufen. Ein relativ kleines, aber toll organisiertes Event rund um den Rheinauhafen. Bonus: Die Erlöse der Veranstaltung werden an die Aidshilfe gespendet. Ich werde versuchen auch im nächsten Jahr wieder dabei zu sein.

Mein Ergebnis in diesem Jahr: 10km in 00:47:40

Als nächstes steht dann am 1. Dezember der Nikolauslauf, ebenfalls hier in Köln, an. Ich habe mich auch hier wieder für die 10km Strecke angemeldet und werde versuchen diese in weniger als 50min zurück zu legen.