dherls

If true, this is next level incompetence from PingCap. Apparently the attackers set up a replication pipeline for a month?!

> We even stood up a replication feed of their own control-plane database using credentials committed in their own repositories — GCP service-account keys and an Azure service principal — and let their infrastructure deliver it to us. Every six hours, for the last twenty-two days of the campaign, from 8 September to 30 September, that pipeline faithfully re-exported every table of the operational heart of TiDB Cloud — tenants, users, API keys, cluster credentials, changefeeds, migrations — and pushed it out.

What is the benefit of building the same website twice with different hostnames instead of using relative links to content on the same domain?

Basic details from post:

* $2.99 one-time fee to register without a phone number

* Only works with Google in-app purchases right now, but they are working to expand to other payment methods

* An ID and Key are generated for these accounts which are used for login

* Maybe future support for removing phone numbers from existing accounts

This whole website appears to be Claude slop articles about Postgres.

Seems needlessly angry about what is ultimately a decent if imperfect source of entropy, and a good illustrative example for the general public

Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me.

NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should.

For the point about query optimization, again your agents should not be issuing random queries against a production database. We have had the concept of separate analytics databases with different architectures to support exporatory queries for decades.

The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date

It's much easier to detect a single account abusing your API and ban them/require payment. Trying to police an endpoint open to the internet is like playing g whackamole

Really impressive that it's implemented in < 400 lines of Javascript code and runs so smoothly in my phone's browser (Firefox on Android)

I would definitely recommend not putting complex logic like this in your cron definitions. Much more annoying to find and debug in the future. I prefer to write a short wrapper script that contains the test logic instead and track/version control it

Some of the alternatives that the author suggests (Slack, Discord, Matrix rooms) are so much worse to search for answers in. Stack overflow has many disadvantages, but it is extremely good at being a publicly searchable repository of answers to common questions

Even in the case you mention you really shouldn't be overriding these methods. Your load settings method should take the path of the settings file as an argument, and then your test can set up all the fake files you want with something like python's tempfile package

This blog post talks as if mocking the `open` function is a good thing that people should be told how to do. If you are mocking anything in the standard library your code is probably structured poorly.

In the example the author walks through, a cleaner way would be to have the second function take the Options as a parameter and decouple those two functions. You can then test both in isolation.

I like how the article uses "Googling" as a verb meaning to shut down a service

I think the sandwich demo is really good. Once you establish the sandwich idea you can start zooming out to OK now you have a cook making multiple sandwiches, now you have a whole kitchen, and use that to talk about levels of abstraction and how SWEs go from solving one specific problem to more general problems by reusing techniques

I think the "joke" is if the US government orders a company to hand over that data, the fact that the servers are physically in the EU won't stop anything

A solution could be enforcing hardware keys for 2FA for all maintainers if a package has more than XX thousand weekly downloads.

No hardware keys, no new releases.

Another scummy tracking move from Meta, shouldn't be surprised.

In general I think browsers should prevent websites reaching out to localhost without explicit opt-in from the user.

With Java, there are a lot of usability issues with checked types. For example streams to process data really don't play nicely if your map or filter function throws a checked exception. Also if you are calling a number of different services that each have their own checked exception, either you resort to just catching generic Exception or you end up with a comically large list of exceptions

I'm confused why it's encrypted as a JPEG image per frame instead of one AES encrypted video file. Since the same AES key is used for each frame it wouldn't add any additional security imo

Charitable, use of system level randomness primitives can be audited by antivirus/EDR.

I was thinking that one solution might be to specify that the "justification" also has to be a justified true belief. In this case, the justification that you see a cow isn't true, so it isn't a JTB.

Of course that devolves rapidly into trying to find the "base case" of knowledge that are inherent

> These interviews can identify candidates with strong problem-solving skills and logical reasoning abilities.

I would disagree with this premise. Leetcode identifies people who have just finished cramming for Leetcode questions. You don't need logical reasoning abilities to solve Leetcode, just encyclopedic knowledge of algorithms and data structures