milkey_mouse

If the free market were one entity that could coordinate and say "nobody build more housing, let's squeeze as much money from what we have already", sure, that would be pretty profitable. But if there are enough participants in the marketplace (which depends on the barriers to entry to homebuilding, like regulatory capture, knowledge, capital, and permits) one will want to undercut the others and build houses marginally cheaper than the competition until their marginal profit is zero. Having everyone agree not to build houses and keep prices high is like the "nobody snitch" outcome of a prisoner's dilemma: it's not a stable state/Nash equilibrium. At least this is what I heard in Econ 101, I'm sure I'm missing much nuance here.

There was a fun game for the Zune HD reminiscent of this called Dr. Optics Light Lab. The only record of it seems to be these poor-quality YouTube videos: https://www.youtube.com/watch?v=xKvLCDMe2Og https://www.youtube.com/watch?v=zeUYFhT68E4

There are a couple reasons why I think it's important for cheating not to be widespread. I've seen The Case Against Education, signalling theory, and all the usual stuff along those lines (well, maybe it's only usual if you have a particularly contrarian friend who never stops talking about it) and while it's made me jaded about where The True Value Of A College Education lies, it didn't make me think "well, it's pointless, so I might as well cheat!"

There are sort of three groups at play here, although the boundaries are fuzzy. Some are truly there to learn, in which case there's not much motivation to cheat. Some are there to get a degree because of its implications in the job market, but don't cheat (for better or for worse). And some are there for the piece of paper and will do whatever it takes to get it. I don't fault these people: maybe they have to maintain a certain GPA for a visa or scholarship, or maybe they got COVID and an inflexible professor told them as of 2022 it's "policy" not to offer extensions "just" because of COVID. At least, I wouldn't fault cheaters were it not for the knock-on effects.

Part of me says the faster we dilute the value of a degree (by granting them to people who cheat their way through) the faster we get rid of the wasteful, cost-disease-ridden, elitist status quo for universities (at least in the US) as the amount of entropy afforded to a prospective employer by the presence of a degree drops to zero. But I also want all the work (and $$$) I have put into getting a degree to mean something. Every time someone cheats their way through a course and, despite their degree or GPA, is less competent on the job because of it, they marginally decrease the school's reputation: if the last person with those credentials wasn't actually that good, why would the next? I'm not sure how much this is happening yet, but I think it will increase in the future if cheating remains easy and common. Even discounting "degree seigniorage", if a professor grades on a curve, obviously students that don't cheat will be at a disadvantage. It's not really correct to say "cheaters don't affect you, just focus on your own work."

So why not have everyone cheat? First of all, some people actually want to learn something. Second of all, I think most people would like it less than I if universities and their degrees lost their cultural and economic cachet. Finally, I can't believe I have to say this, but cheating is inequitable: some are better at cheating than others. In the past (and probably still today, but what do I know) this was frats with banks of past assignments and tests. In the last few years, it goes as in the article: someone makes a group chat, though if they have an ounce of sense they won't post a link to it in a chat the professor is monitoring, at least if they intend to cheat through it. Invites spread organically from student to student or from DNS-like "hub" chats where people can ask for invites to any class's group chat. It would be really bad for cheaters if professors were on the "hub", able to join every class's group chat, so invites to the "hub" are guarded more zealously. Obviously they'd never be shared in a Zoom chat or other official platform, so online students (most of them, in 2020 and 2021) are left out. Offline, less socially connected people are less likely to get invited. Personally, even putting morals aside, I would not have been able to cheat if I wanted in the past few years. Cheating was everywhere, but I was anxious enough as it is actually doing the work; the added anxiety of cheating and maybe getting caught (especially in such a dramatic way as in this post!) would have been untenable. Maybe I should demand exam answer keys as a Section 504 accomodation...

Urbit has not put much effort into security, for some reason. To be fair, they don't claim their runtime is secure (yet)[1]. The process downloading and executing code from the network is not sandboxed with seccomp or anything similar, and its "jets" are unverified C libraries which any of this code is allowed to call into. They could sandbox it pretty easily (the worker process which runs third-party code only talks to a host process and not the rest of the world, so it could probably be run under seccomp, not even seccomp-bpf) which makes it all the more surprising that they haven't.

Urbit has also had (and almost certainly still has) bugs where jets give different results than the code they're supposed to accelerate (a "jet mismatch") [2]. I agree that its "axiomatic" bytecode would lend itself well to verification theoretically, but Urbit as she is spoke is not anywhere close. They also at least historically seemed somewhat hostile towards academic CS research (including formal methods) probably for weird Moldbug reasons.

[1]: https://urbit.org/faq#:~:text=The%20security%20of%20the%20ru....

[2]: https://urbit.org/blog/common-objections-to-urbit#:~:text=Ye...

That's pretty cool. Are you sure it's trying to read the signs, as opposed to consulting a pre-made map of speed limits at the current GPS location?

The Tuskegee Experiment ended 50 years ago. One would have to have had a rather long career to have been employed at the CDC both then and now.

I'd imagine one can only lengthen their limbs so much before they end up looking like a Japanese spider crab.

I suppose you'd have to write your resolution as "apnews.com will at some point publish a page with the <title> tag containing '49ers', 'win', 'Super Bowl'" and hope the possibility of some sort of retraction would be priced into the market.

Much like Signed HTTP Exchanges/Web Bundles, the value of an opt-in protocol such as TLS-n is much less than one that would work with all the HTTPS sites already out there. I doubt the Associated Press wants to get into the blockchain oracle business.

> As long as AP cryptographically signs the outcome of the game (as they do for all HTTPS served content)

I looked into this use case before and came to the conclusion that it can't work because TLS is not non-repudiable. Once the initial public-key handshake is finished, the rest of the session uses a symmetric cipher. Because anyone with the symmetric cipher's key can encrypt their own data with it, you could encrypt your own spoofed response from the server in any transcript of the session.

https://crypto.stackexchange.com/questions/29751/are-https-w...

One solution to this is to use the site's public key to sign a Web Bundle instead of using TLS:

https://web.dev/web-bundles/

https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

Web bundles can be served from any origin (and I'd imagine can be verified by oracles) as the data itself is signed. However, this requires the server to use web bundles in the first place, which likely isn't happening any time soon. Mozilla considers the proposal harmful: they expect Google will serve the majority of web bundles, allowing them to see what sites the user is visiting.

https://github.com/mozilla/standards-positions/issues/264

https://www.ghacks.net/2020/08/30/google-proposed-web-bundle...

It's funny that we've gotten to the point that a "graphics-less GPU" is actually useful. Perhaps they should call it something else...

Each block contains a commitment to the state of the chain in the form of a Merkle tree. In that regard it's not that different from Bitcoin's MAST or Ethereum's (WIP) stateless clients. To prove something (say, an account balance) is in the block, one would need to know the data you're trying to prove as well as its Merkle path in that block's tree.

> that means that the state of the smart contract, and the contract's executable code, need to be publicly known.

Yes, they would need to be separately distributed somehow. But I think this is similar to how Ethereum contracts typically have their source code (and by extension ABI) uploaded to Etherscan, without which they'd be difficult to interact with.

> Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts?

A good rule of thumb is that Mina full nodes behave like other blockchains' light clients that just happen to sync quickly & trustlessly. I am not an expert on smart contracts, but I think in practice, a Mina DEX would probably work something like this:

- You visit minaswap.io or whatever (or a copy on IPFS). The static page includes a copy of the contract's interface.

- The page tries to call a hypothetical Mina browser extension running a full node in the background. If it's installed, it uses it; otherwise, it downloads & runs a Mina full node compiled to WASM as a "polyfill".

- As the WASM node syncs & verifies the latest block's proof, it asks someone for the contract's current state and the Merkle path to it within the block.

- Once the node has synced, it verifies the contract's data is actually in the Merkle tree using the given path. Now we know the interface & state of the contract and that's all we have to keep locally.

Also: although block producers don't necessarily have to, provers always keep a copy of the current ledger state (see my above comment; sorry if my first comment was a bit misleading). This would include smart contracts' state (but not their code). If you run one of these nodes, it knows every contract's state, which should still be small compared to Ethereum as so much can be done off-chain.

I realized this is misleading as an answer to your question, but it's too late to edit. Block producers (i.e. miners) don't need to keep track of chain state, but provers need to know the state of block n-1 to generate a proof for block n. In practice, the current state is pretty small, but admittedly way more than 22KB: I just synced a node and its data directory is 235MB.

The zero-knowledge proofs still provide the advantage that historical state doesn't need to be kept by anybody: if news of a better chain tip comes along (including while bootstrapping), it'll come with a recursive proof of its validity, whereas with Bitcoin et al. it'd need to check if it's building on a valid block (and thus keep at least the hashes of previous blocks).

Yes. The proof of block n's validity proves both that the state transition from block n-1 to block n is valid and that the previous block's proof was valid. The arithmetic circuit for a state transition proof actually encodes a program which verifies SNARK proofs (in addition to the less academically interesting "doesn't create $ out of thin air" sort of rules). The proof of the latest block at any height (which is all the state you need to know you're on at least a valid chain history) remains constant size because of the indirection of proving that a verifier accepts the last block's proof without actually including it (taking advantage of the fact that a zero-knowledge proof doesn't have to include or even reveal the data it's proving something about).

You could use a lookup table to turn the nth letter of the alphabet into the nth prime number, then multiply those primes together. This "hash" would be unique up to reordering of the primes/letters.

I keep it disabled on one of my systems for exactly that reason: I want to make sure my own code works with overcommit disabled, as it'll always be on Windows or OpenBSD.

(Disclaimer: I hold Mina.) There is no need for Mina archival nodes to exist outside of running services like block explorers (which are admittedly nice to have). The Mina SNARK proof proves two properties at once: a) the state transitions from the previous block to this one are valid (they don't create money from thin air, etc.) and b) the previous block used in (a) itself carries a valid proof. The contents of previous blocks do not necessarily need to be kept at all, because of the "zero-knowledge" part of zero-knowledge proofs. Much like Yao's millionaires[1] don't have to reveal their net worths, the latest block's proof doesn't have to "reveal" the entire history that came before it.

[1]: https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_Proble...

I've found overcommit useful for some scientific computing applications, but you're right it's not the most intuitive default. You can disable memory overcommit on Linux for the same behavior as Windows, if you want.

https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

Also, I found this post that suggests Windows technically does overcommit memory, but only for stacks(‽): https://superuser.com/questions/1194263/will-microsoft-windo...

This site probably predates SVG, or at least its widespread support!

It could just as easily have been a quote from Foucault. Not sure that makes it any less edgy though.

Signal didn't back up contacts and settings to their servers until they implemented "Secure Value Recovery", which relies on SGX to rate-limit guesses of a weak PIN. If SGX is broken and Signal's database falls into the wrong hands, encryption keys could be brute-forced pretty quickly (most people have 4-digit PINs).

Might I ask where you found a $16/year VPS, and whether you'd recommend the provider?

Evidently not very good, seeing how long some of them take to load.

> if you mainly live in a web browser and don't do GPGPU

For what it's worth, I use Guix and I've been able to do everything but CUDA just fine. (CUDA will never be supported in Guix as it requires proprietary drivers to function.) There are opencl packages, for example. It works well enough to run an Ethereum miner, Blender, and even games in WINE. I've been meaning to package AMD ROCm for better GPU compute support.

> Could you please link to any documentation or HOWTO?

Here you go: https://guix.gnu.org/manual/en/html_node/Binary-Installation...

> if I attempted to re-install software with Guix in parallel, would that lead to namespace collisions?

It shouldn't. That's one thing Guix (and Nix) excel at: packages only refer to specific versions of their inputs, so you can even install multiple versions of the same package at once if you want.

In terms of Guix shadowing packages installed by Arch, you can put $HOME/.guix-profile either at the front or the end of your $PATH depending on whether you want to prioritize Guix or Arch packages. When I was getting my feet wet with Guix, I ran Guix on top of Gentoo (doing basically what you suggested, gradually shadowing Gentoo packages with Guix ones) for a few months without any significant problems.

> your test would take so long to run

I think GP's test would probably be implemented with property testing (or even better, symbolic execution). It wouldn't necessarily take super long to run.

The question is, will it take the crown for "best book about combinator calculi" from To Mock a Mockingbird? At least, Raymond Smullyan's writing style is much more enjoyable than Wolfram's.

As fun as the puzzles and whimsical framing are in the latter book, I have been looking for a more straightforward book to suggest to people learning about combinators. The table of contents is intriguing, but I doubt this will be the concise introduction I'm looking for.

That's a pretty clever system. I'm not at all against advancements in ballot technology, I just think their explainability should be considered.

> there are a lot of folks who are quite sure they've settled on a set of good techniques to manage nuclear waste. On the other hand, individual communities that might host nuclear sites keep not being convinced that the selected techniques are 'safe.'

This reminds me of the "legibility" problem in voting. Perhaps in theory it's possible to hold a magic unhackable blockchain-based secret-ballot-preserving cryptographically-secure digital election, but the average voter cannot be convinced of its security without teaching them tons of CS concepts (can you imagine trying to explain trapdoor functions in a voters' pamphlet?). Meanwhile, paper ballots can go into a tamper-proof box with a big lock on it--which has "security" written all over it figuratively, if not literally--and you can record video of every time the box moves and invite observers as you count the ballots. Up until very recently, this was so obviously secure that anyone saying otherwise would be considered a lunatic.

Based on the title, I had hoped this article would be a study of fast typists to determine the most efficient typing styles. While this article is not that, if you also came to the comments looking for something like that, such studies do exist:

https://userinterfaces.aalto.fi/136Mkeystrokes/

An interesting conclusion is that "non-standard typists" are catching up to touch typists on standard keyboards. This matches my personal experience as someone whose teachers thought cursive would forever remain more relevant than typing...

https://www.sciencedaily.com/releases/2019/10/191002075925.h... https://news.vanderbilt.edu/2016/10/18/todays-self-taught-ty...