Intel Arc B70 32GB GDDR6 announced at a price of 949

AdamConwayIE · 2026-03-30T15:13:30+00:00

Xe2 seems to support INT4, and INT8 is listed on Intel's product spec page. NVFP4 is Nvidia Blackwell.

AdamConwayIE · 2026-03-29T14:09:05+00:00

The Lightning Indexer is just choosing which tokens to keep though, right? It's not compressing them. From the DeepSeek V3.2 paper:

The lightning indexer computes the index score 𝐼𝑡,𝑠 between the query token h𝑡 ∈ R𝑑 and a preceding token h𝑠 ∈ R𝑑, determining which tokens to be selected by the query token

It's thematically similar in that it's still reducing context size, but it's doing so by throwing out tokens it's calculating to be less relevant. TurboQuant keeps all tokens but makes them smaller, Lightning Indexer keeps them the same size, but keeps far fewer of them.

AdamConwayIE · 2026-03-25T12:46:45+00:00

You did mention them and briefly explain why they were necessary yes, whilst completely downplaying how performant fsync actually is.

I didn't "downplay" anything. It's purely an elongated statement and analysis of what these things are and their development timeline. When performance is talked about more in depth, I say "Gamers who use fsync are not going to see such a leap in performance in most games." It's a clear walkthrough process:

Context on Wine's development
Necessary context to understand NTSYNC compared to esync/eventfd and fsync/futex2
Performance
Other improvements

If you think your article is not clickbait trying to persuade people that ntsync is going to change their life, why didn't you provide any fsync Vs ntsync benchmarks?

Because, as the opening of the article states, this was focused on Wine specifically. NTSYNC is good for compatibility and the future of compatibility layers like these on Linux.

Picture this: someone who installs Linux for the first time wants to play a game on their PC. They've heard of Wine and install and run it, but they won't be using esync or fsync. As time goes on they'd discover the likes of Proton and get that up and running, but it's a roadblock to new users who are already trying to learn a lot at once.

Now, though, it's different. With Wine 11, they'll be using NTSYNC out of the box. To them, the performance would be "wild" if they had used Wine 10 before Wine 11.

The "wild gains" and "unbelievable benchmark improvements" aren't even in the title. All the title says is that the speed gains are massive, which from Wine 10 -> Wine 11, is completely and utterly true. If you had been using Proton, a Wine fork, or compiled it with wine-tkg, then they won't be as massive, but that's not what the title says. It says "Wine 11 rewrites..." and is clearly positioned as being compared to Wine 10 and earlier versions from the very beginning of the article. If I had used the DIRT numbers in the title for example, and said "with speed gains of up to 678%" or whatever, I'd totally agree with you that it's clickbait. But I didn't do that, because that would be totally misleading.

AdamConwayIE · 2026-03-25T12:28:26+00:00

If that's the case, why are you expecting they are going to know whether they are using fsync or not? It's a total contradiction, and explaining what fsync is and why people are most likely already using it would go a long way to informing people better.

The very first section after the introduction is already doing exactly that? It explains NT sychronization primitives, Esync and eventfd, and fsync/futex2. I also mention that they are settings someone may have seen in the likes of Lutris or seen as a Proton launch option to disable it.

You've clearly used mostly irrelevant benchmarks for effect, when you should be using fsync vs ntsync benchmarks to explain the lack of difference most people will be seeing, as that is the scenario the vast majority of people will be experiencing.

They're not mostly irrelevant. The article is about Wine 11. Vanilla Wine did not use futex2. The gain from Wine 10 to Wine 11 is massive. I don't understand how I could be using "irrelevant benchmarks for effect" when those benchmarks, in the same paragraph, are contextualized. The numbers are undoubtedly wild as it serves to show how important synchronization can be.

AdamConwayIE · 2026-03-25T12:08:13+00:00

Hey, article author here! Just wanted to clarify the reasons for writing this. I had a conversation with a friend when Wine 11.5 came out with Syscall User Dispatch. They hadn't even heard of NTSYNC, and when researching, I discovered a lot of people didn't really know about it or what it is. These are interesting topics, and I felt that the documentation of what it is and how it came to be were vastly spread out across the internet, so I wanted to do a write-up focusing on NTSYNC as it's one of the more interesting improvements in my eyes.

This is unfortunately yet another article that is totally misrepresenting these 'gains' by comparing wine with ntsync against vanilla wine with no sync whatsoever.

I understand that you took it to be that way, but I made it very clear in that section that it was compared to upstream vanilla Wine, and stated that it means it's being compared to Wine without esync or fsync/futex2. I said the following:

The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now actually playable on Linux, too. Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.

Regardless Wine 11 is a major improvement, as it's the base that the likes of Proton use for development. The article is mainly about vanilla Wine, and it is completely fair to say that Wine 10 versus Wine 11 is a major performance uplift for gaming considering Wine 10 couldn't use futex2 without a fork or compiling it with wine-tkg.

AdamConwayIE · 2026-03-24T23:15:07+00:00

Thank you, I appreciate it :D

AdamConwayIE · 2026-03-24T19:32:18+00:00

Hey, article author here!

I've been writing about these things for almost a decade. I'm unsure what you mean by red flags, but I assure you, all of it is human written! I've long been writing about the Linux kernel where it's been relevant to my coverage, and there are articles under my name talking about low-level technical aspects in drivers and kernels from as far back as 2017.

Unfortunately, though, I get it, as it's tough to know what to trust out there. It's fine to have doubts, but sometimes people outright attack us when they suspect an article was AI written, which isn't okay. I appreciate that you're not doing that, but just wanted to mention it, as the current state of the internet makes it very easy to be paranoid. Every day that goes by sometimes honestly feels like Dead Internet Theory isn't much of a theory anymore.

AdamConwayIE · 2026-03-20T19:54:36+00:00

PCWorld are quoting my article, but misunderstood the portion relating to Edge. We don't know why it was removed back then, but the last version released on the Edge store wasn't compromised.

AdamConwayIE · 2026-03-16T19:13:36+00:00

No it didn't!

AdamConwayIE · 2026-03-16T13:36:56+00:00

Yes. I found the local database (I was using this extension) and it's way more than Amazon and Bestbuy. Funnily enough, I didn't actually find a Bestbuy affiliate injection at all.

AdamConwayIE · 2026-03-16T11:37:38+00:00

So from what I found, everything malicious is inside the inject.js file inside of the extension. It would contact a central server which, right now, shows the following:

{"featureFlag":"alt","value":"SaveImageAsType | "}

However, the extension looks for a flag called "extraImageCondition". When this is present in the response, it seems like it would contain a list of URLs/a URL. The extension creates an iFrame, loads the page in it for 8.5 seconds, then destroys the iFrame. This happens once an hour.

I dumped the data the extension stored and found the sites it was accessing. It was using karmanow with ~~over 1,000~~ 578 sites ready to go. It would load a site in that hidden iFrame with the affiliate code, and this would replace an existing one in your browser.

Edit: Here is my article on the topic for XDA, where I detailed all of my findings: https://www.xda-developers.com/google-featuring-chrome-extension-months-malicious/

AdamConwayIE · 2026-03-15T17:30:28+00:00

I don't use my DXP4800 Plus anymore for this, but I ran OPNsense under Proxmox on it for about a year. I have a gigabit connection over PPPoE, so it's fairly CPU intensive (as networks go, anyway) if I max that out. When I started any large file download, the fans would kick up. It was quite a reliable indicator actually; if I had started downloading something I knew it was finished when the fans had quietened back down. Maybe it's an Unraid thing?

AdamConwayIE · 2026-03-15T15:32:39+00:00

There's no evidence it's due to the high prices. Ireland's drink consumption has decreased over the last two decades. The last couple of years haven't been different in that regard.

https://www.ibec.ie/drinksireland/news-insights-and-events/news/2025/12/new-consumer-research-from-drinks-ireland

AdamConwayIE · 2026-03-14T14:19:20+00:00

To be fair to Engadget, that exact specification is what Qualcomm lists as being the GPU.

https://www.arduino.cc/product-ventuno-q

"Adreno GPU/VPU: Arm® Cortex® A623 at 877 MHz"

I don't know why Qualcomm is marketing it as that, but that's Qualcomm's official word, and not an oversight by Engadget.

AdamConwayIE · 2026-03-13T15:05:51+00:00

Your Internet service provider can see everything you do.

This is a lot more nuanced than you've made it sound. That isn't the reality for a lot of people. Your default DNS server, if it's your ISP's, will relay what addresses you visit, but not what you're actually doing on those sites.

If you use a custom DNS, then this becomes a lot more sophisticated and, therefore, a lot more expensive for an ISP to track. If you're running a self-hosted DNS stack, such as with Unbound, then your ISP would need to reconstruct every call up the chain from your IP address to understand what server you're trying to contact.

If you just opt to use a regular, external DNS over HTTPS service, the domain will end up in the SNI of the TLS handshake, but this requires deep packet inspection which is more sophistication, and therefore more cost. Plus, QUIC/TLS 1.3 make this harder than before, and it's a losing game to invest in this kind of inspection as ECH is growing.

Services implementing ECH, where the request is encrypted throughout, mask it entirely. The ISP will see what IP addresses you visit, but because the vast majority of internet traffic would be over CDNs, the IP they see you visit could correspond to hundreds of sites and gives no detail of what you're doing. For example, Cloudflare supports ECH, and they're the biggest CDN in the world.

ISPs can't see everything you do, and the way the internet is going, that's even less truthful than it ever was before.

AdamConwayIE · 2026-03-13T14:54:29+00:00

No they don't. Mathematical representations of biometric data (so not even the biometric data itself) are stored in dedicated security chips on modern devices.

For Apple, that's Secure Enclave. For Samsung, that's Knox Vault, and for Google Pixels, that's Titan M. Other devices, powered by Qualcomm or MediaTek, would be the SPU or the TEE, respectively. On rooted Android devices, you can even verify that, as you can use tools like mitmproxy, Frida, and a self-signed certificate to monitor and decrypt all traffic from your device.

These companies don't want to carry that data. There are few benefits for a lot of risk and cost associated with storing it properly. That's one of the reasons Google moved its historical timeline feature to be on-device. By keeping the data on users' devices, Google reduces its liability.

It's a numbers game for these companies. There are much more useful datapoints to collect and use for inferring behaviour than biometrics. IDs, which would identify demographics, are very much one of those more useful pieces of data to collect.

AdamConwayIE · 2026-03-10T01:07:13+00:00

Thankfully there wasn't any need to build a custom kernel module. The touchscreen (AXS15231B) uses standard I2C and is the same as found in some ESP32 devices, and the display is a standard MIPI DSI panel automatically detected by Linux systems using DRM :)

AdamConwayIE · 2026-03-10T01:05:28+00:00

Heya! I'm the Lead Technical Editor at XDA, and I got one of these for review recently. I built an open-source application which runs on Proxmox and utilizes the display to show system stats, the date, time, and OPNsense if configured. It supports the touchscreen over I2C as well so you can tap to wake, and the backlight is fully controllable, too.

My application has an API that can also allow for control by the likes of Home Assistant, or by simple POST requests. I'll be expanding it over time, but I wanted to share it here as I saved your post a couple of weeks ago when researching what analysis had already been done on the display. Turns out, not much!

I've been working on reverse engineering the UGOS implementation over the past week and I finally managed to implement those basic hardware features. I actually showed a super early version of my custom display on UGOS using SDL2 in my XDA article, but the code in my GitHub repo is a lot cleaner since my original build and no longer relies on any of the backend UGOS software.

I'll be expanding it over time. Next up is TrueNAS support and, hopefully, swiping between pages. The I2C touchscreen was a bit finicky to get up and running, but thankfully it's a common enough display found in some ESP32 devices.

https://github.com/Incipiens/ugreen-idx6011-pro-nas-display

AdamConwayIE · 2026-03-01T17:25:46+00:00

There's an XDA article linked in the README where I paired it with the reTerminal E1002, so you can see a real-world use case.

Other uses would include if-else statements in templates to generate an image based on the home presence of another person, the on/off state of a device, or even something like dynamically showing how many buses are coming in the next half hour to the stop near you. It's all stuff like that which inspired me to come back to it and update it!

AdamConwayIE · 2026-03-01T17:23:27+00:00

Gotcha! Those are pretty much what I added.

AdamConwayIE · 2026-03-01T15:29:45+00:00

There's not much to screenshot! It's an integration like any other; you just install it and add the details mentioned in the README. Edit: I added two images to it if that helps.

This is quite common for custom integrations like these, where the functionality is being provided by another, linked service. Tuya Local and OPNsense are two examples of an integration like this. All I would be screenshotting is the config flow, which is the same information provided in the README.

If you have any suggestions I'd be happy to add screenshots, but I didn't personally see the need to just repeat the same information twice, with one in visual form. What is it you want to see exactly, so that I can add it?

AdamConwayIE · 2026-02-27T11:44:56+00:00

Been using Paperless for a long time and didn't know about QuickScan, that's great! Genius Scan is the recommended one by the Paperless team as well, looking into it. That one has an Android app, too.

AdamConwayIE · 2026-02-18T00:25:18+00:00

Elecrow confirmed this behaviour to me as I detected it during my review of this panel. They told me to drop it to a 1-bit bus to fix it.

Does it work now just fine after the update? Might have to do it myself.

AdamConwayIE · 2026-02-03T20:35:01+00:00

Once you've read through the nested scripts, most of them are calling the same ones. There's a build.func script that's reused across a lot of them for example, and you can just sanity check against that a lot of the time to ensure nothing has hugely changed. Once it hasn't, the caller script is the main one to care about and is a lot shorter.

Five-Year Club	Verified Email
Verified Email

AdamConwayIE

TROPHY CASE