The Shark - E J Pratt

 E. J. Pratt (1882–1964) was a Canadian poet with a sailor’s eye and a theologian’s nerve. Trained for the ministry, he abandoned pulpits for poems, and brought with him a moral seriousness stripped of sentimentality. His work is often nautical, scientific, and unsparingly physical. Pratt writes nature not as metaphorical comfort, but as mechanism—precise, indifferent, and lethal when necessary.

The Shark is one of his cleanest cuts.

The Shark

He seemed to know the harbour,
So leisurely he swam;
His fin,
Like a piece of sheet-iron,
Three-cornered,
And with knife-edge,
Stirred not a bubble
As it moved
With its base-line on the water.

His body was tubular
And tapered
And smoke-blue,
And as he passed the wharf
He turned,
And snapped at a flat-fish
That was dead and floating.
And I saw the flash of a white throat,
And a double row of white teeth,
And eyes of metallic grey,
Hard and narrow and slit.

Then out of the harbour,
With that three-cornered fin
Shearing without a bubble the water
Lithely,
Leisurely,
He swam—
That strange fish,
Tubular, tapered, smoke-blue,
Part vulture, part wolf,
Part neither—for his blood was cold.

 

---

Short notes on The Shark

• No symbolism required.
  The shark is not a stand-in for evil, capitalism, war, or the subconscious. It is a shark. Pratt’s restraint is the point.

• Engineering language.
  “Sheet-iron,” “knife-edge,” “tubular,” “tapered.” This is a poem written with calipers, not adjectives borrowed from romance.

• Motion without drama.
  “Leisurely” is doing heavy work. The menace lies in the absence of urgency.

• Cold blood matters.
  The final line denies moral analogy. “Part vulture, part wolf” is immediately revoked. The shark belongs to neither warm-blooded hunger nor carrion logic.

• Harbour, not open sea.
  This is civilization’s edge. The shark knows it. That’s the quiet unease.

• Modern, not Victorian.
  Early 20th century. Post-Darwin, post-romance. The universe does not explain itself, and Pratt doesn’t ask it to.

---

Composting Toilet

 

Mark Bolton <markawbolton@gmail.com>

11:31 AM (0 minutes ago)

	to me

Camp Toilet — Feasibility Notes (Condensed)

Baseline

• Existing composting toilet works: cheap plastic bin (~$16) for solids, standard toilet seat on top, sawdust/leaf litter.

• Main deficiency: no urine separation → wet solids, smells, frequent emptying, awkward for women.

Objective

• Add a urine-diverting insert under a normal toilet seat.

• Keep everything else crude, cheap, and familiar.

• One new part only.

---

Design approach

• Standard toilet seat (comfort, ergonomics solved).

• Plastic bin for solids.

• Urine diverted to a jerry can via a formed insert.

• Vent optional but desirable.

---

Materials

• PETG sheet for the urine-diverting insert (vacuum-formed).

• ABS / HIPS acceptable alternatives.

• Cheap ply for mould (scrounged packing ply is ideal).

• Polyester body filler (“bog”) for fairing.

• Epoxy or polyurethane for sealing mould surface.

---

Manufacturing method

• Vacuum forming of PETG over a reusable mould.

• Once mould exists, producing multiples is trivial.

---

Mould construction

• Build mould by stack-laminating CNC-cut slices:

  • Generate rib profiles in Fusion 360.

  • Cut on flatbed CNC.

  • Dowel-align, glue, sand.

  • Fair with filler, seal, smooth, wax/PVA.

• Shed-appropriate, repeatable, low cost.

---

Geometry (critical point)

• Do not invent the urine-diverter shape.

• Copy a proven design:

  • Buy/borrow a commercial urine-diverting insert and replicate geometry.

  • Or obtain an STL and adapt it.

  • Physical prototyping acceptable, but correctness beats originality.

---

CAD role

• CAD is only for:

  • Cleaning up an existing shape.

  • Generating slice profiles for CNC.

• Geometry acquisition is the real work.

---

Men’s Shed outcome

• One-off effort to make mould.

• Build time ≈ 30 minutes per unit.

• Material cost minimal.

• Mould can be donated to Shed; project scales easily.

Conclusion

• Project is viable and worthwhile if geometry is copied.

• Everything else is straightforward fabrication.

Raspberry Pi 5 Case - Laser Cut

Creality Falcon 2

# Linux Mint Cinnamon (APT-based)

# Refresh package lists from all configured repositories
sudo apt update

# Verify available Inkscape version in current repos
apt-cache policy inkscape

# Install or upgrade Inkscape
sudo apt install -y inkscape

NOTE ... the fpllowing  is the meat .. we just lost the "bones" ie ... URLs etc ... due comms fail ...

Project purpose

Design and build a simple, robust laser-cut case for a Raspberry Pi 5. The case is intended as a functional enclosure for a Pi used as a long-running system hub (NAS / automation support), not as a decorative or novelty object. Priority is clarity, access, cooling, and ease of modification rather than visual gimmicks.

Machine used

• Creality Falcon 2 laser cutter

Software and tooling

• Inkscape as the primary design and inspection tool

• Vector files (SVG / DXF / AI as supplied)

• Workflow decision: open an existing design in Inkscape, inspect and understand it, make only minimal or later modifications. No redesign at this stage.

Source design selected

• Laser-cut Raspberry Pi acrylic case design sourced from VectorsFile

• Chosen because it is mechanically straightforward, industrial in appearance, and not “fancy for the sake of it”

• Uses flat panels and mechanical fasteners rather than decorative finger-joint excess

Material choice

• Acrylic / Perspex, specified as 0.3 neutral density (ND) tinted acrylic

• Rationale:

  • Cleaner, more “factory” aesthetic than MDF

  • Transparent/tinted material allows visibility of the hardware

Adhesive / assembly method

• Use proper acrylic solvent cement (e.g. acetone-based or commercial acrylic cement) rather than mechanical interference fits

• Decision explicitly made to avoid kerf-critical friction joints; glue is acceptable and preferred for simplicity and reliability

Design and aesthetic considerations (initial, non-binding)

• Case should look mechanical and industrial rather than ornamental

• No etched graphics or decorative patterns at this stage

• Ventilation openings are functional; any shaping should serve airflow first

• ND acrylic provides contrast while still showing internal components

• Size and proportions kept conservative; avoid oversized or ostentatious designs

Concrete decisions made

• Use an existing laser-cut design as a starting point, not a ground-up custom design

• Use Perspex / acrylic instead of MDF

• Use solvent cement instead of friction-fit joints

• Inspect and possibly adjust the design in Inkscape after the Raspberry Pi 5 is set up and measured, not before

• Treat this case as a first, simple laser-cut project before moving on to more complex mechanisms (e.g. iris assemblies for later projects)

Current status

• Design selected

• Material and assembly method decided

• Next step: open the vector files in Inkscape, review dimensions and layout, then park the project until the Pi 5 is fully configured and ready for final fitting

How to modify chatGPT work flow to operate in Telstra Mobile Data Dark patches.

 

Pinjarra is STT unusable. 

Waroona is intermittent.  

# ============================================================
# Operating AI Workflows in Telstra Mobile Data Dark Patches
# ============================================================

CORE REALITY
- Assume comms are unstable.
- Tools will fail quietly and continue sounding fluent.
- Fluency is inertia, not lift.

FAILURE ORDER
- STT fails first.
  - Desktop browser STT dies before mobile.
  - iPhone STT is more resilient (tighter audio + buffering).
- Text output may continue after capacity is exceeded.

EARLY WARNING SYMPTOMS (AIRSPEED BLEED)
1. Constraint slippage
2. Glue language appears (“overall”, “in summary”)
3. Verbosity up, information density down
4. Rephrasing replaces progress
5. Partial compliance with confident tone
6. Silent revision of frozen outputs
7. “Done” tone with missing elements

RULE
- No symptoms ≠ safe.
- Assume stall risk under load or bad comms.

THREE TEST MODULES
[TEST 1: CONSTRAINT PIN]
- Reassert one non-negotiable constraint mid-task.
- FAIL: acknowledged, then violated.

[TEST 2: DELTA INJECTION]
- Add a small change dependent on prior state.
- FAIL: ignored or whole task restarted.

[TEST 3: FREEZE & RECALL]
- Freeze output A. Require exact reference to A.
- FAIL: paraphrase, drift, or silent edits.

TERMINAL STATES
9. COMA   – fluent, hollow, unresponsive to tests
10. DEATH – confident nonsense; runway assumed, terrain confirmed

WORKFLOW MODIFICATIONS
- Chunk ruthlessly: one task, one objective
- Freeze early and often; capture externally
- Externalise state (notes outside the chat)
- Write fragments first (nouns, verbs, decisions)
- Avoid nesting and long dependency chains
- Stop early; checkpoint before it looks impressive
- Defer synthesis to clean networks

OPERATIONAL SPLIT
- Bad comms: thinking, fragments, note-taking, humans
- Good comms (Men’s Shed / landline): synthesis, summaries, structure

BOTTOM LINE
- You can fly in dark patches.
- Just don’t pretend it’s VFR.
# ============================================================
 

Assumption: comms will drop, stall, or gaslight you. Design accordingly.

Principles

• Treat AI output as volatile, not persistent

• Fluency ≠ capacity; assume silent failure under load

• Interruptions add overhead, not insight

Workflow Adjustments

• Chunk ruthlessly: one task, one objective, short hops

• Freeze early, often: capture outputs immediately; don’t rely on scrollback

• Externalise state: notes live outside the chat (Mark’s Log, notebook, text file)

• Fragments first: jot nouns/verbs/decisions, not prose

• Avoid nesting: no long dependency chains in one pass

• Checkpoint mindset: stop while it’s still working, not when it’s impressive

• Defer synthesis: heavy summaries only when comms are clean

Operational Split

• Bad comms: thinking, note-taking, human conversation

• Good comms (Men’s Shed / landline): synthesis, summarisation, structured output

Bottom Line
You can fly in bad weather—
just don’t pretend it’s a sightseeing trip.

System Rescue Tools - Filezilla / Ventoy and Timeshift

Home Automation Computer Newtork Architecture - Mark's Truck

Exaust Fan Iris Shutters - Laser Cutter

Why Speedtest Lies (and What Your Network Is Actually Doing)

  Version: Bush Mobile Data—Observed in the Wild

---

1. Speedtest is an Advertising Tool, Not a Diagnostic

Speedtest exists to:

• flatter telcos,

• reassure customers,

• keep everyone feeling warm and connected.

It is not designed to reveal network failures.
Its job is to present the best-case number it can wring out of your connection, even if the underlying link is dying like a lizard in the sun.

---

2. It Cheats — By Design

Speedtest stacks the deck:

• Picks an ideal server (close to you, low latency, cooperative).

• Uses parallel TCP streams to inflate throughput.

• Smooths out jitter so the graph looks pretty.

• Retries aggressively to mask packet loss.

This creates the appearance of a stable, high-bandwidth link even when the network is held together with fencing wire and hope.

---

3. Why You See “20 Mbps… 0.1 Mbps… 20 Mbps”

What looks like a square wave isn’t real bandwidth variation.
It’s the cheat system breaking down temporarily.

When the tower chokes:

• routing collapses

• packet loss spikes over 80–90%

• TCP stalls completely

• Speedtest can’t fake it anymore → drops to 0.1 Mbps

When the tower recovers for a moment:

• a handful of packets get through

• Speedtest’s parallel streams kick back in

• the illusion resumes → 20 Mbps!

You’re not seeing performance.
You’re seeing optimistic marketing interspersed with reality.

---

4. The Real Condition of the Network

Your proper tools tell the truth:

ping → catastrophic loss

• 80–100% packets dropped

• regular “destination unreachable”

• no stable path to anywhere

mtr → routing collapses mid-path

• hops flapping

• latency in the thousands of milliseconds

• segments disappearing entirely

iperf3 → no sustained throughput

• can’t negotiate

• can’t maintain a TCP session

• server unreachable most of the time

This is structural failure, not “slow internet.”

---

5. What Speedtest Can’t Admit

If Speedtest were honest, it would show:

“Your connection is unusable.”

But honesty doesn't sell telecom services.

So instead it:

• cherry-picks its best 2 seconds,

• prints a big shiny number,

• and pretends the rest of reality didn’t happen.

---

6. The Bottom Line

Speedtest lies because it's designed to.
It reports potential performance, not actual conditions.

Your tools revealed the truth:

• Massive packet loss

• Routing instability

• Flapping radio layer

• Near-zero usable bandwidth

• A connection that works by coincidence, not design

If a network cannot deliver consistent packets,
it doesn’t matter how fast Speedtest claims you are in theory.

---

7. Field Rule of Thumb

Always trust packet loss and routing behaviour.
Never trust a single-number speed result.

Speedtest is a postcard.
ping, mtr, and iperf3 are the autopsy.

---

Note  :  Yeah, it's a bit like the bloke whose wife never cheats on him, except for when he actually finds her in his bed with the milkman, and then he walks out of the room and she's not cheating on him anymore.

FIELD DIAGNOSTIC — “HONEST LINK TEST

 

MARK’S FIELD DIAGNOSTIC — “HONEST LINK TEST”

Purpose:
Run three real-world tests that expose the true condition of a network link (jitter, loss, routing stability, sustained throughput).
Replaces Speedtest completely.

---

COMMAND BLOCK (copy/paste and run as-is)

# 1. Stability & packet loss (50 probes to Cloudflare)
ping -c 50 1.1.1.1

# 2. Route quality (live traceroute + loss/jitter per hop)
mtr -rw 1.1.1.1

# 3. Sustained throughput test (TCP, real flow)
iperf3 -c iperf.scottlinux.com

---

INTERPRETATION (brief)

1. ping

• 0% loss + tight latency → good link

• Loss > 1% → unstable

• Jitter swings > 30 ms → VPN, STT, games, Zoom all degrade

• “Destination Net Unreachable” → upstream routing failure (tower/backhaul dead)

---

2. mtr

• Shows where packets die.

• Loss at hop 1 = tower or local NAT failure

• Loss at hop 2–3 = backhaul congestion/microwave link fault

• Loss only at far hops = upstream ISP issues

This is the “forensic” tool.

---

3. iperf3

• Tests real, sustained throughput — no cheating, no smoothing.

• Smooth graph → link can carry load

• Bursts/stalls → congestion or jitter

• Disconnects → upstream failure

If iperf3 can’t connect at all → the link isn’t routing.

---

CONCLUSION

This triple test reveals:

• jitter

• packet loss

• route instability

• tower congestion

• backhaul collapse

• VPN viability

• torrent viability

• STT reliability

• true usable bandwidth

Speedtest hides all of these.
This rig exposes them instantly.

 

---------------------------------------------------------------------------------------------------------------

Righto — here’s your compact, portable field-diagnostic script.
Name it whatever you like; I’ll call it netcheck for simplicity.

This gives you:

• one command

• clean output

• no dependencies beyond mtr and iperf3 (install once)

• works anywhere

---

1. The Script (netcheck)

Copy/paste this into a file:

#!/bin/bash

echo "===================================="
echo " Mark's Honest Link Test – netcheck "
echo "===================================="
echo

# ---- 1. PING TEST ----
echo "[1] PING: Stability + Loss"
echo "--------------------------"
ping -c 50 1.1.1.1
echo
echo

# ---- 2. MTR TEST ----
echo "[2] MTR: Route Quality (loss per hop)"
echo "--------------------------------------"
mtr -rw 1.1.1.1
echo
echo

# ---- 3. IPERF3 THROUGHPUT ----
echo "[3] IPERF3: Sustained Throughput Test"
echo "--------------------------------------"
iperf3 -c iperf.scottlinux.com
echo
echo "Done."

---

2. How to install it

Save it somewhere sensible — I’d suggest:

~/bin/netcheck

Then make it executable:

chmod +x ~/bin/netcheck

If ~/bin isn’t already in your PATH, add it by editing ~/.bashrc:

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

---

3. How to run it

Anytime, anywhere:

netcheck

That’s it.
No mucking around.
It runs the three honest tests in sequence:

• ping → stability

• mtr → route diagnosis

• iperf3 → sustained usable throughput

You get a complete truth readout of the link without touching Speedtest or any GUI.

---

4. Notes

• If mtr or iperf3 aren’t installed, do this once:

sudo apt install mtr iperf3

• If iperf3’s test server is ever unreachable (rare), swap in Cloudflare’s:

iperf3 -c speedtest.wobcom.de

But the default one is rock solid.

---

If you want a version that logs automatically to a timestamped file for later analysis, I can package that too.