The decision to do it was made in 2011, and they've been building the parts that will go into it, and they'd already committed to doing the installation at the end of the current operating period, but the schedule for ending that period is "mid-2026", so he gets to be the one who makes that date exact, with people hoping to get one last experiment that doesn't need the upgrade in before they have to wait a long time.
That's what a kernel developer told me when I reported this problem. In particular, they said I had a machine with an nVidia device that was different from all the similar devices they'd seen in not having the second copy engine actually function. They gave me one line of config for my PCI ID, and then it worked perfectly.
They found and fixed the issue immediately upon seeing logs from my machine, but they'd never seen exactly that issue before to know in advance that it was a possibility.
It seems to me that, if you were developing something like this, you'd want to write the encryption and decryption code separately from the non-trivial key management code, so that you can unlock it easily if someone accidentally locks the wrong system. You only make the build that doesn't have an obvious key when you're really going to use it. For that matter, it's probably wise to do your demos with the version with the master key, so that potential affiliates can't attack a real target for the demo. Then you give the version that doesn't make it easy to unlock to paying affiliates who aren't SentinelOne. It's not like they'd need to redesign the whole system to generate a random key and not write it in plaintext anywhere.
Silicon wafers are the wrong thing to compare against. The CZT semiconductors are like photodiodes (for other radiation), not what they make the logic out of. It would make more sense to compare with InGaN (for blue LEDs), which plays a similarly specific role in common devices.
These days, the market is more trusting of the statement that better tools and processes require fewer employees to serve the same customers if you call that AI. If you get more of your customers to succeed in using your website or app to do what they need without having a human do anything for them individually, you don't need as many employees doing it. But the market doesn't want to hear that you can cut jobs because your website doesn't suck as much any more, so you say AI and they think you've done something futuristic when you've actually done something practical, and you're vague enough about it that the SEC can't say that you claimed to be doing something you're not.
My understanding is that despite the competition catching up in terms of the image creation/editing capabilities Abobe is still where you need to be to when you need to manage font licensing and pantone color matching and print workflows.
I'd be happy to be told I'm outdated/wrong on that though...
Give it time, he also doesn't watch TV, but only just recently stopped announcing it.
It's actually pretty understandable.
Despite the meme power of a broken login, the bug affects a fallback feature you might well go years without using.
It requires you have PIN/Touch sign in enabled; which if you've enabled that, that means that is how you normally login.
And that works just fine. Nothing is broken there.
What is missing is a "password" icon in the 'fallback' options to "sign in a different way" (using a password, e.g., instead of a PIN or fingerprint.)
So despite being on the login screen, its not actually something you are going to regularly interact with normally, unless you forgot your pin or something. And its hardly something human beta testers are going to think to explicitly test for, every single build. And since the bug is a missing element as opposed to a visibly broken element, well, its easy to fail to notice something you almost never use isn't there.
Meanwhile, clicking where its supposed to be still actually works, so its entirely plausible that you could have automated test scripts that continue to pass if they've been scripted to click at coordinate (X,Y), or to select the password button programmatically by an identifier or something, and then 'expect' something to happen in response, because the button is there and it works just fine, its just missing its texture or something. This would slip past a lot of test frameworks, the button is "in the model", "its active/enabled", "its selectable", "its clickable", and "it fires a click event if you click", "and whatever it is supposed to do happens", and its probably even "visible" (though you can't see it); most likely the icon or texture is missing or unassigned or referencing a transparency by mistake, and its just a "transparent button". So unless you specifically add checks to screen capture and compare a pixel block range to a reference image bitmap or something, you aren't even going to catch it with an automated test.
Tests like THAT do exist and can be written, but its not usually very useful, and the cost to write and maintain such tests with reference images is huge. change an icon or font or background color and a zillion tests need to be updated. Its a difficult balancing act to decide what to test, even for a highly competent QA team.
It's possible it just outright incompetence too... but in this case, for this bug... its pretty understandable.
All of the headline changes go in during a two-week window at the start of the cycle, having been developed previously. Several people write articles during that window about what got merged, so the list is already known when the release actually comes out two months later. (That two-month period is used for testing in more unusual situations and checking for incompatibilities among the set of changes that got merged for the cycle.)
So this article is really reporting that two compact weeks of merge decisions in early October are now officially considered tested and ready, and they wrote the article and people checked it over a while ago now.
The part that's harder to track is ongoing development work, which happens continuously without a set schedule, but it happens in separate trees and only goes into the official tree when it's complete, has been reviewed, and has gone through various testing in systems managed by kernel developers. All of the work described here was done before 6.17 was released, and developed during several releases before that, but it didn't need to affect Linus's tree until he decided it would land in 6.18.
They generally use a primary and standby system, just because it's a lot harder to avoid consistency problems with multiple primaries. This means that you need to direct traffic to the current primary, and redirect it to a standby when necessary, which is fine except that the system you're switching away from and the configuration interface for your DNS provider are both in us-east-1, because everything normally is. That's why they're looking for the ability to make a different region primary specifically during in AWS outage.
Spotify offers lossless... I recently enabled it.
There's a typo in the headline. It's supposed to read "Microsoft Forms Superintelligence Team Under AI Chef Suleyman 'To Serve Humanity'".
"a decision and action appear to takes place milliseconds before the conscious mind is aware of it, but phenomenologically it feels like you made that decision before the event happened."
I certainly don't know, and I don't think the research answers that question yet.
But from what I've read its research that raises many more questions than it REALLY answers.
For example, what if the consciousness feedback loop is not "aware" of the decisions (its "output") until they've been dumped to memory and looped around and come back in as "inputs".
So that doesn't necessarily mean you don't consciously make decisions, it just means you aren't yourself aware you made it until after you made it.
In web programming terms, suppose "consciousness" is the local application state view, which is a reflection of the data on the server "memory" and has all your data labels and field contents showing (including the logs of its decisions). Imagine too that a "decision" is like activating a call to the server to make a an update to the back-end database.
So based on the data in the local state, and the running software, the local app "decides" to calls the server and make an update. Lets just say, it just does it -- in particular it doesn't feed that information back to the local state object, no UI is updated, no labels are changed. Yet.
The local state is not updated with even the record that it made the call until it gets the state update from the server a few milliseconds later.
Then, if you are a brain researcher monitoring the application state (aka consciousness), you'll discover it doesn't "know" it called the server, until after the server has been called and returned.
The point is: just because we don't know what we decided right away doesn't necessarily imply that we didn't decide. The brain is an organic system that evolved over millions of years, perhaps having consciousness run a few milliseconds behind is perfectly serviceable solution for the problems it evolved to solve.
Perhaps its even advantageous, waiting for the awareness of the decision to propagate through consciousness before emitting the decision to the rest of the body might cause enough action latency that we're polar bear or sabre tooth tiger food. Better to get the body acting act as soon as the information is there -- there's simply no survival advantage to waiting for it to get dumped back to memory and updated in the consciousness first.
Or maybe consciousness is an illusion, so we can watch a show that aleady happened with no impact on the world around us... but that seems relatively useless in a world with polar bears and sabre tooth tigers.
My concern is the opportunity to lie.
An empty room is tough to gauge the size of (even in person).
A staged room, with a bed and dresser gives you a better idea of how spacious or not spacious the room is, and how you might furnish it. This is valuable information when forming an opinion about the house and its suitability.
Realtor photos already have a fisheye problem with a lot of the pictures and video as they trying to show more of the room at once which causes scale to be tough to determine.
Add AI staging to that and it is even more problematic, because they can stage it with furniture that isn't scaled correctly. I've seen some AI staging where things are just scaled wrong, like the bedroom dresser is only 4" deep, and couches are sunk into walls. But its not obvious to look at it. Or there's two cars in the garage but they're 15% smaller than they'd actually be so it looks more spacious. OR there's two large couches with a large coffee table between them with a fireplace off to the side, and room to walk around it all and then you realize that either the fireplace is 8 feet high and 12 feet wide and the ceilings are 25' high
Physician: One upon whom we set our hopes when ill and our dogs when well. -- Ambrose Bierce
