SyzygyRhythm

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.

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.