pilif

It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented.

Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening.

So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.

As far as I understand, the key material for any post quantum algorithm is much, much larger compared to non-quantum algorithms which leads to huge overheads in network traffic and of course CPU time.

[1]: https://eprint.iacr.org/2025/1237

Plus, keeping i386 the same also means any still available support for running 32 bit binaries on 64 bit machines.

All of these cases (especially the installable 32 bit support) must be as big or bigger than the amount of ARM machines out there.

(snark aside: I understand the arguments for and against making the change of i386 and I think they did the right thing. It's just that I take slight issue with the headline)

Why do I still know how to optimize free conventional memory in DOS by configuring config.sys and autoexec.bat?

I haven’t done this in 2 decades and I’m reasonably sure I never again will

A third party client was used whose only purpose was to log conversations. That third party client’s archive was then hacked.

Any client must by definition have access to the unencrypted data (in order to display it to the user). If you deliberately create a client that logs all communication, well, then all communication will be logged.

https://github.com/tailscale/tailscale/issues/3363

I’m using their MagicDNS feature with three domains and I think that’s the reason

yes. Battery usage is super bad, mainly because of their DNS features which forces every DNS resolution to go through their network extension. At least recent updates have stopped the background power usage when you disconnect from the network in the app.

>But tunneling traffic through them is extremely worrysome.

it only does that in case of super bad NATs that make the usual NAT traversal techniques impossible. And presumably, the traffic is end-to-end-encrypted, so it doesn't matter if they have to be in the loop.

If you don't trust them to properly end-to-end encrypt, then it really doesn't matter whether they are in the loop for forwarding a packet or not because if you don't trust them to encrypt properly, all bets are off to begin with.

If you trust them however, it doesn't matter where the traffic is flowing through because only the intended machine is able to decrypt it.

on iOS you also need a special entitlement that's only available on specific request and only to known developers, so practically impossible for any open source project to acquire.

The moment the inevitable enshitification will start at Tailscale, this feature will go away.

I’m saying this as a currently super happy Tailscale customer who was burned multiple times in the past by other companies being sold or running out of VC money

This gives certificate owners ample time to look for a different issuer and no certificate buyer would deliberately purchase a certificate from an issuer when they know some percentage of users will not trust that cert.

So for the end users, everything will keep working: the existing digicert certs stay valid and newly refreshed certs will be signed by a different authority. There is no need to turn off automatic updates over this.

Between Entrust and Symantec, we've already seen this happen to large well-known CAs and everything remained fine (not for the offenders, but, hey, that's the system working as intended)

In this case it's probably additional subterfuge in case somebody examines all notifications posted and sees apple and thus ignores it.

As a PHP developer myself, I'm still not clear as to why that warrants a submission to HN, much less a promotion to the front page.

What Ingot is an article about how to use libc bindings to make libc issue syscalls.

That’s not the same thing.

After pg_upgrade, no stats will be available for the optimizer which means that any query will more or less sequence-scan all affected tables.

From personal experience, most of the queries become useable after the first stage has completed which on my 8TB database took less than 5 minutes

I really wonder how an in-place `pg_upgrade` of such small amounts of data would take 30+ minutes.

My experience from a less mission-critical situation where 5 minutes of maintenance are absolutely acceptable is that an in-place `pg_upgrade` with `--link` of a 8 TB database takes less than a minute and will not accidentally lose data or fail to properly configure schema search paths or whatever other mess the article was talking about.

I understand that 30 minutes of downtime are not acceptable. But if it's 5 minutes or less, I would seriously consider an offline upgrade using `pg_upgrade`

And if it takes 30 minutes to hard-link less than 1 TB of data files, you should seriously consider changing hosts because that's absolutely unacceptable performance.

we're hosting some pretty unknown very domain specific sites and are getting hammered by Claude and others who, compared to old-school search engine bots also get caught up in the weeds and request the same pages all over.

They also seem to not care about response time of the page they are fetching, because when they are caught in the weeds and hit some super bad performing edge-cases, they do not seem to throttle at all and continue to request at 30+ requests per second even when a page takes more than a second to be returned.

We can of course handle this and make them go away, but in the end, this behavior will only hurt them both because they will face more and more opposition by web masters and because they are wasting their resources.

For decades, our solution for search engine bots was basically an empty robots.txt and have the bots deal with our sites. Bots behaved reasonably and intelligently enough that this was a working strategy.

Now in light of the current AI bots which from an outsider observer's viewpoint look like they were cobbled together with the least effort possible, this strategy is no longer viable and we would have to resort to provide a meticulously crafted robots.txt to help each hacked-up AI bot individually to not get lost in the weeds.

Or, you know, we just blanket ban them.

Or do you remember a 20+ random character string for each site and thus do not need a password manager?

1Password allows me to authenticate with my passkey in Safari (my default browser), Chrome and Firefox on macOS and Windows.

same as trying to recover a password: You go through the account recovery workflow.

My opinion on passkey is that they are a wonderful tool to speed up the authentication process with sites in some cases (which turns out to be most cases). Rather than typing your password (hopefully on the correct site...) and then sometimes confirming with a magic link or a 2FA code, all you do is use your platform native's authentication conformation method (face recognition, fingerprint, PIN code, whatever) and you're done. This works independently of which site you're on.

Just as with password managers: If you use the OS built-in solution, you're locked into a specific platform (though I admit that with passwords it's at least possible to move them manually, albeit super painful if the passwords are secure), so if you're using multiple platforms concurrently use a password manager that supports all your platforms - most if not all password managers these days support passkeys.

For all breakages related to passkeys, the same applies as with passwords: You use the account recovery flow (which often is the weakest link on any site).

As such, passkeys feel like a wonderful shortcut with even slightly improved security (you can't present a passkey to the wrong site) in the default case.

We upgrade the development environment around the time when our tooling (phpstan, cs-fixer) runs on the next version, but doesn't necessarily support new language features.

We upgrade the production environment when our tooling supports most of the new language features and at least all of the ones we want to make use of.

This usually happens within 3-6 months of the release. By that time the version has stabilized enough to be safe for production use.