Here's an update from the admin. They say it might stay down until Christmas.

It was a bit of a day at work, I must say.

It started well, we were only minimally affected by the PHP apocalypse. Only two services to update, neither of them mission critical AND even better, both were already on fairly recent patches, so updating them was pretty much a five-minute job once the patch was released.

Then we had a bit of a TLS issue, not related to eMudhra tho. Our public TLS certificates auto-renewed yesterday, routine stuff. But today two different clients complained that their browsers were giving them SSL errors. After a bit of back and forth, it turned out that our cert provider had switched to a new CA, and the IT departments at those two clients had, for some reason, pinned our domain to a specific CA and that had now to be updated. I can fully understand this kind of setup for internal CAs and such, but our service is on the public internet and uses a well-known SSL provider. This is the first time we've encountered something like this. I'm wondering whether it's common for IT departments to do this. If so, why? Anyway, one customer had no problem with this, but the other tried to blame the “downtime” on us. Apparently, they expect us to warn them at least two weeks before rotating TLS certs. Trying to explain how ACME works didn’t help.

Final headache of the day, one of our developers forwarded me an email they'd received from Atlassian. At first, it looked like a scam attempt (it started with something like "You need to make changes immediately!"), but it turned out to be real. Apparently, Bitbucket is changing their SSH endpoint. While that doesn't seem like a too big deal, their messaging about it is just absolutely horrible. The deadline is in less than a month(!), but almost all their documentation still refers to the old endpoint. Even https://bitbucket.org/site/ssh still only returns the old hostname! I was really confused where to find the new host keys, but apparently they've decided to use the same host keys for the new hostname. That seems a bit odd to me, but it’s whatever... Then as a final F from Atlassian, when I tested connecting to the new hostname, the whole of Bitbucket went down. You can't make this stuff up! Okay, I don't think my connection attempt was what actually crashed it, but still, I wouldn’t be too surprised even if it was.

Found it on Bluesky here and in the replies there's a link to Patreon, maybe that's it?

Edit: Looking at the publicly available posts in that Patreon, the artist seems to have a similar style. I'd say it's definitely from them.

I've been using ldns.pl since I saw a post about it here in Lemmy a year ago or so. Zero problems so far.

I think the OP is asking why Debian doesn't do it automatically. It can't just remove the old kernel immediately, because what if the new one fails to boot or otherwise doesn't work? It's good to keep an older kernel around so you can go back to it if necessary. In theory, they could implement some logic that automatically removes older kernels while keeping the latest one or two untouched.

But generally I agree it's the user's responsibility to make sure they have enough disk space available and to clean up when necessary.

This is one of the reasons why I don't use a separate partition for /boot anymore. As I understand it, a separate /boot partition is mostly a legacy thing unless you have an encrypted root partition or some other special setup. For simple cases I recommend having /boot on the root partition to avoid issues like this.

I think that's also the default setup used by the Debian installer if you select Guided partitioning – use entire disk. I'm not 100% sure tho.

On varmasti, mutta ymmärtääkseni ensin pitää antaa X määrä varoituksia yms. Ja miten edes todistat tupakoinnin tapahtuneen jos vuokralainen ei sitä itse myönnä?

I'm in the 2027 gang, damn. Oh well, on the bright side I basically have an extra 1k disposable now.

What I don't understand is why Valve didn't share this information from the beginning. Their communication led to believe that everyone who landed into the reservation queue would receive theirs within weeks, or within 1-2 months at most. Making us first wait almost a month only to be like, 'btw, you're not getting yours until next year' is a really shitty way to treat your customers.

Röökaamisen täyskielto ellei muuta ole erikseen vuokrasopparissa sovittu on kyllä erinomainen parannus. Mutta luulen, että kiellon rikkojan häätäminen on edelleen pitkä ja hidas prosessi.

Basically yes, but it won't happen immediately or quickly. It's very unlikely any domain would be revoked just like that, but they might eventually stop registering new ones and accepting renewals. ICANN has a retirement policy that they will follow.

Interestingly, this is relevant to the popular (among tech bros) .io domain, which belongs to the British Indian Ocean Territory, a small cluster of islands in the Indian Ocean that is currently in the process of being transferred to Mauritius. That might mean .io domains will eventually be phased out.

As others have mentioned, adblockers seem to break it somehow. It's probably not intentional. The page doesn't serve any (actual) ads, so it's safe to try disabling your ad blocker. For me, refreshing the page a couple of times also fixed the issue even with uBO enabled.

Happened to me too, had to reload a couple of times. Not sure if it was intentional, but realistic anyhow xD The only thing missing is random loading times between each step.