If you only take the bottom (lowest) 1% of all frame rate measurements (and average them)

I don’t think that is the methodology. I think it is taking the 99th percentile frame time. So basically if took the time it took to generate every single frame this is the time that 99% of frames were faster than and 1% were slower than.

If this number goes down it means that the worst frames are less bad. This is a pretty important part of the experience as even if you have good average frame time (and decent FPS) having a few slow frames really makes the game feel choppy and can make precise inputs difficult.

Honestly AI has been used for moderation for decades. The newer models will be quite effective. It could be very useful for limiting lower effort spam. Sure dedicated spammers will figure it out and get by it but as the models get better that will get harder.

Of course like every use of probabilistic technology like AI it should still go to human review. We shouldn’t be shadowbanning people because computer said no. But holding suspicious posts in a review queue for the moderators seems quite reasonable (much like they already do with their current systems).

Honestly this sounds more like an investor update showing how innovative we are using modern technology and how it is going to really improve the platform and stonks will go up up up than any meaningful change to their current moderation systems.

Every team has a QA environment. The fancy ones have a separate production environment.

In most distros shutdown is a symlink to systemctl.

declaring multiple variables is less error-prone than in C. In C, the following declares x to be a pointer, but (surprisingly at first!) y to be a normal integer:

int* x, y;

Whereas the equivalent in Go does what you’d expect, declaring both to be pointers:

var x, y *int

I don’t think this is a related at all. C could have easily decided that the definition makes both x and y pointers. They just decided not to so that you can declare more variables on one line by being able to do int x, *y, **z, .... It is more flexible.

Similarly that Go line could have been parsed like var x, (y*) int if they wanted to. They just made a different choice.

I’ve definitely ran into the situation where I fucked something up half-way though installing a new distro, then had to wipe it to go back to an old distro so that I could access the internet and find out what I did wrong so that I could start from scratch.

I hate doing debugging on my phone, but man sometimes is it better than the alternative.

Because not everyone has or wants credit cards. Children can’t get credit cards. Code cards are also useful for gifts.

I think you are right that even less people will buy them than physical games, but I don’t think they will be irrelevant.

Trump doesn’t appear to care much about the law.

I understand that this is frustrating but it is arguably the right option. If the correct owner can recover the account without TOTP then the TOTP isn’t really protecting the account.

Of course there are various ways to authenticate and it can make sense to have authentication to be (username + password + OTP) OR (email verification) but for a lot of people that email verification is a weaker link. It is more secure to only allow the former.

What I wish is that more sites would document their account recovery procedure. Often times they ask for a phone number for verification or notifications and that silently becomes a backdoor into the account. Even better would be if users can select what authentication combos are supported on a per-account basis (there are a few companies with “lockdown” settings that are a simplified version of this).

Of course it then becomes important to make it clear to the user “if you ever loose you X your account is forever lost”. It shouldn’t be surprise.

This advice feels like “Have you moved to the surface of the sun? Make sure to drink lots of water.” It’s not wrong, but also not particularly helpful. The only solution is to stop buying these things. Ideally take them back and get a refund if it isn’t too late.

We have all evaluated the options. Most of us decided that sewing was in fact too extreme.

Generally speaking it will be fine. SSH will also refuse keys with open permissions so you would notice if it was wide-open to other users of the device.

But you know if you are running random code or AI harnesses as that user it can be at risk. Or if you copy around the key all over the place it is more likely to leak. But generally speaking you are secure by default, just don’t do something dumb with the key and you’ll have no problems.

It sounds pretty reasonable. As long as you keep SSH patched and keep the key safe it should be quite locked down. Do double-check that password login isn’t allowed (or that all users have a very strong password).

One non-security note is be careful with rsync backup. Generally rsync isn’t considered a backup as any mistakes made in the source will be propagated to the “backup” on next sync. Although there are ways to use rsync to take good backups (like copying to a new directory for each backup).

Why only streaming services? Why not target the volume of any ads within content that contains audio? While we are at it why not say that the add can’t be significantly more bright?

I built Chibichange to have a way to conveniently deliver changelogs to Dawarich users

Have you considered just posting a changelog to your blog? That would be much more convenient than every app I run pinging me in its own way by phoning home to its server.

Yes, on one hand every commit to nixpkgs needs review (to some degree) on the other hand there are far too many committers to nixpkgs.

There are also gaps such as the bots to auto-merge packages with maintainer approval, so a simple attack looks like this:

1. Submit a package with you as a maintainer.
2. Create a new GitHub account and send a malicious update to that package.
3. Use a bot to merge with maintainer approval.

So nixpkgs is better than the AUR, but it isn’t great and unlike Arch has no separate official repos.

The problem is that only your heaviest users are going to pay to remove the ads, so it doesn’t make sense to price the subscription at any sort of average user. You need to slide the price point way up the distribution just to break even.

Oof, that is really not a good look. This should have been clearly disclosed and probably with a per-notification for the patch release.

There are a few main benefits.

1. For hardware-backed keys they can’t be stolen aside from physically stealing the hardware. So unless your machine has malware there is no way for an attacker to authenticate using them.
2. Even for software keys the site you authenticate to doesn’t learn enough to impersonate you. For example if for some reason your bank leaked some logs with PW + MFA someone could use that to log in as you (although admittedly short timeouts on MFA validity makes that window very small).
3. The browser ensures that you only authenticate to the correct domain. So it prevents phishing. (Although a password manager that only fills into the correct domain also accomplishes this.)

So I think if you are using unique passwords with an automated password manager the effective benefit is quite small. However for the “average computer user” who likely has less than 5 passwords that they use for everything it forces a pretty high base level of security.

I doubt Gaussian blur is an accurate model of real-world situations.

At the end of the day if you are worried about the codes being painted over print a few out and paint over them. Then scan with a variety of scanners.

If I had to come up with some more digital tests I would guess that a few of these are more representative of real-world situations:

1. Lower contrast. For example lighten or darken the whole code. This would simulate things like scanning in low light or with glare.
2. Block out sections of the code. This will test error correction levels and simulate partial damage or pockets of extreme glare.
3. Skew the code in various ways. This simulates the perspective shift of people scanning the code from an angle.

Ideally combine them in a bunch of scenarios then try to scan with a variety of scanner implementations.