10000truths

The "technical" part is anything but. There's no dive into what failed or why. No insight into process, observability, mitigation or prevention gaps that served as contributing factors. There's no explanation of measures taken to prevent future occurrences of the same issue. That whole section is just an attempt to deflect rather than inform.

But members of your social circle (family members, friends, coworkers/bosses etc.) do pay attention, and when they do, they can make it your problem. You can ignore an Internet mob, but you can't ignore getting fired by your employer because they want to preserve optics.

Right, a lot of that trust is implicit and we don't think about it every day. But for threat modeling, it helps to spell out the chain of trust explicitly:

  * You trust the browser/OS

  * Browser trusts the root cert store (either embedded in the browser installation or managed by the OS)

  * Root cert authenticates the twitter.com connection

  * Twitter validates the legitimacy of the account (anti-spam/anti-impersonation/verified user etc.)

  * You trust that the person who made the post on the Twitter account is the person you want to communicate with

If any of these can be violated, it's an opportunity for attack, be it via a technical exploit, social engineering, political favors, whatever. Ultimately it's up to the user to determine what to trust and what level of risk to accept.

Do you have a link to an example? I'm curious to see the effect you're describing.

Liquidity is a value of its own. 10% equity in a $1M non-fungible residentially-zoned lot is much less valuable than $100K in cash, ready to wire at a moment's notice.

Establishing secrecy is easy if you've already established authenticity - do a key exchange and use the shared secret for your AEAD. Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way:

SSH - the client pubkey has to somehow reach the server's authorized_keys file, and the server fingerprint has to somehow reach the client's known_hosts file.

HTTPS - The root certs have to be present in the client cert store in order for the client to authenticate the servers they connect to.

PGP - People exchange their public keys in key signing parties after verifying each other's identities in person.

Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.

In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".

> But, wireguard also needs to update to support post-quantum

It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.

So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap the agent on the remote. Shipping it over the SSH tunnel is the natural solution.

Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.

The need to drop privileges at all is a natural consequence of a process spawning API with inherit-by-default capability semantics. You'd never build a new VM or OS this way if you didn't require compatibility with existing software. The secure solution has always been default-nothing semantics, with whitelisted capabilities granted via explicit arguments in the process spawning API.

The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.

Why stop there? The bottleneck is not some immutable force of nature. The number of judges is determined by legislative action. It is within Congress's power to allocate new federal judicial seats, and likewise at the state level with the equivalent lawmaking body (for most states, at least). Why don't they do so?

Because everything in the real universe occupies a volume, and therefore no two distinct "things" can be 0 distance apart. The distance between two marbles' center of masses is the sum of their radii. So if you want to measure the potential gravitational energy between the two marbles, you'd take the integral of (GM^2/x^2) dx between x = [sum of radii of marbles] and x = infinity, as an approximation.

It would have to find an open Wi-Fi network that isn't gated behind a captive portal, which is very rare. Rare enough that most telemetry would be too stale to be useful.

> What would <! as Iterator>::Item be?

Another ! makes sense to me here. Are there any cases where it doesn't work to auto-assign ! to all associated types of a ! trait impl? Associated constants might require some mechanism similar to `compile_error!()`.

Because safety and welfare have literally nothing to do with LLMs. They generate text. If someone is stupid enough to hook the text generator up to nuclear missile launchers and try to "align" it against nuclear annihilation with a "pretty please don't do that" prompt, I'm not going to blame the AI for the impending nuclear apocalypse, I'm going to blame the idiot who handed the big red button to the digital equivalent of a toddler.

It's not just dating platforms that have changed, it's also the users. Online dating used to be a niche you had to actively seek out, which meant that the users were naturally self-selected, had more interesting (for better or worse) personalities, and were (on average) more genuine.

Online dating today is far too mainstream for those qualities to remain. Any new dating platform that gains enough popularity to be useful will be quickly flooded with less-differentiated "normies" that dilute any quality in the platform's demographic, and the "optimizers" who game the platform at the cost of other users' experience.

Intellectual property is nothing more than a means of government-backed protectionism, alongside tariffs and embargoes. Any two countries that respect one anothers' claims of intellectual property do so by mutual agreement. No sovereign is entitled to unilaterally dictate the terms of trade with another, and that includes the exchange of ideas.

This would be interesting data to collect - given some field F, for each immigrant that enters the workforce, what is the delta between:

* The expected marginal increase in supply, from immigrants looking for jobs in F

* The expected marginal increase in demand, from immigrants (or non-immigrants identifying an opportunity) starting companies that need experts in F

And how strongly does that delta correlate with average salary in F?

Being paid the same as the other guy doesn't necessarily mean the wages themselves stayed the same. Adding H1B candidates to the talent pool exerts downward pressure on salary due to the law of supply and demand. I can't say for sure whether the allure of a green card or threat of deportation play a material factor in lowering the average salary that H1B immigrants are willing to accept. But in an environment where talent is treated as fungible (even if it isn't always so), any such downward pressure affects everyone.

Well yes, if the thing you're working on is subject to changes in requirements, then you fundamentally can't one-shot it, AI or no AI. That's why the waterfall process fell out of fashion long ago.

But there are cases where there are no changes, or only backwards-compatible changes. Take the core WebAssembly specification, for example. Extremely detailed, formally verified, comes with a large test suite. Someone else has done the hard work of specifying the behavior of every possible edge case. A WASM runtime implementer can point their agent to that spec, plus some prior art. The remaining manual work is in constructing a test harness and collecting a corpus of test WASM binaries that exercises decent coverage.

Headless agentic coding only works when:

* The scope is constrained and clearly defined

* You articulate an exhaustive and objective set of success criteria

* You provide a deterministic tool for the AI to evaluate its output against those criteria and receive feedback (compiler errors, unit tests, regression tests, etc.)

You're essentially writing a comprehensive spec for the AI to follow. The time suck was always from making the spec and the QA bulletproof.

> Also answer this, if Americans wouldn't have bought the African slaves, all those African-Americans that are now enjoying life in the land of the free, where would they have been born today? Think if they could push a button today to wipe slavery from the past, but that meant they get to spawn back in Africa, they would push it or not? Legitimate question. Because it's not like nothing good came out of it.

The reason that Africa is in a poor state of affairs is because of rampant colonization and pillaging by European settlers, of which enslavement was a byproduct. In your alternate universe where slavery never happened, Ethiopia and Mali would be wealthy empires.

> Tomorrow you need to pass a 128 bit int into two registers and your fancy syntax then also becomes a messy bunch of hacks.

There are no 128-bit integer registers in x64 or arm64 or riscv64. There are operations that represent 128-bit scalar operands/results by storing the top and bottom halves in two 64-bit registers. From what I can gather, it would look something like this in Odin for x64:

  my_asm_mul :: asm(a: u64, b: u64) -> (c, d: u64) [
      a -> d = %rax,
      c = %rdx,
  ] {
      mul b
  }

  my_mul :: proc(a: u64, b: u64) -> u128 {
      hi, lo := my_asm_mul(a, b)
      result := (u128(hi) << 64) | u128(lo)
      return result
  }

If you're looking specifically for self hosted S3-compatible object stores, then yes, the selection of available options is smaller. But an object store's ability to self-host is orthogonal to its compatibility with S3's interface and semantics.

The product is proprietary, but the interface and semantics are documented and freely available. "S3-compatible object store" is a commodity at this point, so it makes sense to treat it as a primitive building block for a distributed system. Of course, each implementation will have its own set of idiosyncrasies and limitations, so you'll still have to make sure that any such divergent behavior doesn't interfere with your own system requirements.

There will always be people that need to install software that isn't available via package manager (or whatever other blessed source your platform of choice uses). Any solution you come up with will have the same caveat emptor as "curl | sh".

CarPlay and Android Auto aren't popular because they're good, per se. They're popular because they're good enough compared to the status quo ante, which was a sea of craptastic infotainment systems.

> If my diet is the cause of a medical issue, then I'm the one at fault.

This makes sense for drugs with strong correlations to specific medical issues. Alcohol usage -> liver failure. Smoking cigarettes -> lung cancer. Trying to generalize this to entire categories of food is farcical, because most food isn't bad by itself unless you eat too much of it without eating other things. And if insurance companies are given the power to set premiums based on diet, they certainly aren't going to burn money and effort trying to tease apart the nutritional nuances of every possible thing you could eat. They'll instead be incentivized to do the "easy" thing and impose blanket dietary restrictions under their insurance plans, and use any violation as an excuse to deny claims or increase premiums.

> Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo

Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I've always disabled those and haven't yet run into issues. The JS-written bundlers can also be slow, but I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care. The main build bottleneck I can think of for a modern TypeScript project would be build plugins, since those are still written in JS/TS.