• 0 Posts
  • 23 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • My Linux laptop is set to check for updates daily, which I then apply manually when I notice the tray icon. I sometimes procrastinate when it comes to reboots though.

    My Android phone is on auto-update, which seems to mean whenever it’s being charging for a few hours (so typically when charging overnight). Because the battery is still pretty good and I don’t need to charge daily, that comes down to once every 2-3 nights or so.

    My personal Linux servers (which run my self-hosted apps) are configured to automatically apply all updates (and reboot if necessary afterwards) at the time of day I’m most likely to be awake and available to manually fix stuff if anything goes wrong. The Docker-containers that run on them mostly get auto-updated to the latest version every 6 hours by Watchtower. A few containers have more cautious policies though, ranging from pinning a major version (but auto-upgrading to new minor versions within that) to pinning a specific version and at most sending a notification if there’s an update. The latter is limited to stuff that has broken before and/or where newer releases are known to be buggy or incompatible.

    When it comes to major updates (i.e. new distro releases) of my Linux machines, I typically wait about a month before upgrading because I’ve been bitten by release-day bugs before.




  • You don’t actually have to set all the modification dates to now, you can pick any other timestamp you want. So to preserve the order of the files, you could just have the script sort the list of files by date, then update the modification date of the oldest file to some fixed time ago, the second-oldest to a bit later, and so on.

    You could even exclude recently-edited files because the real modification dates are probably more relevant for those. For example, if you only process files older than 3 months, and update those starting from "6 months old"1, that just leaves remembering to run that script at least once a year or so. Just pick a date and put a recurring reminder in your calendar.

    1: I picked 6 months there to leave some slack, in case you procrastinate your next run or it’s otherwise delayed because you’re out sick or on vacation or something.








  • In fact, unless you post your domain somewhere online or its registration is available somewhere, it’s unlikely anyone will ever visit your server without a direct link provided by you or someone else who knows it.

    If you use HTTPS with a publicly-trusted certificate (such as via Let’s Encrypt), the host names in the certificate will be published in certificate transparency logs. So at least the “main” domain will be known, as well as any subdomains you don’t hide by using wildcards.

    I’m not sure whether anyone uses those as a list of sites to automatically visit, but I certainly would not count on nobody doing so.

    That just gives them the domain name though, so URLS with long randomly-generated paths should still be safe.






  • You produce a hundred 24 core cpus, then you test them rigorously. You discover that 30 work perfectly and sell them as the 24 core mdoel. 30 have between one and eight defective cores, so you block access to those cores and sell them as the 16 core model. Rinse and repeat until you reach the minimum number of cores for a saleable cpu.

    Except the ratios of consumer demand do not always match up neatly with the production ratios. IIRC there have been cases where they’ve overproduced the top model but expected not to be able to sell them all at the price they were asking for that model, and chose to artificially “cripple” some of those and sell them as a more limited model. An alternative sales strategy would have been to lower the price of the top model to increase demand for it, of course, but that may not always be the most profitable thing to do.




  • You can only federate via tor or i2p if both sides support those protocols, because for federation to work between two nodes both nodes need to be able to initiate connections to the other. That means one-way bridges like tor exit nodes are not sufficient.

    I’d guess most Fediverse servers don’t support either of those protocols, so any new server trying to federate solely through them would have an extremely limited view of the Fediverse.

    Though I suppose theoretically nothing is really preventing a motivated group of server admins from setting up a parallel “dark Fediverse” containing only onion sites.