Joe8Bit

Reading the article I got the impression the big challenge is doing "personalzation" of the content at scale.

If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering".

To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!

In a previous role we used their (first party) physical transfer appliances to upload ~600PB of video into S3. It was a complex logistical exercise to take it from the physical SANs, but the AWS specialists we worked with were great and it went without a hitch.

I don't want to be too negative, I generally agree with and am aligned with the content of the article, but this struck me as a really bad take:

> In my experience, “show me the data” is often a tactic employed by weak managers who don’t know how to hang as part of a design process.

I really don't understand how asking to see data and talk in facts, rather than opinions, is a bad thing? This take seems to be implying the "design process" is just a giant, strictly qualitative "appeal to authority" fallacy and anyone who doesn't "get it" is some kind of naive rube?

In my experience, a lot of the motivating factors for large enterprises mandating encryption at rest aren't about specific security controls. They will often hand wave in that direction, but as as the OP says in their post, without being able to describe a coherent threat model.

Instead a lot of motivating factors I've seen are about preventing various paths for "legitimate" data disclosure to third parties. For example, when data at rest is combined with additional requirements like "bring your own key" it means a subpoena or NSL needs to be served on the _first party who owns the data_ (as they need to provide the keys) and can't be served on just the cloud provider without the first party having at least visibility of it.

The "template" use case was a very common one from iframes/framesets in the early 2000s, and the markup often looked a lot like your desired example.

My memory's hazy, but I remember it becoming more and more complex to maintain as the web's security and performance model evolved, as you needed to manage and secure all of these disparate, discrete DOM trees in the same page context.

Wouldn't what you suggested just been "reinventing" frames/framesets if you added the ability to arbitrarily pull in templates via the network?

"Hard to write but easy for customers to deploy" is my guess. There are a bunch of very high-performance computing use-cases in finance (quant, HFT) that Java gets used for pretty routinely. That's a very attractive market to build primitives like databases for, they have very deep pockets, but you need to play in their ecosystem.

I've seen this "GC-less" Java in those use-cases quite a bit. From a conceptual design POV it's likely not the best approach, but there's a lot of sunk cost in that eco-system and a lot of trust and expertise where "Choosing a better language" is often several orders of magnitude more expensive.

> in my experience you provide the debt collections agency all supporting contracts and account documents for each loan

This might be true for first party lender to first party debt buyer, but it often falls apart after that first step.

The article mentioned the chain of debt ownership and that, in my experience, is where contracts and supporting docs are lost. Once you're buying debt 3 or 4 steps removed from the primary lender the documentation becomes sparser and sparser, which is why as the article rightly said, most of these "last mile" agencies rely on people's ignorance and use a "spray and pray" strategy for debt collection.

My experience, from a large primary card issuer in the US, was that most of the major, reputable debt purchasing agencies would only buy primary debt portfolios that had _contractual guarantees_ about the accuracy of the supporting contracts and docs. They'd spend a lot of time and effort reviewing them, but they would in turn outright _refuse_ any such provisions when THEY sold their debt to smaller agencies!

I'm interested in this line "Many media outlets are increasingly reliant on money from betting companies" as I'd be interested to know how reliant the Guardian was on this revenue. Is stopping this type of advertising a big impact on their top line?

I applaud the move either way, but stopping doing something that's 0.1% of your revenue vs something that is 25% are two very different things.

I visited Chittagong a decade or so ago (as part of a non-profit working with child workers) and I can only emphasise what a visceral and horrifying thing this kind of ship breaking is to witness. 10,000's of people (as young as 6/7) working 24/7 in conditions that bear absolutely no respect for their health or safety.

One of the most morally repugnant parts of the Western legal system is the creation of the labyrinthine corporate structures used to to protect the ship owners for any liability as part of their ships being broken.

I can second fly.io, I moved a bunch of personal (but "production") projects from Heroku to it recently (Node, Rust, Rails) and the experience has been great. I can also second their Heroku migrator, worked pretty flawlessly.

Overall, my pricing has been about the same or 5-10% less per month.

It doesn't have the same "Click this button to add this third-party service to your dynos, with billing included" eco-system that Heroku has (had?) but my Heroku usage was pretty vanilla so it wasn't an issue for me.

I do a fair amount of pre-seed and angel investing and I've seen a _massive_ increase in the number of very early businesses that have a "product" that they've been able to build with no/low code tools. It gives non-tech founders a set of options they've never had before, in my experience.

That obviously isn't viable for all early businesses and even the ones it is viable for eventually need to hire engineering teams to build their products, but I love how much more accessible these tools have made shipping something basic.

This is a really interesting point and it resonates with my experience. When I moved to the US from Europe I was suddenly in a world where people had enormous fridges and freezers and could buy a massive amount of food at a time. They would never have fit in dinky little European apartment before!

This is also my experience for folks that live in NY.

They put all kinds of locks on the account but they never worked, my assumption was that people who worked at the provider (who could unlock anything) were the ones stealing it!

I had a UK mobile number that had seven consecutive digits (e.g. 079* 444 4444). I got it through a friend who worked in provisioning at a new mobile operator that had just been assigned its new number blocks.

The problem was people would constantly try to "steal" the number. Four or five times a year my phone would just stop working because someone had "persuaded" a call-centre worker at my provider to assign the number to a new SIM they could sell on eBay. Apparently people pay a LOT of money for vanity numbers.

No matter what additional "security locks" they put on my account it kept getting hijacked, so eventually I just got a new (much less interesting) number.