jaimeyap

I just got the rocm branch compiled and running. Starting with one of the common strix halo rocm toolboxes, just needed to install a few more dependencies to get the repo to build. So far just tried the q2-imatrix model and I'm seeing ~7.32tok/s with a locally bound claude code session. It's pretty unusably slow for agentic coding like this - with it being tens of minutes per round of thinking. But it does seem to be working. Suspiciously amdgpu_top is only showing ~16GB of memory being used. Not sure if this is somehow misreading that.

I think the difference is right wing "preppers" are more individualistic. For them it's about saving themselves and their immediate family. The left acknowledges that we live in a society. And the real power to prevent happens at a societal level. So their energy is focused more on fixing government and through high leverage policy changes instead.

We can't yet equivocate ML systems with human beings. Maybe one day. But at the moment, it's probably better to compare this to a compiler being fed licensed code. The compilation output is still subject to the license. Regardless of how fancy the compiler is.

Also, a human being that reproduces licensed code from memory - because they read that code - would constitute a license violation. The line between derivative work, and authentic new original creation is not a well defined one. This is why we still have human arbiters of these decisions and not formal differential definitions of it. This happens in music for example all the time.

> There is no logical basis for it. Or rather, any latticework of logic you erect to justify this choice is based on a foundation that has nothing to do with reason.

Any formal system is going to be based upon some set of axioms. You can't apply reason without some foundational choices (ie. your axioms).

The bright line you are looking for is a lot fuzzier than it seems at first glance.

If you take as axiomatic that "the human race surviving is a good thing we should work towards". Having kids becomes an exceptionally rational thing for people to do.

This. The march to authoritarianism accelerates when people accept the meme that the truth is unknowable. So they simply accept the reality put forth by the autocrat.

The most basic kind of truths are facts. We at least need to agree on those as best we can first. And then apply critical thinking on the the squishier stuff on top.

We seem to be focusing on defending against different things. I am focusing more on mechanisms to defend the integrity of the election itself against hacking or election fraud. Which seems like a dominating concern in the modern context.

Different threats require separate considerations for sure.

To be crystal clear. I'm still for secret voting, and being able to lie about your vote if you want to. But without an ability for the voter to verify their vote, you must trust the entities themselves that are holding the election. Both that they are acting in good faith. AND that they managed to secure the election against outside tampering. The very people that you are worried might compel you to declare your vote are the ones running the election systems themselves in many situations.

We need to be able to operate with less trust here, not more.

> If each one has a secret passphrase, nobody can verify that the total is calculated correctly.

It's possible we are misunderstanding each other. There would be a verifiable ledger. With opaque tokens for each vote. The total can be verified by counting. Just like normal. We could use our signature method of choice to sign and verify the integrity of each vote and all the votes. The body holding the election would be able to verify the total counts are correct and not tampered with.

For a specific vote, an opaque identifier that nobody except the voter can resolve, provides a mechanism for the voter to self verify their vote was counted in the way they expected.

A passphrase was just one idea to avoid printing the token on your vote receipt. But if we really want to go down the rabbit whole of having cover. There are many other ways to provide plausible deniability. You could opt to not get a print out of your token. And your deniability would be you don't have it, and you can simply lie about which vote is yours (even though you know the one that is yours).

> It was a long fight to get secret votes

I'm still saying we keep voting secret. What we are discussing is the ability for a voter to verify their vote was counted. But it's still meant to be secret. In fact, something analogous to the 5th amendment to the constitution could help enshrine the right to a private secret vote as a fundamental right.

> Just imagine that during McCarthyism people that were requested testify in the committee has to first say their national ID, token and passphrase to be sure that they didn't vote for the Communist party.

We make it a constitutional right to have your vote be secret. Make this clearly illegal. If you are worried about the central government not obeying laws, then nothing really helps you. The central government ultimately wields the final say in all matters here. They can put you to death if they like. A verifiable election system is meant to help ensure we never devolve to a government that does what you are worried about.

---

Ultimately all of your examples about being forced to declare things apply also to your credentials to your personal devices and online account. All of which contain more less enough information to both figure out what your vote was, and much more.

Outlier probably wasn't the right phrasing on my part for this specific issue of spousal voting pressure. Thanks for calling that out. You were right to.

The way I think about this though is that we should view these concerns as needing tailored (sometimes orthogonal) solutions. There is an analog here to testimony in court. Defendants have the right to know the evidence against them. Including the identity of witnesses and the nature of their evidence and statements. This often puts witnesses at risk for retribution. It's a huge problem. But do we do away with requiring this kind of evidence disclosure? Not having it makes it easy for evidence to be fabricated without consequence. And for defendants to not know who or what is being used against them in court. This would potentially have even more dire repercussions. So currently, we find other ways to help ensure the safety of witnesses and accept this major issue.

In the same way we might find other solutions to the issue of Spousal pressure. Opt-in voting receipt print outs. Support programs for domestic abuse, etc...

This is for sure a problem. And maybe even a major one (like witness safety). But overall, the alternative of having insecure and unverifiable elections is increasingly seeming like the more important issue to address. Most complex systems are about balancing tradeoffs. And it should be unsurprising, that a stable election system is too.

Some schemes could require the person to remember a passphrase (not printed out) that is mixed in with the one-time-token to compute the final verifier token.

> you can be "encouraged" to send an email to bigbrother@example.com with your national ID number and your token

Would the system providing some sort of plausible deniability token give enough cover for this? Is this a problem at scale?

Also... they can do this to you for your email, and social media logins too right?

> Or the day after the election, in each office at work everyone can just meet and show their token while cheering for the current government.

I don't understand why this is fundamentally different than todays world where people wear MAGA hats or drive around with Obama/Biden bumper stickers. Sure it's not cryptographically verifiable. But it's certainly "good enough" for all practical purposes.

It seems like the argument here reduces to "personally verifiable votes should never exist".

> In traditional families women will effectively lose their vote.

People can lie. That's the only recourse they have today right? Would producing a "plausible deniability token" to show to adversaries suffice here to provide usable cover?

> Vote buying becomes possible.

This is already possible. Though you are right that it is not strictly verifiable today. But I would argue that we lack data on how many people would take money to vote X in todays system, and then vote Y instead and lie about it. If this set is tiny, then this problem doesn't grow much does it?

> fellow party or church members start to check the votes

This should simply be illegal. Bright line. Your vote is private and no-one or organization shall be allowed to force you to disclose it.

---

It seems again like the arguments here are sort of baby/bath water. There are outlier problems preventing this from being perfect. Yes. But the benefit of a truly verifiable election would inoculate us against mass election hacking. Which increasingly seems like a genuine threat we need to deal with. Are the outlier problems not worth the price of preserving democracy?

I might be mistaken. But either you have the ability to verify your specific vote was cast, for the person you expected to cast it for. Or you don't.

It would seem impossible to offer election confidence to the majority of people without a simple system that has this property.

If kidnapping and torture are on the table for your threat model. I think most people's voting record could be figured out with near 100% accuracy if they get access to your computer logins, emails, hacker news account, and all your social media accounts. Which according to your coercion model, they totally could. No need to go after your vote token specifically.

So unless the voting system singles you out in particular (which a random token wouldn't. Every vote would have one). Ruling it out as a solution because of a super low probability scenario seems like a misattribution of probability in the face of clear value (ie. easy and private verifiability by all parties).

Having secure elections is how we create a world where no one has to worry about coercers coming after them.

3800X is "gamer priced" :).

I think the 3900x is in a great position to provide the best of both gaming and productivity. Extremely aggressively priced at $500 for the horsepower it seems to give you.

I suspect there is going to be a 16 core 3950x later in the year. Maybe with slightly lower single core frequencies. But maybe 20-25% greater multicore performance.

I bet they are delaying that to keep something up their sleeves when Intel responds. And to not totally cannibalize TR prior to releasing TR3.

Nice. What build times are you seeing for clean builds of the rust toolchain itself? Curious to benchmark against my 2700x. I'd imagine near linear scaling with the core count.

I think the 3900x might be a happy middle ground. I'm guessing we would probably see (with the increased IPC, core count, and core clock) like 70-80% increases over a 2700x in these kinds of multithreaded workloads. So probably slightly more than half way to a 2970x or 2990wx?

If that's round trip latency. Then input latency will be 8ms right? Input action to Frame update latencies are reliably 12-13ms+ with a local console routing through a TV.

So if they can do something fancy with rendering frames to the network to sync with your monitor. We might see a minimal increase in actual overall latency.

I had the same thought. The hard parts really are the containerization of apps, and the auth and permissions model. Sandstorm as far as I know is the best thought out attempt at tackling those problems.

I would assume you propagate a transaction ID or expected row version (and persist transaction histories and/or version numbers along with the inventory item row after mutation).

Oh for sure. Thought experiments like this are often far cries from workable solutions that are robust in the real world. That's basically a summary of why viable crypto for the masses in other domains remains such an albatross.

I would flip it and say that the Government only maintains the public key registry, and you alone keep your private key. You can extend that kind of scheme by signing "birth certificates" of your children using your private key to prove familial relationships. The hard part is dealing with key revocation in the event someone steals your private key. And of course overcoming the ambient distrust of government some people have.

The formulation of the question frames Social Security and Medicare as being mutually exclusive with a UBI.

UBI ought to replace things like food stamps and welfare. Not healthcare or retirement benefits!

I am a huge fan of UBI, and I would have voted "disagree" the way that question was framed.

A better formulation would be to frame UBI as an "automation dividend". Where we dip into increased efficiencies produced by automating labor to fund a basic income.

Git reflow does this (and more). If you want to do presubmit code reviews, and squash merge to master to preserve history. You might like it. https://github.com/reenhanced/gitreflow

This is generally why smaller changes are better. They are more easily reviewed, and more easily "steered" as you put it by a good review.

And of course having a design doc ahead of time that the team can review and comment on for a longer, more complicated change, is a great thing to do. And compliments the subsequent code review[s].

I second this. I've given Gosublime (and more recently VSCode) a solid try on several occassions. Neither hold a candle to the Intellij Go plugin. Being able to give solid rename refactor, and code navigation, even when your code is in a partial spaghetti, non-compiling-mid-development state is hard. And the Intellij plugin does a decent job at it. Not quite Java-level good. But pretty darn good.

The existing command line Go tooling (while great) just don't do a good job at providing that kind of support to your IDE.

People can want more than just one thing. It might be fairer to say that they want all the things they say they want. But they want this other thing the most, and since this other thing isn't compatible with the others (can't travel the world and also be CTO) it wins.

The more deterrents to war we have the better. Lowering the perceived risks of it seems dangerous and might in fact make it more likely to wage war. You need skin in the game to make you think twice about waging it. I worry the actual human costs could be much higher by removing humans entirely from one side of the fight.

You pay taxes. You vote. You spread ideas that you believe help the world. That in and of itself is immensely useful.

Your impact on the world isn't just what you directly build or finance. But also the impulses and ripples you leave through your interactions with other people.

As a sofware developer, I hope to make enough to one day to not worry about providing for myself and family. So I can more directly contribute to solving the world's issues. But until then, I can continue to try to be a good person and individual economic contributor. Donate what I can (time, brain power and money) to good causes. And to spread knowledge and ideas that, if they reach enough people, can make big differences.

The inflation argument is a little misleading. We have been printing money to offset historically low and increasingly declining money velocity. The money velocity is declining precisely because wealth is being aggregated in silos and not being spent. Money velocity is essential to a healthy economy. And quite frankly, we could do with a little inflation to encourage spending and not hoarding by the uber wealthy.

Thinking that properly raising children and investing in bettering oneself doesn't tangibly generate revenue is a bit short sighted.

In 15 years when machines are cheaper and better at driving, manufacturing, and doing most unskilled labor (or even some knowledge worker type jobs). Would it have been a bad economic investment to have all the kids growing up today have parents with the financial freedom to go back to school or focus on giving their kids a proper childhood (so they can grow up and be productive citizens)?

Do you genuinely think that we are better off as a society sticking to "you have to work to live" when the machines are outperforming an entire class of people at their jobs? Not everyone can or wants to be an engineer. At some point our populations will stabilize, and technology will make it so that we have enough food and basic essentials for everyone.

We are all in it together.

Basic income is absolutely not zero sum!

The people who would benefit from it the most would have the freedom to invest their time and money raising their children, bettering themselves, or taking risks and starting businesses.

Also, money repeatedly changing hands itself generates tax revenue, as well as personal wealth. Again, not zero sum. Giving these people purchasing power can also spur innovation from businesses who would offer them services that otherwise wouldn't be easily monetizeable.

As more jobs get replaced with automation, basic income will become increasingly attractive.

6 hours a night on weeknights sounds like a heck of a lot! Owning might make sense for you, but you might be an outlier.

I would have to think most people with a job and family might struggle to find 3-4 hours a week to game. No offense intended by the above. I'm quite envious :).

Well one difference is being able to easily propagate failures end to end.

Agreed about idempotent processes in the "consumer" processes. But I generally prefer marking an end user session in a persistent store before propagating the request for payment (effectively acting as a sticky current transaction ID), and making synchronous requests down the chain versus generating a transaction ID and doing a bunch of async message queuing.

It's just easier to know when something didn't work and display the appropriate user feedback. But your point is valid.

Credit card authorization might be better suited to a synchronous request, versus going through a message queue.

I could imagine at most once being good for something like a ping or a heartbeat. Or even a "this is the current version of some piece of data". And if your consumers are prone to failing to ack and you don't want to gum up the queue with retries.

But your point stands that it is certainly not what we want in the lions share of use cases. I guess that's why the default semantics are at least once. With at most once being a configurable option.