Post #4061704

2026-07-24 11:36 UTC

@mohs@climatejustice.social Redis war das Werk von Salvatore "antirez" Sanfilippo und das erste Redis waren 300 Zeilen Tcl mit dem Namen LMDB. Das Protokoll und das Event-Driven Single-Thread Design standen damals schon fest. Sanfilippo hat es dann in C neu geschrieben und Redis genannt. redis.c waren einige tausend Zeilen C in einer einzigen Datei. Für Persistenz hat es sich einmal geforkt, und der Kindprozess hat dann seinen Speicher auf Disk erbrochen. Für kurze Zeit hat die Datenbank bis zu zweimal den gesamten Speicher belegt (das hing sehr von der Change Rate im Speicher ab). Das aktuelle Redis (seit 2.4) wurde refactored. Es gibt aber immer noch viele C-Dateien im Code, die viele tausend kloc gros sind. Ich wette, daß die Codebasis immer noch weit entfernt von best oder good practice ist.

Replies (5)

@defnull@chaos.social 2026-07-24 12:12

@isotopp@infosec.exchange @mohs@climatejustice.social Redis hängt ja normalerweise auch nicht am bösen Netz sondern spricht nur mit 'vertrauenswürdigen' Clients in der selben trust-domain. Ich hab jetzt nicht alles durchgeschaut, aber lass mich raten: Alle diese Exploits benötigen direkten Zugriff auf den socket? Sind natürlich trotzdem Bugs aber ... meh.

Open ##4062493
@mohs@climatejustice.social 2026-07-24 11:40

@isotopp@infosec.exchange ich bin auf einmal ganz froh, nie ernsthaft in die verlegenheit gekommen zu sein das aktiv zu benutzen.

Open ##4089311
@burningTyger@nrw.social 2026-07-24 14:16

@isotopp@infosec.exchange @mohs@climatejustice.social Vielleicht liegts daran, dass antirez mittlerweile selber den Code von KI schreiben lässt? Ich weiß es nicht.

Open ##4089313
@hillu@infosec.exchange 2026-07-25 17:07

und der Kindprozess hat dann seinen Speicher auf Disk erbrochen @isotopp@infosec.exchange ich mag Deine einfachen bildhaften Erklärungen zur Funktionsweise von Software.

Open ##4101394
@ploppy@mastodon.social 2026-07-25 23:27

@isotopp@infosec.exchange @mohs@climatejustice.social Ich kenne die Code-Basis nicht, aber vermutlich haben sie geforkt um eine unveränderliche Kopie zu haben, während der Hauptprozess weiter arbeiten kann. Dann verwenden (unter Linux) beide Prozesse dieselben Speicher-Pages. Die Pages werden erst dupliziert, wenn einer der beiden Prozess darauf schreiben will. Also nur die Pages, die während des Speicherns verändert werden, werden auch tatsächlich doppelt gehalten.

Open ##4101395