SudoAlex

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.

The one thing which bothers me about the current ISPs is how their networks are designed for downloads. All cable, ADSL, and even some fibre connections all have greater download compared to upload.

How is any company which deals with a residential ISP expected to be a peer?

All ISPs need to do is provide IPv6 connectivity, a router with IPv6 support - and the traffic will flow.

It really should be as simple as that! Windows Vista supports IPv6, modern versions of OS X supports IPv6, etc. You don't have to configure it - just like you don't have to figure IPv4 with DHCP. Typical end users don't question their IPv4 connectivity, they just plug in their router and things work. The exact same thing should happen with IPv6.

The only issue is going to be old customer routers which can't be upgraded with new firmware.

There's still some value.

I'd love to be able to connect to a QuakeNet IRC server which is SSL/TLS protected to help guard against anyone sniffing on the local network, or along the route to the specific IRC server.

Yes, there are problems to solve. Clients need to validate the servers certificate properly. Users need to understand that whatever they send may still be logged by the network, other users on the channel, etc.

Saying that IRC doesn't need SSL is like saying that other IM applications such as Skype don't need it either. Anything which helps prevent eavesdropping should be done.

As someone who uses virtual machines on both providers (and a few more) - benchmarking a single virtual machine and taking that as the single conclusion is not going to give you accurate results which reflect the entire network of servers which either provider has.

Both providers are likely to have certain host servers which are relatively empty, and others where a number of busy servers are going to really skew your results.

The one thing I'd recommend is to install monitoring which can keep an eye on your servers to ensure the performance hasn't dropped significantly since you first provisioned it. Munin http://munin-monitoring.org/ graphs disk IO latency by default, keeping a track of this allows you to make a decision on if you want to migrate a virtual machine elsewhere on the same provider - to see if you can avoid the noisy neighbours problem.

Never assume that you'll get the same performance on a daily basis.

From the top of my mind, many of the french ISPs have IPv6 ready on the customer side, a radio button click away, while some are even on by default.

I think this is one of the key points that certain people end up missing.

Windows Vista and later can do IPv6 by default, recent versions of OS X will do it by default as well. All an ISP needs to do is send a user a router which can handle IPv6 traffic - and suddenly the entire network will start doing IPv6 traffic with places like Google who are IPv6 ready.

It will just happen! Add the IPv6 ready equipment and the traffic will flow. The only problem is certain ISPs who are still stuck with their heads in sand, not providing IPv6 connectivity, and still providing customers equipment which can't deal with IPv6 traffic - some of which might not be possible to upgrade.

On a local server at home, it's a low powered ARM box (QNAP TS-219 running Debian) with RAID1. The same thing could probably be done with a Raspberry Pi for lower costs if I was doing it now.

For database backups, you need a consistent snapshot of the data - something which might not happen if you attempt to access the data directly. Add a script to your daily crontab directory, such as:

mysqldump --skip-extended-insert --all-databases --single-transaction --master-data=2 --flush-logs | gzip -9 --rsyncable > backup.sql.gz

Or:

sudo -u postgres pg_dumpall | gzip -9 --rsyncable > backup.sql.gz

Into a directory which rdiff-backup will download.

I always prefer to pull my backups from a local server I can trust instead of running a process on the server to push backups - if someone gains access to the server they could potentially destroy the backups if all the credentials are left on the server.

Treat DigitalOcean as any other provider - something you can't trust, so always have backups of your own data in a place you trust (not a DigitalOcean snapshot) so you can restore when needed.

Personally I use Ansible http://www.ansibleworks.com/ and rdiff-backup http://rdiff-backup.nongnu.org/, along with Vagrant http://www.vagrantup.com/ for testing. So the day something happens with my droplet on DigitalOcean - I'll just run Ansible on a fresh server and restore the remaining data with rdiff-backup.

Yes, the lack of IPv6, being unable to use a virtual machines bootloader, a lack of a decent rescue image, and no private networking apart from one location sucks. However for the price - it's a good deal.

Windows XP support ends in April 2014. Android 2.2/2.3 is currently at 28% market share and dropping.

There's a point at where you have to drop support - even if you've got laggards. Look at the stats for your sites, find out the percentage of IE users on Windows XP. A quick sampling of 2 popular sites I'm running shows it to be around 2-3% for IE/XP users - I wouldn't call that heavy use, but obviously it's going to be different for every site.

Charge higher prices for those wanting a dedicated IP for their site - pass on the costs which you'll be facing due to IPv4 exhaustion. Prioritise the more important sites for dedicated IPs. If the site generates revenue - keep it on a dedicated IP for a bit longer, if not then it can share an IP with SNI.

Perhaps the better thing to do for this would be that no changes are made between the last release candidate and the final release. Some projects do it, some don't.

Mistakes can be made if you have to do version number tweaks in various places before releasing.

This is probably setting the requirements a bit too high for the average site - requiring a unique SSL certificate from their CDN provider.

Most sites will probably be fine using SSL for their main site using their main servers - requests going direct to the site, with static/media files being served from a shared SSL certificate with their CDN.