Pikchr (gesprochen wie picture) ist eine Sprache zum Zeichnen von Diagrammen, angelehnt an Unix/GNU PIC, aber vereinfacht, sicherer und zugleich erweitert. Aus Pikchr können SVGs generiert werden mit entsprechend erweitertem Markdown-Prozessor oder auf der Kommandozeile mit

fossil pikchr grafik.pc grafik.svg

(bei installiertem Fossil).

fossil kommt aus dem sqlite-Projekt und nutzt sqlite für seine Datenhaltung; es ist einfach zu benutzen, kann mit geringem Aufwand selbst gehostet werden und bietet ein Wiki und ein Ticketsystem.

Die Unterschiede zwischen Fossil und git, insbesondere hinsichtlich des Entwicklungsmodells, sind im Fossil-Wiki gut erläutert.

Fossil ist als (gleichnamiges) Debian-Paket verfügbar.

Übrigens wird Git rebase in der Fossil-Doku gut erklärt – und gleichzeitig erläutert, warum es schädlich und eigentlich überflüssig ist.

Mojo🔥 ist zugleich eine neue Programmiersprache und eine Python-Erweiterung: Es bettet CPython quasi ein, erlaubt aber, kompilierbare Python-ähnliche Programme zu schreiben und dabei auf Hardware-Datentypen zuzugreifen und native Performance zu erreichen. Es bietet Speichersicherheit (wie Rust) und Metaprogramming (wie Nim). Allerdings ist Mojo derzeit nur auf der Entwickler-Website in einer Sandbox verfügbar; es soll aber bald völlig open-sourced werden.

Die Motivation für die Entwicklung von Mojo liegt im Bereich von KI-Anwendungen.

Vergleich mit Nim: https://forum.nim-lang.org/t/10159, https://forum.nim-lang.org/t/10270

Update 2023-09-15: Jetzt kann Mojo auch lokal installiert werden. Allerdings muss man sich auf der Webseite registrieren, und es läuft (bei mir) nicht alles reibungslos. Folgendes habe ich gemacht (auf der Webseite wird die „manuelle Installation“ beschrieben, die hätte ich durchführen sollen):

$ mkdir ~/projects/mojo && cd ~/projects/mojo
$ curl https://get.modular.com | MODULAR_AUTH=<TOKEN> sh -
#   das TOKEN wurde auf der Webseite nach der Registrierung angezeigt
#   das Passwort für sudo wurde abgefragt!
#   eine interaktive Abfrage vom apt install blieb hängen, eine Eingabe war nicht möglich
#   nach ^Z und fg brach der Prozess ab, aber ein deb „modular“ war installiert
$ modular auth <TOKEN>
$ modular install mojo
# -> error: externally-managed-environment
$ python3.11 -m venv --prompt mojo venv-311
$ . venv-311/bin/activate
(mojo)$ pip install -U pip wheel
(mojo)$ modular install mojo
# -> etliche Fehlermeldungen zu Symlinks „File exists“
(mojo)$ ~/.modular/pkg/packages.modular.com_mojo/bin/mojo
Welcome to Mojo! 🔥Expressions are delimited by a blank line.
Type `:mojo help` for further assistance.

Jetzt kann man tatsächlich Mojo laufenlassen:

1> var i = 0
2. while i < 11:
3.     print(i, i*i)
4.     i += 1
5.
0 0
1 1
2 4
3 9
4 16
5 25
6 36
7 49
8 64
9 81
10 100
(Int) i = {
  (index) value = 11
}
5>

Achtung – das ist nicht Python, das ist Mojo, und da gelten andere Regeln! (Und die Cursortasten funktionieren im REPL nicht.) Mit :help bekommt man nützliche Hinweise; z.B. kann man einen Eingabeblock mit %%python beginnen lassen und dann „echte Python-Statements“ eingeben. Allerdings funktioniert das erst einmal nicht („Unable to locate a suitable libpython, please set MOJO_PYTHON_LIBRARY“).

Also:

(mojo)$ export MOJO_PYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython3.11.so
(mojo)$ ln -s ~/.modular/pkg/packages.modular.com_mojo/bin/mojo \
        venv-311/bin/mojo
(mojo)$ mojo
Welcome to Mojo! 🔥Expressions are delimited by a blank line.
Type `:mojo help` for further assistance.
1> %%python
2. import sys
3. print(sys.version)
4.
3.11.5 (main, Aug 29 2023, 15:31:31) [GCC 13.2.0]
(PythonObject) sys = {
  (PyObjectPtr) py_object = {
    (pointer<scalar<si8>>) value = 0x00007fd9b9b7aca0
  }
}
4> :q

Nun ein Versuch mit einem (abgespeckten) Python-Beispielprogramm:

(mojo)$ mojo iq.mojo
…
(mojo)$ mojo build iq.mojo
(mojo)$ ./iq
(mojo)$ time ./iq.py  # -> 0.169s
(mojo)$ time ./iq     # -> 0.002s

(Seltsamerweise sind die Ergebnisse zunehmend verschieden, vermutlich durch unterschiedliche Implementation der Bibliotheksroutinen (oder unterschiedliche Datenformate??).

Das Paket django-pgcrypto erlaubt die Nutzung der PostgreSQL-Erweiterung pgcrypto von Django aus. Damit sind verschlüsselte Datenbankfelder weitgehend transparent nutzbar; ein Hashcode (bzw. HMAC) kann automatisch ein einem anderen Feld abgelegt werden, um z.B. unique-Constraints zu ermöglichen. Aber aufpassen: Die Ver- und Entschlüsselung wird auf dem Datenbankserver ausgeführt; hierzu werden die Passphrasen im Klartext übertragen – man muss also dem Server grundsätzlich vertrauen. Andernfalls kann nur im Clientcode „zu Fuß“ ver- und entschlüsselt werden.

Lobster ist eine interessante Programmiersprache mit modernen Konzepten (und vielen Ähnlichkeiten mit Python, Nim, Rust). Allerdings ist sie stark fokussiert auf Spieleentwicklung, daher sind einige Aspekte nicht sehr weit entwickelt. Sie existiert seit 2013 und wurde von Wouter van Oortmerssen in erster Linie für seinen eigenen Bedarf geschrieben.

Lobster ist ein Open-Source-Projekt auf GitHub.

“Code to the Moon” stellt Lobster in einem kurzen, aber informativen Video vor. Auf HN gibt es eine Diskussion zur Sprache und ihren Konzepten.

Caddy ist ein in Go geschriebener Webserver, der mit sehr einfacher Konfiguration als statischer Webserver und als Reverse proxy, aber auch als allgemeiner Go-Anwendungsserver eingesetzt werden kann.

Er kann über ein spezielles Dateiformat (“caddyfile”), aber auch per JSON-Datei oder über API-Aufrufe konfiguriert werden. Wenn ein Domainname spezifiziert (und dieser per DNS verbreitet und aus dem Internet erreichbar gemacht) wird, besorgt Caddy sich automatisch ein Letsencrypt-Zertifikat und bietet darüber HTTPS an.

Mit folgenden Schritten kann Caddy auf dem Localhost eingerichtet werden, um ein Nikola-Blog als Vorschau anzuzeigen:

1. (auf einem Debian-System) das Paket caddy installieren

2. die Datei /etc/caddy/Caddyfile mit folgendem Inhalt versehen:

   :8088 {
           # Enable the static file server.
           file_server * {
                   root /home/meinekennung/projects/nikola/output
           }
   }

3. Caddy mit der neuen Konfiguration laufen lassen:

   caddy reload --config /etc/caddy/Caddyfile

4. ein Browserfenster auf localhost:8088 öffnen und staunen

Unter https://caddyserver.com/docs/ gibt es eine ausführliche Dokumentation zu Caddy.

OpenSnitch ist eine lokale Application Firewall (mit GUI, speziell für Workstations geeignet), die anwendungspezifisch Verbindungen filtert und auch als Adblocker fungieren kann.

Wenn eine neuartige ausgehende Verbindung eines Programms erkannt wird, fragt OpenSnitch den Benutzer, ob diese Verbindung angenommen oder abgelehnt werden soll (nach einem Timeout wird eine wählbare Standardreaktion ausgeführt). Der Benutzer kann auswählen, ob die Portnummer, die Zieladresse, die Benutzerkennung, das Programm oder eine Kombination dieser Kriterien für ein zukünftiges Blockieren verwendet werden sollen.

Im GUI kann man die ausgehenden Verbindungen live kontrollieren und nach verschiedenen Merkmalen durchsuchen.

Außerdem kann OpenSnitch systemweit Domains blockieren (mit Listen von Domainnamen, IP-Adressen oder regulären Ausdrücken).

In Debian testing bzw. experimental gibt es derzeit drei Pakete hierzu:

• opensnitch (die eigentliche Firewall),

• python3-opensnitch-ui mit dem GUI,

• opensnitch-ebpf-modules mit eBPF-Filtermodulen für effizientere Filterung.

Ich habe es probeweise installiert; Beobachtungen:

• Anfangs kommen (nach dem Start des GUI) häufige Popups, die nach der Zulässigkeit einer Verbindung fragen. Das kann natürlich nerven.

• Die damit erzeugten Regeln sind temporär (für die laufende Systemsitzung). Es ist nicht offensichtlich, wie die Regeln einen Neustart überdauern könnten.

• Es ist grundsätzlich schon interessant, was für Verbindungsaufnahmen so stattfinden. Aber gänzlich Unerwartetes war nicht dabei.

Django-Unicorn ist eine Django-Erweiterung, die es ermöglicht, reaktive Komponenten direkt in Django-Templates einzubetten. Diese können „eigenständig“ AJAX-Aufrufe ausführen und das DOM der gerade geladenen Seite aktualisieren.

Bei RealPython gibt es einen Artikel zu Installation und Initialisierung von IPython, der einige nützliche Tips enthält.

Anmerkungen dazu:

• Wenn man ohnehin mit einem virtuellen Environment (z. B. für eigene Software) arbeitet, braucht man nur ipython dort hinein zu installieren.

• Bei vielen Linux-Distributionen kann IPython als Paket installiert werden (Debian: ipython3).

• Ansonsten ist anstelle des angegebenen Befehls zur Installation von IPython ein virtuelles Environment sinnvoller:

  $ python3 -m venv --prompt ipython ~/venv_ipython
  $ . ~/venv_ipython/bin/activate

  Anstelle des Prompts ipython und des Verzeichnisnamens ~/venv_ipython kann, je nach Geschmack, natürlich was Schöneres gewählt werden.