Right that is the real problem isn't. Google has not yet worked exactly how to stuff enough ad impressions to make money without destroying the utility the user is getting out of the experience to the point they are likely to abandon Google for a traditional search engine or go pay for Chat-GPT or something.

Really 'ad words' in AI summaries ought to be "easy" from an implementation standpoint. The 'problem' is doing its going to use even more tokens that need to be paid for.

I agree

The winners here are going to be people with actual hardware IP (Nvidia, Apple, others), people with actual hardware fabs, and likely Google and Meta. I predict despite the current crazy valuations the Magnificent-7 eventually end up acquiring the leading AI labs.

The real costs are in building models, not hosting them comparatively speaking and that picture only improves as the energy infrastructure and hardware markets gradually align to the volume demands. The labs are already just reselling the hyperscallers computer, there is no reason those guys are not going to take 'good enough' models and beat them on price.

Having the 'best' models is an asset someone with existing SaaS, Marketing, etc business on the hand can leverage and by extension justify the expense. That is why I see OpenAI and Anthropic eventually becoming acquisition targets once the gold-rush investors capitulate on their valuations.

The option is for them to get directly into the datacenter biz (not contracting for them and agreeing consumption commitments but actually building them and owning the dirt all they way up to the roof top chillers. Anthropic seems to be trying to make that play but I still don't know where the revenue will really come from...

Only in the most utterly pedantic sense of the word "different" wherein you mean that by definition, infant mortality occurs early and wear occurs later. But they can both stem from the same root cause, which is a component not built with adequate tolerances. In other words, they can be the same fundamental issue, just expressing themselves at different times.

Most products don't have an MTBF. And things that do have MTBF are based on accelerated wear testing on a small number of units, and can have almost zero basis in reality. There was one model of major brand hard drive about twenty years back where a couple of RAIDs where I used to work got lost because the drives all died after such a predictable number of powered-on hours that by the time you could re-stripe the RAID, the next drive would die. They ended up making sure the drives had a high variance in powered-on hours before using them in RAIDs after that.

It's an example that proves or demonstrates a point. And the point it was proving was that the same root cause can be responsible for both catastrophic early product failures and premature deterioration-related failures.

Wear-out failures aren't always different from infant mortality failures, though. If the defect is caused by a design flaw in a component resulting in a structural weak point, that same weak point could fail after one use or a thousand, and it could just be a ticking time bomb. Someone could get very unlucky and find one that is slightly weaker, and it could break much sooner.

Case in point, I recall a machine where some people would have to have their laptops replaced every couple of months for motherboard failures, while others lasted for years, and it turned out to be dependent on how people closed their laptops at the end of the day and whether they pressed on the bottom of the case in a particular spot that wiggled the GPU. But if you handed one that had been working for five years to someone who used their left hand under the laptop while closing it, it would be dead in two or three months. If you replaced it with a brand new one, the brand new one would be dead in two or three months. And so on.

Not that anyone in the TOS cast really deserves much criticism as far as how they manage(d) their celebrity, but Koenig always came off as a class act. In every interview he always seems grateful to just have had the privilege of being part of something big. Really seem to care about the fans and wanted to be entertaining for them at conventions and the like, was willing to participate in some of the fandom projects. Just a good guy.

Nice little supply chain attack.

Hijack of shipment of servers equipped with presently very very expense silicon that nobody will consider just disposing, insert your implants, let some patsys get busted and the kit get returned to the owners.

Bonus points make it seem like a general / widely implemented scheme by hijacking some large liquor shipments and various other goods as well. Pass out the spoils at the field office party or fence them to finance some other activities that need kept well away from oversight.

Yeah, and their whole argument is irrational. $1500/$30 = 50 months. A four-year ROI isnâ(TM)t irrational. Whatâ(TM)s irrational is companies expecting to make back their costs in a year, and expecting that because their service sucks so much that people wonâ(TM)t stay past the promotional period.

In my experience, most sufficiently advanced use of PHP involves rendering the HTML. You can do it either way.

And most sufficiently complex PHP uses PHP as a full-fledged language, complete with classes, etc., and to the extent templates are used, the code in them consists of tiny partial-line-long fragments of code that call some method in some other file that is basically just code.

In other words, very fragmented code isn't caused by PHP; it's caused by the way that the developer chose to use PHP.

These are also many of the most looked at, most often fuzzed, SAST scanned, valgrind'd things in the world.

I really don't think it will be as bad as all that. We have not seen Apache, Nginx, etc pwnd like this, or OpenSSH, or Bind, or postfix ...

I could go on. I think the actual posture and condition of most of these project is far better than you apparently expect. (I guess we are going to see who is right).

What AI is finding is stuff the other scanners miss, which is stuff where there is a clear temporal component. We are going to see races, toc-tou, probably more stuff like these PHP issues which if I understand correctly is a use-after-free or something you could at least force into that taxonomy.

So there are going to be new bugs found, even seriously impactful appearing ones, but the reach-ability and chances of successful exploitation outside laboratory conditions is going be low... Do they work when it is a VM on you lab server you can hammer away at with 1000 threads yes; when there is a AWS ELB in-front or a waf that has any impact on request ordering or pipe-lining, good luck..

I am not saying people won't be spending more hours patching over the next year or so than they have been, they will but the sky probably also isn't falling

People say that but I think they say it without a lot of real understand of what the web was like when it was born, and second that PHP5(+) does not look much like PHP 4(-)

Before PHP there were CGI scripts/programs, which were Perl, sh, or C or if you were on Windows classic-asp. If you wanted maintainability your wrote in Perl (yeah I am being serious) and if you wanted performance or needed to do something complicated you wrote it in C. Remember we are talking 1995-97 here there isn't even a C++ standard yet! These were you main choices for 'web development'.

PHP let people do what demanded C in something that did not have to be compiled and did require understanding C style memory management. Here comes the big BUT though, all the really good, really useful library code out there was C. All those library authors did not talk to each other so everyone was different in terms of conventions, who allocates the the caller or the called, who frees, are we passing references or values for primitives, etc. All different and php did not attempt to hide any of that as it pulled in those libraries it wrapped them in its runtime and memory management without attempting make their use orthogonal and part of some consistent ecosystem.

It wasn't a 'hack' it just was not a complete abstraction.

That was 'fine' for people who came to PHP from writing C, and were using PHP because it let them make changes on the fly, saved writing a lot of boiler plate request life-cycle management stuff, etc. It all made sense, if you can at it not from C though it was confusing mine-filed of gotchas. It made web development possible for a whole lot of people who never got access to compiler. That was cool, but it also put a lot of power in the hands of people the way the Visual Basic "Declare" keyword did, and unsurprising they did hack-y things with it, cause themselves all sorts of problems..

I still want a USB-A port on my MacBook Pro. The number of times I don't have the right cable/adapter with me is still way too high.

But no, I meant phones, where Lightning was dumped on iPad in 2018, but didn't go away on the iPhone for another half decade.

Yes. At the very latest, they should have changed when they changed the iPad over. Having a different charger for iPhone than for every other Apple device was overtly user-hostile. It meant carrying around extra crap for zero reason other than because Apple extracted four bucks worth of MFi revenue off of every licensed iPhone cable sold, and couldn't extract revenue from every USB-C cable sold.

And given how thin Lightning cables had to be because of the miniature connector and the inability to use a bigger connector because of case manufacturers building the holes too small to accommodate them, and how often the cables failed because of the too-thin wires, I'd imagine that was quite a nice revenue stream. The number of Lightning cables I went through was nuts.

USB Mini was in 2000. Micro was in 2007. Both were before the first iPhone. Don't get me wrong, micro-USB sucked. But we'd all have been better off if they had gone with mini-USB and stuck with it. We'd all have been better off if Apple had stuck with the Dock connector another two years and pushed the USB Forum (of which they are a member) to make a reversible connector happen, then switched to USB-C. We'd all have been better off if they had switched to Lighting, scared the rest of the industry into making USB-C happen, and then dumped Lighting for USB-C in 2018, starting with the iPad and then quickly progressing through the entire product line, rather than changing the iPad, but keeping the iPhone on Lightning until 2023.

Instead, Apple waited until the EU forced them to do it. By the time they finally switched, I was about to give up and move to Android, because the experience was so much better being able to share power infrastructure with my Mac instead of carrying around special sh*t-quality, low-data-speed cables just for the iPhone. Don't get me started on the fact that Apple never put USB 3 silicon into any iPhone, so they maxed out at a pathetic 480 Mbps data rate. It made photography and videography on iPhone absolutely horrible, because you couldn't get data off of them in a timely manner.

Everything about the way Apple handled Lighting on iPhones was botched just about as horribly as you could possibly botch it. Consumers put up with it, but that didn't make it suck any less.

Apple has sold two different versions of their display on Mac laptops for years — a glossy screen and a matte screen. An OLED screen option wouldn't be unthinkable. They'd just have to price it appropriately based on availability.

But you're right that doing it across the entire product line would be a lot of hardware. Even doing it for the Pro line would be a lot, largely because that's more than half of Apple's laptop sales — a sad testament to how badly Apple screwed up when they dropped the standard Macbook in favor of the thermally throttled Air. Contrast that with when the first Macbooks came out and the Pro laptops were maybe a percent or two. This doesn't leave Apple with the wiggle room to have truly high-end-only features except by making them BTO/CTO options.

It's still noise compared with the 1.1 billion OLED panels expected to be sold this year. Whether manufacturing capacity drove Apple's availability or Apple's demand helped drive capacity is unclear. Probably both.

As far as I can tell, this is an Android phone minus the phone. It is the iPod Touch of the Android world (which Apple discontinued years ago for lack of any real-world demand beyond use as a developer test device).

Why are they building this?

Oh. For "audiophiles" (in the "I don't understand how anything works, but making the back of the device out of some special kind of metal sounds like it could make the sound better, so I'll spend thousands of dollars on it" sense of the word). Now I understand.

Therefore, don't look. Yeah, this is indeed a fairly likely explanation.

To be honest, I don't think this is them ignoring privacy. I think this is them having gotten so complacent about privacy that nobody there even understands how to protect privacy anymore.

I mean the first rule of privacy on the Internet is "DNS isn't private." This is such a basic mistake that nobody with an ounce of privacy sense should make it. The URL's hostname should contain only the organization name or individual username and maybe some unique identifier if they really need that. But 99% of titles aren't secret in and of themselves, so I'll give them a pass on this one for now, even though it is still a horrible bug for the remaining 1%.

And the second rule of privacy is "Knowledge of a resource is not authorization." The fact that a resource that has not been shared can be accessed by its URL, and that apparently no attempt has been made to ensure that only people who are authorized to access that URL can view its contents means that they effectively have no access control at all. This would be an epic fail even if the first security bug weren't there.

This makes me suspect that some intern vibe-coded this thing as a prototype with no human design review at all, and that their team shipped it without actually taking the time to understand how it worked, relying too much on AI to do the review, and that the AI had inadequate training on how to implement privacy and security. Either that or the design docs did not adequately cover how the authentication worked and the reviewers did not bother to ask, which is an even bigger concern.

Either way, Meta needs to seriously clean up their act. This should have never shipped without a proper security review, and the fact that problems this severe were not caught is clear evidence that a proper security review did not happen. Identifying the underlying reasons for that failure should be a top priority, and the answer is never "Fire person X for not doing their job," because something this bad is never the fault of one person or even a small number of people. It's always systemic. It's always a lack of adequate controls, adequate numbers of eyes on design, adequate review, etc. And until they address the systemic problems that led to this outcome, I won't trust anything that Meta does going forwards as far as I can throw it.

So my advice to Meta would be that they do a very detailed internal postmortem, identifying all of the different places where this could have been caught and why it was not caught, identifying mitigation strategies to ensure that similar things don't happen in the future, etc., then implement all of those mitigation strategies, and finally create a second, publicly sanitized version of that doc and publish it externally as a "Here's what we're doing to make sure this never happens again" document. That's what they need to do to restore the faith of the folks who have witnessed this disaster.

Anything short of that level of public documentation showing that they truly understand how badly they screwed up and have genuinely taken steps to ensure privacy and security in future products would be inadequate, given the level of corporate ineptitude required to reach this point.