Aside from architecture holy wars; this is the main reason why server CPUs are still offered in very low core counts(along with some specialty parts that are all about frequency and single thread performance; or low-ish core count parts that are aligned with specific common licensing schemes):

Your big database or mostly-cached web server, say, is still going to need a whole bunch of RAM and some high speed networking, possibly storage, so you are basically buying a big fat memory controller and lots of PCIe lanes; at which point the percentage of the silicon that is 8-16 86 cores vs. something else starts to look a lot less interesting compared to that 12 channel DDR5 controller and 128 lanes of PCIe; which would need to be there regardless of architecture.

Obviously the existence of actually-viable server ARM puts some limits on Intel and AMD's ability to play pricing games(at least against large customers); but, if anything, it's the computationally lightweight stuff where I/O is going to be a huge chunk of the package(literally and figuratively).

There's also the fact that a nontrivial amount of what is being provided has already been spent: there has been some new production, mostly of ammunition and smaller systems; and some draw-down of stockpiled hardware that's faster than purely letting it age out and destroying it at end of life, which implies some production in the future; but (both because it is what is available and because the process for approving transfer of existing DoD property is easier than the one for doing appropriations for new stuff, bidding the job out, having it manufactured, and then transferring it) the bulk of the military equipment provided is stuff that was already HIMARs or howitzers or Bradleys or whatever. There's also the specific case of the various cluster munitions, which would otherwise have been destroyed because the US hasn't wanted the PR hassle of using cluster munitions since Desert Storm.

As noted, just because it's in stock doesn't mean its free(especially if it's something you expect to need to replace; rather than something that was close to aging out or no longer approved for use and you were expecting to pay someone to scrap it in the relatively near future); but it's nonsense to just take the unit acquisition cost of a 10 year old M142 and pretending that that's a cash transfer that could have been used to build science machines or fix potholes.

Did you really get confused by the fact that a "crematorium" can refer either to an entire building dedicated to burning corpses or to the individual modules that handle one body at a time; then pat yourself on the head for your cleverness?

The problem is that 'knowing' language structure and more or less nothing else is the perfect recipe for apparently plausible, syntactically appropriate, nonsense lurking in.

Traditional speech-to-text is often a bit on the rough side; but it has the 'virtue'(in a sense) of breaking in stupid visible ways if it chokes on a bit of input. You'll get a similar-sounding word that has no business being in that part of a sentence, or a sentence-length or two of total word salad if there's a burst of background noise or a mic level issue or something. It's not a pretty looking failure; but for the same reason it's not all that sneaky. Not as good as a system that gracefully admits that the input is unusable from timestamp A to timestamp B and tells you as much; but a fair way from the exceptionally smooth confabulation you get out of LLMs.

It seems unlikely that data caps are primarily about protecting overloaded links at peak times: they do keep you from just running at advertised speeds at all times; but, were they the only mechanism at play, a heavy user could still be overloading the line for some days after the cap resets before they hit it again. Any congestion management you want to do(and aren't restricted from doing, it's not like there are SLAs here) you'd want to do significantly more quickly than that.

It's possible that the psychological effect of a looming fine helps keep utilization down, especially among people who don't really know much about how much various things consume; but as an actual congestion management tool a meter of "X GB/month" is pretty poor: it counts traffic the same regardless of how heavily loaded the line is at the time, so does nothing to encourage off hours usage or backing off in response to signs of congestion; and, in the case of all but the most draconian caps or the most questionably supported nominal peak speeds, it generally won't stop one or more heavy users from hammering the line for days after whatever the reset date is.

Apparently the 702MP satellite bus uses two different types of engines for station keeping; both fueled by one of the unpleasant hypergolic combination options(anyone know which?). The 702SP offered Xenon electrostatic ion thrusters as an option instead. It's also designed for satellites in the 6-12Kw range; so I'd imagine that the battery isn't tiny; though its production values are hopefully pretty high.

What I'd be curious about is how much energy is actually required to cause a dramatic breakup. They presumably build satellites durably enough to avoid being shaken to pieces during launch; but there is presumably zero extra credit for blowing mass on overbuilding something that is going to spend its operating life in close to zero atmosphere and close to zero gravity; and since it's a communication satellite loaded with antennas it presumably has a lot of parts that are quite carefully designed in ways that give them outsize radar signatures.

I'd be shocked if it was carrying something (or even hit something large enough) to cause much breakup of the sorts of structural pieces that sometimes survive being deorbited; significantly less shocked if a bunch of delicate multipart unfolding antenna bits or collapsible dishes take considerably less violence to shake loose.

It seems like that sentence either needs some clarification; if it's intended to mean that the 'anomaly' caused the satellite to lose power and stop providing communication services; which seems like a pretty natural consequence of a communication satellite losing power; or some of their customers need to put down the SCADA and back away slowly.

I don't doubt that there are some out-in-the-sticks facilities where satellite modems are the only thing keeping the operator clued in about when they need to send a tech out to replace the #3 turbo-encabulator because it's started to wobble outside of tolerances; but that's the sort of thing that would presumably be tolerant of at least brief outages.

Is it just the framing that triggers you; and "poisoning someone is at least a tort and possibly a crime" would be just fine(despite poisoning being tortious or criminal essentially implying that we have a fundamental right to be not-poisoned which is sufficient to make poisoning a damage that creates liability)?

It's absolutely the case that 'fundamental right' as a framing at least creates the impression that whoever is formulating the idea(unless talking about property or guns) probably skews liberal by American standards; but it's important not to be misled by the wording when quite different wording(either the small-c conservative/moderate business liberal flavor that formulation in terms of uniform environmental protection and health and safety regulatatory objectives would have; or the hard 'classical' liberal/libertarian flavor that some pure tort law and private litigation proposal would have) all basically leans on the idea that people have legitimate objections to being poisoned and others shouldn't be allowed to poison them. The language of torts is older than the language of rights by a fair bit; but articulating a tort is effectively describing the corresponding right that makes whatever action or inaction tortious; so (while you can definitely make a solid guess about the speaker by how they prefer to sell the idea) it really doesn't do to start frothing just because you dislike the formulation rather than because you think that something isn't a right or shouldn't be a tort or a crime.

It's a lot easier to get non-x86s that aren't vulnerable; because x86 has basically abandoned cores small enough for branch prediction to be omitted(with the possible exception of Intel still using their otherwise-abandoned 'quark' 32 bit x86 cores in the management engine; I think the most modern x86 that didn't engage in it was the Atom designs of a decade or so ago), while ARM and RISC-V still show up right down to microcontroller territory; but all the high performance ARM options that do speculative execution have spectre-type issues. Not sure offhand if anyone is doing RISC-V parts sufficiently performance focused to do so.

Aside from the extra nonsense introduced by some of the fixes being in microcode(which drags motherboard vendors and PC OEMs into it; which is rarely helpful) is it even accurate to speak of "spectre" as a specific flaw with a specific solution? My (admittedly layman's) understanding was that 'spectre' was the name that stuck thanks to it being assigned to an early and dramatic demo; but that it refers to an entire family of more and less subtle quirks and potential side channels that affects basically anyone doing speculative execution(which, inconveniently, is basically anyone who wants high performance); with mitigations being added as specific cases are uncovered; but there being no particular reason to expect that you'll ever necessarily get to the bottom of the issue(especially if you aren't willing to accept substantial performance hits); just eliminate some of the more readily useful exploits but not ever arrive at a 'solution' that will eliminate the crop of ever subtler side channels and esoteric information leakage possibilities.

They made a lot of fuss about theirs a few weeks ago during their annual cult/networking/expense-tickets-to-vegas thing. Theirs is called "Einstein" so you know it has to be smart; and they are super all in on paying them to use 'agents' to chatbot customers, along with 'generative' to increase your sales team's spamming efficiency.

In one sense I can understand why he's rubbishing Microsoft so vigorously: not only does 'copilot' deserve it; MS has a fairly obvious interest and fairly obvious ability(at least on the integration side; not necessarily on the 'getting useful or secure results' side) in having all your 'cloud' Microsoft stuff feeding into 'Copilot', either core or the various upcharge modules, so "Copilot for Sales" with Dynamics 365 will automagically have all the user's context from exchange and sharepoint and recall and whatnot in ways that Salesforce either won't or will need a bunch of integration hassle to have.

On the other hand, though, it seems like a potentially dangerous move to point out that Microsoft's 'AI' hype is dangerous bullshit that delivers questionable real world value and shows no signs of being able to resist prompt injection attacks when you(and what seems like literally everyone else with a software product that can have a chatbot rammed in) are also pushing an "AI Strategy" built around tech with the same set of limits.

He must be a bit nervous about the risks presented by "eh, it's kind of shit but Microsoft will give us a discount since we are already buying all those SQL server licenses and E5" willingness to just shrug and force Dynamics on people to be so publicly breaking with the tech suit trend of proclaiming that, while our 'AI' is of course extra special revolutionary; 'AI' in general is the glorious innovative disruptive future that any doubters just don't understand or will be replaced by.

Given that this is Apple-collected data; not included with the cellular message itself; there presumably needs to be a mechanism that pairs the two for display. Not rocket science to check phone numbers against a database of phone number/logo pairs; but raises a rather urgent question about where that happens. Is this a "eh, flash is cheap and vector art is fairly small" thing where the matching is handled locally? Is every iPhone going to tell Cupertino when it receives a call and ask the mothership for instructions; providing them with a strikingly detailed message log on every iDevice?

"Javascript" was a more or less cynical branding of an unrelated technology because "java" was still a name worth piggybacking on at the time Netscape made that call; but it's managed to evolve (more by brute force than by fitness for purpose) into something that actually has java-like properties in terms of being able to target an abstracted runtime environment for cross platform compatible programs.

Makes one wonder how it would have gone if they'd acknowledge that that was the plan originally and followed the path of doing java integration with Sun, rather than tacking on an unrelated scripting language for some lightweight dynamic page capabilities. Certainly would have been more work upfront; but might well have saved a lot of trouble. Or, alternately, it might be a case where worse was actually better and half-assing it upfront saved us from "the web" basically just being nothing but opaque java applets that happen to be served over HTTP.

I'll be (morbidly) curious to see how MS reacts when Win10 goes EOL.

They'd clearly like everyone to rush out and buy a shiny new 'Copilot+ PC with Windows 11 and Office 365'; but that's just not going to happen in a great many cases; and we've seen behavior in the past(eg. having Windows Update function normally even on PCs that have failed activation for a prolonged period of time) that suggests that they know that a major threat to their customers is their poorer or less enthusiastic customers running wildly insecure outdated OSes and getting coopted for attacks. We've also seen (paid, aimed at corporate and institutional customers, optional extensions to security update availability 3 years beyond EOL) for relevant products.

Are they actually going to hold the line and just tell everyone on win10 who doesn't have a TPM or something to fuck off and become a worm farm for all they care? Cave a bit and continue to release some security patches for sufficiently critical vulnerabilities but otherwise fix nothing? Do some sort of means-tested thing where win10 Home SKUs that are only slightly incompatible(eg. fails TPM check but is new enough to have the expected CPU instructions) get some sort of deliberately-lousy Win10.1 thing; but Pro and Enterprise are expected to either migrate or pay for ESU? Do some sort of thin-clientification thing where Entra-joined win10 systems being used to access 'Windows 365 Cloud PC' get security support but an S-mode style lockdown?

I doubt that they have any specific contractual obligation to care; but there is definitely going to be some blowback from what is one of the larger forced-obsolescence events in history; and stories about DDOS botnets being built out of Win10 systems exploited using vulnerabilities that they fixed in 11 but didn't bother to fix in 10 aren't going to be terribly complementary.

I wouldn't be desperately optimistic about client ARM Windows(especially since both AMD and Intel's more recent forays into laptop chips have suggested that they can actually put in pretty solid battery life along with the x86 compatibility you'd expect from an x86 when made sufficiently nervous about it; and when Qualcomm seems committed to positioning their parts as relatively premium even when emulation overhead can still be pretty rough); but it seems less likely to follow the path of IA64.

It's true that really lousy x86 emulation made transition-period IA64 even less likeable: Itanium boxes were premium-priced gear(and, admittedly, did have some of the neat old-school-big-iron-UNIX RAS and similar features); so watching your x86 workload get stomped by considerably cheaper x86s was pretty miserable; but the real nail in the coffin was that IA64 was also pretty underwhelming when running native(there were a few applications that really did like it; but results in general were not encouraging). Since the big-memory applications you would buy an Itanium box to run were going to have to be rebuilt anyway(either because they used to be 32 bit, maybe PAE aware, x86 or because they were coming over from a RISC UNIX); lousy x86 emulation wouldn't necessarily have been a deal-killer if IA64 had actually been good: OK, that MMC snap-in or vendor database config utility runs like trash; but it isn't performance critical and the actual database runs nicely. But it wasn't actually good. Then AMD came in with something that was both a highly competitive part for existing x86 stuff and offered 64 bit support basically for free. Game over man.

ARM, by contrast, is at least credible when being itself: a lot of the benchmark wins are price/performance or threads per socket rather than maximum single thread performance; but there are absolutely cases where the Ampere or Nvidia stuff you can actually buy or the various in-house hyperscaler ARM instances are things you would choose to use for specific purposes. Windows, specifically, on ARM is presumably mostly an Azure thing; but it's an actual niche were its survival makes sense; rather than just being Intel attempting to tell everyone who needs more than 32 bit address spaces that they'll take what they're given and like it.

It's just not clear how helpful this will be for getting down to Windows client; where it's all assorted special cases and there's less of a clear separation between "The Big Application we run this server for" and "random utilities where performance barely matters". It's probably more viable than it used to be; given the shift toward either outright browser-based applications or locally installed applications that are basically just chromium with some holes punched in the sandbox: get an ARM-native browser and MSEDGEWEBVIEW2 and Teams will run just as badly on ARM as it does on x86; but if everything you do is browser-based it becomes less clear why you'd necessarily go Windows; rather than chromebook if you are cheap and need a keyboard; ipad if you are cheap-ish and not typing too hard; or macbook if you want something a little nicer: you really going to buy an "Inspiron 14 Plus" from Dell when you could get a macbook air (13in) for the same money? And if everything you do isn't browser based; you still care about x86 emulation and the apparently really uneven GPU performance.