root.cz
./blog.sh on Root.cz, the Czech Linux site, in Czech and in my own words: why the text and the pictures belong on your own disk, what a build is and where its result can live, how comments ride on the Fediverse, and why twenty-two importers read an export rather than an API. It also says plainly who the engine is not for: more than one author, anyone who wants a web admin, plugins.
LinuxDays 2026 take place in Prague this weekend, on Saturday 3 and Sunday 4 October, at FIT ČVUT in Dejvice, as they do every year. Admission is free.
On Saturday I will be at the stand of my friends from OSCloud all day. If you want to talk about ./blog.sh, ask how this or that works, find out whether it would carry your blog, or tell me what got in your way, this is the chance to do it face to face rather than in issues on GitHub.
Nothing much to prepare. A question is enough — or the blog you have been meaning to move. Everything else we will talk over at LinuxDays 2026.
Programme and directions: linuxdays.cz/2026
#blogsh #LinuxDays
Five posts have covered what 1.9 is about: a post in two languages, the site in the language of the page, what stands in a deploy target before the first deploy, a host that only speaks FTP and one phone shortcut instead of two. This one is the rest, in the order an operator meets it. Most of it came from two people who set 1.9 up from nothing and upgraded a copy of a 6,600-post site, doing only what the docs said.
Sending a post from an iPhone took two shortcuts until 1.9: one to take the files from the share sheet, one to open the SSH connection. Written on a train walked through both. It is one shortcut now, imported rather than built, and it runs on a Mac as well.
A shared hosting plan often comes with a directory, an FTP login and nothing else — no SSH, no rsync, no git. That has been enough for blog.sh all along; the docs just never said so until 1.9. The way there is the rclone backend, because rclone speaks FTP as one of its many remotes.
Somebody moves a blog off WordPress onto blog.sh and keeps the same hosting, the same directory, the same address. The build is ready, the first deploy goes through without an error — and the front page is still the old one. Nothing went wrong in the upload. The old site was simply never taken away, and the host prefers it.
Somebody translates their posts, opens the Czech half of the site — and the menu still says Writing, the footer still says Links, and every tag on every pill is the English word. The posts were only ever half of what a reader reads. The rest is what the site says about itself, and in 1.9 that has a language too.
Somebody writes in Czech, and some of the people who would read it don't read Czech. The usual answer is a second blog — a second archive, a second set of tags, a second feed — and within a year the two have drifted apart: a post fixed in one and not the other, a tag renamed on one side, a reader who switches languages and lands somewhere that no longer matches. blog.sh 1.9 gives a different answer: one site, and the other language beside it.
./blog.sh 1.9 is out — release on GitHub.
The release about publishing in more than one language. Name them in site.locales, and a post keeps one date, one set of tags and one series, with a text per language written by ./blog.sh translate. The site's own language keeps the root, every other one gets its own, and one rebuild makes all of them. The banner, menu, footer and tags speak each language too; a post nobody has translated still shows, linking to the one copy that exists. This very site has been running in English and Czech since the release was a draft.
Around it, the first hour: two people installed 1.9 from nothing and upgraded a copy of a 6,600-post site, doing only what the docs said, and everything they tripped over is fixed. Esc never does anything, the setup speaks your language from its first screen and will not take the template's example as your site's name, a draft's properties show where to read it — with a QR code for the phone — and doctor --online now asks the deploy target what stands in its root that the site does not put there.
A laptop dies, or a server gets rebuilt from nothing, and the question that actually matters is narrower than it sounds. Not "how do I back this up" — "which of these files does the engine actually need me to protect, because nothing else here can make them again on its own."
Most of an installation doesn't qualify. The engine itself is a git clone; pull it again and it's the same engine. Everything the build writes comes back with one rebuild, given what's left.
The instinct is to back up the site itself — the folder a browser actually sees. That's precisely the one thing this list leaves out. public.nosync, the build's own output, is exactly as disposable as the engine that made it: one rebuild reproduces it byte for byte, so keeping a copy of it would just be storing the same information twice, under two different names, and trusting the older copy by accident.
What's left, once the engine and the site it builds are both set aside, is a short list.