Mirror here:
https://blog.davidshoon.org/draichess/
Username: open
Password: sesame
It's got some goodies from the naughties. Archive.org doesn't have it all, so I've published the entirety of the website on my blog.
NB: You'll need IPv6 to access blog.davidshoon.org.
In computing, a buffer is meant to be a place of order — a defined space, a promise of containment. Data comes in, it fits neatly, it moves on.
When it works, it’s invisible.
A buffer overflow happens when more data is written than the space was designed to hold. It’s a simple arithmetic mistake, yet it tells a deeper story: that expectations and reality have drifted apart. Somewhere, a promise was made that the system could handle it. It couldn’t.
Every buffer has boundaries. They aren’t failures of imagination; they’re expressions of discipline.
Good code checks its inputs — not because it doubts the data, but because it respects the container.
The trouble begins when that respect erodes. A few extra bytes here, a little exception there — it all seems harmless. After all, the system hasn’t crashed yet. The logs are clean. Things appear to be running smoothly.
Until, suddenly, they aren’t.
Overflows rarely announce themselves immediately. They don’t explode in a dramatic cascade of errors. Instead, they leak — a value overwritten here, a flag flipped there. Something subtle, deniable.
By the time the failure becomes visible, the origin is hard to find. Everyone points somewhere else in the code. It’s difficult to assign blame when the system’s integrity has been quietly compromised over time.
Sometimes the corruption spreads. Adjacent structures — those meant to hold something entirely different — begin to behave strangely. Functions misfire. Memory turns unreliable. Trust becomes guesswork.
Developers often overestimate how much a buffer can hold. Maybe they assume the input will stay small. Maybe they’ve handled bigger loads before and assume it’ll be fine again. Maybe the warnings were commented out long ago — "temporary," of course.
But capacity isn’t about confidence. It’s about measurement, and respect for constraints that aren’t negotiable. Once a buffer starts stretching to accommodate everything asked of it, something essential has already gone wrong.
Resilient systems anticipate excess. They install boundaries not as barriers, but as protections for what’s inside.
They check lengths before trusting input. They reject what doesn’t fit. They log, they pause, they push back.
The best code doesn’t aspire to handle *everything*. It knows what it’s for, and stops there.
After an overflow, cleanup is difficult. You can patch the code, harden the interface, maybe even redesign the structure. But the memory once corrupted can leave traces — artifacts of what used to be reliable.
Over time, systems that keep overflowing develop a kind of brittleness. Patches pile up. Documentation grows vague. No one remembers why certain limits exist, only that removing them “breaks something.”
Healthy systems are unglamorous. They validate, reject, and defer. They leave a little space unused — not wastefully, but wisely.
It’s easy to admire a program that takes on more than it was meant to, that runs hot and appears to handle it all.
But real stability — the quiet kind — comes from knowing precisely where the edges are, and refusing to cross them.
Because when a system fails, it’s rarely because it didn’t have enough capacity.
It’s because it didn’t respect the capacity it already had.
From the Systems Desk
Author: Anonymous (but probably someone who's seen a few core dumps, both digital and otherwise).
If ZZimps charges $0.02 per dollar for every DLC asset in an indie game, then:
* Assuming 200 DLC assets that can be sold across all indie games
* 4000 players in each indie game willing to buy all 200 DLC assets
* 500 indie games being developed each year
Then ZZimps gets a recurring yearly revenue of = 200 x 4000 x 500 x 0.02 = $8,000,000.
DLC asset creators getting $0.49 per dollar for every DLC asset. And Indie developers get $0.49 per dollar for every DLC asset.
Then:
* Assuming DLC assets get sold on all 500 indie games:
* DLC asset creators get = 0.49 x 4000 x 500 = $980,000 per asset, per year. If all 200 assets are theirs, then their total revenue is: $196,000,000 / year.
As for indie game developers:
* Assuming all 200 DLC assets are purchased by all 4000 players on their game:
* Indie game developers get = 0.49 x 4000 x 200 = $392,000 per game.
$392k is a big improvement in revenue compared to the usual payment for the game, which is usually $5 to $10 per game per player (i.e. $40,000 per game at $10 each).
But again, all of this assumes the DLC market has the capability to charge roughly $200 worth of DLC asset per Indie game, which may or may not be realistic.
It's a tough market for Indie developers, but ZZimps may provide some help.
As you can see though, the market is for DLC asset creators. However, monetizing DLC assets is difficult, as 3D mesh markets generally don't charge for "each DLC download" but rather, for each 3D model.
What does it take to be a DLC asset creator with ZZimps?
You first need a 3D mesh. But then you need to write some code that controls the mesh and has logic which pertains to the DLC character, such as health statistics, inventory, etc.
This code logic is written in such a way, that using ZZimps DLC plugin, it will work in as many game engines ZZimps has interfaces for. It will be digitally signed code, so players will know it's secure.
The ecosystem for Indie game developers is maturing, and ZZimps is trying to encourage it further.
If you have any further questions, feel free to contact me via ZZimps (www.zzimps.com).
When you create a piece of code, it's like a cookie cutter template. You can replicate the software very easily, but if there's an error in the template, the error propagates to every copy of the software.
You also end up with a bad reputation.
That's why when you create code, quality must come first. Quantity (lines of code, features, etc) come second, because it doesn't matter how many features or lines of code you have, if ONE single line of code has an error, that's a potential show-stopper.
Here's where DRUDGET'S cybersecurity software comes in. You might write sloppy C/C++ code where you don't check for buffer overflows. It doesn't matter, you pray the mitigations will catch it. It doesn't. Unless you use MMU (memory management unit) based mitigations. That's what DRUDGET's heap buffer overflow protector uses.
Again, DRUDGET's code wouldn't be necessary if you wrote perfect code the first time around. DRUDGET catches other things too: memory leaks, deadlocks, all caught and solved; garbage collection for memory leaks, and deadlock detector plus real-time deadlock workaround.
Unfortunately though, none of this is useful for "critical" applications that demand life-safety first: DRUDGET's software can only do so much. Embedded firmware running in some RTOS that is used in a medical device, or auto-pilot vehicle, needs to be written with QUALITY in mind.
That's why DRUDGET also has a source code auditing service. We audit your source code to ensure it complies with standards and use automated tools, that we crafted ourselves, as well as manual intervention, to secure your source code.
(As an example using our auditing tool, we found a flaw in Apache: CVE-2023-31122. https://ubuntu.com/security/CVE-2023-31122 - CVSS 3 Severity Score of 7.5 "high". I wanted to find a flaw in an open source application, and it took less than a minute to find it.)
So if you write C/C++ code, and your reputation is on the line, go visit DRUDGET (https://www.drudget.com.au) and send us your details. Our software makes QUALITY code easier to manufacture.
There's over a billion mobile phones out there.
I could license Drudget's cybersecurity software for $1 each -- securing mobile phones against memory corruption hacking.
That's a one billion dollar TAM. No joke. One billion dollars. Or more. I could be a billionaire.
But I haven't pushed it yet. I know I should, and I have been worrying about getting enough money for my daily needs instead, so I've been focusing on my day job at a SaaS company.
I don't even know how to get mobile phone companies to sign on. I need a sales guru.
So here's the kicker: I'm hiring a sales guru. But I can't afford to pay you a salary. Instead you will get a commission based off the licensing that you're able to get signed up. And equity. You get what you earn.
The product is already made by me, and works on Linux based operating systems, such as Android. It secures C/C++ apps on your phone against memory corruption bugs (i.e. buffer overflows, use after free, double free, etc). Even prevents memory leaks.
There's literally nothing you need to do; except sign contracts with big companies like Samsung, Nokia, Motorola, etc.
Also, there's a cloud self-healing code, which prevents hackers from successfully crashing web servers (with buffer overflows, etc) and exploiting them. It's like a WAF (web application firewall) except it uses IPC (inter-process communication) to figure out what to do. It knows what was sent to the server, and adjusts a ban-list accordingly, and re-adjusts buffers on the fly.
In the future (i.e. with additional funding), and with Generative AI, it could even fix the code in the open source web server. Otherwise it could patch the web server binary in real-time, using process injection techniques.
The self-healing cloud market is even bigger than the mobile phone market, because server-side security is paramount to having a secure endpoint for all your devices to talk to. Imagine the amount of tech support calls that would be saved with self-healing cloud code.
Alas, I still worry about my daily bread, so I cannot pursue this dream. If I got VC (venture capital) funded that would be a different story, but Drudget is a self-funded venture, and I don't have the time to travel around to find VC funding.
So I'm also hiring a VC fund manager. Again, no salary, but equity in the company. Obviously the more you can attract investors, the more you get as equity.
Summary: Hiring a sales guru, and VC fund manager. No salary. Do it only at your own risk to financial health. Apply via https://www.drudget.com.au.
NB: I'm pretty stressed out right now, due to my day job, so please don't waste my time. Just apply by sending your CV and a cover letter, preferably in markdown (.md) format.
For example, if I was given a ticket for a requirement, where I say y = x + 2.
Then the code I write:
```
int func(int x)
{
return x + 2;
}
```
Now I'm given a new requirement, where it's supposed to double the input, and chain that up with the original function.
```
int func2(int x)
{
return 2 * func(x);
}
```
Now I'm given a third requirement, which is to substract 4 from the input, and it's supposed to chain up to func2.
```
int func3(int x)
{
return func2(x) - 4;
}
```
Now I'm given a fourth requirement, which is to substract 2x of the input from the chained function.
```
int func4(int x)
{
return func3(x) - (2 * x);
}
```
If I put all the code together, and run it:
```
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int func(int x)
{
return x + 2;
}
int func2(int x)
{
return 2 * func(x);
}
int func3(int x)
{
return func2(x) - 4;
}
int func4(int x)
{
return func3(x) - (2 * x);
}
int main()
{
int i;
for (i = 0; i < 256; i++) {
printf("%d\n", func4(i));
}
}
```
I will get all zeroes.
If I simply refactored the code, I would get:
```
int refactored(int x)
{
return 0;
}
```
This is why AGILE development sucks, and never gives the simplest possible code to do a particular task, unless you refactor it constantly.
Because you will always get "new" requirements, and some of them are conflicting with each other, or cancel each other out, and if you don't refactor to remove these conflicting requirements, they linger in code as bloat.
Strictly speaking, waterfall designers "know" what they want and would've gone straight towards "refactored(int x)", if they have enough insight (and deep knowledge of the task). This is why they still can't be beaten, when it comes to designing good software or hardware.
AGILE development is for babies who don't know what they're doing, and they're guessing every step of the way.
