SudoAlex's comments

There have been rule changes to equipment at different levels to help counteract some of the issues with two handed bowlers, and modern bowling balls.

(Note: I bowl in leagues in the UK, so definitely not at a competitive level).

Back in August 2020 balance holes were banned by the USBC (and therefore applied internationally), which would have a greater impact on two handed bowlers - as they don't insert a thumb in the ball, it gave them the potential for two balance holes instead of one. Currently every hole drilled into the ball must be used during the release of the ball.

More recently certain competitions (PBA mostly) are restricting the use of urethane balls to ban any balls which don't meet a minimum level of hardness. This hasn't been applied at a wider level yet, although it may have an impact over time.

https://www.pba.com/2023/june/2023-pba-hardness-report

So things are changing, but it's mostly reactionary rule changes as new problems are being discovered.

They already do something - the oil patterns they use on the lanes is considerably different for open/league bowlers compared to competitive bowlers.

However the professional bowlers will have the skill, experience and equipment to deal with all the different oil patterns.

Sony ZV-1, Elgato Cam Link 4K, and a few other minor accessories (eg. lighting).

A huge amount of time is spent on video calls these days, and although there are more advanced webcams out there these days - a camera which is geared towards video (the ZV-1 is aimed at vlogging) will produce significantly better video for any calls you're on.

Spending a little bit of time optimising your setup so that you're the one in the call with good quality video/audio is worth it. Get a decent camera, get a good microphone, improve your background lighting.

Technically CloudFront requests to the origin server are IPv4 only, so there's still IPv4 in the stack even if the distribution has IPv6 enabled.

Personally this is one area I'd like AWS to focus on, along with load balancers listening on IPv6 only (currently it's dual stack). Every load balancer we deploy takes up at least 3 IP addresses - I'd quite happily switch them to being IPv6 only if CloudFront could access them over IPv6.

As someone learning stenography (but with a different keyboard) - try it and see, however your ability might be hindered without the right keyboard, key switches and keycaps.

I bought an ortholinear keyboard with DSA keycaps to get started, which is absolutely fine when you're chording fairly simple words, however once I reached a point where words involved chording multiple keys from the top and bottom rows - it started to become a little bit painful. After switching to F10 keycaps [1], it made a huge difference in the enjoyment of chording more advanced words.

[1] https://pimpmykeyboard.com/f10-flat-key-keyset/

Same here - a price increase makes you reconsider the relationship you've got with the service you're using. Companies should strongly consider leaving existing customers alone with legacy plans rather than aiming to extract as much revenue as possible.

For me Dropbox didn't do that, so instead of happily leaving our existing business account for most team members - we re-evaluated our usage of it, limited it to just a few accounts with the aim of getting rid of it entirely.

At that point it's not something you'd consider recommending it in passing to other people.

Or you do nothing wrong on your server, but another user using your mail server ends up with a compromised password, or reuses the same username/password from elsewhere as their mail login. You wake up and see thousands of outgoing emails in your mail queue, all from the spammer, followed by other users who can't send outgoing emails.

You could attempt to limit the outgoing emails per account per hour, however if that's set too low then you end up with other users who can't send out emails to their "mailing lists" consisting of hundreds of contacts, instead of using a real mailing list to manage it.

The effort just isn't worth it.

The correlation could also be the fact that you've blocked the attack, they can see that their previous attack is no longer working by testing it themselves - so they'll switch anyway, regardless of a status page update.

The feature isn't enabled by default, you'll need to set linked_clone to true:

https://docs.vagrantup.com/v2/virtualbox/configuration.html

Is it that difficult to setup, or are people biased against it when something they've got works, and something new doesn't?

When IPv6 doesn't work, it's easy to blame it, turn it off and stick with IPv4 because it works. When IPv4 doesn't work it's a problem that has to be fixed to access the vast majority of services online.

If your DNS can't resolve A records, you'd immediately complain and get it fixed.

There needs to be more promotion of this, as this is the first time I've heard about the version specific classifiers.

I'd have to agree with simonlebo - it's getting harder to find packages compatible with the latest version. Some of these are just slow at updating, but will eventually get around to it at some point. However given how old Django is now, there's going to be plenty of old projects which clutter up search results for packages which are no longer maintained.

Maybe djangopackages.com could add support/filtering to hide outdated Django projects. Or perhaps the encouragement could come in a more official way with a Django Package Index - a site which uses PyPI data, but with filtering biased towards the current released version of Django to encourage people who maintain those packages to get a new version out with support for the latest version.

Libraries are a problem - it's difficult to switch unless all your dependencies are Python 3 compatible. The only ways to fix it are to either use an alternative, or perhaps to fork or contribute patches to the project - both of which take up valuable time when your code is still functional under 2.7.

I'm currently creating 2.7/3.3+ compatible code in whatever I create, but I'm still deploying to 2.7 hosts. For most of my projects this is due to just one package which has some Python 3 related bugs, so hopefully I can just flick the switch soon and use 3.4.

It's only easy when your project depends on a few popular packages (eg. the top 200 where 86% are currently Python 3 compatible [1]), it's much more difficult if you've got a long list of dependencies.

[1] https://python3wos.appspot.com/

Chances are the worst link in the chain is your ISP provided modem/router. It's the typical device which will buffer several hundreds of milliseconds of data, and it's the slowest upstream. Most sane ISPs won't do this with routers on their network which serve multiple people - it's a fault if they're over capacity (unless they intentionally want it, eg. ISPs vs Netflix).

If you've got little or no control over the device your ISP sends you - there are ways around it. Either turn off WiFi (or don't connect to it), connect a single OpenWrt or CeroWrt router to that over ethernet and get all devices to connect to that router instead. You'll probably need to fiddle around with it to avoid double NAT (eg. setup the OpenWrt router in the DMZ of your ISP router if you can).

Personally I've stuck with OpenWrt - it works just fine. Install qos-scripts and luci-app-qos, set your bandwidth limits in Network > QoS in the web interface, and tune anything else you want. It should enable fq_codel for you.

As someone who admins a bunch of Debian powered servers, it would've easier for me if the Debian LTS project had been announced last year instead of earlier this year.

The 1 year gap between the release of the new version and the end of support for the old version just wasn't long enough. Sadly I'm also switching servers to Ubuntu because of it - along with a push towards using Docker containers powered by distros with long term support.

You can get a /56 - which should still be sufficient for most users needs.

Sorry, forgot to mention that Linode does give more options now.

Is this a single IPv6 address sharing the same /64 with stateless auto-configuration, or static?

The implementation is important, over the years I've had annoying experiences with certain providers trying to do IPv6 - but not getting things quite right:

Hetzner - Gave customers a /64, but using additional IPv6 addresses required setting up proxy NDP - which at the time was annoying as only more recent Linux kernels supported it. I believe they've improved on this since though.

OVH - Requires setting up a default route outside of your normal netmask - this isn't fun. We don't do this with IPv4 - so why do some providers do it with IPv6?

Linode - Enables IPv6 auto-configuration, so many servers share the same /64 by default, and they give accounts "pools" of /116 allocations. Sites like Google considers all of them to be part of the same /64 network - so your server will probably have trouble accessing certain resources if another server is doing excessive queries.

Any details on exactly what you get with Digital Ocean IPv6? The page doesn't really go into much detail - and the implementation can make or break things.

Is this a single static IPv6 address with a /64 (or /56 or /48) subnet routed to it? Or is it something else?

Upgrades/downgrades requires transferring all your data from one server to another - so that means downtime. The bigger the server, the more downtime in transferring.

As for backups, Linode backups seem to get a bad reputation. They do take a snapshot of a running instance - but reports from the forums indicate that they regularly fail, leaving you with a missing backup at some points. The only way of restoring a backup is to deploy that backup as a new server.

I'd recommend avoiding Linode backups and doing your own.

This might be a good thing for some customers.

In the past on certain host servers you get a great experience - low latency and the ability to burst CPU usage. However occasionally you get provisioned on an awful server where the latency of your server varies significantly, and your apps struggle to get a decent share of the CPU.

I'd rather see my servers have a small but more fair amount of burst instead of all packages getting 8 CPUs with some of them getting a bad experience from noisy neighbours.