I doubt they'd have to retire the phone - digital radio power levels are normally pretty easy to change in the radio firmware. Which also means it's pretty easy to change, intentionally or unintentionally, in a later OS version.

Perhaps Apple chose to cheat to improve reception after mandatory testing was complete and the phone was available to buy, figuring they'd never get caught out. Perhaps Apple didn't retest with later OS versions and it was unintentional. We will probably never know.

Pulumi code ends up looking like a DSL anyway with all the stuff you end up using from the top-level pulumi package to do anything vaguely complicated.

Only now, compared with Terraform, you need to worry about resource ordering and program flow, because when you have a dependency between resources, the resource object you depend on has to be instantiated (within the program flow, I mean - Pulumi handles calculating the ordering of actual cloud resource creation) before the dependent resource. This gets old really quickly if you're iterating on a module that creates more than a few interdependent resources. So much cut, paste, reorder. FWIW CDK has the same issue, and for the same reason - because it's using a general-purpose programming language to model a domain which it doesn't fit all that well.

I like Pulumi and it's got a lot going for it, especially if you have complex infrastructure requirements. You get a bunch of little quality of life enhancements that I wish Terraform would adopt, like cloud state management by default, and a built-in mechanism for managing secrets in a sane way. Python/TypeScript etc. modules are much more flexible than Terraform modules, and really help with building large chunks of reusable infrastructure. The extra programmability can be useful, though you need to be extra-careful of side-effects. You get more power, but you also get some extra work.

But for most people deploying a bit - or even quite a lot - of cloud infrastructure, Terraform is honestly just easier. It's usually some fairly simple declarative config with some values passed from one resource to another, and a small amount of variation that might require some limited programmability. Which is exactly what Terraform targets with HCL. It's clear to me that Pulumi sees this too, since they introduced the YAML syntax later on. But IMO HCL > YAML for declarative config.

If you're on-call 24/7/365 without a break, and it's not because you have equity in the company, then find a new job.

If you don't, then your health (physical and mental) will eventually force you to leave anyway. I did it at a startup where I was employee #1 (no equity for me), just me and the founders, and I nearly had a nervous breakdown from it, and ended up quitting from stress. Afterwards I decided I would do no more than 1 week in 3, and life got better after that.

What? Tech companies the world over have people on 24/7 on-call rotas, and it's usually voluntary.

Depending on the company, you might typically do 1 week in 4 on-call, get a nice little retainer bonus for having to have not much of a social life for 1 week in 4, and then get an additional payment for each call you take, plus time worked at x1.5 or x2 the usual rate, plus time off in lieu during the normal workday if the call out takes a long time. If you do on-call for tech and the conditions are worse than this, then your company's on-call policies suck.

I used to do it regularly. Over the years, it paid for the deposit on my first house, plus some nice trips abroad. I enjoyed it - I get a buzz out of being in the middle of a crisis and fixing it. But eventually my family got bored of it, and I got more senior jobs where it wasn't considered a good use of my energies.

Your internet connection, the websites and apps you use, your utilities - they don't fix themselves when they break at 0300.

If TSMC's approach to on-call is bad, then yeah, screw that. I don't see anything in the article that says that one way or the other. But doing an on-call rota at all is a perfectly normal thing to do in tech.

Russians in positions of power have frequently said that Ukraine is an aberration, and doesn't actually exist at all as a national identity. So any Ukrainian symbol is an act of resistance to that.

Why use that particular flag? Well, why does anyone do any trolling? Because it feels good getting an emotional reaction out of other people. Because it feels good sticking it to those people who want you dead, or assimilated.

But also because it helps to figure out who isn't a fan of the concept of Ukrainian statehood. If the initial reaction towards a Ukrainian nationalist flag is that it's "Nazi" then that's a pretty strong signal.

It's worked though, hasn't it? No one with half a gram of understanding of modern Ukraine thinks it's Nazi - nationalist, yes, but not Nazi - and yet there are several accounts on the thread who have taken that bait.

Finding Nazis everywhere is paranoia, and demeans the experience of the millions who suffered and died because of actual Nazis.

"V for Victory" is Nazi too, right? Think about how the occupied French must have felt when they heard that on the BBC, after all the Frenchmen killed by those English longbow archers.

Meanings evolve.

Smells like two instances behind the load balancer, one is fine with the JWT, one is not.

Like it or loathe it, the BBC is the UK's most important broadcaster by a country mile.

If the BBC's internal procedures are shown to be reasonable and to have been followed, which it appears so far to have been the case, then I don't see anyone jumping ship about this.

People do dumb stuff all the time, some of which may or may not be illegal. It isn't an employer's responsibility until the employer finds out about it. What matters is the response and, so far at least, it appears the BBC has done fairly well this time, although perhaps more effort could have been made after the initial followups made by the BBC to the original complaint were ignored.

Do you really think they're going to try and hold an election in January 2025 at the last possible moment for a general election?

Traditional wisdom is that for the incumbent party, spring/summer is a better time to hold the election because people are generally happier with their lot in the warmer months, and are thus more likely to vote for the status quo. In January, everyone is broke after Christmas, and miserable from the cold, wet and dark, thus more likely to vote for a change of government. All the more so if energy prices continue to be sky-high.

Personally, I'd be surprised if it's more than a year until the election.

Nvidia drivers have (slightly) more timely support for the latest cards, and more mature support for non-3D uses of the GPU, especially scientific computing. To a large extent they are the same code as the Windows drivers, and that has positives in terms of breadth and maturity of support.

For everything else, the AMD drivers are better. Because they are a separate codebase from the Windows drivers, and are part of the de-facto Linux GPU driver stack Mesa, they integrate much better into the overall Linux experience, especially around support for Wayland. Unless you have an absolutely bleeding-edge card, they "just work" more often than the Nvidia drivers. If you like doing serious tinkering on your Linux system, then the AMD drivers being fully integrated and having the source available is a major win. Also, it used to be that the Nvidia drivers did a much better job of squeezing performance out of the hardware, but today there's very little in it, and the AMD drivers might even be a little more efficient.

I've got both AMD and Nvidia GPUs currently in different machines, and I much prefer the Linux experience with AMD. I don't think I'll be buying another Nvidia GPU unless the driver situation changes significantly.

FWIW I don't stream so I can't comment on the exact situation, but I have used the video encode hardware on AMD cards via VAAPI and it was competent and much faster than x264/x265 on the CPU. I think OBS has a plugin to use VAAPI (which is the "standard" Linux video decode/encode acceleration interface that everyone but Nvidia supports).

Cool poster! Though I think dark energy (and possibly dark matter) will be seen by future generations like we see luminiferous ether or epicycles today.