7
votes
What programming/technical projects have you been working on?
This is a recurring post to discuss programming or other technical projects that we've been working on. Tell us about one of your recent projects, either at work or personal projects. What's interesting about it? Are you having trouble with anything?
Last weekend I published https://ichi.city. It's like Neocities but simpler and with less features. It's inspired a lot by flounder.online but for the web. I'm a big believer that not everything we create needs to make sense. I'm hoping it inspires people to build quirky and fun pages.
This is really cool! I was pretty deep into Geocities back in the day. What are the free storage/bandwidth limits here?
Thanks a lot! It's 10MB per site for now, and the whole server shares 4GB of bandwidth per month.
I got a 2-Bay QNAP NAS recently that I've been setting up. It's Intel-based, so not being one to trust the proprietary stock OS, I threw Debian on it. The stock OS had been installed on a small memory card (~4GB) that was too small for Debian, so I made a smaller (~30GB) partition on the HDDs for the OS, with the rest of the drive mostly taken up by a big mirrored storage partition.
Problem is that some process is writing to disk pretty frequently, and the drives/enclosure are somewhat noisy - not terribly so, but enough to be noticeable in my cramped office. My plan is first going to be taking a look at iotop and /var/log timestamps, but it got me thinking: Has anyone played around with something along the lines of mounting /var/log as a temporary in-memory partition and using a cronjob to periodically persist logs from the temp partition to disk? I.e. creating a filesystem-level buffer to minimize the number of disk writes at the expense of some potential data loss?
Update answering my own question: Looks doable - use tempfs to create an in-memory partition, mount it as
/var/log, set up a cronjob to transfer logs to the real, on-disk log directory usingrsyncwith the--appendflag and then wipe the directory again (to limit amount of memory needed). Would have to fiddle with the journald conf too, I think, to turn off log rotation.Rsync's
--remove-source-filesoption might be helpful here.For your overall goal it might also be worth looking into power saving options if your hardware supports it. Some of them are geared towards reducing disk writes / keeping disks spun down. For example:
https://www.kernel.org/doc/html/latest/admin-guide/laptops/laptop-mode.html#the-details
No clue if that would help with your particular use case, I just remember it from when I was setting up a new laptop not too long ago.
I reworked the way links are handled in my static site generator. The SSG is designed so that it's easy to add documentation to an existing project. It's executed as a GitHub Actions pipeline. What it does is takes the repo's main
README.mdalong with the markdown files in thedocsfolder. It converts those into HTML files and publishes the site on GitHub Pages.One thing that's tricky is that I also want the markdown files to stand on their own. This means that to link to another markdown file, you'd do
[Other file](./b.md). I like this because it means the docs aren't bound to the SSG. The SSG just gives a nicer view on them.To get clean URLs, a file called
docs/a.mdends up at/a/index.html. Or/docs/nested/b.mdends up at/nested/b/index.html. The main README.md ends up at/index.html. This requires rewriting links so they still work in the context of the generated site.For a while I was keeping relative links relative, but then I also wanted to support linking to other files outside the
docsfolder. For example[Go to src](../src/). These types of links should instead get rewritten to the GitHub repo.Given this structure:
I ended up with this conversion table from inside the main README.md:
Outbound / Other:
Relative:
Absolute:
It was annoying to implement, but at least it seems to work for all the links I throw at it.