Perhyte

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"¹, 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.

¹: 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 a rather large part of the world (the solid green parts of that map).

Small correction: Pi lies between 2^1 and 2^2, so its floating-point exponent is 1. With all the mantissa bits cleared you’d be left with 1 * 2^1, not 1 * 2^0.

Have you considered putting alias htop=btop (or equivalent) in your shell profile?

It’s nice in theory, but I’ve had very little luck using it for the last few days.

I wouldn’t be surprised if whatever instances it picks to send people to are soon afterwards rate limited because demand is too high relative to supply.

If this is something you run into often, it’s likely still only for a limited number of servers? ssh and scp both respect .ssh/config, and I suspect (but haven’t tested) that sftp does too. If you add something like this to that file:

Host host1 host2
  Port 8080

then SSH connections to hosts named in that first line will use port 8080 by default and you can leave off the -p/-P when contacting those hosts. You can add multiple such sections if you have other hosts that require different ports, of course.

Assuming they went to signed 64-bit time, it should be about 3:28:32 pm UTC on Sunday, December 4, 292277026596. Yes, that last number is a year.

!distrohopping@lemmy.world - no posts yet though.

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.

Just checked, registered since at least 2018. The .org and .net variants are still available though!

I recently got temporarily IP-banned from a site, apparently for subscribing to one of their RSS feeds and occasionally opening a post. The error page they served me (instead of the content I wanted to read) accused me of “botting”. Why even have RSS feeds then? 🤷‍♂️

There’s a bit more to it than captured in the summary, which is why it’s just a summary of the spec and not the actual spec.

From a bit further down on that page:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Lemmy is still in major version zero, so it can make breaking changes without incrementing the major version and still be in compliance with the spec. This way, projects won’t have their first “real” version be something like v123.0.0.

Lemmy still being v0.x also serves as kind of a warning to app developers that changes like this may be made at any time.

My family shares a fairly uncommon surname with a professional athlete we are (as far as we can tell) completely unrelated to.

My father always joked that we should answer “we don’t discuss that” when asked about it, as if there had been some huge falling-out.

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.

We did build stuff on ActivityPub: Lemmy, Kbin, Mastodon etc. are all based on that underlying protocol.

Because you need a way to be reachable over HTTPS for other instances to be able to securely send you updates (new posts/comments/votes etc.), so you need a trusted certificate. While HTTPS does not strictly require a domain name¹ it vastly simplifies the process.

¹: It’s possible to get a trusted certificate for an IP address, but not nearly as easy as getting one for a domain. And it’s probably also more expensive than just getting a domain and using Let’s Encrypt to get a certificate.

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.

It was the third time. Rutte I, III, and IV all fell, but Rutte II served its entire term (though there were still some interim changes in its composition due to a few resignations of individual ministers).