SyzygyRhythm

I don't see how classic RS codes could beat Turbo Codes (or LDPC). One of the key innovations of the latter is that they handle soft decoding; i.e., different levels of uncertainty of the incoming bits. It's much better to say that you're only 51% confident that a bit is 0 (when it should be 1) than 100% confident! This is especially important for analog systems (like radios) where the incoming bits naturally come with a confidence value.

There are soft versions of RS codes, but these came much later and use the same iterative techniques that Turbo/LDPC decoders use.

There's a set of problems that are (it is conjectured) easy to verify but hard to solve. One of them, called 3SAT, looks for values (a, b, c, ...) such that an expression like ((a or b or c) and (b or not-c or e) and ...) evaluates to true. And it turns out that all of these supposedly hard problems can be converted to 3SAT, so if you find a solution to one you find a solution to all.

The Exponential Time Hypothesis in effect says that 3SAT can only be solved by brute force--trying every possible combination until you find the right one. If your 3SAT expression has 100 variables, then this will take about 2^100 tries (exponential time).

What they found was an algorithm faster than brute force. 3SAT is still potentially one of these hard problems, but finding anything faster than brute force is a major advance.

My point isn't about the most active NIMBYs; it's about the central mass of the voting public. Yes, the NIMBYs have disproportionate influence, but politicians still have to keep their voters happy.

Perhaps my view is too California-brained, but homeowners here like high prices because it gives more flexibility to downsell, they can get large home equity loans, and Prop 13 ensures they won't be paying full property tax (at least if they've been living there for a while). Even for those planning on living there until they die, their children would still like to inherit a valuable place.

At any rate, I didn't intend to limit the reasons to just price. The solution is to build more housing, but building housing is unpopular, and it isn't hard to see why. So we end up with bad policy like rent control instead.

I admit it's awkward phrasing. I try to be accurate.

About half of US adults own their home. It goes up to ~2/3 if you include adult children, grandparents, etc. that live in the house but don't own it.

I wasn't trying to dance around this fact; my point is that a large fraction of the voting public has their interests aligned with keeping home prices high (presuming that these non-owning residents share interests with the people that do own the home).

It's not very complicated; it's just that the solutions are deeply unpopular. Making housing affordable by definition means driving down prices. But existing homeowners don't like to see their home prices go down! And about 2/3 of the US public lives in a house owned by a resident.

I'm semi-convinced that the reason why we see so many bad ideas in housing is because the good ideas negatively affect too much of the voting public. Or, they perceive the ideas as negatively affecting them.

Graphics is part of the problem, certainly, but at least it's moderately independent of the rest. You can scale the quality up and down without affecting the rest (within limits: having many armor variants, etc. are more costly with greater graphic fidelity). As far as the rest: all of these different gameplay mechanics have a complexity cost. You can try to add everything, but then you run into balance problems and/or it just feels too complex for most people, not to mention having a high development cost. So something needs to be simplified, and that means either reducing the depth or reducing the mechanics. But if you've already decided to include something for everyone, that necessarily means that everything is shallow.

I disagree. This is the strategy taken by AAA games and is the reason why the AAA games are in such rough shape.

A game that tries to appeal to 100% of people will, at best, be a lowest-common-denominator mess, and very likely manage to turn off everyone because it includes something that they actively don't want in their game.

A game that targets a specific niche while not caring about others does not have that problem. Because the target audience is smaller, it can't support enormous budgets, but enormous budgets don't usually mean the difference between a good and bad game. And a game targeting a niche takes less money to develop, anyway.

> which is equivalent to just finding the most similar key and then returning the corresponding value. Why would you take a combination of all powers, when you know that higher powers work better?

The article has the answer. The problem with that is that it is no longer differentiable.

The limit to infinite powers is to use the exponential function, which has weighted powers up to infinity. But you still need a kind of smoothing factor so that you don't end up just picking the closest one and losing differentiability, which they call beta and is picked based on how many memories you've stored.

Claude is also very good at dashboards. I have my 5 radios all going through different decoders, streaming the data into a SQLite database, then visualized on a custom dashboard. Has tiles for the weather stations, a map for the ADS-B/UAT traffic, a status page for the radios themselves, and so on.

Learning the fundamentals behind radio really blew my mind at the time (years ago), and having Claude there to help visualize things must be an incredible boon.

Everything in SDR has an analog equivalent, from local oscillators to PLLs to filtering. In fact most of it simply is a direct implementation of decades-old analog concepts.

But the underlying math is what I found most incredible, where the "true" representation of a signal is complex, and that every real (both in the ordinary and mathematical sense) signal is actually the sum of a positive and negative frequency, such that the complex component cancels out. Phase becomes much more comprehensible as simply the angular component of the signal, and frequency is the derivative of phase. All of this had the indirect effect of improving my understanding of complex numbers as well.

At the moment I have 5x RTL-SDR dongles streaming into a box on different bands (137, 433, 912, 978, and 1090 MHz). They pick up all kinds of things, from local weather stations to the water meter for my condo to ADS-B/UAT transmissions from local aircraft. I even see the tire pressure monitor signals from cars that drive by (some of you guys need to add air!).

Mostly it's just fun. I like peeking at all the ambient transmissions in the area.

A while back I was more deeply involved in the SDR space and even reverse-engineered some pager signals. At least a few years ago, pagers were still widely used in hospitals (totally in plaintext, by the way).

Even aside from the calling the developers pedophiles, the author seems to just throw a bunch of arguments at the wall, hoping some will land. But there seems to be a deep contradiction: if it's true that the projects all suck and are very far from being useful, then Adobe has nothing to worry about. People only use counterfeits willingly when they're a good replacement for the real thing. You can barely call them a clone if they haven't copied the real differentiators.

Personally, I think what the companies really have to worry about isn't these sorts of clones, but that it won't be long before everyone can just spin up some software that does the 5% of the job that they actually care about. Software gets clunky and bloated because every new feature appeals to somebody; it's just not always the same somebody. So there's a ratchet effect where you can never remove a feature because someone will always complain.

Docker Sandboxes are just that. The default file access is just the directory you create the sandbox under. They lock down most network access also, with whitelisting of domains and a firewall.

It looked for Ghidra and radare2, but I didn't have those installed (I do have WinDbg, but it didn't use it). So instead it built a bunch of Python scripts using pefile and Capstone (many of them inline). FYI, the linked log has most of the intermediate work removed since some of it contained personal information. It took a little over half an hour total, though some of that might have been waiting on approvals.

There's honestly not much to say--I just described the bugs and it fixed them. This was just Opus 5. I put a stripped transcript here in case you want to look: https://nvidiot.net/ai/rdp-bugfixes.html

I'm pretty familiar with reverse engineering and for most of my career I doubt I went more than a month without patching some memory into 0x90. The explanations are perfectly reasonable and are close to what I expected. It's just that it would have taken me a week to find where to patch without the source!

Here was the explanation for the window-growing bug. It did the window adjustment math wrong, and it was able to fix it by replacing the call with NOPs.

  Bug 2 — window grows on every fullscreen→windowed transition

  mstsc.exe implements container-handled fullscreen (mstscax.dll calls it through a vtable thunk at RVA 0x1a3e0). In LeaveFullScreen (RVA 0x161a0):

  SetWindowPlacement(hwnd, &savedPlacement)   // restores the pre-fullscreen WINDOW rect
  GetWindowRect(hwnd, &rc)                    // rc = that window rect (frame included)
  SetWindowLong(GWL_STYLE, style | WS_CAPTION|WS_THICKFRAME|WS_MAXIMIZEBOX)
  AdjustWindowRectEx(&rc, style, FALSE, exStyle)   // <-- adds the frame a SECOND time
  SetWindowPos(hwnd, ..., rc.width, rc.height, SWP_NOMOVE|SWP_FRAMECHANGED)

  EnterFullScreen (0x15a8c) saves a raw GetWindowPlacement, and the clamp just above compares rcNormalPosition against [this+0xb0/0xb4], which 0x104b0 computes as window sizes — so the saved rect is unambiguously a window rect. Running AdjustWindowRectEx on it inflates by one non-client frame per cycle: +2×SM_CXSIZEFRAME wide (~16px) and +SM_CYCAPTION+2×frame tall (~39px). That's your "slightly wider, mostly taller."

  Patch: mstsc.exe RVA 0x16385 (file offset 0x15785), e8 16 2d 00 00 → 5× 0x90. The restored size is now exactly the saved one. The call's return value was already discarded, so NOPping it has no other effect.

Minimal. Literally the entire prompt:

I have a challenging task. There is a copy of the Windows Remote Desktop executable in this dir. I'd like to see if you can fix two bugs in it (without source code). First, occasionally texture filtering will be disabled until the program is restarted. What happens is that if the window isn't full size, it looks grainy (aliased) instead of smooth, and text is difficult to read. The second bug is when switching from full screen to a window. Each time you do this, the non-fullscreen window gets slightly wider and taller (mostly taller), which causes the aspect ratio to go wrong over time (not to mention getting too big). Can you try to fix one or both of these bugs by patching the binary? You'll also have to strip the signing since it will no longer be correct.

I'll have to take a look at this, but I've found that the top models do quite well at this work without any extra work.

The Windows Remote Desktop client has two bugs that have been driving me crazy for the better part of a decade. One day I got fed up and fed the binary to Claude, asking it to fix the two bugs. And it just did it. Patched one with some NOPs and adjusted a stack offset for the other. Produced a credible explanation for both, and in fact the fix worked. It helps that I was able to describe the bugs clearly, but still, it had to figure out the right spot among megabytes of executable code.

I vibe code a lot of little projects. Specialized calculators (math, programming, electronics, etc.), an SVG maker for my laser cutter, a blueprint explorer for my condo, various little graphics projects (visualizers for space, math, physics, etc.), games, and so on. I made a little tool to publish these to a subdomain with the ability to selectively make them public or available only via my Tailnet. I also host an LLM and some things at home that the VPS can access if it needs.

I just use a $10/yr VPS with one core, 1 GB RAM, and I forget how much storage. It's more than enough. None of my things need much storage, and if they did I could pull them over Tailscale from home.

Not quite a VPS, but I recently found a box of old single-board computers that were collecting dust: a RasPi Zero W, an MK802+, a DragonBoard, a BeagleBone, and some others. All pretty ancient and I wasn't super motivated to go scrounging for working Linux images. But Codex did a great job of building images for them and getting them running with minimal intervention. So now I have one running with the sole purpose of keeping a persistent tmux session going (with the terminals going to various other endpoints). I'll put the others to work in some similar way, probably.

The other reason is to delegitimize the word slop. If everything is slop, then nothing is slop. So some AI supporters also just call everything slop.

In some cases they have a full Lean formalization; in others they just use it for the problem statement. Getting rid of that "sorry" means you've proved the statement. I'm not a Lean expert but it reads pretty clearly as the original conjecture (though the definition of PlaneEmbedding seems quite involved!).

It's the "Nobody thought this was possible" that I found curious. Yes, there is a lot of room between O(n) and O(n^2)! That's why it seems strange that it would be thought impossible.

But I guess it is just that people have been working on it for a long time with no progress, and so the thought was that there must be something especially hard about it. And, well, there is something comforting about round numbers, and so O(n^2) is something special, whereas if the O(n^1.9992) algorithm was known from the start I doubt anybody would have been surprised if O(n^1.9991) was possible.

Do you have any more detail on this? When I first saw the 3SUM result, it was accompanied with a comment something like "There is the obvious O(n^3) algorithm, and a pretty easy O(n^2) algorithm". I thought for about 15 seconds and came up with: put all the numbers in a hash table (O(n)). Search every pair of numbers (O(n^2)) and check if the negative value is in the table (O(1)). I checked Wikipedia and that is basically the simple version (though there are algorithms with a lower constant and lower storage).

But it seems strange that an algorithm that I can come up with in 15 seconds (and I'm not very good at this) is also optimal! It's more surprising that this can't be beat (or couldn't be beat). So there must be something more to the story.

I knew, before I had scrolled more than a page down, that you would have an Eames chair. I was not disappointed. Very nice lamp collection!

You sound like a character in a Neal Stephenson novel (in a good way!). I don't suppose the two of you ever had contact?

Quads and biquadratic texture mapping truly were an awful choice and it's incredible that the company still pulled through. I have an NV1 floating around somewhere; I should dust it off again.

I'm familiar enough with the history, but I really have to wonder why quads were pursued. It seems like even at the time, triangles were the obvious long-term bet. Of course it's never quite that obvious at the time, but nevertheless quads seem like one of those weird tech offshoots that are simply too different to ever get traction, like ternary arithmetic. And the trajectory of transistor counts was such that per-pixel division for perfect perspective correctness was simply inevitable.

No point in running them at room temperature. GPUs, etc. run fine at 95 C. If you run your cooling loop at 70 C instead, you get 70% more cooling compared to 27 C.

At any rate, 1 MW for a single satellite is fine. Just launch several thousand of those and you get to real numbers.

Also, there's no need to talk about "magic" radiators. You orient them so they're at a knife edge to both the Sun and Earth. This is not difficult (the Moon is irrelevant).

Aside from the fact that these formats were developed decades ago (S3TC evolved into DXTn compression, which became BCn compression), there's the fact that these formats are designed to be decompressed on the fly. Hence the block-based, fixed rate compression: the GPU can compute the memory address of a block directly from a texture coordinate without knowing anything but the format and dimensions.

What looks like complex addressing in software is fairly simple on the GPU side. Swizzling is just interleaving address bits. Various block schemes are likewise just simple bit shifting on the address. The block compression just takes a weighted average of two colors (with various storage schemes) and uses a small index per texel to look up the color.

There are a lot of combinations but it's designed to be very gate efficient to implement, so it can be decoded on demand. It's even stored compressed in the cache (usually).

I love penny smashers. I have a paradoxical attitude toward souvenirs: on one hand, I like to have reminders of places I've visited as well as a physical token of "proof" that I've been there; on the other hand, I hate household clutter and don't like to spend money on what amounts to junk. Penny smashers fill a perfect role. They are literally a token of proof that I've been to a place, while also taking up almost no space and being very cheap.

Always hard to be sure, but I think so, yes. The dispenser is only triggered when he runs either fast enough or long enough (I forget the thresholds, but it's something like 10 mph or 10 seconds). Sometimes he'll run and not quite trigger the threshold, but wait next to the dispenser for the treat to come out. When it doesn't, he'll go back to the wheel and run/walk for a much longer period.