What does the 'ad network and search engine' have to do with it? Wouldn't any organization who serves lots of traffic have the same cost cutting goals you mentioned?
Yes, to expand: Both search and ads mean serving immense amounts of traffic and users while earning tiny amounts of revenue per unit of each. The dominant mid-90s model of buying racks of Sun and NetApp gear, writing big checks to Oracle, etc, would have been too expensive for Google. Instead they made a big investment in Linux running on large quantities of commodity x86 PC hardware, and building software on top of that to get the most out of it. That means things like combining workloads with different profiles onto the same servers, and cgroups kind of falls out of that.
Other companies like Yahoo, Whatsapp, Netflix also followed interesting patterns of using strong understanding of how to be efficient on cheap hardware. Notably those three all were FreeBSD users at least in their early days.
It is the unfortunate reality that we tend to only remember the creator(s) of the first version (if anyone). Not just cgroups, but a lot of tech or protocols.
Anyways digging it up, looks like the primary author was at Facebook for a year before cgroupsv2, redhat for three years before that, and Google before that. So... I don't know haha you'd have to ask him.
As I commute on a motorcycle (often in the rain, causing lower visibility) this is terrifying to me and I hope regulators in my state don't let it happen here until Tesla can prove their "camera only" approach is safe.
> The attacker already had access to ... my Google Authenticator codes, because Google had cloud-synced my codes.
This was such an obvious mis-feature I can't believe they actually rolled it out. For those using Google Authenticator you can and should disable cloud sync of your TOTP codes.
I can understand it. Ordinary users were getting locked out of their accounts when losing their phones. Some of those stories hit HN.
Don't disable cloud sync unless you have a backup of all your TPTP secret keys. It's dangerous to advise people to disable cloud sync without mentioning backups. Being locked out of thousands of dollars in your crypto account is as damaging as losing that crypto to hackers.
In that case wouldn't you be better off just disabling 2FA? The problem with the cloud sync is that users like the one in the article think they have 2FA but in fact if their Google account is compromised all their accounts using Google Authenticator TOTP second factors are also compromised.
TOTP isn't that great, you should definitely use a hardware and/or pass key for important and financial services. That said your cloud synced Google Authenticator can be behind a Google account with strong 2FA (i.e. not SMS nor TOTP), then it's mostly fine.
The lesson here is really not to ever share codes you receive by SMS, and preferably disable phone as recovery and second factor.
> And then there’s the code that we rely on for bank transactions, package deliveries, medical results, satellite launches, airline flight paths, self-driving cars, mortgage payments, and nuclear power plants. This is durable code, and it’s going to stay that way.
I can tell you from first hand experience that, since long before LLMs were invented, critical software supporting these industries is held together with duct tape and baling wire (and Excel). "Durable" does not mean "good". In my experience production code is often ugly, poorly abstracted, full of special cases and hacks, but most importantly it works.
A few years ago I came across (probably on HN) this little Firefox extension that I quite like https://addons.mozilla.org/en-US/firefox/addon/fraidycat/ . Seems like it could help you fill this use case although as other commenters are saying I'm not sure I understand the distinction with RSS
