The good news is that Roku has also introduced a recommended content row, that will compile picks from across various streaming services and use AI to point customers toward new shows and movies they might like.

How the fuck does this merit the description "good news?" Here, let me translate this for you:

"We're going to take away the channel selection menu that you put together and prioritized according to your own wishes, and replace it with paid placements and whatever our half-baked Mechanical Turk chundered up. And replace the lower-third of the main screen with video ads."

While you're at it, why not dump dogshit on my plate and call it chocolate cake?

âoeIâ(TM)m sorry you are having this problem have you rebooted your wifeâ âoeIâ(TM)m calling about cracked glass on a phone screen, how will rebooting help? â¦and my wife?â (Sound of pages flipping frantically) âoeYes, rebootingâ âoeFor cracked glass?â (All right, I thought a punchline that could tie it all together would occur to me, but noâ¦)

This is just a Hall Effect switch, with some tweaks so you can change where the tactile 'click' is.

Granted, the best keyboards I have ever used were Hall Effect, but they were also extremely expensive.

So very much agree.

(Which actually makes sense in the context of the movie)

The "Cleaning the elevator" scene.

Recommended!

John Oliver on Last Week Tonight did a whole show on McKinsey. The service they actually provide, as has been noted earlier in these comments, is a way for management to deflect responsibility for what they were always planning to do, anyway, which is usually budget cuts and layoffs, and/or massive boosts to executive pay packages.

Here's the show.

While it has been a decade since I worked at Apple, the CoreOS division had an institutional response to the IT team asking for anything. It was laughter. The security team within the CoreOS team doubly so, but only when they could stop laughing long enough to listen to the request first.

This isn't always healthy, it is part of why it took Apple so long to design a device managment system that made IT departments happy, because they never listen to their own it took much longer to figure out what IT departments in general wanted.

Apple's motive in this case is their cert system is intertwined with having securityd do as much of the work including in many cases policy enforcement as possible. That is a great tradeoff for their normal application stack, but doesn't intermesh well with the corners of how curl expects things to work. So they get a variant behaviour. Since curl isn't part of the "UNIX standard" (which Apple does care about complying with) anyone that gets the bug assigned to them can either work on it for a week and a half to get matching behaviour, or they can spent 7 seconds sliding the resolution over to "Won't fix -- Behaves as Intended" and get on with whatever they think of as their "real work". Or maybe e split the difference and spend ten minutes on a snarky comment about "use openSSL's command line tools if you want fine control over cert usage, why expect curl to be useful here?"

The switch to zsh was likely a confluence of the bash license change, and that zsh was the personally preferred shell of multiple members of the BSD team (er, before I left Apple, which was about 5 years before they changed the default shell, so maybe the entire BSD team turned over and I'm just indulging in wishful thinking). So you can blame me for introducing them to it ;-)

Cheap reliable oil bad.

Read up on the term "external cost", then actually think about the implications for more than 750ms.

You should then realize that oil is not, and never has been, cheap, but rather has been monstrously costly, and all those costs are coming due.

They're already making those errors plus memory errors in C. With not C, the memory errors go away.

This! So much this! Keeping track of memory issues is so much cognitive overhead in C that not only are people bound to make one every few hundred thousand lines they are going to drop the ball on something else as well while trying to keep track of the six different things that might "own" a particular struct allocation and figuring out when exactly it is safe to let go of and when it is a fatal mistake.

No one codes in C without realizing memory management and buffer overruns is a problem

Indeed, the vast majority of people that still program in C realize buffer overruns are an issue, and that dangling pointers are an issue.

That doesn't mean they don't occasionally one out of million times forget to bounds check something, or accidentally miss a path where something "should" be retained but isn't. Or know that some value won't overflow, but missed elsewhere where some value gets multiplied and overflows something so it becomes vastly negative, and then gets added to something else and we allocate the wrong number of bytes for something. People are bad at being consistant.

I know, I use to (a decade+ ago!) be one of the people that did security audits of iOS code.

Of corse I'm exaggerating a little: a lot of people do program in C and when you find a buffer overflow, or more frequently an unchecked numeric overflow/underflow and bounce a code change because of it they complain "that isn't a security problem! you can only reject us for security problems! show how that particular overflow/underflow is a security issue!" (I'm pretty sure not all overflows are exploitable, and the effort differential between merely finding some place that something gets multiplied and can overflow and proving that number eventually is used in away that misallocates a buffer is pretty large...but at least at that point in time we could bounce any code that had "questionable practices" even if we didn't come up with a direct exploit)

I mean look at how frequently iOS gets "jailbroken", isn't each one of those someone who knew that something should be secure missing a way in which it wasn't?

I don't doubt that Rust has its flaws, but I would expect Rust code to have fewer memory exploits then C code written by good programmers and audited by good security experts. I would expect Rust writer by good coders and also audited by security experts to have even fewer issues. (I mean Rust doesn't make sure your RNG is good, and not all security issues are memory and overflow related)

Especially not Intel since they use their fabs only for themselves (something they wish to change, but that's not easy).

Intel has been using their older fabs to make 3rd party designs for a while now, maybe over a decade. It doesn't get much press because it mostly isn't a very interesting business segment. It is about as interesting as "hollywood blockbuster from the 1980s still sells a few new DVDs each year" or "popular 1980s movies still generate income on streaming services".

Intel has been making noise about selling fab services on more modern fabs for years now, but nothing has come of it. Many people speculate that it is mostly because they are not cost competitive with TSMC. Many people speculate that they aren't cost competitive with TSMC becasuse every hour the spend producing (say) Apple's M1/M2/M3 is an hour they don't make x86-64 CPUs, so they have to charge relative to what they would have made by producing the x86-64, not something inherent in how much it costs per hour of production on Intel Fabs relative to TSMC fabs.

Intel and Microsoft recently made announcements about Intel making "AI" chips for MS using Intels most advanced production fabs (and around 15 billion of MS's dollars). So either they built more capacity then they needed to keep up with x86-64 demand on purpose, or a lower demand took them by surprise, or the theory about why they never managed a deal like that before is crap.

I personally think it is because demand for Intel's CPUs has slacked off partly due to competition in the x86-64 market, and partly because the x86-64 market has been contracting. Fewer people feel a need to buy a new laptop or desktop anywhere near as frequently as they use to. Many people do their primary computing with smart phones, and ARM dominates there not x86-64. The server market isn't really shifting to ARM, but long after x86-64 took the majority of the server market away from RISCs (unjustly if you ask me, for the most part x86-64 headless support still isn't on par with what most SPARC systems had decades ago -- not that that is actually a CPU arch issue) ARM is making a small appearance.