Why Sponsor Oils? | blog | oils.pub

Things To Do For the New oils.pub Domain

Last week, on the old oilshell.org site, I wrote that Oils Will Move to the oils.pub Domain.

And then I wrote the final post: Oils 0.24.0 - Closures, Objects, and Namespaces. It belongs there because the corresponding tarball is published there.

So what's left to do before we fully migrate to oils.pub?

TODO

1. Publish the first new post.
   • That's why I'm writing this :-)
2. Create links both ways, e.g.
   • The old home page will be a pointer to https://oils.pub/
   • Link from the new oils.pub/blog/ to the old blog
3. Highlight important posts on the old site, like What Oils Looks Like in 2024

I'm not going to migrate all posts and other content. The redirects are a bit of a pain, and it's nice to have a clean start after 8 years.

But oilshell.org will remain up forever, as a historical archive. There's still useful knowledge there! I'm glad that people still read it.

4. Check that the analytics job works on the new domain.
   • Many years ago, I wrote my own analytics scripts that read Apache's access.log. We don't burden your computer with Google Analytics!
5. Maybe remove obsolete entries from the Cross Reference, which I copied from the old domain. Again, it's nice to have a clean start!

Enhancements

6. Create friendly pages for OSH and YSH.
   • I noticed that more people are visiting the site, which is good! But we don't have short, friendly intros.
   • The YSH page will likely be based on Seven Parts of YSH
7. Mirror portions of the Wiki https://github.com/oils-for-unix/oils/wiki to the oils.pub domain.
   • Github has a quirk where it doesn't make wikis searchable.
8. Long term: Implement git push-to-deploy.
   • I've been using make and rsync this whole time! But they've run their course.

I've mentioned that I should have used Ninja rather than Make. I learned and wrote 3 Makefiles from scratch as "research" for Oils, but now I think that Make is pure legacy.

It may be hard to match the speed of rsync, but the timestamp-based syncing is fiddly because I use multiple computers to publish to the site.

So git push-to-deploy is natural alternative, but I wonder if there is a way to avoid building the entire blog on every push. CI services like sourcehut and Github Actions are stateless, so incremental builds won't work.

Let me know if you have a solution in the comments!

Releases

Note that there are already 2 releases on oils.pub:

• Oils 0.25.0 - I briefly mentioned this in the post about oils.pub
• Oils 0.26.0 - Build fixes, and more bash compatibility

I hope to write an announcement for them, but there is a lot to do!

Conclusion

See you on oils.pub from now on! I will no longer publish anything to oilshell.org.

Appendix: Dreamhost SSH Has Become Unreliable

I wrote about similar problems in June: Comments on Scripting, CGI, and FastCGI. This site was put on a new machine, and the OS configuration has bugs. They don't appear to affect serving, but they affect deploying.

I don't really want to migrate to a new web host, and the alternative hosts aren't better in every dimension, like network speed, disk speed, and the base OS image.

But I suppose now is a good time to do it, since we have a new site. And 15 years is a pretty good run for Dreamhost.

I've already mitigated the problems by:

1. Moving from FastCGI to CGI
   • which means that wwz is slightly slower
2. Disallowing crawling of .wwz files in robots.txt
   • There are many dumb crawlers out there, and those pages are mostly test and benchmark results.

And I've contacted support multiple times. So the only thing left to do is to migrate ...

I might do that when I figure out git push-to-deploy.