Technology

Archive link: https://archive.ph/EkF2v (Almost all links omitted)

If data brokers can track the devices you take with you, they know where you live, where you go, and what you do. And the stakes are only poised to climb higher, now that surveillance companies that sell automatic license plate readers (ALPRs) are getting in on the game. Defense contractor Leonardo is promoting a new technology called SignalTrace that will package plate cameras with sensors that can scrape unique identifiers tied to your smart devices and make that data available to law enforcement.

A recent report by 404 Media dives into the objective of SignalTrace and how it’s being marketed to authorities. Police, border security, and other government agencies already comprise Leonardo’s customer base, and with this technology, those clients seek to correlate footage from these cameras to phones, tablets, wearables, AirTags, and, naturally, the electronics inside cars themselves.

If SignalTrace can pick up your Bluetooth headphones, you can be damn sure it’ll also be looking out for your vehicle’s 5G hotspot, infotainment system, and even its tire pressure monitoring sensors. Hell, the company includes pet microchips as a potential entry point to tracking.

An excerpt from Leonardo’s own literature on SignalTrace. Leonardo

The goal here, as 404 sums up, is to “bridge the gap between vehicle and occupant.” Previously, these cameras could track a car’s whereabouts at a given time. Throw in a glut of unique identifiers, though, and the job of tying an individual or multiple people to that vehicle becomes trivial—and not something anyone can simply opt out of.

Of course, ALPRs were already bad news; the Electronic Frontier Foundation found that the simple act of repeatedly capturing photos of cars in transit at multiple points of their journeys, day in and day out, was enough to establish someone’s “pattern of life” and even identify those they associate with.

Leonardo was granted the patent for the technology that underpins SignalTrace two years ago. A press release announcing the milestone concludes with a disclaimer that the company’s tech “captures device frequencies emitted into the air” and “does not decrypt or capture the contents of the devices or their communications.” That’s precisely how these firms are able to evade culpability for the surveillance they enable. Whether they’re cracking encryption or not, the results are the same.

cross-posted from: https://lemmy.ml/post/48869069

I recently put together a PC which has a Zhaoxin KX-7000/8 CPU, a Moore Threads MTT S80 GPU, and it is running Deepin 23 installed on a YMTC manufactured NVMe SSD.

Someone had the same idea and beat me to the punch, and made a similar build in which they tested gaming performance on Windows.

However, I am a Linux user. I don't use Windows at all for anything. So, naturally, I tried the Linux drivers for the MTT S80, and immediately ran into some issues.

I could not even browse the web, because Firefox kept crashing due to some driver glitch. It turns out, however, that it is only because, for some bizarre reason, Moore Threads lists driver 3.0.0 as the most up to date driver on their website, but it's a lie.

Burried in this specific version of their SDK is a folder containing driver 3.1.0, which when I installed, all the crashes went away.

Gaming on Linux with the MTT S80 is impossible. Moore Threads only provides 64-bit drivers. The Steam client is 32-bit, so it won't even launch. It's possible to force it into software rendering then tell the games you run to use the GPU, but most games still have some 32-bit dependencies, so basically 99% of games will not launch. I tested with dozens and only could get Vampire Survivors to launch.

When I gave up on getting gaming to work, I decided to try and run AI models on the GPU instead to experiment with its AI performance. Deepin has a built-in AI assistant which can you configure to use your GPU and run entirely locally, which it would be neat if I could try to get it to work with the MTT S80.

However, I immediately ran into another issue. For some reason, Moore Threads locks down the driver to only run on Ubuntu 22.04 specifically. If you boot into any other Linux distribution, the driver has a built-in whitelist that will detect it's not Ubuntu 22.04 and throw an error.

Of course, I could not let that deter me. So I cracked it. Below is the project page for my cracked version of their driver. Basically, I just had to disassemble the driver and look for the branch instruction that jumps to the section of code where it throws the "unsupported OS" error, and overwrite that instructions with NOPs, and then the driver functions just fine on Deepin.

https://www.foleosoft.com/software/MUSA-Unlocked

I am specifically using Deepin 23 because it works well with the iGPU driver for the KX-7000 as well. The neofetch says I'm using the iGPU because I actually am running the graphical environment on the iGPU and not the MTT S80 to free up VRAM on the GPU.

I tried for ages to figure out how to get Moore Thread's SDK working and kept running into so many issues I was considering giving up. Even installing all the versions in a single package from their website, it would still say there was a version conflict between the different parts of the package.

However, I found that if you are running driver 3.1.0, they actually have an official Docker container which has a pre-setup SDK environment for you. This is another reason why you will want to be using driver 3.1.0.

Getting this setup is very easy. llama.cpp has official support for this GPU, so I was able to compile it quite easily within the Docker container. I tested running gpt-oss-20b on it, it takes up about 14GB of the GPU's memory, I tied this also as the back end of the AI assistant in Deepin.

It runs at a starting speed of 13 tokens per second (LLMs tend to slow down the more you fill up the context window / the longer the chat log is before starting a new session). Not very fast but neat seeing it run at all regardless.

There is also a Python package called "torchada" which translates all PyTorch calls to an Nvidia GPU to the Moore Threads GPU, so programs that are built for Nvidia GPUs in Python will just think you have an Nvidia GPU and run normally.

You can get ComfyUI working just by adding "import torchada" to the top of the "main.py" file, and then you can generate images on the GPU. A 1024x1024 image takes about 1 minute to generate, and a 512x512 image about 15 seconds. This also takes up about 14 gigabytes of the card's VRAM. None of these speeds are particularly fast. But I had fund tinkering with it regardless.

Sadly I could not get my favorite image generating studio to work on it, EasyDiffusion, which I like because it is the only image generating studio I'm aware of that allows for parallel batch generation, which is useful in my AI server with two 3060s since I can batch generate images twice as fast in parallel. I am sure it's possible to get it to work, but would require a lot of tinkering with the files.

As for the CPU, you can run GeekBench 6 on Linux, so I ran it both on my PC with a KX-6000 CPU and my new PC with the KX-7000 CPU.

Almost three times the performance uplift in a single generation is pretty impressive, relatively speaking, although the absolute performance is not particularly great.

The KX-U6580 is comparable to an i5–750, and the KX-7000/8 is comparable to an i7–4790 for its single-core score, and an i7–5500 for its multi-core score.

Not great but then again, I had used an i5-3470 for ages before finally building a proper gaming PC when I upgraded to an i7-12700K. Even a third gen i5 is enough for web browsing, remoting into your work, and playing smaller games. As long as you're not trying to play AAA games then it is fine for most people.

The iGPU on the KX-7000 basically cannot do anything graphically intensive, but it does do video playback fine, so it is a nice-to-have if you want to take some load off of the GPU by running the graphical environment on the iGPU. I haven't had much issues with it playing video in Firefox on YouTube and Twitch and Bilibili and such.

Anyways, that is all. I would not recommend this setup. I built this PC because I wanted something to tinker with (my house is filled with weird computers). It actually cost a decent amount of cash to acquire all the parts to put together, despite not even having good performance. It's more of something I built for fun rather than an actual good investment.

As mentioned, I also have a PC with a KX-6000 processor. The insides are kinda cursed because the board I acquired I think was meant to be integrated to a display, not used in a desktop PC, but I got it to work with many adapters.

This is running UOS Home Edition, which I managed to get an official license key before they discontinued it, so it is actually an activated copy. Since they stopped officially updating it, I started playing around for fun with updating it myself. I managed to port Flatpak to UOS which lets you then install things like the latest version of Steam, which if you have at least Flatpak 1.16.1, you can also get Lossless Scaling to work within Flatpak Steam.

I then put an RX480 in this computer and was playing around with gaming in UOS on it. I could only get like 30 FPS in Megabonk... not exactly a gaming powerhouse lol, but another one of my weird projects. My cracked driver for the Moore Threads GPU can theoretically be installed into UOS, so I could swap out that RX480 for one. Maybe I'll pick up an MTT S30 to put in there to tinker with.

There's a really interesting quirk in modern architecture that a lot of people have been noticing lately referred to as the Curse of Depth in the paper. Basically if you look at popular models like Llama or Qwen or DeepSeek you will find that the deeper layers are surprisingly useless. You can completely prune away huge chunks of the later transformer blocks without actually hurting the performance of the model. The representations in these deep layers end up looking practically identical to each other, and it's a massive waste of GPU hours because we are training billions of parameters that end up doing almost nothing.

The authors trace the root cause directly to Pre-Layer Normalization. Pre-LN makes training massive transformers way more stable than the old Post-LN setups, but the catch is that as you pass data through more and more Pre-LN layers the output variance explodes exponentially. Because of how the math works out this exploding variance forces the derivatives in deep blocks to essentially become an identity matrix turning the layer into a pass-through filter that cannot learn any meaningful new transformations.

And turns out that the problem can be fixed using a remarkably simple tweak called Layer Norm Scaling. They literally just scale the output of the layer norm inversely by the square root of the layer depth. This completely stops the variance from blowing up as you go deeper into the network. Because the variance stays under control the deep layers actually wake up and start contributing to the representation learning.

They tested this trick on models ranging from tiny 130M parameter setups all the way to 7B parameter models. In every case Layer Norm Scaling beat out standard Pre-LN and other normalization tricks. The pre-training loss drops significantly and those gains carry right over into supervised fine-tuning tasks. Best of all it requires zero new hyperparameters or learnable weights. It is just a clean mathematical fix to a fundamental architectural flaw.