Looking at your comments, which each and every one of is anti-EU and somewhat similar, I am almost convinced you are, in fact, a bot. And if you're not, then you have a clear agenda and given this very comment, just spread lies.
European brands, especially French, are currently absolutely cooking with the new EV models. The boom started with Renault 5 and it took off from there.
So I personally am absolutely not afraid of the European brands disappearing somehow because China makes them quite well and affordably now, too. This previously already happened with Japanese and Korean ones as well and, to be honest, European brands just keep delivering exciting new cars that get your heart pumping and they still do. Meanwhile it hardly ever happens with the Asian ones. It does, but it's still... not the same kind excitement.
421 4.3.2 The maximum number of concurrent connections per resource forest has exceeded a limit, closing transmission channel. xyzxyzxyz.outlook.com. PRX8 [Name=InboundProxyTrackingAgent][AGT=IPT][MxId=xyzxyzxyz] [xyzxyzxyz.ausprd01.prod.outlook.com 2026-11-13T01:08:15.373Z xyzxyzxyz]
Nah, no way they're getting rid of their M.C.-Escher-esque 'Forefront' mail-disappearance-machine-that-nobody-in-Microsoft-seems-to-understand-or-control, but, yeah, even their Internet-facing infrastructure seems unhappy:
451 4.3.2 Temporary server error. Please try again later ATTR2 [MI3PEPF00008486.eurprd02.prod.outlook.com 2026-11-12Txxxxxxxxxxxxxx]
It won't actually bounce until either gmail gives up on its retries (which generally is 24 hours) or the outlook server gives an explicit rejection (rather than a temporary error or timeout)
> (assuming they're true and measured accurately).
Precisely, because TTM doesn't tell the full story about the potential shifts in quality of the work. I don't refer to vibeslop here, to be precise, just the additional followup work required on those features released faster, which always happens but with AI it may or not happen more often.
TTM for sure is a bad indicator. Earlier this year at $DAYJOB, they attempted to switch all of the devs to a fully LLM based workflow: LLM writes the ticket, gets stakeholder input to refine the ticket, reads the ticket, does the work, submits the PR, etc. Their case study was a single project that did that process soup to nuts. The estimated time was a couple months, but they ended up going about, and I quote, "2x-3x" faster. So obviously they expected everyone to go faster.
The problem is that the way it was described to the other devs, they were able to sit all of the stakeholders down to really flesh out the idea and produce a working and detailed description of what needs to be done. A process that the company struggles to get done in general. I'm also convinced myself that they did not include the time to get the specifications written, a time we typically include in our TTM.
So of course the example's TTM was shorter, but that's always true when you start with detailed specifications. I can't speak to quality of the feature, since they hadn't even finished rolling it out to customers by the time they told us that's how we're operating. With promises of 2x-3x more features. And we continue to struggle to get stakeholders to nail down specifications and struggle to get features complete as a result. In fact, now it seems even worse than ever.
Rosetta is an emulator (or, I suppose, a series of emulators), i.e. a piece of software that makes a computer pretend to be another kind of computer. This is also a bit of lower level software that makes a (x86_64) computer pretend to be a different kind of computer (aarch64), in this case, by AoT and JIT translation, though that's an implementation detail. What distinction are you trying to make?
This doesn't emulate a computer so that code in another architecture can run, it translates the other architecture'a code to native code. It's a small difference, but I guess it is a difference.
Is this not how qemu works? Is rosetta not considered an emulation layer? For all its name suggests otherwise, I would certainly refer to wine as an emulator, and it also uses these techniques.
Not to be That Guy, but WINE doesn't use those techniques, and thus isn't an emulator.
It lightly translates binary formats (Windows executables) into Linux-compatible executable code, and then runs that code against libraries that implement Windows APIs in terms of Linux underneath. It's not an emulator in the same way that your libc isn't emulating lockf(3) in terms of fcntl(2) underneath. In web-dev parlance, we'd call WINE a polyfill.
Rosetta and QEMU on the other hand are emulators--emulators, in this instance, being a term of art that implies interpreting bespoke meaning from machine code instructions written in another program. Some emulators translate instructions 1:1, some have optimized stencils, some (like Rosetta) have kernel support for emulating very quickly, and some (maybe like Rosetta; sources disagree) also have hardware support as well.
WINE emulates an ABI, rather than a CPU or such, but I'd happily argue that that's an emulator. (In fairness, though it's not generally described that way, I would call web polyfills API emulation)
It "emulates a behaviour" and natural language is fluid, so sure, you could call WINE an emulator and I wouldn't be mad at you. But WINE is very different compared to what most emulators are. Usually the term is reserved for when you emulate in software what used to be hardware.
I believe WINE doesn't actually translate any instructions; it's a Windows PE loader and a bunch of libraries that implement Windows APIs using Linux equivalents.
Windows apps don't use syscalls directly; they call into kernel32.dll, which is convenient for Wine. (Microsoft enforces this by scrambling the syscall numbers on OS updates [1].)
Yes. Linux is the only major operating system where there is even a convention to directly access system calls. For macOS, everything goes through libSystem.
> It lightly translates binary formats (Windows executables) into Linux-compatible executable code,
Does this not involve transpilation? I guess I was grouping that in under dynamic recompilation and AOT techniques.
Regardless, I don't think that there's a benefit from defining emulation from an implementation rather than an empirical perspective. If it runs a chunk of code as if it were in a different environment, I'm kind of ok to call it an emulator. To the sibling's point, a polyfill would also fit as an emulation layer here.
Not necessarily. It could just rewrite the outer portion to be an ELF loader that then calls into a runtime that actually shims the syscalls for example. I don't think WINE does exactly this but it's not really transpiling either.
You don't even need that, really; just have wine load the PE binary into memory and hand it a bunch of DLLs that use Linux syscalls under the hood. It's less transpiler and more of a funky dynamic linker+loader plus libraries.
reply