DuckDB ist eine moderne, schnelle und vielseitige Datenbankimplementierung, die von einem niederländischen Team federführend als Open-Source-Software entwickelt wird. Heute (!) gibt es nun endlich eine Erweiterung dazu (EendDB, eend ist das niederländische Äquivalent zu duck), die eine passende Lokalisierung der ansonsten am Englischen orientierten Abfragesprache SQL bereitstellt. Nach der Installation von DuckDB – wenn noch nicht vorhanden – mit

curl https://install.duckdb.org | sh
ln -s ~/.duckdb/cli/latest/duckdb ~/.local/bin/duckdb

kann man die EendDB-Erweiterung sehr einfach laden und sofort benutzen:

$ duckdb
DuckDB v1.5.1 (Variegata)
Enter ".help" for usage hints.
memory D INSTALL eenddb FROM community;
memory D load eenddb;
memory D CALL enable_dutch_parser();
┌─────────┐
│ success │
│ boolean │
└─────────┘
  0 rows
memory D MAAK TABEL eenden (id GEHEEL_GETAL, naam TEKST, gewicht KOMMAGETAL);
memory D TOEVOEGEN AAN eenden WAARDEN (1, 'Donald', 1.2), (2, 'Daffy', 1.5),
         (3, 'Dagobert', 3.7);
memory D SELECTEER * VAN eenden WAARBIJ gewicht > 1.3 VOLGORDE PER naam;
┌───────┬──────────┬─────────┐
│  id   │   naam   │ gewicht │
│ int32 │ varchar  │  float  │
├───────┼──────────┼─────────┤
│     2 │ Daffy    │     1.5 │
│     3 │ Dagobert │     3.7 │
└───────┴──────────┴─────────┘
memory D .q
$

Bleibt zu hoffen, dass nun auch deutsche, vielleicht sogar bayerische oder rheinische Lokalisierungen in Angriff genommen werden (TU INFÜJEN, ERKLÄR MISCH, ROLLE RÜCKWÄRTS).

Anscheinend sind zahlreiche Nutzer dazu übergegangen, sich mit einer „Cooldown“-Frist gegen bösartig manipulierte Softwarepakete zu schützen, also neue Pakete erst einzusetzen, wenn eine Woche lang keine Probleme bekanntgeworden sind. Darauf reagieren nun die Urheber der Schadsoftware: Offenbar werden einige der bösartigen Payloads nun erst nach einigen Tagen aktiv – wenn der Cooldown-Schutz nicht mehr wirkt …

Zur Zeit werden auch andere mögliche Abwehrmaßnahmen diskutiert, beispielsweise die Überprüfung hochgeladener Software auf verdächtige große Binärdateien (Blobs). Mal sehen, wer das Wettrennen gewinnt; einstweilen sollte man mit Versionsupgrades vorsichtig sein.

Diese Vorsicht muss sich (einstweilen??) nicht auf Pakete der gängigen Linux-Distributionen erstrecken, da deren Aktualisierungen wohl noch gut genug von den Teams kontrolliert werden.

Ein Blog-Post berichtet von guten (beeindruckenden!) Erfahrungen mit Vibe-Coding in Go und erklärt, weshalb der Autor keine Chance sieht, mit Python oder Rust ähnlich produktiv zu sein.

Astral ist die Firma, die die (aus gutem Grund inzwischen sehr beliebten) Python-Tools uv, ruff und ty entwickelt und entsprechende Kompetenz in Rust-basierter Python-Software aufgebaut hat. Sie war risikokapitalfinanziert und ist jetzt von OpenAI, der Firma hinter ChatGPT und DALL-E, übernommen worden.

Über mögliche Auswirkungen auf das Python-Universum schreibt Simon Willison in seinem Blog. Es scheint so, als müsste man sich wegen der Nutzung der Astral-Tools (einstweilen) keine Sorgen machen …

Immer wieder wird Software entdeckt, beispielsweise auf GitHub, die manipuliert und mit Hintertüren versehen ist, durch die Bösewichte die Kontrolle über jeden Rechner erlangen können, auf dem die Software läuft. Durch solche Malware kann man auch betroffen sein, wenn man für seine eigene Python-Software die Paketabhängigkeiten aktualisiert – und das vielleicht gerade deshalb, weil man durch neuere Pakete Fehler in früheren Versionen beheben lassen will.

Gerade jetzt ist das Python-Paket LiteLLM als kompromittiert aufgefallen, das in der Version 1.82.8 SSH-Keys, Zugangsdaten, Krypto-Börsen etc. geklaut hat.

Deshalb gehen manche Entwickler und Admins dazu über, nicht die neuesten Versionen der Abhängigkeiten zu benutzen, sondern ein paar Tage abzuwarten, ob in der Zwischenzeit Probleme erkannt werden.

Einige Subkommandos von uv haben eine Option --exclude-newer (z.B. run <https://docs.astral.sh/uv/reference/cli/#uv-run>_), mit der Paketversionen, die neuer als ein bestimmtes Datum oder ein Zeitraum ('1 week') sind, von der Auflösung von Abhängigkeiten ausgeschlossen werden können. (Stattdessen kann global die Variable UV_EXCLUDE_NEWER auf einen geeigneten Wert gesetzt werden.)

Dieses Feature ist für reproduzierbare Builds gedacht, kann aber auch zum Dependency Cooling genutzt werden, um Probleme mit solchen Malware-Paketen zu vermeiden.

Wenn man im Firefox mehrere Webseiten einer Site „komplett“ (in einem dafür eigens angelegten Unterverzeichnis) speichert, legt er zusätzlich zu einer HTML-Datei pro Seite jeweils ein Verzeichnis mit den verlinkten Dateien an. Dadurch entstehen meist zahlreiche Kopien derselben JS- und CSS-Dateien, Hintergrund- oder Titelbilder usw. usf., die unnötig Platz beanspruchen. Wie kann man diese Daten platzsparender speichern?

Das Programm rdfind (das z.B. für Debian-Systeme als gleichnamiges Paket existiert) kann helfen: Man wechselt in das Verzeichnis, in dem die Downloads liegen, und ruft es zunächst im dry-run-Modus auf:

rdfind -dryrun true -makehardlinks true .

Wenn die Ausgabe plausibel erscheint, klopft man dreimal auf Holz und lässt es im Normalmodus laufen:

rdfind -makehardlinks true .

Es gibt einige Informationen über den Ablauf aus und teilt u.a. mit, wieviel Speicherplatz eingespart wurde, indem die Dateiduplikate durch Hardlinks ersetzt wurden. Das heißt, in jedem Seitenverzeichnis sind nach wie vor alle Dateien vorhanden, aber identische Dateien sind nur einmal im Dateisystem gespeichert, alle Kopien verweisen auf denselben Datenbereich. Löscht man später einzelne Verzeichnisse, so bleiben die Daten so lange erhalten, bis die letzte Referenz (der letzte Hardlink) gelöscht wurde – genau so, wie man es braucht.

Je nachdem, welches Backup-Tool man verwendet (hoffentlich überhaupt eines!), kann es sein, dass dieses die Hardlinks nicht berücksichtigt und die Dateien pro Link einmal auf das Backup-Medium kopiert. Dadurch kann sich der Speicherplatzbedarf der Backups unerwartet vergrößern. Falls das Tool selbst dedupliziert, dürfte dieser Effekt nicht auftreten.

Einer umfangreichen Recherche zufolge hat Meta viele Millionen $$ und mehr als 80 Lobbyisten eingesetzt, um Google und Apple mit ihren App-Stores für eine Altersverifikation im Internet verantwortlich zu machen – und selbst, mit seinen Social-Media-Angeboten, damit keinen Aufwand zu haben.

LWN macht darauf aufmerksam, zumal in einigen US-Bundesstaaten schon (offenbar als Ergebnis dieser Lobbyarbeiten) entsprechende Gesetze verabschiedet wurden. Dabei soll die Altersverifikation, natürlich verbunden mit biometrischer Identifikation der Nutzer, vom Betriebssystem erzwungen werden. Dies wäre nicht nur eine großartige Basis für eine totale Überwachung aller Internetaktivitäten der ganzen Bevölkerung (Big Brother lässt grüßen!), sondern womöglich auch das Ende freier Betriebssystemsoftware.

Sollten die Internetaktivitäten Minderjähriger nicht am besten von ihren Eltern kontrolliert (und mitverantwortet) werden? Vielleicht durch administrative Einstellungen im System? Kinder können auch ohne „Root-Rechte“ ein Smartphone, ein Tablet oder einen Laptop / PC sinnvoll für Schul- und Freizeitzwecke nutzen und dabei Medienkompetenz erwerben …

Update: Ein Artikel von The Register behandelt ebenfalls dieses Thema und die Auswirkungen auf Linux.

Einige Subkommandos von uv haben eine Option --exclude-newer (z.B. run), mit der Paketversionen, die neuer als ein bestimmtes Datum oder ein Zeitraum ('1 week') sind, von der Auflösung von Abhängigkeiten ausgeschlossen werden können. (Stattdessen kann global die Variable UV_EXCLUDE_NEWER auf einen geeigneten Wert gesetzt werden.)

Dieses Feature ist für reproduzierbare Builds gedacht, kann aber auch zum Dependency Cooling genutzt werden, um Probleme mit Malware-Paketen zu vermeiden. (Der verlinkte Artikel beschreibt, wie man diese Funktionalität mit pip erreichen kann, das sie noch nicht voll unterstützt.)

Anscheinend kaum noch jemand. Jedenfalls geht es schief, wenn man es als normaler User (mit k3b) versucht – es wird ein Fehler von wodim gemeldet, das keinen ausreichend großen mmap machen darf (Debian testing; Problem ist schon länger bekannt, siehe diesen Thread von 2018 im Ubuntu-Bugtracker).

Mit dem Kommando sudo chmod u+s /usr/bin/wodim lässt sich das Problem auf die Schnelle lösen.

Nimmt man dieses (hoffentlich nur geringe) Sicherheitsrisiko in Kauf, steht dem Brennen auch von altmodischen Audio-CDs nichts mehr im Weg, und die Weihnachtslieder können vom CD-Spieler kommen. Frohe Weihnachten!

… unter diesem Filmtitel als Überschrift enthält seit Python 3.8 die Freigabemitteilung (fast) jeder Python-Version einen Abschnitt mit Fun facts.

Hugo van Kemenade stellt in seinem Blogpost die einzelnen Themen vor und geht ausführlich auf die zu den 3.14er Releases gehörenden (und von ihm verfassten) Artikel ein, die sich alle mit interessanten Aspekten rund um π beschäftigen.