The fact that this approach is catalytic rather than requiring a binding agent seems positive in terms of longevity and not being directly depleted by repeat exposure; but I'd be curious how durable the material is under real-world conditions(clothing that gets hard wear tends to get hard washes) and also how specific it is. 'Organophosphate' means something moderately specific in the context of chemical warfare; but a lot of fairly prosaic compounds are, technically, 'organophosphates'(like DNA and RNA when held together by phosphodiester bonds); and this would be considerably less helpful in practice if it is busy chewing up the genomes of random soil bacteria; and markedly less helpful in practice if there's a "do not perturb the nanites in your clothing if you want them to not migrate into your cells and start mitigating the harmful effects of your DNA" user notice on the treated article.

This doesn't seem like a lie, a NIC is in a pretty good position to knock something off the network if it feels like it and the 'bluefield' devices have enough punch onboard to run some rules regarding whether or not to do that; but it seems like a wild exaggeration of how helpful it actually is.

If you actually have a set of rules that detect your bot being wicked it will presumably save you some CPU time to run them on the NIC rather than having the host CPU watching the traffic; but the hard part is the set of rules that detect your bot being wicked.

This is basically the equivalent of adding a firewall and claiming that you've solved network security. Yeah, the firewall is pretty well placed to block malicious traffic; defining 'malicious traffic' is left as an exercise for the reader.

Support for Office 2016 and 2019 ends October 14th of this year; I assume that the feature is dropping now; rather than either 20 years ago as part of ECMA-376 and eventually in a live product for either Office 2010 or 2013, or never if they didn't want to do that, in order to draw a hard line under the utility of those?

It otherwise seems like a kind of weird time to do it. In principle what a 'cell' is has never really had an obvious mandatory scale: it has essentially always been relevant that a 'cell' existed in relation to other cells, so that something like an array could be a row; but it has also long been allowed and encouraged to do things like substring operations that acknowledge that cell contents are 'larger' objects that contain smaller ones; and are not automatically spilled out for that reason alone. Not clear that the pragmatic use case for spreadsheets would ever have supported some sort of 'any data type that implies it can be decomposed into elements shall be' rule, strings getting broken up into substrings and so on; but it's also not clear that the pragmatic use case is going to be much clarified by a single cell being n levels deep of lists and arrays of lists and arrays being a fully supported thing rather than something you hack on by shoving JSON into text cells or whatever.

It definitely seems like asking for confusion when some, but only some, "excel spreadsheets" have cells that are arrays, potentially of arrays, while others have rows of cells with contents that, at least formally, are not acknowledged as arrays.

That's the sort of curious thing about this announcement: at least in theory(I assume things are uglier in practice) the X1 parts that they shipped for windows-on-ARM/Copilot PCs already use UEFI/ACPI in line with what MS wants for booting Windows.

That obviously doesn't mean that there's a working GPU driver; or that naive power management doesn't cause the system to run at 90% of maximum power and hammer the battery flat; but the theory was that the last gen was already doing the "big kid ARM that has embraced PC standards" thing; very similar to the 'standards base' that ARM encourages ARM server part vendors to use.

I'm always a little curious what the thinking/strategy is with the Chinese outfits. I don't necessarily expect much from the OrangePi guys; they ship a surprising number of different SoCs, including multiple architectures and multiple vendors, for their size, so are likely to be mostly at the mercy of the SoC vendors; but is the situation for someone like Allwinner such that people who want linux to work on their stuff could be a resource for them and they are just not taking advantage of that very well; or are they actively annoyed by GPL-related claims and really just want to shove minimum-viable android out the door as cheaply as possible to win cheap tablet tenders and really do not want to hear from SBC hobbyists.

SOP at Qualcomm. It has been literal years of hammering on them by Google and basically every Android handset OEM to even keep parts that ship with android support in support for more than a few years(I think the current timeline, at least for 'snapdragon 8 elite' flagship parts, is a princely 8 years from release; and that is with the 'project treble' stuff that attempts to reduce the number of changes that might potentially need to be supported). Especially with the, um, raging success, of Copilot+ AI PCs they are probably ready to pretend that X1 never happened and call it good. I'm not even sure how long the windows support on X1 is expected to last.

That's a pretty shallow(thought admittedly depressingly popular) analysis of the situation.

Being in public does leave you with no particular defensible expectations of not being observed, and possibly even remembered for a time, by assorted passers by; and typically also permits more direct tailing of people for observation purposes(subject to some, often slightly vague, threshold at which having PIs or paparazzi hunting someone remains a problem even in public; as we saw here where the police took the notion seriously enough to show up but not to do anything in particular).

What it has historically never meant, for technical reasons, was pervasive coverage and longterm retention. Which is certainly increasingly feasible with only moderate levels of investment; but is absolutely a novel development for what 'public' and 'no expectation of privacy' meant.

It's like defending the installation of a massive network of sprinklers because "you have no expectation of staying dry when you go outside; haven't you heard of rain?" Sure, nobody the weather to be sunny all the time, any more than they expect everyone to avert their eyes in public; but they would correctly consider the installation of irrigation equipment on every lamppost to be an intrusion on their ability to stay dry despite the fact that the sky has never extended them a constitutionally protected right to no rain.

Pity the poor Europeans, crying out without the bot slop occupying the top half of the results. I wonder what Google is going to do to ensure that the 'degraded' results aren't universally preferred to the alternative?

I suspect that the relationship is not linear in a case like this: cancer tends to be a big issue for otherwise healthy-ish people because a lot of varieties of it take some time to develop; either chronic exposure to whatever the carcinogen of concern is or some time after the exposure when your luck with the mechanisms that suppress abnormal cell division eventually fails, or both.

There is probably a part of the graph that is mostly linear, nondrinkers to very light drinkers to light-ish drinkers; but anyone who is really hitting the sauce and succumbing to DUIs, cirrhosis, or other non-cancer alcohol mortality is making themselves ineligible for alcohol related cancer death.

How good is their game-streaming at cutting out the various 'filler' time(loading screens, startup animations telling you that Nvidia is the way it's meant to be played) and does it have some sort of 'suspend' state to handle cases where you would pause a game if it either doesn't have save on demand anywhere or takes a little while to load from save?

I know I have a bunch of games that I don't actually play all that much, in wall time terms; but Steam's 'executable run time' number is 2x-10x as high because I'm not necessarily going to save, quit, open, load if a game can be paused and alt-tabbed without crashing or continuing to eat all the GPU time to render a static image I'm not looking at; and I'm not necessarily going to do anything other than pause if I'm called away for 15 minutes by something else.

Unless the streaming service is impeccable at cutting out the various little waits it seems likely that people are going to start resenting the time limit even more than their level of seriousness and actual hand-on-controller-and-attention-locked time suggests.

Given that they already purchased Activision Blizzard King, including the "King" part of it, they clearly already have a considerable interest in casual players.

What is less obvious is how that is supposed to work for their streaming service. The stuff aimed at casuals, sensibly, is normally targeted at either potato-tier PC specs or the (pretty punchy in absolute terms) mobile devices that people worth targeting have.

It is much less clear whether there's a 'casual' market that demands current-gen console performance in very limited amounts rather than mobile or iGPU level titles. Given the extreme prevalence of various 'free to play' models that do sneaky monetization later it also looks like the 'casual' market's (significant) amount of money is largely locked up behind the sort of price sensitivity that requires clever psychological tricks to break through. I'm not sure that they'll be a good fit for something as obvious and psychologically burdensome as a ticking countdown timer hanging over every minute they play.

I have no particular reason to assume that Nvidia is lying about what this software does; but unless they've stumbled on a veritable miracle it's going to mostly be a mechanism for running largely separate models of whatever size your hardware allows; not anything close to what the datacenter comparison implies.

There's a reason why Nvidia sells most of their higher end models intended for parallel use with NVLink between the chips inside the chassis and a lot of either infiniband or RDMA-capable ethernet between multiple chassis; as well as shoving a considerable amount of RAM per GPU onto those parts. And it's because latency and bandwidth matter a lot.

As it is people seek out the unified memory parts, Apple's or strix halo, or nvidia's little GB10, because the GPU having to go to main memory over a mere x16 PCIe link is already a serious problem. If you think either 256 or 512 Gb/s directly to the PCIe root on the same die as the main memory controller doesn't cut it I have some...bad news...about how well NICs are probably going to work for you, especially with the Nvidia parts that don't support RDMA even if you have NICs that do.

Physical ones are definitely rare beasts. Hypervisors make having support for it a lot more generally useful, though. You can still run into weird edge case limitations(certain PCIe devices, under some circumstances, really don't like being detached from the host and popped onto a VM); but the hypervisor will definitely be able to tell guests stories of dynamic reconfiguration that the hardware isn't electrically or mechanically capable of supporting; and being able to add or remove CPUs or RAM without rebooting is nice.

It could certainly just be a numbers game; tons of ICE vehicles out there; or whether there's an issue with accumulated cultural assumptions and engineering priorities.

I can at least imagine that there's a difference in mindset between "this is a 12v lead acid starter battery; it'll put out a solid few tens of amps for the starter motor assuming it is working correctly; but its energy density is kind of trash and we mostly prefer not to dump additional systems onto it, especially when that exposes them to the slightly gross output of the alternator" and "This battery has been designed to fully provide for all energy requirements of a vehicle; if you displease it it will probably kill you and then burn vigorously for a day or two. A foundational assumption of all systems that need energy is that they'll be connected back to it in one way or another because there aren't other energy sources here."

Not like electric vehicle designers couldn't/don't make mistakes, and certainly some of their mistakes burn with the really exciting commitment of a large light metal fire; but the engineering culture around an ICE vehicle seems much more likely to produce a string of individually reasonable, collectively dangerous, "c'mon, it's just one little 12v system" requests that get bolted onto a fairly antique battery without too much broader thought; while analogous feature demands in a fully electric vehicle will either be judged high energy enough to potentially get brought into the high voltage wiring(which, barring gross negligence across the design is treated like it can and will kill you) or totaled in to some low voltage system budget that will be handled by a DC-DC converter designed with actual care because going from 600v to 12v isn't something you do as casually as just slapping another 12v requirement in parallel with the other stuff on the 12v battery and calling it good.

This sounds like it was written by someone who actually knows what they are doing, so I assume that they know better than I; but I am surprised to hear that it is impersonating a system dll; since (in all comparatively recent windows versions) system components are signed. Absolutely tons of fuckery you can do to them and around them; but if dpapi.dll doesn't have a signature that checks out the mechanisms that try to keep OSes up and running on marginal hardware subject to random power loss will likely eventually object and attempt a repair, even if there isn't any more paranoid EDR tooling in place.

Is the on-disk copy of dpapi.dll untouched and only the in-memory instance tampered with?