foxylion

When I write a bot like this I generally prefer using browser automation (like puppeteer). This requires less reverse engineering and is often a lot simpler and faster to implement.

You can now link the takeout to another cloud provider (e.g. Dropbox or Microsoft OneDrive). And configure the takeout to take place every two month (for up to 6 times).

So you just need to configure the takeout once a year and you'll automatically receive a backup once every two month.

You can also just do a normal form post request into an invisible iframe that is generated by the attacker's javascript.

This is, as far as I know, only possible if you bought it online.

But managing an IRC server cluster for 10.000+ users is no simple task.

Paying experts in their field (chat tools in this case) is most of the time the most reliable and cheapest variant. You must also include that Slack has plenty of features that are not available in IRC and mean the productivity is not as good.

Did you try to upgrade using AWS database migration service?

Normally the operational status is automatically updated on outages. The past incidents part is managed manually.

Nearly everything. Old k8s version. No upgrade possible. Odd deployment process (not fully automated). Support is unable to help in a timely manner. First deployed cluster was directly broken (no DNS resolution).

We eyed on switching from kops to EKS. But immediately stepped down after experiencing so many issues.

I wonder who is writing those status messages. as a customer this reads like "please wait, ETA to fix unknown" in 10 different ways.

Yes it is nice for experiments, but if you already invest thousands of dollars a month for cloud resources, an additional 150$ are for sure not a problem.

I second this. This means you don't have to setup and manage those master nodes. AWS will do this for you. A developer fixing an issue with your self-managed master nodes will be much more expensive than 150$/month.

As an individual this may look expensive, but as a company this is much cheaper than paying the loan of a developer.

Yes, we are planning to just fail, as the chance of a collision is really low and the user will then be able to just retry creating the object.

The article contains a footnote about UUIDs as primary keys.

> UUID as a primary key is a terrible idea, by the way — cryptographic randomness is utterly designed to kill locality of reference, hence the performance penalty

Is there anyone who can go a little bit more in detail?

We planned to migrate our database to use UUIDs as primary keys. This will allow creating new rows on clients knowing the new primary key before sending them to the server (simplifying client and server code).