Does it run on an RPi now? :)
It'll be so much easier next time I try!
Though I did run it on Drupal off a Pi cluster for a few weeks as an experiment.
Jeffgeerling.com has been migrated to Hugo
141–150 of 253 posts
Re: Jeffgeerling.com has been migrated to Hugo
#142Earlier quoted context omitted.
If you're okay with the images being on a CDN, why wouldn't you also be okay with the HTML and CSS also being on the CDN? Just fronting the entire static site with a pull-through CDN is an easy solution that doesn't require any complicated workflow.
I’m talking about integrating with GitHub. Publishing to Cloudflare for instance is fine, but where do you put the images between drafting and publishing? Or do you just check in images to GitHub and call it a day?
I commit the images alongside the markdown files in GitHub. My site is has numerous images and there are logical groups of posts. I make those logical groups of posts a git submodule, so I don't have all posts on my machine (or iPad) at one time.
Working Copy (git for iPad) handles submodules reasonably well, I have a few that I'm working on cloned on it and others are not so I don't use so much space.
Re: Jeffgeerling.com has been migrated to Hugo
#143What's the temperature on Pelican [ https://getpelican.com ] these days? Best Python SSG is mostly down to Hugo and Pelican as far as I can tell. I've always loved SSGs, but ActivityPub integration is also looking very attractive absent wider adoption of RSS.
I use pelican, with a bunch of self-made plugins, and it works very well.
There's a few commits every month, so it's not a dead project.
Re: Jeffgeerling.com has been migrated to Hugo
#144Earlier quoted context omitted.
What is the downside to committing the binary? Immunity to supply chain attacks and a faster build time?
The best of both worlds is hosting the binary independently of git in some cloud storage and just have a script that fetches it (and set it in .gitignore). git itself doesn't like binaries very much and it will bloat your git clone speed/size if you update the binary ad it will effectively store all versions.
The specific use case here is someone storing the binary because they're _avoiding_ updates.
Re: Jeffgeerling.com has been migrated to Hugo
#145I made the jump to Hugo too (from a managed service: svbtle) a long time ago, but I'll be really honest... I regret it. I decided to use an off-the-shelf theme, but it didn't quite meet the needs and I forked it; as it so happens Hugo breaks userland relatively often and a complex theme like the one I have requires a lot of maintenance. Like.. a lot . Now I can't really justify the time investment of fixing it so I j…
Why not go back to the version that your last post was published at, and stick with it?
I can try that version, but it's entirely possible (and even: likely) that I was already using an old version of Hugo then; whatever was installed by my package manager - assuming I updated my machine somewhat recently.
If I used MacOS then Hugo was probably very old, since I often forget to update brew packages and end up running very old software.
But, that's what I thought to do first also.
In the end, it becomes not worth the hassle, and spending time fixing it means that whatever I was going to write gets pushed out of my head, and it's very difficult to even bother.
I'll probably go back to Svbtle.
Re: Jeffgeerling.com has been migrated to Hugo
#146Earlier quoted context omitted.
I’ve slowly grown to realize there’s some software you just don’t need to update. A static site generator (almost certainly) won’t have security issues as long as you control the input and the output is just a bunch of static files. Unless the new version of the software includes some feature I need, I can be totally fine just running an old version forever. I could just write down the version of the SSG my site buil…
Is there any static site generator where you specify the version you use, and the launcher will simply run the old binary that you want? Like most build systems work, for example when you set a "rust-version" in Cargo.toml and only bump it when you explicitely want to. This way it will still use the older version on a fresh checkout.
Just wrap it in a Nix flake and define a devshell. The entire config won’t exceed more than ~10 lines of Nix.
Once setup, all you need to do is:
$ nix develop —-command hugo regenerate
$ # version is pinned by flake.lock
Re: Jeffgeerling.com has been migrated to Hugo
#147A few years ago, I decided to migrate my personal website to a Common Lisp (CL) based static site generator that I wrote myself. In hindsight, it is one of the best decisions I have made for my website. It started out at around 850 lines of code and has gradually grown to roughly 1500 lines. It handles statically rendering blog posts, arbitrary pages, a guestbook, comment pages, tag listings, per tag RSS feeds, a con…
How do you handle comments in a "static blog"?
On mine, I don't. Any interactivity is too much hassle for me to worry about wrt moderation etc. I also don't particularly care what random people have to say. If my friends like what I wrote, they can tell me on Signal or comment on the Bluesky post when I share the link.
Re: Jeffgeerling.com has been migrated to Hugo
#148Earlier quoted context omitted.
Shoehorn basic interactivity like comments? https://gohugo.io/content-management/comments/ This includes a giant list of open source commenting systems. I really don’t understand why people commonly say static site generators are a good candidate for building your own when there are a good selection of popular, stable options. The only thing I don’t like about Hugo is the experience of using other people’s themes.
Pretty much every single option there involved letting a 3rd party collect and own the comments. If you're fine for 3rd parties to own all your comments and content, why even take on the extra effort of hosting or managing or building your own website? That's basically what social media is for.
What do you mean? The list has more open source options than not. You can self-host those.
It’s going to be easier to self-host a drop-in comment system than an entire dynamic site plus/including comment system.
Re: Jeffgeerling.com has been migrated to Hugo
#149Earlier quoted context omitted.
How did you get to that position? Did you have to create the server side components to solve the SSG comments problem...?
I have always had a comments section on my website since its early days. Originally, my website was written as a set of PHP pages. Back then, I had a PHP page that served as the comment form. So later when I switched to Common Lisp, I rewrote the comment form in it. It's a single, self-contained server side program that fits in a single file [1]. It runs as a service [2] on the web server [2], serves the comment and…
Nice! So you weren't forced to rewrite a comments solution when you shifted to an SSG, you just coincidentally had to do them at the same time?
It looks like you did exactly what Jeff did: got fed up with big excessive server sides and went the opposite way and deployed and wrote your own minimal server side solutions instead.
There's nothing wrong with that, but what problem were you solving with the SSG part of that solution? Why would you choose to pregenerate a bunch of stuff which might never get used any time anyone comments or updates your website, when you have the compute and processes to generate HTML from markdown and comments on demand?
The common sales points for SSGs are often:
- SSGs are easier (doesn't apply to you because you had to rewrite all your comment stuff anyway)
- cheaper (doesn't apply to you since you're already running a server for comments, and markdown SSR on top would be minimal)
- fewer dependencies (doesn't apply to you, the SSG you use is an added dependency to your existing server)
This largely applies to Jeff's site too.
Don't get me wrong, from a curious nerd perspective, SSGs presented the fun challenge of trying to make them interactive. But now, in 2026, they seem architecturally inappropriate for all but the most static of leaflet sites.
Re: Jeffgeerling.com has been migrated to Hugo
#150I made the jump to Hugo too (from a managed service: svbtle) a long time ago, but I'll be really honest... I regret it. I decided to use an off-the-shelf theme, but it didn't quite meet the needs and I forked it; as it so happens Hugo breaks userland relatively often and a complex theme like the one I have requires a lot of maintenance. Like.. a lot . Now I can't really justify the time investment of fixing it so I j…
I'm on your side.
Nobody can point to a reason why it's a good idea for a site with any interactivity now.
All the supporters here are all the same: "I had to do a whole bunch of mental gymnastics and compromises to get but it's worth it!" But they don't say why it was worth it, beyond "it's easy now ".
When you try get to why they did it in the first place, it's universally some variation on "I got fed up with so took the nuclear SSG route "
Part of this is a me problem: a personal website should be owned by the person, IMO. A lot of people are fine to let other people own parts of their personal websites, and SSGs encourage that. What even is a personal website if it's a theme that looks like someone else's, hosted and owned on someone else's server - why not just use Facebook at that point?!