Skip to content

Instantly share code, notes, and snippets.

View rmcdaniel's full-sized avatar

Richard McDaniel rmcdaniel

  • Huntsville, AL
View GitHub Profile
@rmcdaniel
rmcdaniel / published27-1.25-r1-after.tsv
Last active September 29, 2026 15:12
Server 2.4.27 exact published image: fixed-envelope load, readiness, size and recovery evidence
server-1 180559842 79843328 0 0
worker-1 4471511 51138560 0 0
mysql-1 90394664 616513536 0 0
redis-1 9437839 5730304 0 0
sdk-worker-1 1201105 18657280 0 0
sdk-worker-2 1227089 18874368 0 0
@rmcdaniel
rmcdaniel / README.md
Created September 29, 2026 14:15
Server #222 Apache and OPcache configuration screens, 2026-09-29

Server #222 runtime configuration screen, 2026-09-29 UTC

Two isolated changes were screened against the untouched published Server 2.4.26 Apache/mod_php image after the Git-only candidate and baseline matrix. Both use the same published image index sha256:d9d13157f91d5418ba74759bc1b32f1ba0fc649e165f6206faab55e0f4737a1e, Workflow 2.2.18, published PHP SDK 2.1.5, pinned MySQL/Redis digests and fixed envelope described in the Git-only matrix. The x86_64 host had four available CPUs and 15 GiB RAM. HTTP was capped at 1 CPU/1 GiB, with separate declared caps for queue worker, MySQL, Redis and two SDK workers; each container's swap limit equaled its RAM limit.

apache-low-idle.conf changed only StartServers and MinSpareServers from 2 to 1 and MaxSpareServers from 4 to 2. It retained MaxRequestWorkers=24 and MaxConnectionsPerChild=1000. The config was mounted read-only into only the HTTP container. opcache-immutable.ini changed

@rmcdaniel
rmcdaniel / README.md
Created September 29, 2026 13:48
Server #222 Git-only image paired raw matrix, 2026-09-29

Server #222 Git-only image screen, 2026-09-29 UTC

This local fixed-envelope matrix compares the published Server 2.4.26 baseline to a candidate built from the exact 2.4.26 source with the Dockerfile from corrective PR #278. The candidate preserves Node.js, Python 3 and Python venv support for published conformance, and removes only build-time Git. It is not a published registry image.

Exact inputs

  • Published baseline index: durableworkflow/server@sha256:d9d13157f91d5418ba74759bc1b32f1ba0fc649e165f6206faab55e0f4737a1e, local Docker ID sha256:70dce06f20ee95f8f35613493100d2ffa927b177e6718b398d3feab66aee3f6a.
  • Candidate local Docker ID: sha256:7a6558121f090f44b1f99ddd8d1dcc041e5299ef9d46ef13334c78b93c66e5e7.
  • Source: Server 2.4.26 archive plus PR #278 Dockerfile at 8329ca49; Workflow 2.2.18 commit 09158ab3fb4cfa5e46e320e2d70853122af209cc; published PHP SDK 2.1.5 from scripts/perf/sdk-php/composer.lock.
  • MySQL mysql@sha256:679e7e924f38a3cbb62a3d7df32924b83f7321a602d3f9f967c01b3df18495d6;
@rmcdaniel
rmcdaniel / README.md
Created September 29, 2026 13:13
Server #222 paired published vs package-trimmed Apache image raw local matrix, 2026-09-29

Server #222 paired local image screen, 2026-09-29 UTC

This is a synthetic local comparison of the untouched published Server 2.4.26 Apache image (durableworkflow/server@sha256:d9d13157f91d5418ba74759bc1b32f1ba0fc649e165f6206faab55e0f4737a1e) with the local package-trimmed image (sha256:37a59f394ad300850ce35583e2e5c02f4d767e6fdca3a95dbe5ec70a44639e06) built from the exact Server 2.4.26 source and Workflow 2.2.18. The only Dockerfile change removes Node/Python and removes Git after pinned source verification. Draft PR #276 carries that change and the separate regression-test-container Python correction. No published candidate digest exists yet.

Host: x86_64, Linux 5.15.0-190-generic, Docker 27.5.1, four logical CPUs and 16,618,160,128 bytes RAM. Compose: scripts/perf/standard-workflow-profile.compose.yml plus scripts/perf/standard-workflow-fixed-envelope.compose.yml. Exact backend digests are in pins-baseline.env and pins-candidate.env. HTTP 1 CPU/1 GiB, queue worker 0.75 CPU/768 MiB, MySQL

@rmcdaniel
rmcdaniel / server222-baseline-pull-20260929.log
Created September 29, 2026 12:33
Server #222 exact-source package trim local screening, 2026-09-29
docker.io/durableworkflow/server@sha256:d9d13157f91d5418ba74759bc1b32f1ba0fc649e165f6206faab55e0f4737a1e: Pulling from durableworkflow/server
6b37362b3da7: Already exists
ec4b910ecd85: Pulling fs layer
09971b4ee5a4: Pulling fs layer
ef6a0198ab6b: Pulling fs layer
8533c506bb23: Pulling fs layer
b15c39e3310f: Pulling fs layer
c532d54f8f45: Pulling fs layer
834530c845a5: Pulling fs layer
a00c79c6b7b7: Pulling fs layer
@rmcdaniel
rmcdaniel / resource-samples.json
Last active September 29, 2026 11:47
Server #137 local fixed-envelope offered-rate raw results including OpenSwoole, 2026-09-29
{
"artifact": "server-137-local-resource-samples",
"date_utc": "2026-09-29",
"method": "Container cgroup CPU and memory point samples before and after each offered-rate plus drain and history-verification window. memory.current is not a peak.",
"windows": [
{
"tag": "apache-050",
"server_cgroup_before": "cpu_usage_usec=12060830\nmemory_current=73756672\nmemory_peak=swap_current=0\n",
"server_cgroup_after": "cpu_usage_usec=63590601\nmemory_current=81334272\nmemory_peak=swap_current=0\n",
"mysql_cgroup_before": "cpu_usage_usec=25768534\nmemory_current=565481472\nmemory_peak=swap_current=0\n",
@rmcdaniel
rmcdaniel / server137-apache-event-measurement-1.jsonl
Created September 25, 2026 00:59
Server #137 fixed-envelope Standard Workflow low-load runs, 2026-09-25
{"phase":"started","sdk":"2.0.10","php":"8.3.33","interval_seconds":5,"duration_seconds":300}
{"workflow_id":"soak-standard-6ceecdad231155140f725a03","phase":"workflow","completed":true,"run_id":"01m3b0v1xgdx25yw6sycx79zyd","latency_seconds":2.543644663}
{"workflow_id":"soak-standard-9db235f27ef4f04506af70f1","phase":"workflow","completed":true,"run_id":"01m3b0v6q82049rh1tc7bd8qdb","latency_seconds":2.469898331}
{"workflow_id":"soak-standard-663738c8729636e35a0ddf5d","phase":"workflow","completed":true,"run_id":"01m3b0vbm7b0sh3z6g1hy1f22a","latency_seconds":2.478375722}
{"workflow_id":"soak-standard-b7d97e4d39da130e37bd8608","phase":"workflow","completed":true,"run_id":"01m3b0vggpjadp2rn9943q10w7","latency_seconds":2.453931214}
{"workflow_id":"soak-standard-42f4a0d01a9288f02cfaf9ba","phase":"workflow","completed":true,"run_id":"01m3b0vnd4zzh0dqcxxp7sd37b","latency_seconds":2.466235917}
{"workflow_id":"soak-standard-0d7dc3fc36eabe0bda182a09","phase":"workflow","completed":true,"run_id":"01m3b0vt862nztjcnkybwst
@rmcdaniel
rmcdaniel / LLM-Architecture.md
Created April 22, 2026 13:48
A three-part argument for building LLM systems around secure boundaries, visible affordances, and explicit coordination structures rather than ever-growing prompt instructions.

The Right Security Model for LLM Systems Richard McDaniel March 12, 2026

Most systems that use LLMs to process external input make the same mistake: they give the model access to secrets, expose it to attacker-controlled content, and then instruct it not to reveal anything.

That is a policy defense against a capability problem.

The threat is not that the model is malicious. The threat is that a sufficiently clever prompt can make an otherwise honest model behave as though it were. If a component can read secrets and also produce external output, then an adversary who controls its input has a path to exfiltration. The model does not need bad intent. It only needs enough reasoning ability to follow the wrong thread.

<?php
declare(strict_types=1);
namespace App\Workflows\Database;
use Workflow\Activity;
class DatabaseActivity extends Activity
{
<html>
<head>
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css">
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.2.1/font/bootstrap-icons.css" />
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.16.0/umd/popper.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/js/bootstrap.min.js"></script>
</head>