3 ms·

I agree it could have been phrased more nicely, but it actually pointed out something valid, which I didn't catch at first. The author hasn't written any posts

by chubot 6y ago

I agree it could have been phrased more nicely, but it actually pointed out something valid, which I didn't catch at first. The author hasn't written any posts in 5 years, and has ~15 total since 2010: https://blog.steren.fr/ https://blog.steren.fr/ As someone who blogs regularly, I'm more interested in the toolchain of people who HAVE done significant writing. I read blogs for at least a decade before I wrote one, and it's harder than it seems, and coercing a good result out of tools isn't easy. In fact I just wrote a few of my own tools to fix the image problem, e.g. http://www.oilshell.org/blog/2021/01/blog-roadmap.html#unix-y-web-services-i-wrote http://www.oilshell.org/blog/2021/01/blog-roadmap.html#unix-... Basically, the author's strategy is not likely to last (though it's not impossible). My blog started out very minimal, but as you write, you bump into the need for more automation and tools. My site looks very simple and minimal, but there is a surprising amount underneath. Funny comic: https://rakhim.org/honestly-undefined/19/ https://rakhim.org/honestly-undefined/19/ When I was writing those tools I often wondered if we should just go back to Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! I remember trying it briefly in the early 2000's. Although his blog also rotted due to CityDesk rotting! It's a hard problem. https://www.joelonsoftware.com/2016/12/09/rip-citydesk/ https://www.joelonsoftware.com/2016/12/09/rip-citydesk/

cxr 6y ago
> it could have been phrased more nicely That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be. > Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! Among the things that Microsoft first started pushing to GitHub around the time that they formed the .NET Foundation was Live Writer. <http://openlivewriter.com http://openlivewriter.com> Dave Winer's Frontier is open source, too, but has also rotted. Brent Simmons, the creator of NetNewsWire, set out within the last couple of years to recreate it as a modern Mac app, but dropped the project last summer. > Although his blog also rotted due to CityDesk rotting! It's a hard problem. I'm convinced that we've missed the obvious and have been doing it all wrong, due to predilection for certain systems and ways of working. If you have a personal homepage, you should have among the stuff hosted there a document that describes how your site is updated. This document should be less of a blog post than an SOP. But now make sure it's specified with enough rigor that you can feed the same document into a machine that can perform those steps automatically. The reason the "WordPress setup from 2004" works and "old-ass blogger.com site" work is because they're closer to this ideal than Jekyll or Hugo or the others are. The caveat is that the hosted services make it really hard to actually look over the procedures that the machine will run, and if they let you, then you'd find that they were spread out over multiple "documents". Whatever the case, the thing not to do is to have this sort of thing live out-of-band elsewhere as a tool that requires its own configuration and setup (with both the tool and the configuration being subject to rot) accompanied (if at all) by a terse README. (Otherwise, if you're keeping that sort of thing elsewhere, then your homepage is not really a true digital home, is it? It's a Potemkin palace, and the place where those other things live is your real home.)
- chubot 6y ago
  Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1] I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build your blog. Basically check in a spec for a container (Dockerfile) into VCS. It's done off of your machine, and it will "never" rot. You still have the cloud portability problem, and the "shell scripts and YAML are gross" problem. But those are solvable, especially for the relatively simple case of building a blog. I'm working on that: https://news.ycombinator.com/item?id=25343716 https://news.ycombinator.com/item?id=25343716 [1] I think it's funny that VC's use non-startup platforms for their own blogs, because they know that blog platforms do not last. https://blog.samaltman.com/ https://blog.samaltman.com/ https://posthaven.com/ https://posthaven.com/
  - cxr 6y ago
    > now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS This is an example of the "predilection for certain systems and ways of working" that I referred to. > it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) That's not really what I meant. My reference to WordPress was probably more misleading than I intended. I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes". (This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.) That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter. The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing <500kB without even trying is pretty easy. My prototype is actually currently at 109kB, but that just covers the build SOP. Albeit, that is both man- and machine-readable (i.e. machine-executable), so it's detailed to a high degree of rigor. That's one long document that includes stuff like formally describing how the SHA-1 algorithm works, how Markdown gets processed, how templates and includes work, and so on. The adapter doesn't really exist, though; since it's a static site, it's just a note that says, essentially, "use rsync; here's the hostname and the exact command-line flags". In the document specifying how building the content from source works, I punt on specifying YAML, because a drastically simpler subset (i.e. colon-separated, key-value fields on separate lines) was able to accommodate 100% of how my frontmatter already looked. I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.

by chubot 6y ago

cxr 6y ago

> it could have been phrased more nicely That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be. > Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! Among the things that Microsoft first started pushing to GitHub around the time that they formed the .NET Foundation was Live Writer. <http://openlivewriter.com http://openlivewriter.com> Dave Winer's Frontier is open source, too, but has also rotted. Brent Simmons, the creator of NetNewsWire, set out within the last couple of years to recreate it as a modern Mac app, but dropped the project last summer. > Although his blog also rotted due to CityDesk rotting! It's a hard problem. I'm convinced that we've missed the obvious and have been doing it all wrong, due to predilection for certain systems and ways of working. If you have a personal homepage, you should have among the stuff hosted there a document that describes how your site is updated. This document should be less of a blog post than an SOP. But now make sure it's specified with enough rigor that you can feed the same document into a machine that can perform those steps automatically. The reason the "WordPress setup from 2004" works and "old-ass blogger.com site" work is because they're closer to this ideal than Jekyll or Hugo or the others are. The caveat is that the hosted services make it really hard to actually look over the procedures that the machine will run, and if they let you, then you'd find that they were spread out over multiple "documents". Whatever the case, the thing not to do is to have this sort of thing live out-of-band elsewhere as a tool that requires its own configuration and setup (with both the tool and the configuration being subject to rot) accompanied (if at all) by a terse README. (Otherwise, if you're keeping that sort of thing elsewhere, then your homepage is not really a true digital home, is it? It's a Potemkin palace, and the place where those other things live is your real home.)

chubot 6y ago
Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1] I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build your blog. Basically check in a spec for a container (Dockerfile) into VCS. It's done off of your machine, and it will "never" rot. You still have the cloud portability problem, and the "shell scripts and YAML are gross" problem. But those are solvable, especially for the relatively simple case of building a blog. I'm working on that: https://news.ycombinator.com/item?id=25343716 https://news.ycombinator.com/item?id=25343716 [1] I think it's funny that VC's use non-startup platforms for their own blogs, because they know that blog platforms do not last. https://blog.samaltman.com/ https://blog.samaltman.com/ https://posthaven.com/ https://posthaven.com/
- cxr 6y ago
  > now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS This is an example of the "predilection for certain systems and ways of working" that I referred to. > it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) That's not really what I meant. My reference to WordPress was probably more misleading than I intended. I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes". (This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.) That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter. The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing <500kB without even trying is pretty easy. My prototype is actually currently at 109kB, but that just covers the build SOP. Albeit, that is both man- and machine-readable (i.e. machine-executable), so it's detailed to a high degree of rigor. That's one long document that includes stuff like formally describing how the SHA-1 algorithm works, how Markdown gets processed, how templates and includes work, and so on. The adapter doesn't really exist, though; since it's a static site, it's just a note that says, essentially, "use rsync; here's the hostname and the exact command-line flags". In the document specifying how building the content from source works, I punt on specifying YAML, because a drastically simpler subset (i.e. colon-separated, key-value fields on separate lines) was able to accommodate 100% of how my frontmatter already looked. I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.