xPaw

That proposal has existed for 4 years, it hasn't gone anywhere yet.

I wish browsers also supported directly running typescript files.

Githubs performance has been rapidly degrading ever since they started rewriting everything in React.

It's basically impossible to view diffs now because they often fail to load, render correctly, or just are incredibly slow.

Slow IO is why I still use wsl1.

Yeah, I made a userscript for myself to fix that up: https://gist.github.com/xPaw/4fffaf776fe14d15c9602991f51dbfa...

You don't need to convert querySelectorAll to an array, you can directly iterate it, or use forEach.

With Cloudflare Fonts enabled, you are able to see within your Network Tab that font files are now loaded from your own hostname from the /cf-fonts path

Is there a particular reason why is it not using /cdn-cgi/ prefix?

Link? I don't see this in ToS.

Likely blocked by Firefox tracking protection because it uses Facebook domains.

This is a good move for the secure-by-default move.

In The Lounge IRC client, we've also opted to this approach years ago, where secure connections show no icon, and insecure connections show an insecure icon.

It really is bizzare, old Firefox used to support all addons, then they shipped a new version and only allowed like 10 addons, and to this day they don't allow any more. It's already been years.

I know my addon works fine on mobile, but they provide no means of specifying that*. I tried to email them for it to become "recommended" but never heard back.

The fact that they allow tampermonkey which allows any kind of script just adds insult to the injury.

* when uploading a new version, it does ask to specify which Firefox desktop/android versions are supported, but this existed before the new Firefox and doesn't do anything.

Everything is done on a single server. What makes you think it's low?

Games gifted to the bot are used to gain access to some extra info.

I do get game gifts to my personal account from time to time.

I know some Valve employees use it.

Hetzner.

That's still correct.

I can, but I have no interest in doing that currently.

SteamDB: https://steamdb.info/

I've been running it for over 10 years now, it's a database of Steam games, their updates, price history, charts, and a lot more.

In the early days we took monetary donations but stopped a few years in. It costs less than 100$ a month to run. Cloudflare reports 552.2M requests in the past 30 days, and 6.09M unique visitors.

I have tried using cloudflare's client certificate, but it doesn't play well with nginx ssl cache due to increased size on a relatively high load website.

I purchased it directly from their site, and there is no upgrade option either.

Heck even a tweet at the owner might be good enough.

I disagree with this, don't spam people. Sometimes people even go out of their way to contact you using multiple channels and it gets even more annoying.

Github also can't send webhooks to ipv6 only hosts.

What I find mildly curious, that's also the only place where a length was provided as an argument into `Gitlab::Password.test_default`.

How different is this from "I don't care about cookies" extension?

I rarely see websites that actually make use of `:visited` style as intended, it would be good if browsers had an option to just disable it and prevent this class of leaks completely.

Another big mistake with defaults is that you need an explicit `server` block with `default_server` for all the `listen` directives you have.

Otherwise if you have a listen directive for some host that doesn't have a default, this server will be used as the default for this particular listen directive.

For example doing `listen 80` and then requesting any non matching host will still return this server.

I have experimented with IPv6 only, but a lot of stuff still doesn't support it. For example Github and Discord webhooks fail to send.

The word list is in Wordle code, so you can just grab that.

It's currently returning 502 Bad Gateway, so the title is very fitting.

There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization.

We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.