Liebes BLOG Tagebuch!
Man sagt:
Was wir wissen, ist ein Tropfen, was wir nicht wissen, ist ein Ozean.
(von Isaac Newton oder aus
Dark)
Ich muss heute also noch sehr viel trinken. 😉
Diese Seite benutzt KEINE Cookies! Wozu auch?
Hier geht es NICHT um Browser-Kekse, Werbung und Google-Spionage, SONDERN um Programmierung, Hardware, Software und was mir sonst noch so im Leben passiert ist!
Das “RPi-PowerPack” ist ein Board mit einem LiPo Akku, der einen Raspberry PI 2 und 3 B eine Zeit lang bestromen kann.
Doch diese Board hat einen unguten Fehler:
Beim Umschalten zwischen externem Aufladen und reinem Akkubetrieb,
gibt es einen kurzen Stromaussetzer, der einen ungewollten Reboot
(und eventuell Datenverlust) einleitet.
Unit tests sind in der Entwicklung ein notwendiges Übel, weil die Vorgesetzten es als Funktionsbeweis haben wollen.
So habe ich es viele Jahre gesehen und auch heute erscheinen mir manche Testanforderungen nur als lästige Bürokratie, die selten wirklich etwas “abtestet”.
Doch nun beweist mir meine eigene Fehlbarkeit, dass Unit Tests IMMER eine Existenzberechtigung haben.
Stromausfälle sind in Wien verdammt selten. Das passiert vielleicht alle 10 Jahre mal, wenn ein Stromzähler getauscht werden muss. Ansonsten kann ich mich an keine Unterbrechung erinnern.
Aber … was wäre wenn? Und wäre es nicht toll, wenn man ein Gerät an einen anderen Ort versetzen kann ohne seinen Betrieb zu unterbrechen?
Die Lösung heißt UPS (Uninterrupted Power Supply) bzw. Unterbrechungsfrei Stromversorgung.
Schriftarten (auch “Fonts” genannt) sind heute eine komplexe Sache. Alles ist vektorisiert und die Zeichen orientieren sich an mehreren Linien um Schleifen Punkte und Striche auf der richtigen Höhe im Verhältnis zu den anderen Zeichen zu setzen.
Früher hatten wir feste Schriftarten, die es in ein paar Größen gab und in
denen Zeichen für Zeichen und Pixel für Pixel fix gespeichert waren.
Denn sowas kann man nämlich sehr leicht selbst implementieren.
Ich dachte eigentlich, dass meine alten IDE (P-ATA oder auch ATAPI) Festplatten schon alle tot sind. Aber stimmt nicht, die meisten Festplatten funktionieren seit tatsächlich noch seit 15 Jahren.
Trotzdem ersetze ich die unerträglich lauten und langsamen Teile durch Flash-Speicher Varianten.
OpenWatcom eröffnet mir also heute im Jahr 2021 ein Tor 30 Jahre zurück in die Vergangenheit, denn der Compiler unterstützt auch heute noch MS-DOS und Windows 3.x als Zielplattform.
Auf was muss man also achten, wenn man Programme für DOS schreiben will?
3 Jahre hat diese Seite jetzt auf dem Buckel. Und ich glaube, damit ist es zum zeitlich längste Webprojekt geworden, an dem ich je durchgehend aktiv gearbeitet habe.
Und langsam komme ich wieder an die Grenze des Erträglichen im
aktiven Testbetrieb mit jekyll serve.
Seit August steht der Windows Server 2022 zur Installation bereit. Basierend auf dem Kernel 21/H2 sollte er eigentlich Server 2021 heißen, aber das war ja bei Server 2019 mit 18/09 damals auch nicht anders.
Und ich möchte nun meinen Domain Controller von Server 2016 auf den “letzten Stand” bringen. Na mal sehen, ob Microsoft das hinbekommt.
Der OpenWatcom C/C++ Compiler zählt nicht nur zu den ältesten seiner Art, er unterstützt auch noch die alten Plattformen wie Windows 3.X, OS/2 und DOS neben Linux und WinNT.
Und er ist wahrlich “antiquiert” in Sachen Standards und std Support.
Kurz gesagt: Genau die richtige Umgebung für meine Experimente.
Java,
Ruby,
Python,
dotNet … also, wie es aussieht, gibt
es heute keinen einzigen Build-Server, der ordentlich (sprich effizient)
programmiert ist, also in C
oder C++.
Damit ist von GitLab über
Jenkins bis zu
TeamCity
keiner geeignet auf meinen Intel Atom
Servern zu Hause zu laufen.
Es kann doch nicht so schwer sein, ein CMake Build in Docker selbst anzustoßen. Also bauen wir uns das selbst, so wie es sich gehört.
Was war das für eine tolle Zeit, als man beim Einsetzen einer ISA Karte eine Bluttransfusion brauchte, weil man sich an den Lötkontakten und den messerscharfen unbehandelten Platinenkanten die halbe Hand zerfetzt hatte.
Ja das war, als ich meinen damals schon veralten 486er PC mit Erweiterungskarten stückweise “nutzbar” machen wollte.
Aus Fehlern lernt man bekanntlich am meisten, und deshalb möchte ich einen
meiner Irrtümer hier schildern.
Es begann mit der Idee:
Man könnte doch einen Stack durch diverse Funktionsaufrufe aufblasen und dann per
setjmp()“Einsprungpunkte” in den Stack setzen. Wenn man dann noch einen Scheduler schreibt, der perlongjmp()zwischen diesen Einsprungpunkten auswählen kann, dann hätte man:
Eine rein generische C Implementierung für Koroutinen.
Mit C++20 werden
Koroutinen
(#include <coroutine>) in den Sprachstandard aufgenommen.
Mich wundert aber, dass im nächsten C Standard (C2x)
von Koroutinen keine Rede ist.
Also habe ich mich mal in den Betriebssystemen umgesehen, wie man Koroutinen selbst implementieren kann.
Da denkt man, statische Bibliotheken (static libraries) wären stets “privat” für ihre Nutzer und nur dynamische gelinkt Bibliotheken (shared libraries) würden ihre Dienstleistungsangebot öffentlich preisgeben.
Doch nicht so beim GCC.
Denn der spielt gerne Twitter und teilt auch Privates quer über
Modulgrenzen hinweg, ohne dass jemand danach gefragt hätte.
Der “exklusive” Zugriff auf Dateien spaltet die Nation der Entwickler, wenn es darum geht, wie, wann und wo dieses Kontrollmittel eingesetzt werden soll.
Dateisperren sind eine recht alte Erfindung und deshalb wundert es mich, wie uneinheitlich das Thema behandelt wurde.
opengate.at.