lentil

> I also remember comparing AWS Lambda at Edge vs Cloudflare Workers ... costs were something like 10x apart.

According to the AWS pricing example[1] 10 million requests per month on Lambda@Edge costs $9.13. The same thing on Cloudflare Workers[2] costs $5.00. So I would expect it to be closer to 2x. Although as you say there's a bit more flexibility with Lambda@Edge so it'll depend on your particular case.

I'm curious if your situation was different somehow that made for such a big cost difference between the two?

[1]https://aws.amazon.com/lambda/pricing/#Lambda.40Edge_Pricing [2]https://workers.cloudflare.com/#plans

Great idea. Thanks for setting that up!

It wasn't discontinued. It was amended to take into account aspects of GDPR, but the rules are very much still in effect.

It's covered by PECR. There's a good overview of the rules here: https://ico.org.uk/for-organisations/guide-to-pecr/cookies-a...

The main change GDPR brought to it (as I understand it) is that it introduced stricter rules about how consent works. But even though GDPR doesn't specifically require cookie warning, it does require that you get informed consent from people before you store personally identifiable information about them; in many cases this effectively means getting their permission before using tracking cookies.

So tl/dr, it's primarily PECR that covers cookie handling, but GDPR also plays a role.

Which is the Go implementation that you recommend? There seems to be a few.

But the cookie is not "Personal data which have undergone pseudonymisation", is it? Assuming we're talking about the case where no PII is being sent along with the tracking data (which I believe is the point of masking the IP address, among other protections) how could this be attributed to a natural person?

What I'm trying to understand is why the addition of an opaque cookie value necessarily changes the situation, such that consent is required.

It's very possible I'm missing something here; genuinely trying to learn what that is.

> You need consent for placing that cookie under the GDPR

Do you have a reference for this? It not how I understand GDPR, and I am not clear which part of it would apply here when personally identifying information is not being tracked.

I'm trying to understand what's broken here. The example is a 90° rotated (portrait) image, and the exif shows a 90° rotation. It's correct, isn't it?

> I'd personally love it if AWS implemented a digital ocean-like "basic" interface which, realistically, covers 90% of startups' needs. Simple is good.

Have you looked at Amazon Lightsail? It might be closer to what you're after.

https://aws.amazon.com/lightsail/

To be fair, the AWS documentation nearly always covers both.

> the 2nd function was taking up over 50% of the concurrent execution limit and new events coming into the front-end would get throttled and in this case thrown out.

It sounds like you already found a great solution for your particular case. But it's also worth mentioning that you can apply per-function concurrency limits, which can be another way to prevent a particular function from consuming too much of the overall concurrency. For anyone who's lambda workload is cheaper than a 27/7 task, that could be a good option.

> Each invocation of the Lambda was authenticating with the GCP SDK before passing the event

I'm curious whether you tried moving the authentication outside of the handler function so it could be reused for multiple events? I've found that can make a huge difference for some use cases.

True, they make it look required there, but you can use one of the direct download links instead (eg linked from https://docs.docker.com/docker-for-mac/release-notes/) or use Homebrew to install it.

The problem is more that they make it harder to find if you don’t log in, which is really not great. But if you don’t want to create an account there is certainly no need to do so.

It doesn’t require one to use it. I use it daily on MacOS and I don’t have an account.

No, you don’t need to do any of that. ECS can inject secrets into environment variables in much the same way as Kubernetes. This behaviour is already built-in, there’s no need to build your own solution for it.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

ECS already has all the things you mentioned here. Some, like daemon set deployments, are built in. Others, like secrets management, are provided as integrations with other AWS services. But they are all there.

That’s not quite true. They do have different limits than regular Lambda functions, but you can certainly make requests to arbitrary hosts. The documentation puts it like this:

> Functions triggered by origin request and response events as well as functions triggered by viewer request and response events can make network calls to resources on the internet, and to AWS services such as Amazon S3 buckets, DynamoDB tables, or Amazon EC2 instances.

Regarding point 3, you can run Lambda on edge nodes too — Lambda@Edge, which uses CloudFront.

Although as you say, whether that ends up reducing latency in particle depends very much on your use case.

That's true for the default behaviour. Ctrl-C also won't call autocommands (like InsertLeave).

But - you can always map <C-c> to <ESC>, so that it'll work exactly the same.

Agreed. I would also recommend this conference talk on the subject by Nickolas Means, it was very well done: https://m.youtube.com/watch?list=PLBzScQzZ83I81fnpqX2AkYD5c5...

This might be more of a complete app than you need, but https://transfer.sh is open source and it looks fairly compact. Could be some interesting examples in there?

> From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.

That's a bit disingenuous. The fact that privilege escalations exist doesn't mean one has to trust all the software one uses completely and unconditionally; it means there are risks that should be taken into account.

Given we're talking about the choice between an authentication method where you can trivially capture someone's password, vs an authentication method where you can't (and where you would need to successfully employ some sort of exploit to do so), then the level of risk involved in each is quite different.

(Not only that, but I'd argue people will tend to trust software more when it appears to be making best efforts with regards to security. Any obvious security-related flaws will erode that trust rather quickly.)

(Edit: typos)

Are you sure they aren't intended for data processing? I've never heard that claim before, and the Go documentation seems to have a lot of examples of using channels in that way. (https://blog.golang.org/pipelines, for example; or https://tour.golang.org/concurrency/2).

The situation has been improved quite a bit with kubeadm. Getting a basic cluster set up is a lot easier with that.

https://kubernetes.io/docs/getting-started-guides/kubeadm/

> and there is no supported way to reclaim that space

That's one of the things addressed in the latest stable release. It now reclaims space on startup.

> If we moved, all existing customers "stored" payment information would, by necessity, go away.

Not necessarily. You should be able transfer the stored card data to another provider. Many (although not all) payment processors seem to allow this.

  https://support.stripe.com/questions/what-if-i-decide-to-leave-stripe-can-i-export-card-data

> I'm now trying to plan vacation time to drive for a 14 hour round trip and pick it up

From a happy and grateful Homebrew user, thank you for all the work you are doing. It's really easy for folks to underestimate how much effort is involved in running a project like this. Details like the above should be a reminder that it's clearly a very significant amount of hard, sometimes thankless, work; work which you are in no way obligated to do. There are large numbers of people who owe you a massive debt of gratitude for all the time and hassle that your effort has saved them. And it's quite sad that we (people) tend not to speak up when we are happy, and only make noise when we're upset about something.

Thanks for continuing to work on this project!!

pg_start_backup/pg_basebackup are used when doing an rsync-style copy. You'll end up with a copy of the data directory, rather than a dump. You can then start up a server instance directly in the resulting backup directory.

You don't need to be offline to make a copy of the data directory. You can do that ahead of time, keeping all the WAL segments up until the point that you make the switch.

(See also https://www.postgresql.org/docs/9.5/static/continuous-archiv...)

Yep, I've had that experience trying to buy petrol in France too. That's the only place I can remember running into a problem with it, actually. Never anywhere in the UK.

> almost no one in UK accepts signature-only cards

> terminals which can take magnetic-strips are just super rare and usually not supported even if the machine has them.

I've not found this to be the case. I used a non-chip US card here in the UK extensively over the last year or so, and I've never once encountered a merchant that didn't want to take my card, nor a terminal that didn't read magnetic strips.

I do find people at checkouts to be a little surprised by someone having to swipe & sign, since that's quite rare now. And often they had trouble finding a pen for me to sign with :) But I was always able to complete the transaction nonetheless.

It's really quite a nice crash reporting product. I think that outweighs the closed-source point for a lot of folks.