This one converts a basic chunk of OpenStreetMap data to an SVG so I can mark it up (by hand) in Adobe Illustrator to make specifically-styled print/PDF maps, such as what get installed at trailheads: https://github.com/c0nsumer/osm_to_ai
And all of this has been put together to make the custom, local, specific-use-case maps that are at https://trailmaps.app (which, via local curation, are overall better mobile/online maps than many of the bigger auto-generated systems such as Trailforks, Gaia, RideWithGPS, etc, for visualizing local systems).
It's neat stuff where I understand all the inputs, outputs, and how most of it works, but AI tooling (Claude, mostly) has allowed me to bolt it together much faster than I would have writing it myself.
The idea came from using the Strava heatmap in JOSM to trace the proper location of mountain bike trails. I'm trying to use Strava less, and usually have ridden the trails enough myself before mapping them that I could use my own routes... So I figured why not have my own heatmap tile server?
It's also cool to just look at.
I could take it a lot further with time boxing what's displayed and whatnot, but generating the tiles is computationally expensive, so I just stuck with what I have for now. It meets the need.
Just something as simple as "that ceiling fan doesn't work so well, and squeaks once in a while when on high" can easily be remedied yourself when owning the house by just going buying and installing a new ceiling fan.
Regardless of how handy one is, with a landlord that's generally not allowed without permission, the landlord often won't install as nice of one as you might like, etc.
This goes for every fixture that's not part of the rental. Major appliances, flooring, even door knobs... Like if you suddenly want an electronic keypad on your deadbolt.
Of course, this flexibility has to be something you care about. Not everyone does, but for those of us that do...
If you live somewhere long enough and under a negligent enough landlord, you can just do a lot of those upgrades anyway and either take them with you when you leave or just chalk them up to practice for when you own a place.
I've lived in my current apartment for 9 years and I've never met the guy who owns it now (it was sold). I'm also not getting my deposit back, so that doesn't matter.
It's the big stuff that's annoying. Can't install A/C or an exhaust fan in the bathroom, for example, simply because I can't afford it. I'd totally feel comfortable upgrading the stove/fridge and tossing theirs or putting it in the basement. They're not going to find out until I move out anyway.
> They're not going to find out until I move out anyway.
Maybe. Probably, given what you've described. But you're still relying on an assumption and the behavior of someone else. It could be sold again tomorrow to an owner who has a real problem with those sorts of changes and it would be out of your control.
Thank you. It's really a simple concept: color them as the colour= tag is in the OSM relation, which matches the signs/markings on the trail.
There's no reason why it couldn't be used anywhere else. This just makes maps that fit within the bounding box of a relation. The only thing US specific about it is the elevation data, and I'm sure something else could be used to get that elsewhere. Or else it could just be turned off for a given map with show_terrain: false.
Yeah, I've seen this in more than a few places. There was a blog "running on a Wii" that, IIRC, was doing the same thing.
On the one hand I get it, TLS is pretty heavy, and it makes sense to take advantage of a VPS or Cloudflare or however you want to do it.
But once you are spinning up a VPS, the question is ... why the Pi? The VPS in the article has less RAM, but more storage. If you're already doing TLS termination on the VPS (the most RAM intensive part), you might as well just do the whole shebang there.
I know this is all for fun, I'm just wondering -- is the Pi Zero really too slow to handle TLS, especially with an optimized TLS library? In this setup, the Pi is already being directly exposed to the Internet anyway, there's no VPN being used. That ARM11 isn't "fast", but surely a 1 GHz ARM11 can handle an optimized TLS library serving some subset of TLS1.2.
The TLS termination isn't actually on the VPS. The article details that Tierhive has an haproxy edge service (handling the TLS), that then has the vps as the backend, but that vps is just doing tcp proxying with socat to the ddns exposed home server fqdn. Feels like a lot of unnecessary loops. Kinda fun I guess but, just, why
Yes it is, "we plan to use our external VPS for handling the TLS termination". Edit: Ah I see you are just pointing out termination is on haproxy service not VPS. Thought you were implying it was terminating on pi, my apologies.
The VPS is running socat only and just doing tcp forwarding. There is a shared haproxy also run by their same host, sitting in front of the VPS and is handling the TLS. I encourage you to read the article fully. They probably should have said "VPS provider" instead of VPS for the TLS bit.
But it's plain text like you said in another comment after the haproxy, so two more plain text paths (with at least one going through the internet (vps->pi), not sure if haproxy->VPS is internal to the provider network (maybe)), so not ideal in my book
This reminds me of the recent "running Doom on DNS" post which in actuality was "running Doom from DNS [as a storage device] on my PC" which is multitudes less impressive.
It is more than a little weird. A pi zero is more than capable of handling HTTP/1.2 and TLS 1.3 for a handful of connections per second. This machine is 10x what we were running web servers on in the '90s.
Also, all web pages are served from RAM. It's automatic that modern OSes will cache this stuff on first access.
Yeah, I ran a phpbb forum (alongside my normal static site) on a 486 in 2003 or so. It worked. It was slow, but it worked just fine for my friends and I! I remember it took multiple minutes to generate the SSH server key after the initial install lol
In the mid-90s, I retired my 486 hardware and brought it over to a local ISP that we were friends with.
It had a second life doing stuff like delivering mail, handling IRC, serving web pages, and whatever else a few of us wanted from it. The performance was fine.
(The Pentium-ish machines stayed on desktop duty where GUIs devoured resources.)
Yeah, I was actually running it on a 386 at first. In those days I didn't have much money and I just dumpster-dived computer hardware that was thrown out behind computer shops. Back before recycling stuff got regulated, PC repair shops threw out totally-working hardware all the time. Every piece of hardware of the web server was free, including the monochrome CRT monitor I had hooked up to it, and the awesome IBM Model M keyboard. The best dumpster find ever was a working Pentium 4 machine, all they took out of it was the HDD! Good times :)
I was initially thinking does the pi zero even have floating point? But then I remembered that encryption only uses integer operations, not even very large ones.
>This machine is 10x what we were running web servers on in the '90s.
Kind of irrelevant since operating systems and web pages in the 90's were significantly smaller in footprints, as the web was mostly plain text back then. Windows XP with its GUI would run Max Payne on 128MB of RAM. You could do a lot more back then that You can't do modern stuff like that today with 128MB of RAM.
In this case, they are static elements, which can even be cached locally to share more easily.
If someone wants a massive build system to render a static HTML page, that's on them, and their personal interpretation. Increasingly, and maybe more often than not, there is more than one way to get the same outcome.
The fact that there's hundreds of downloads for a single web page is up to the constructor of that page. Still, these things can be reasonably cached. For example, host it on the Pi, then put a cloudflare in front of it or something.
The Pi Zero might not be for you, or easy to try to undermine. Which criticisms would go away if it was on a regular pi?
Even then... it's usually built before it's deployed n the server.. the server is still delivering text, css, js, images and images have always been pretty large. So your connection is tied up for a little bit longer... and as content was smaller in the 90's, connections themselves are much faster today... in the 90's you were lucky to be hosting on a T1 or faster and clients on modems. Today, you've likely got between 100mb to 2gb uplink on your home connections, let alone business connections that generally start at 1gb. 600x the bandwidth for the server from a T1
It's possible enough to work from the publication point backwards.
A T1 today put behind relevant caching like CloudFlare could still get a lot done.
Today's home internet speeds between 1gig fibre and up can handle a lot too.
Understanding what's needed, how it could be delivered, constraints can all factor into how to approach structuring, developing and publishing any web application.
LLMs, including open ones, are really good at this it turns out. It stands to reason, there is tons of training material out there no doubt they have consumed and are ready to regurgitate.
Yesterday I one-shotted several interactive pages, that Qwen built out of straight HTML and Javascript. I handed it my API (source code, not even a swagger, via an MCP that Qwen wrote for me), asked for a frontend, and it delivered. One page at a time to keep context down, and mightve gotten lucky on the first draw but after the first one I told it to make the next ones like the first.
Can't say I've had that experience with backend languages & frameworks, incl writing that same API, but perhaps I'm off the beaten path with those, or perhaps there's greater breadth of things to do vs a narrower set of acceptance criteria? IDK.
Here I was sweating that I'd have to research and learn a current-day frontend framework. It felt like a magic wand using consumer-grade AI. HTML and plain old Javascript was plenty.
Tangent but apropos of other contemporary threads on HN, it puts a spin on supply chain threats. There's no NPM or anything, except perhaps whatever mysteries are baked into the model.
Yes. I still have one. I used it in a Soekris 486-class machine running OpenBSD for many, many years. I stopped using the Soekris when they dropped driver support for the accelerator. I think i386 support might be gone now too.
Cool little card; I think I might still have it in a drawer somewhere.
It reminds me of the footage of Doom running on a pregnancy test. And then it turned out it was another computer just displaying to the build in AMOLED display.
What was supposed to be a cool achievement is rendered pointless when one of the key elements is offloaded elsewhere.
Sometimes these demos enable caching on the reverse proxy. So then for these tiny demo html pages you request, you may not even reach the fun tiny computer it is supposed to demonstrate.
Considering that a 'base' raspbian type install can be something like 160MB of RAM used with openssh running and a lot of other launched-from-systemd daemons in the background, that leaves plenty of RAM available for a stock apache2 or nginx setup with TLS. No it won't be able to serve a ton of simultaneous requests, but I'm in agreement with the other comments here that doing purely port 80/http and putting it behind a secondary TLS proxy is not really "serving the website" from the raspberry pi.
Don't have a Pi plugged in now to check, but I have a fresh x86_64 linux and it's using like 600 Mb of ram - server install, I only got around to installing and configuring openssh and samba so far.
Oh and it's Devuan, so not even systemd to blame. I think it was close to 1 G with a systemd distro.
I wouldn’t consider “the way most people do TLS in 2026” weird. That said this isn’t all that impressive or interesting, a computer… serving a website.
Many (most?) are hosting web applications and/or content in separate applications and sometimes servers from where TLS (HTTPS) termination happens. HAProxy, Traefik, Caddy and Nginx as reverse proxy and TLS termination servers are pretty common, even more so if you're containerizing your applications themselves. It dramatically simplifies the application stack.
While I may make the argument that most are probably hosting and doing php on the same server, it's not the typical approach for any custom software at this point.
It's vastly different to do TLS termination within your own network and to do it on a rando VPS and then send normal TCP over the internet. It's not an argument of it being on the same server.
The VPS is your security in this case. It's not sending plaintext over the internet, is it?
Edit: No, the article mentions listening on port 80 at home. I thought they'd be SSH tunneling or something. That is unusual, but I guess for a static website it doesn't really matter.
> That is unusual, but I guess for a static website it doesn't really matter.
It sorta does matter. Either the actual raspi does nothing of value or the traffic has value that should be protected.
Sure, I heard the argument that public HTTP traffic does not need encryption but if it is of any value then both parties have a interest in it unmanipulated, uncenscored, validated or all of the before. Even if it is just preventing the ISP injecting dumb ads.
the airline flight number attached to the icon is in dark color and should be visible, also could switch to satelite view when zoom in, which is dark color
Client isolation is done at L2. You can't add exceptions for IP ranges / protocols / etc this way because that's up the stack. Even if devices can learn about each other in other ways, isolation gets in the way of direct communication between them.
The paper makes the point that you need to consider L3 in client isolation too - they call this the gateway bouncing attack. If you can hairpin traffic for clients at L3, it doesn't matter what preventions you have at L2
Outside of security stuff, over the years I've found this really handy for troubleshooting as well. Being able to extract detailed process info, screenshots, and a bunch of other things from a memory dump have allowed me to get a better idea of what a user was doing when a Windows BSOD occurred.
It builds more a nice picture of what was going on when paired with the users description. Or sometimes, depending on the user, you just don't have anything else to go on besides "it crashed".
I suspect they are meaning because it's uniform you can easily find the studs through it and fasten things directly into them.
An uneven wall material (plaster on lathe, or even plaster on drywall as we have in most of our house) can be quite a hassle to find the actual timbers/studs behind.
Modern plaster has the same properties, and works well with stud finders.
On a related note, if you can find a strong rare earth magnet, you can use it as a stud finder. It'll be attracted to the nails used to hold up the drywall / plaster backer boards. They sell purpose built ones with felt backs + built in bubble levels if you want to get fancy.
And then once all references to the inode are removed (by rotating out backups) it's freed. So there's no maintenance of the deduping needed, it's all just part of how the filesystem and --link-dest work together.
Yeah, give borg a look. It's just faster to back up, faster to delete old backups, and just easier to do restores because so long as you have the appropriate credentials you can list the archive from any machine.
I think there's still a place/use for --link-dst and hardlinks, but as a backup system I think borg does it better.
This one generates maps from OpenStreetMap data + some custom curated info in YAML: https://github.com/c0nsumer/trailmaps.app-map-generator
This one converts a basic chunk of OpenStreetMap data to an SVG so I can mark it up (by hand) in Adobe Illustrator to make specifically-styled print/PDF maps, such as what get installed at trailheads: https://github.com/c0nsumer/osm_to_ai
This one takes GPS recorded rides and builds custom/personal heatmaps serving up the map tiles so I can use them in map editing software: https://github.com/c0nsumer/local-heatmap-tile-server
And all of this has been put together to make the custom, local, specific-use-case maps that are at https://trailmaps.app (which, via local curation, are overall better mobile/online maps than many of the bigger auto-generated systems such as Trailforks, Gaia, RideWithGPS, etc, for visualizing local systems).
It's neat stuff where I understand all the inputs, outputs, and how most of it works, but AI tooling (Claude, mostly) has allowed me to bolt it together much faster than I would have writing it myself.
reply