DEV Community: Panagis Tzivras

Meet Frankie, the 17-year-old laptop that was supposed to build ARGOS : :

Panagis Tzivras — Tue, 20 Oct 2026 12:05:24 +0000

A 2008 MacBook Air, six hours of Linux archaeology, and the belief that one person with a drawer of old hardware can still matter

I am writing this from a 2008 MacBook Air that macOS abandoned a decade ago. Its name is Frankie. It took six hours to bring it to life, and for one evening, I believed it would be the machine that kept ARGOS running while I am on Kefalonia.

The context

ARGOS : : is a digital twin for an island, built by one person. There is no procurement department. There is no EU grant. There is one person and a drawer of old hardware.

The production database runs on an Oracle Cloud VM. The site runs on Cloudflare Pages. The tiles run on GitHub Pages. The heavy builds run in GitHub Codespaces. Every piece of infrastructure was chosen because it does the job without requiring a team to maintain it. The stack is small because the team is one person. The stack is public because the methodology should be auditable. That is the design, not a compromise.

But I still need a local machine. For the Git commits. For the YAML edits. For the SSH into the VM when something breaks at 23:00 and the Codespace has gone cold. For the fieldwork notes I write on the balcony after walking a ravine.

I did not buy a new laptop. I pulled the MacBook Air 2,1 out of a drawer. The one with the Nvidia 9400M chip that Apple stopped supporting somewhere around Mountain Lion. The one that modern macOS will not even boot on.

The archaeology

Lubuntu 24.04.5 LTS. That was the starting point. Lightweight, supported, sane.

The first attempt failed. The Calamares installer hit a known bug :fixconkeys-part1 timed out after 30 seconds, leaving the disk half-erased and the boot chain corrupted. I rebooted into a grey box with an inverted flag. The fix, found in a forum post from 2023, was to edit /etc/calamares/settings.conf in the live session, comment out two lines, and run the installer again. It worked the second time, though the installer window went black mid-process and I had to trust the fan noise.

Then the display. The live session booted fine, but the installed system showed corrupted text — white boxes where characters should be, inverted colors, blank desktop icons. nomodeset fixed the text but turned the sky brown and the sea purple. The real fix was nouveau.noaccel=1: disable GPU acceleration entirely, tell the kernel to stop asking the 9400M for help. The CPU draws every pixel. No 3D. No hardware compositing. Just a Core 2 Duo doing graphics the hard way, like it is 2006.

And it worked. Colors correct. Icons visible. Desktop stable. The trade-off: no 3D acceleration, which is irrelevant for a machine that was never going to run a game.

Then the WiFi. The Broadcom BCM4321 chip is a known problem child. The proprietary wl driver loads but crashes on this kernel. The open-source b43 driver works, but the signal indicator always shows full bars, whether you are next to the router or three rooms away. The connection is real; the bars are fiction. I can live with that.

The trackpad took three attempts. The first driver moved the cursor but would not click. The second clicked but had no right-click. The third, a manual xinput configuration, gave me both.

Then the heat. The default fan control waits until 63°C before it starts ramping. By then the palm rest is already hot. I installed mbpfan and tuned the curve: low_temp = 55, high_temp = 60, max_temp = 86, polling_interval = 1. The fan stays silent below 55°C, starts a gentle ramp at 55 instead of waiting for 63, and never hits full speed unless the CPU is at 86. A cooler machine with slightly more fan noise. I chose usable.

Then the suspend. The MacBookAir2,1 has a documented kernel quirk: close the lid, and sometimes it wakes to a black screen that never clears. I call it a design feature that forces me to shut down properly. If I step away, I save and power off.

Six hours. From a forgotten drawer to a working desktop.

The first evening

I installed Geany, a lightweight editor that opens in under a second. Falkon, a Qt browser that loads pages without choking. I disabled the screensaver entirely, it was rendering while idle, heating the machine for no reason. I set the monitor to switch off after six minutes.

I wrote the first draft of this article on Frankie itself. The text appeared as I typed. The fan hummed quietly. The palm rest was warm but not hot. For one evening, it felt like the plan would work.

Frankie was alive.

But alive and useful are different things. The next morning, I would learn what a 2 GB Core 2 Duo actually feels like in 2026.

The infrastructure, at that moment:

Local dev: Frankie, 2008 MacBook Air, Lubuntu, no GPU acceleration, b43 WiFi, manual trackpad config, mbpfan tuned to 55/60
Production database: Oracle Cloud Always Free ARM VM, PostGIS 16, pgRouting
Site: Cloudflare Pages, global CDN
Tiles: GitHub Pages, PMTiles, 10.88 MB vector tileset
Builds: GitHub Codespaces, ephemeral, rebuilt on demand
Email: Resend SMTP, daily VM health reports at 08:00 EEST
Storage: MinIO on the VM, 30-day backup retention
Domain cost: €1 per month. The rest is built, not bought.

The big twins , Volos, DestinE, HARMONIA Piraeus, run on HPC clusters and EU budgets and consultant teams. ARGOS : : runs on one person, a free VM, and a drawer of old hardware.

That is not a limitation. That is the point.

Or so I thought.

The Sea Looks Calm When It Isn't

Panagis Tzivras — Thu, 01 Oct 2026 06:06:04 +0000

I spent years reading water before I ever wrote a line of code. So when I say this, it comes from both sides of me: the sea on a map and the sea in front of you are not the same object.

Myrtos Beach is one of the island's best-known beaches. White pebbles, steep cliffs, water that shifts from turquoise to deep blue in a few meters. On most summer days it looks like the safest place on Kefalonia. It is not always.

This is the story of the first marine layer in ARGOS, and of the honest limits of what a model can promise you about the sea.

The night it earned its keep

On the night the marine layer went live, the model logged an exposure score of 73.3 for Myrtos. Class: high. Window: 22:00 to 23:00 EEST. Waves from 316 degrees, about 2 m significant wave height.

Nothing about that sentence is measured at the shoreline. It is computed from Copernicus Marine model data, twice a day, for fourteen pilot beaches around the island. The nearest model cells sit 3.1 to 6.9 kilometers offshore, and the model speaks from there. What the beach does with that energy is a translation, not a measurement.

I want that sentence to sit in your chest for a second, because it is the whole piece.

The sea's shape

Within the ARGOS EMODnet window, the deepest cell is 3,841 meters. Our bathymetry comes from EMODnet at roughly 100 meters per pixel, with contours drawn down to 3,500 meters. Kefalonia's west coast is where that deep water leans closest to the shore.

Along Myrtos' open-water bearing of 291 degrees, the corrected EMODnet contours put 25 m of water about 2.1 km from the shoreline, 50 m at 3.0 km, and 100 m at 4.2 km. The 200 m contour lies about 10.0 km offshore. The beach's assigned CMEMS cell sits 3.36 km from the beach centroid, between the 50 and 100 m contours; at roughly 100 m per pixel, this is shelf-scale context, not swim-zone bathymetry.

That geometry matters because it is why a beach can look like a swimming pool and behave like something else. The energy does not need a storm to arrive. It needs a direction, a period, and a floor that shoals the right way.

The layer

Fourteen beaches. Copernicus Marine Mediterranean forecasts: waves and two-dimensional surface currents, refreshed twice daily. The exposure score is a direction-gated wave score at 70 percent plus a current score at 30 percent. The gate exists because a wave from the wrong direction is noise, and from the right direction it is the whole story.

The bathymetry you just read is context, not an input. Our exposure score does not use the EMODnet shelf layer directly; the CMEMS models carry their own model-resolution bathymetry. It knows the sea state. We supply the geography.

What we could not validate, so we are saying so

There is no independent wave buoy on Kefalonia. The published POSEIDON network has no Kefalonia station; its named Ionian mooring is Pylos. We checked. The answer is no.

So this layer ships unvalidated, first in the validation queue. The interim path is cross-checking against KefaloniaPress daily beach scores and the quality documentation that ships with the Copernicus products themselves. The first version of this story had a cleaner ending. This is the honest one.

What it is not

Not a rip-current warning. Not measured beach safety. Not a lifeguard-grade forecast. Not a safe-or-unsafe certification for any beach, ever.

It is an exposure screening: modelled offshore wave and current conditions, translated into a beach exposure assessment. Direction-gated, twice daily, bilingual, and public about its own uncertainty.

The ask

If you are a lifeguard, a boat operator, or someone who has watched Myrtos for thirty years: your observations are the validation this layer is missing. The map will only get as honest as the ground truth it is fed.

Built in Kefalonia. Watching over the places we call home.

Links:

https://argos-geo.org/map · https://github.com/argos-geo/kefalonia-digital-twin

The Answer You Didn't Want: Fiskardo Evacuation Routing

Panagis Tzivras — Thu, 17 Sep 2026 15:16:27 +0000

During a wildfire, how long does it take to move people out of Fiskardo by road?

That was the question. It sounds like a database query, because it is one: load the road network, pick a start, run pgRouting's pgr_dijkstra, read the cost. Milliseconds of compute. One number.

The first number the twin gave me was absurd. And my instinct was to distrust the model. That instinct was correct, but for the wrong reasons. The model was not lying. My data was wrong in five ways. The sixth way was me.

This is the story of all six.

Round 1: The dead table

The routing query ran cleanly and returned plausible-looking paths. The problem: it was reading an old import table left over from an earlier iteration. The geometry looked like Kefalonia. The connectivity was garbage. The network I was querying was a ghost.

Lesson one of geospatial debugging: a query that runs is not a query that is right.

Round 2: The real network was somewhere else

The live road network lived in a different table. Not a bug, just archaeology. But it means everything the first queries "proved" was noise. I threw the results away and started over.

Round 3: cost_m is not a distance

The cost column in my routing table was named cost_m. I assumed meters. It was minutes. (pgRouting itself returns cost and agg_cost; the misleading name was ours.)

Every distance I had reported so far was actually a travel time. This is the kind of error that doesn't crash. It just quietly corrupts every conclusion you draw from it, forever, until someone reads the schema with suspicious eyes.

Round 4: Mixed SRIDs

Somewhere in the pipeline, two projections had crept in. Geometry in one spatial reference system was being measured against geometry in another. Distances were quietly, consistently wrong by a factor only a geodesist would guess.

A digital twin with two coordinate systems is not a twin. It is two maps arguing.

Round 5: The row-order bug

pgr_dijkstra returns path segments. The results looked scrambled: segments out of order, the route jumping back on itself.

The bug was mine. I was reading the result rows in the order the database happened to return them instead of ordering by seq. The path was correct the whole time. I was reading the sentence word by word, in a shuffled order, and calling it gibberish.

Round 6: The road that might not be there

The final answer was now stable. But it was still wrong in a way no query could detect.

The route took an enormous detour inland, ignoring a 15 km coastal road in favor of 29 km of mountain. The prime suspect is a connectivity gap on the Evreti stretch. A node that doesn't quite snap. Invisible to every attribute query. The autopsy is still open.

What we know for certain: the router prefers a 29 km detour over a 15 km coastal road, the road's data looks clean, and local knowledge says the road is fine. The model and the map disagree, and the argument is documented.

A suspected data gap, wearing a software bug's clothes.

The answer

After six rounds, the twin gave me its answer:

Agia Effimia Marina. 29.0 km. 44 minutes. 116 road segments.

That is the answer you didn't want. Forty-four minutes is not a comfortable number if you are standing in Fiskardo watching smoke. At every round of this forensic, a prettier wrong answer was available. Faster numbers. Shorter routes. Numbers that would have looked great in a demo.

The value of this digital twin was never going to be that it produces answers. Any GIS produces answers. The value is that this answer survived six rounds of me trying to break it, and it is still standing.

The lighthouse test

The same engine, asked a different question, once ranked an abandoned lighthouse on an uninhabited islet as the hardest place to reach in an emergency: 108.1 minutes from the nearest fire station. Island-wide worst. The tower was leveled in the Italian bombings of 1942; what remained was felled by the 1950 earthquake. Technically correct, contextually meaningless.

Put the two stories together and you get the real design principle:

The twin finds edge cases and reports reachability honestly. Humans supply context and priority.

A bombed lighthouse and a hospital get the same accessibility score. That is not a flaw in the model. That is the model telling you exactly which decisions it cannot make for you.

Why this matters for civil protection

Evacuation planning runs on numbers. If those numbers come from an unvalidated model with a dead table, a minutes-as-meters column, and an unsolved coastal detour, the plan is a rumor with a map attached.

The uncomfortable number, validated, is worth more than the comfortable one, invented. That is what "no black boxes" means in practice. Not a slogan on an open data page. Six rounds of forensic debugging before a single digit goes public.

Every model in ARGOS carries its validation with it: what was tested, against which events, what worked, what didn't. This routing layer is no exception.

The methodology, the code, and every wrong answer along the way are public. A map that argues back must also admit when it is unsure.

Links:

Built in Kefalonia. Watching over the places we call home.

ARGOS v0.0.1 is live: a digital twin of Kefalonia

Panagis Tzivras — Thu, 20 Aug 2026 16:56:16 +0000

Three weeks ago I started building a map that argues back.

Today it is public.

🗺️ argos-geo.org/map

What you can do:

Click any building, road, beach, or POI
See travel time to the fire station and nearest ferry port
Toggle wildfire risk and flash-flood layers
Find the lighthouse nobody asked about (102 minutes, boat-only)

The stack: PostGIS + FastAPI + MapLibre GL + PMTiles. Hosted on GitHub Pages. Costs €0/month.

The data: OpenStreetMap, Copernicus DEM, Sentinel-2, NASA FIRMS, EFFIS. All open. All attributed.

This is a static snapshot. Phase 2 adds real-time feeds. Phase 3 adds a municipality pilot.

I wrote about how it happened:

Panagis Tzivras

Aug 18

I built a digital twin of a Greek island and it found a lighthouse no one asked about

#opensource #geospatial #postgressql #digitaltwin

5 min read

Coming next: Build Log #2. Why the model thinks Greek firs burn like pine (and why it is wrong).

Built in Kefalonia. Watching over the places we call home.

# Build Log #1: Processing my first Sentinel-2 pass in 48 hours

Panagis Tzivras — Wed, 19 Aug 2026 16:01:26 +0000

48 hours and moderate sleep later, ARGOS just processed its first Sentinel-2 pass over Kefalonia.

This is what that looks like.

What I was trying to do

I wanted a baseline vegetation map of the entire island. Not from a government PDF, not from a paid dataset- from the European Space Agency's Sentinel-2 satellite, freely available, updated every 5 days. The goal was simple: download the latest cloud-free acquisition, run it through a processing pipeline, and get an NDVI layer I could query against.

The stack

Python + rasterio + xarray for data handling
GDAL for reprojection (Sentinel-2 comes in UTM 34N, I need EPSG:4326 for the web map)
A very patient laptop

The problem

Sentinel-2 data is "free" the same way a 500-piece puzzle is "free"- every piece is there, but no one warned you about step seven. The SAFE format, the multiple granules, the 10m vs 20m resolution bands, the cloud masking- none of it is hard individually, but the pipeline has about twelve steps and step seven fails silently if you forget to resample the 20m bands before stacking.

I forgot. Twice.

The fix

A very ugly Python script that I am not proud of but that works. It downloads the granule, filters clouds, calculates NDVI, reprojects to WGS84, and drops a GeoTIFF into a folder that PostGIS will eventually ingest. The script is 180 lines. 40 of them are error handling. That's the honest ratio.

The honest part

The NDVI map looks beautiful. Green valleys, dry ridges, the whole island in false colour. But "beautiful" and "useful" are different things. I spent hour 36 staring at a perfectly rendered map and realising I had no idea whether an NDVI of 0.3 meant "stressed vegetation" or "just rocks." The satellite sees what it sees. Context comes from knowing the island.

What's next

Layer 2: wildfire risk index. Slope + aspect + NDVI + fuel type. The model will be wrong. It already thinks Greek firs burn like pine. But that's Build Log #2.

Links

This is Build Log #1 of the ARGOS series. Build Log #2: Why the model thinks Greek firs burn like pine (and why it's wrong).

I built a digital twin of a Greek island and it found a lighthouse no one asked about

Panagis Tzivras — Tue, 18 Aug 2026 18:10:48 +0000

I built a digital twin of a Greek island and it found a lighthouse no one asked about

One person, one laptop, zero budget, one island.

The problem

Kefalonia is the sixth-largest island in Greece, which sounds impressive until you try to answer a simple question: if a fire starts on that ridge, how long until the fire truck actually arrives?

I spent my summers on Kefalonia. It's the sixth-largest island in Greece, which sounds impressive until you realise what that means in practice: 254 km of coastline, three municipalities, one fire station with a volunteer watch, and exactly zero real-time flood monitoring. When the August fires hit Zakynthos 20 km away, the civil protection alert arrives by SMS. When the February 2025 storm washed out roads, the information travelled at the speed of someone driving to check.

I work in data. I know what Copernicus produces. I know what EFFIS tracks. I also know that none of it reaches the municipality inbox in a format anyone can use. The data is free. The gap is distribution.

So I started building the distribution layer.

What ARGOS is

ARGOS is an open-source digital twin of Kefalonia. One PostgreSQL/PostGIS database that holds the whole island: 12,217 road segments, 22,013 buildings, 1,831 POIs, 197 beaches, 29 trails, terrain from Copernicus DEM 30 m, vegetation from Sentinel-2, and two hazard layers that have already been tested against reality.

The stack is deliberately boring:

PostGIS 16 for the spatial engine (SQL I can write, no Java servers to maintain)
FastAPI for the API (/layers, /buffer, /intersect, /aggregate - all demo queries < 500 ms)
MapLibre GL + PMTiles for the map (9.4 MB single file, served from GitHub Pages, HTTP 206 range requests)
GitHub Codespaces for the dev environment (docker compose up -d, zero local setup)

Boring stacks ship. This one shipped in six weeks of Saturday mornings.

The map that argues back

The live map is at argos-geo.org/map. Click anything - a building, a beach, a road segment - and it answers. The popup tells you how many minutes that building is from the fire station and the nearest ferry port. Not as-the-crow-flies. As-the-ambulance-drives. Or doesn't drive, as the case may be.

The lighthouse problem

Here's my favourite edge case. The model ran its first accessibility analysis and found the hardest place to reach in an emergency. It wasn't a mountain village. It wasn't a remote beach. It was a single building with a travel time of 102 minutes.

That's a lighthouse. On an uninhabited islet. Built by the British in 1824, bombed by the Italians in 1942, flattened by the 1953 earthquakes. Accessible only by boat. No roads. No permanent population. The algorithm correctly flagged it as the most isolated structure in Kefalonia.

The model doesn't know what's "important" to humans. It just knows what's hard to reach. A bombed lighthouse and a hospital get the same accessibility score. Context comes later.

Oh, and - it's an island.

The algorithm knew that too. It just didn't think it was worth mentioning.

The hazard layers (or: why I don't trust my own model yet)

ARGOS WATCH: Wildfire Risk v1.1

Five-factor weighted index: slope, fuel proxy (NDVI), road proximity, aspect, and historical burn scars from EFFIS. Validated against 24 real fire perimeters (2017-2026). Burned areas score 63.6 vs the island baseline of 59.1. Very-high-risk enrichment is ~3.7×.

But here's the honest part: the model thinks Greek fir (Abies cephalonica) burns like Mediterranean pine. It doesn't. Different fuel load, different crown fire behaviour, different moisture retention. The satellite sees NDVI = 0.6 and says "green = fuel." The local says "fir = doesn't crown-fire like pine." Build Log #2 is about exactly this failure.

ARGOS WATCH: Flash-Flood / Debris-Flow v1

D8 drainage network × receiving slope × upstream burn-scar exposure. Validated against the February 2025 storm. The model's top-ranked ravines: Τραπεζάκι 97.5, Πόρος 96.9, Περατάτα 94.6. Those names match the news reports. The model ranked reality correctly.

Both layers are screening baselines, not forecasts. Directionally validated, not calibrated. I say this explicitly because credibility comes from admitting limitations, not hiding them.

The architecture

Every pipeline step is a numbered, committed script in scripts/. Every model has an open methodology document with an honest limitations section. The whole stack runs in a GitHub Codespace. The whole thing costs €0/month to host.

The code is MIT. The derived layers are CC BY 4.0. The sources are all open: OpenStreetMap, Copernicus DEM, Sentinel-2, NASA FIRMS, EFFIS. Attribution is architecture, not decoration.

The three sub-brands

ARGOS GEO - the twin itself: data, pipelines, API, map
ARGOS WATCH - hazard intelligence: wildfire + flash-flood screening, validated in the open
ARGOS COMMONS - whatever this grows into next, with the people who gather around it

What's next

v0.0.1 is a static twin: snapshots, not streams. Phase 2 adds real-time feeds (Open-Meteo weather, ADS-B aircraft, EFFIS/Copernicus EMS alerts), a 7-day hazard outlook, and historical playback. Phase 3 is a municipality pilot: three months, no cost, they provide feedback.

The long-term goal isn't to replace civil protection. It's to give them a layer they don't have: local granularity on top of satellite data. EFFIS shows Greece burns ~50,000 hectares annually. ARGOS is trying to answer which 16 km² of Kefalonia burn first.

Links

🗺️ Live map: argos-geo.org/map
🐙 GitHub: github.com/argos-geo/kefalonia-digital-twin
🌐 Website: argos-geo.org
📧 Email: hello@argos-geo.org
🦋 Bluesky: @argos-geo.org
🐘 Mastodon: @argos_geo@mapstodon.space
🐦 X: @argos_geo

Built in Kefalonia. Watching over the places we call home.

If you know Mediterranean fuel models, Greek forestry data, or municipal civil protection workflows, I need you. Drop a comment or email hello@argos-geo.org.

This is Build Log #0 - the debut. Build Log #1 (Sentinel-2 processing and the crime scene Python script) is already live and a few days old, which in internet years makes it practically vintage. Build Logs #2-10 are coming: the Greek fir problem, drainage mapping, the Vardiani lighthouse, stack decisions, containerisation, the Copernicus → inbox gap, API-first architecture, hosting on Cloudflare Pages, and what "building in public" actually means when your model is wrong.