rft

A dual 3090 system shouldn't go above 600W wall power while running inference, even less with some weights in RAM as you need to do with "only" 48GB VRAM and this model. Unless you are running water cooling, the cards are likely sitting at 200-250W power limit each anyway so they don't run too hot. This is considering a consumer tier CPU and mainboard with about 90W TDP, not a dual CPU or something like a threadripper that can easily push the power draw to 1kw if it runs the calculations on the RAM weights. My dual 3090 setup usually drew about 200W-300W average with LLM workloads according to my HA historical data.

Not sure what their plans are, but the Deck has a wifi 6E radio, so maybe they can use it to connect to the Frame directly. Given modern wifi chips can usually operate both as an AP and a client at the same time, this might just be a software feature they add to SteamOS. Worst case you can stream without a dedicated wireless link via your normal wifi with potentially reduced quality.

If this actually works, this is quite a nice, if a bit niche, combination. I really like the control layout of the Deck and it has more performance than the Frame. If you can put the screen on your head instead of having to look down on it, it might be a bit more comfortable. Sadly it seems the Deck has no IR LEDs so it can get picked up like the Controller by the Frame. Maybe a case/sleeve for the Deck can add those LEDs for full integration.

I intentionally avoid this, especially if I am not the only one connecting to a server. I see potentially breaking others' expectations for my convenience as a clear downside. Plus there is a level of paranoia there, I might have unintentionally included a credential in some config that gets copied over. That potentially increases the blast radius of a server compromise beyond what is strictly required for that specific server. I might copy over some scripts into a directory not in $PATH, easy enough to add it to my shell session if needed, CTRL+R helps as well.

ssh, scp, tmux, (grml-)zsh, grep, less, file, tar, git

The time saving of a well filled ~/.ssh/config is impressive, especially once you start juggling ProxyJump hops.

Chris just has some fun projects. Sandsifter was pretty well known back then due to finding that VIA x86 opcode, the movfuscator is just an amazing piece of mostly useless engineering and the fun reverse engineering psychological warfare was my first contact with his projects. I guess someone stumbled on one of his projects and others clicked through to his other projects. Many of them are a perfect fit for HN, no wonder they got posted.

I get that argument, but I don't think it is that bad. Open weights that are out of reach for local use are still within reach for groups of people or small to medium companies. Even if you only rent enough cloud GPUs to run the weights for a few hours, you still get to do anything you want with it.

Worst case you can still archive the weights and hope for capable hardware to get affordable. At the same time this archive is the base line for a new frontier lab to start over if required. I see open weights as a pure upside even though I can't run the bigger models in my home lab.

Article is missing a note on the existence of MX records for the domains. Sure, you can easily have a send-only domain without an MX record, but the common case is likely to setup both send and receive capability. It would be interesting to have that number included as domains without MX and DMARC might just not be configured for email at all. Worst case the 45% of domains without DMARC are simply not relevant for email and thus not configured at all. I would find "x% of domains with configured email don't enforce DMARC" more interesting.

Those numbers are wrong for most use cases. Likely the LLM did not take SWA (Sliding Window Attention) of G4 into account. Without SWA those numbers could be correct, I can't load a q8 without SWA on a 24GB card.

I tested this with the at the time newest llama.cpp master on a Linux system with 2 3090 24GB, only one was used for testing. q8 without any KV quant, 256k context, mmproj loaded takes less than 20GB VRAM. This runs at about 1.5k to 2k tok/s pp and 40-50 tok/s gen (slightly lowered power limits & undervolted). q8 with 64k non-quant context and mmproj takes just under 16GB VRAM. Drop down to the q6k model, no mmproj, 64k non-quant context and it fits in 12GB VRAM. All the way down to q4km and some batch size tweaking and it barely fits into 8GB VRAM.

64k context is the minimum for Hermes agent, so a vision capable "agentic" model fits into a 16GB card. This is very impressive. I am currently testing how smart the model is and it does decently so far, had one looping issue it recovered after a lot of tokens, did some basic tool calling.

Ah, ok. I took a look at the 3090 numbers and they list 400 tok/s prefill, so if I normalize my expectations to that base line the numbers you posted do make sense. I haven't dug deep into that site's methodology, but their estimates seems way off. Especially since they don't take into account cache quant when deciding whether or not you can run a model. Overall I found that website a bit confusing, but maybe the UX just didn't click with me.

> The MI100 is roughly double the performance on Qwen 3.5 35B A3B Q5_K_M to the R9700 (462 token/s prefill vs 239 tokens/s, 217 tokens/s vs 118 token/s for inference)

Those prefill numbers look really low to me. I can run nearly that same model (qwen 3.6) at q4km with q6 cache on a single 3090 and get 2.3k-4.4k prefill and 100-170 generation. Just based on raw numbers I would expect the R9700 to land around 70-90 generation (about 2/3 of memory bandwidth of a 3090) and at least the same or higher prefill (nearly 3x FP16 TOPS on the R9700). That means the numbers really don't add up. Is the benchmark done with some special settings, e.g. parallel requests or with very low prompt length?

Without having firm data, I can see a few factors that are different. After the collapse of the GDR, it was easier for eastern Germans to move to west Germany than for Polish to move to a different country in the west. Mostly younger and educated people would have made that move, hampering future generations. With the Reunification also came the whole Treuhand issue which essentially sold off a good chunk of eastern Germany for pennies to western investors, because eastern investors had no capital. That meant the east lost out on the profits from its economy as they would accumulate in the west instead. Even today a large part of east German rentals are owned by western landlords or corporations. Then the industrial base of west Germany was setup far more for competing on the open world market with automotive companies in the NW (VW), SW (Daimler) and SE (BMW) plus the big industrial area Ruhrgebiet. So you naturally got an economic focus even after Reunification on the old BRD with the previous GDR requiring decades to hopefully catch up to the rest of the new country.

And a minority of those kids will get curious about the How and Why. Those are the security nerds of the future securing the networks against both the kids they were themselves and actual malicious actors.

Source: Early interest in wifi security, including in other people's networks, lead me down an education and career in security