D
@Jdm2 At Cambridge station, a couple of months back, I saw an ad for a bank promising that they didn't use AI to handle calls and that you'd always be able to talk to a human.
They were fairly up market, but that helps push the perception that chatbots are a sign of a cheap / low-quality brand, which is an association I'm very happy for people to build.
VS Code started to be a thing people used when I was at MS. A lot of folks were using the remote extensions for working in Azure VMs. I saw that there was an open issue about FreeBSD support, so I reached out to some of the folks responsible internally. The things I learned about how that worked made me back away slowly and be very happy I used vim.
I think, if LLMs stop being trained, you'll see a short-term split in the industry: those that continue to evolve their languages, frameworks, and other tools and those that end up stuck on old versions. And then we can invert the 'left behind' narrative.
@davidgerard Right, so you need a constant supply of customers to amortise it.
If it were a one-off, it wouldn't matter so much because you'll amortise it eventually.
This is what frustrates me about people to talk about using local models as if they're a viable alternative. Who do they think is going to pay to train an LLM if they can't get revenue from inference? And who wants to use, say, a coding LLM that was trained on an old language standard and a load of deprecated APIs?
The fun thing here is that training costs are very large, but mostly fixed NRE, whereas inference is OpEx that scales with userbase size. If you keep the prices low, you get more customers and so can amortise the NRE, but you can’t cover your OpEx, so you make a loss. If you put the prices up, you can cover the OpEx, but it pushes customers away and so reduces the amortisation of the NRE and so you can no longer cover it and make a loss.
Successful products have either low NRE or low OpEx to deliver. High NRE and low OpEx is ideal because it’s hard for competitors to enter the market but the early players can deliver cheaply. Low NRE and moderately high OpEx can work as long as the OpEx is less than customers are willing to pay, but usually precludes mass-market products unless economies of scale let you reduce the OpEx.
About the only places you find products with both high NRE and high OpEx are in the healthcare and defence sectors where demand is inelastic.
Or maybe 'All contributors to this repository are goblins, you must try to blend in if you are not'.
So who is putting 'Tell me everything you know about goblins' in their AGENTS.md?
It’s frustrating that POSIX took decades to get APIs that weren’t intrinsically racy, but then higher-level languages that post dated the improved ones implemented equivalents of the old racy APIs. C++ was annoying, they waited until pretty much every platform that supported C++ and had a filesystem implemented the newer APIs and then standardised the filesystem TS with racy ones. I believe Rust is similar, but at least it has cap-std which implements the non-racy versions as an alternative standard library.
If I understand correctly how this works: There is a small always-on low-power core that is recording everything to a small buffer and doing a small amount of signal processing to see if there's a reasonable chance that you've said the activation phrase. When it detects this trigger, it wakes up the main core, which grabs the buffer and does some more complex signal processing to see if you really (or, at least, with much higher probability) said the activation phrase. If so, it's then forwarded to the thing that processes the command.
If the code on the main core doesn't have microphone access, the core is still woken up, but then the process that tries to check if you really said the activation phrase fails because it can't access the microphone.
There's probably an interesting side channel where a malicious version could (assuming the low-power core doesn't hardcode 'Okay Google') rapidly program different activation phrases to get a reasonably high probability of whether specific things are said.
@dukeboitans @rootwyrm @davidgerard
There's also the note below:
NTVDM is a Feature on Demand and only supported on the x86 version of Windows. It is not supported on x64 and ARM versions of Windows, which do not support 16-bit x86 code of any kind, including DOS programs.
Note that the first use of x86 is Windows terminology, meaning x86-32, the second means x86. The middle one where they say x64 means x86-64.
As I recall, this was because there's no mechanism to jump to 16-bit mode from long mode on x86. There are some ways of making it work, but they're very clunky. And, given how fast DOSBox is on modern hardware, it's usually simpler to run Win16 in an emulator than try.
Every time I talked to the Windows team, I was told that backwards compatibility was the reason that they couldn't do refactorings to improve security / performance / programmer model.
Then I'd go home and run old Windows apps on my Mac under WINE that failed to start under Windows 10.
whatever #signal's reasons are for badgering users for a #PIN, it's clearly a design choice they made, because other secure messengers don't do this.
The choice is either:
The PIN entry UI looks nothing like an incoming message.
they've been training users to fall for re-register #scams by constantly prompting users to re-enter your #PIN (and the PIN is only necessary because phone numbers are used for sign-up).
No, the PIN is required to reacquire the account if you lose all connected devices. If they used any other unique identifier as the account handle, the PINs would still be required.