65a

Or maybe we are repeating the experiment of the 1990s/2000s and can't wait to see the results confirmed?

The base unit is actually a single bit, so why aren't we talking about decabits instead of bytes, following the SI argument?

I refuse to say mebibyte or whatever alternative unit. 1024 bytes is one kilobyte, and 1000 kilobytes is not a useful unit (and so on). As far as being a conspiracy by hard drive manufacturers, Western Digital did settle the case rather than win: https://arstechnica.com/uncategorized/2006/06/7174-2/

Only with additional hardening between the container and the kernel and hardware itself.

Other than process specifics, they could, and that's exactly what happened when the 1980s US Government got worried about a single CPU supplier. The result was (to some extent) modern cheap computing.

I agree if we extend it to mathematics and the use of simple machines.

There would be an ironic twist if nvidia (who first competed with AMD nee ATI) was forced to license their IP to intel for national security reasons, but it would rhyme with history (x86 licenses to AMD) and benefit the consumer.

Disgusting abuse of the democratic process to halt scientific and technological progress in the name of making one sketchy man rich.

It's somewhat regional, and it means to hunt down the target at the expense of everything else, as a dedicated hunting dog might.

Is there a proper reverse engineering of the payload yet?

Isn't u-root also basically this?

Pointers are "nullable types", but if you're seeing that a lot, it generally indicates an architectural problem.

I used many of these as test cases: http://wiki.franklinheath.co.uk/index.php/Enigma/Sample_Mess...

CWOWD CZKZO DLUML TPRHR KXFHH MHIUS TMXON CHQXQ DFMBI APKZV DRFIU SEFLV ZSSPK ESGNE BNRQA QBVHH YMAZ

just to not be cruel, it's an m3 without UKW-D, 3 rotors and a plugboard :)

EDIT: I think I answered my question looking at the code. There are a lot more rotors known (see cryptomuseum). Some things I found while writing an enigma: many online enigmas have some bugs with double stepping the wheel on a single press, which the machine did not do. The Humboldt University Berlin's online enigma is correct. There is also a very similar machine used by the Soviets until the 1980s that you can probably represent with the same datastructures called Fialka: https://en.wikipedia.org/wiki/Fialka.

My test case that returns different results on different emulators is: M3, rotors III, II, I, no ring setting, UKW-B, starting position AEQ. The string ABCDEFGHIJ produces OMUQBCLPVR in minarke.c and produces LUINDKMWNH in the University Humboldt Berlin enigma. I believe the latter is correct.

Ollama does a nice job of looking at how much VRAM the card has and tuning the number of gpu layers offloaded. Before that, I mainly just had to guess. It's still a heuristic, but I thought that was neat.

I'm mainly just using llama.cpp as a native library now, mainly for the direct access to more of llama's data structures, and because I have a sort of unique sampler setup.

Yep, and it deserves the credit! He who writes the cuda kernel (or translates it) controls the spice.

I had wrapped this and had it working in Ollama months ago as well: https://github.com/ollama/ollama/pull/814. I don't use Ollama anymore, but I really like the way they handle device memory allocation dynamically, I think they were the first to do this well.

Go has a clear() function now, but I haven't checked to see how it actually behaves in terms of secret abatement in memory. https://tip.golang.org/ref/spec#Clear

By chunking and binning the data by user contribution count, you are structuring it as described. Pretraining is often accomplished on similar chunked text. k-anonymity is not perfect though, or state of the art, the wikipedia explains several known attacks.

https://en.wikipedia.org/wiki/K-anonymity Basically keeping only chunks of text which have are not unique and contributed by many users.

The inference side (adding something * something else) to every layer seems a lot like what happens with a LoRA? If so is it possible to encode a Control Vector as a LoRA for the purposes of using this with existing inference frameworks without too much trouble? Or is my understanding way off?

ROCm is preferred over vulkan for AMD GPUs, performance wise. Using OpenCL or Vulkan should only be for older cards or weird setups.

I found it much easier to make ROCm/AMD work for AI (including on an laptop) than getting nvidia work with Xorg on an optimus laptop with an intel iGPU/nvidia dGPU. I swore off nvidia at that point.

llama.cpp has had ROCm support for a long time

I assume that terminals are authenticated, and stolen/diverted terminals can be disabled, so outside willful negligence or failure to report stolen/diverted terminals, it seems like it should be obvious who is accessing their modern communication network.

But...why?

I'd rather intelligence agencies spent their time fucking instead of killing, I guess. You're describing an ideal that has not been realized historically, so while I agree, I also completely understand the fact that tradecraft tends to the practical.

Look, I get what you are trying to say. But in a democracy, do what you can with what you have. Not voting or not participating leaves the entire game board to whoever pissed you off this much.

40s, I'd say Fritz-X was a good example.

https://en.wikipedia.org/wiki/Fritz_X

Go works fine for C FFI, all of its problems there are caused by its innovation wrt dynamic stack sizes and having a garbage collector. I'd rather write multithreaded Go FFI than deal with JNI again, anyway. There isn't really a language keyword-level concept of async in Go that's comparable to `await` in JS, or Java futures, or Rust async.

Not resiliant, because in the 10-20 year lifespan of a home electrical panel, at least one critical vulnerability is going to allow complete remote pwnage of that device. It's stupid IOT garbage that belongs in ewaste, especially with a trivial remote code execution mechanism.