> Consent must be "freely given, specific, informed, and unambiguous."

and

> Apollo notifies them when their data is added to Apollo's database of business contact information and provides them with instructions on how to opt out.

https://knowledge.apollo.io/hc/en-us/articles/4409141087757-...

Now, their claim appears to be that they're processing business contact data under the legal basis of "Legitimate Interests". But as much as I am a big fan of not doing things that require a legal basis of "Consent", I'm unconvinced that they ensure their customers are sticking as tightly to their basis as they ought to be if they wish to claim it.

In other words: yes, if you have a CRM in then you might derive legitimate interests in sharing with Apollo. But you need to make sure you actually have the right legal basis for putting customer details into your CRM, and your support database almost certainly does not hold appropriate data!

So ultimately I think this is on both Browserstack (for connecting and sharing data other than in accordance with a legal basis) and Apollo (for making it too easy for their customers to send them data without a sound legal basis and then for sharing that data without suitably validating they had the legal basis to).

Apollo's privacy centre makes all the right claims about how they comply with GDPR, but the OP's story demonstrates that they're not as scrupulous in their verification as they claim to be. And strictly, both should be reporting the breach and taking steps to ensure it doesn't recur.

As a society (more so here in the UK than in the US, I'll grant) we have laws governing what one party may demand of the other. They don't prevent a genuine meeting of the minds, because enforcement of a contract will only be an issue if at least one party doesn't follow through. But they do limit the ability of the company to impose sanctions beyond a point.

One limitation in the UK is that penalty clauses that are "private fines", like this one, must be based on the actual damage caused.

In this case, as in the non-compete case, I would say that if a company wants to continue to influence what someone does, they should continue to pay them.

It still remains to be seen what the actual requirements are, and even if F-Droid could become "approved" that doesn't mean they want to. Time will tell.

I've only hit the compaction limit a handful of times, and my experience degraded enough that I work quite hard to not hit it again.

One thing I like about the current implementation of plan mode is that it'll clear context -- so if I complete a plan, I can use that context to write the next plan without growing context without bound.

Specific examples for the UK: inducting politicians into the Privy Council in order to qualify them for security briefings, Henry VII powers, and ministers' authority deriving from the seal they're given by the sovereign. Which would almost make as much sense if it were a marine mammal as it does being a stamp.

The thing being, they work well enough. And if you want to replace them, you need to work out what to replace them with and how.

This protocol was amenable to inspection, the next might not be.

I use NextDNS, one of the features it provides is letting you register a source IP so requests from your network "just work". It might not be a mainstream consumer feature, but neither NextDNS nor managed Unifi controllers are mainstream consumer products.

However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from.

Neither is necessary, though, given inspection does appear to work.

Arterial roads are normally still 30mph, and it's not a huge city so it doesn't take that long to get from the outskirts to the centre. Or when it does, it's not because of low speed limits.

LLMs won't add information to context, so if the output is larger than the input then it's slop. They're much better at picking information out of context. If I have a corpus of information and prompt an extraction, the result may well contain more information than the prompt. It's not necessarily feasible to transfer the entire context, and also I've curated that specific result as suitably conveying the message I intend to convey.

This does all take effort.

My take is also that I am interested in what people say: I have priors for how worthwhile I expect it to be to read stuff written by various people, and I will update my priors when they give me things to read. If they give me slop, that's going to affect what I think of them, and I expect the same in return. I'm willing to work quite hard to avoid asking my colleagues to read or review slop.

For a library, you really want the widest range of "allowed" dependencies, but for the library's test suite you want to pin specific versions. I wrote a tool[1] that helps me make sure (for the npm ecosystem) my dependency specifications aren't over-wide.

For an application, you just want pinned specific dependencies. Renovate has a nice feature wherein it'll maintain transitive dependencies, so you can avoid the trap of only upgrading when forced to by more direct dependencies.

The net result is that most version bumps for my library code only affect the test environment, so I'm happy allowing them through if the tests pass. For application code, too, my personal projects will merge version bumps and redeploy automatically -- I only need to review if something breaks. This matches the implicit behaviour I see from most teams anyway, who rely on "manual review" but only actually succeed in adding toil.

My experience is that Renovate's lock file maintenance makes update a whole load safer than the common pattern of having ancient versions of most transitive dependencies then upgrading a thread of packages depended on by a newer version of a single dependency.

1: https://www.npmjs.com/package/downgrade-build

I've created any number of empty files in my lifetime, and I wouldn't say that more than a couple of them were programming, but I don't think it's controversial to claim that the IOCCC submission I linked up-thread definitely was programming, and (maybe slightly more controversial) that my deliberate replication of the program when I first heard about it $mumble years ago was also programming?

In your specific example, if someone constructed an ASCII file which made use of the control codes to do something interesting (or even something boring!) then wouldn't that be programming? While typing ASCII into this text field isn't programming because the value of the information is in the human interpretation of the content rather than the machine having interpreted the content as code.

https://gist.github.com/andrewaylett/27c6a33bd2fc8c99eada605...

But actually nowadays I use JJ and don't worry about named branches :).

An empty file was an IOCCC winner: https://www.ioccc.org/1994/smr/ but you need to interpret that empty file as C source in order to reasonably claim to have programmed the computer.

My reasoning comes more from the other direction: someone who writes HTML is programming therefore HTML is a programming language.

I have a decent career that means I've paid off my loan. I can easily imagine that many folk with fees and modern loans won't ever even cover the interest payments.

Edit to add: It might not be an imperative language, but having written some HTML and asked the computer to interpret it, the computer now has a programmed capability, determined by what was written, that's repeatable and that was not available apart from the HTML given. QED.

The UK had what I think was a really nice set up, although it's now not nearly as palatable. My student loan had an interest rate tied to inflation, and repayment was a fixed amount of my income above a limit, collected via the same mechanisms used for income tax. Any unpaid loan would be written off when I turn 60.

The modern system is similar, but the interest rate has been decoupled from inflation which means that instead of paying back essentially the same value, no matter how slowly you pay it off, it's now definitely better to pay more earlier. Which makes it much more like a regressive "graduate tax" that you only have to pay if you don't earn enough.