johncolanduoni

This is I think an under-appreciated aspect, both for detractors and boosters. I take a lot more “risks” with Rust, in terms of not thinking deeply about “normal” memory safety and prioritizing structuring my code to make the logic more obviously correct. In C++, modeling things so that the memory safety is super-straightforward is paramount - you’ll almost never see me store a std::string_view anywhere for example. In Rust I just put &str wherever I please, if I make a mistake I’ll know when I compile.

What warranties? I assume you’re comparing it to ext4 and not e.g. ZFS?

Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems. Fuchsia/Zircon have improved on the model further.

Someone will of course bring up XNU, but the microkernel aspect of it died when they smashed the FreeBSD kernel into the codebase. DriverKit has brought some userspace drivers back, but they use shared memory for all the heavy lifting.

In fact, SecurityFramework doesn’t have a real Swift/Obj-C API. The relevant functions are all direct bindings to C ABIs (just with wrappers around the CoreFoundation types).

An easy solution to having to put your PIN in too often for SSH is to use the `ControlPersist` option in your SSH client config. This lets you only create a new SSH connection every 30s (or whatever you put), even if you’re doing separate operations. With a low timeout, there’s no realistic security risk (what’s the chance an attacker will only have control of your machine for 30s?).

I do this for GitHub in particular, because of tools that connect to the remote multiple times. Works with anything that uses the actual ssh executable under the hood.

Okay, but institutional investors didn’t create that fact of reality, and I don’t think they’re responsible for the fact that people want to live in or near cities either (instead of the middle of nowhere, which remains dirt cheap). If they’re not holding significant stock, what effect are they having on scarcity?

Manipulating markets by controlling liquidity while not holding a large percentage of the overall stock is a thing. The fact that you could juice trading volume by doing something stupid for no reason doesn’t make it a useless statistic for evaluating what is going on in a market (unless you’re alleging that institutional investors would do this, and I can’t see the motive). This isn’t some shitcoin whose creators are faking trading volume to appear on the leaderboards - it’s houses with deeds.

To be clear, I don’t think institutional real state investment is a substantial part of the reason housing prices are so high. I’m just trying to push whatever argument they were thinking of toward something quantifiable.

How do I distinguish the world where institutional investors are meaningfully contributing to high housing prices and the world where they aren’t? Is there some metric you’ve seen that substantiates the mechanism? For example, are they only 1% of holders but 50% of trading volume or something?

Because if I saw a house 15% below market where I live, I would buy it (to live in). I don’t imagine I’m the only one. Institutional investors can’t stop me from doing that if it’s offered - can they stop the seller from offering that?

The TPM was never designed to be the only holder of a key that cannot be reset. The idea was that it prevents you from typing in a password or reseting an attestation signature in a database for 99% of boots, but if certain things in the boot process change (as determined by the firmware, the CPU, the OS, and the application using the TPM) it’s designed to lock you out so those things cannot change without anyone’s notice.

For that purpose they’re pretty good, though there are advantages to a more signature-oriented boot security option like Apple’s Secure Enclave. But that only works so well because Apple simply doesn’t permit altering parts of the macOS boot process. For Windows/Linux, you have a variety of hardware, firmware, and OS vendors all in the mix and agreeing on escrow of keys for all of them is hard.

It was designed mostly for mechanisms where in the event of certain changes (BIOS upgrades, certain other firmware changes, some OS changes) there is a fallback mechanism to unlock the system and reset the key. This is why Windows BitLocker is so insistent about you saving your key somewhere else - if you do a BIOS update and it can’t decrypt, it’ll require your copy of the key and then reset the TPM-encrypted copy with the new BIOS accounted for.

A TPM’s primary function works by hashing things during the boot process, and then telling the TPM to only allow a certain operation if hashes X & Z don’t change. Depending on how the OS/software uses it, a whole host of things that go into that hash can change: BIOS updates being a common one. A hostile BIOS update can compromise the boot process, so some systems will not permit automatic decryption of the boot drive (or similar things) until the user can confirm that they have the key.

If you have a model where you can do price manipulation of something while owning 1% of it, I understand why you wouldn’t share it. Where are you on the Forbes Billionaire List, out of curiosity?

I don’t understand what your point about TLS 1.3 is. It’s only relevant if you’re doing a downgrade attack (or equivalently, using an active middleware box). TLS 1.3 itself is not vulnerable to this because it (a) doesn’t have non-PFS suites to downgrade to and (b) protects the cipher suites by including them in the key exchange material. But if the server supports TLS 1.2, an active MITM can still downgrade to it if the client doesn’t demand TLS 1.3 specifically (which browsers do not by default). It won’t matter to China until there are lots of TLS 1.3-only websites (which hasn’t happened yet).

China was already leaning on passive DPI and L3 blocking before TLS 1.3 complicated (but as I said, did not preclude) downgrading to PFS ciphers. The reason being that for about the last 10 years, many sites (including default CDN settings) used SSL profiles that only allowed PFS ciphers. For such a server, downgrade attacks are already not useful to the Great Firewall, so adding TLS 1.3 to the mix didn’t change anything.

> So did they? Remember, I'm not talking about some hypothetical future, this technology is actively in use today and has been for some time.

Google Chrome (for example) will now use ECH if the website has the relevant DNS record - but it doesn’t use the anti-censorship mechanism in the spec to make requests to servers that haven’t enabled it look like they may be using ECH. This, combined with the fact that China can just not serve the relevant DNS record by default, means it doesn’t really impact the great firewall.

This is actually a good example of the non-technical side of this: Chrome could send a fake ECH on every request, like the spec suggests. This would perhaps make China block all Chrome traffic to prevent widespread ECH. But then Chrome would lose out on the market share, so Google doesn’t do it. Technical solutions are relevant here, but even the most genius anti-censorship mechanism needs to content with political/corporate realities.

The great firewall was updated to support inspection of TLS 1.3. They didn’t just decide it was whatever and let everything through. It was easier to just update their parsing than to force everyone to turn it off, so they did that instead. Perfect forward secrecy was a thing before TLS 1.3, and they’ve found other methodology to accomplish what they want.

For ECH, China can just require you turn it off. Or distribute their own blessed distribution. It’s the more marginal censorship regimes that will be in an interesting spot. Especially ones where the ISPs are mostly responsible for developing the technical measures.

Yeah but you can’t use the vast majority of crates that way. You have to create a separate unsafe C ABI, and then use it in the caller. Ergonomically, it’s like your dependency was written in C and you had to write a safe wrapper.

The best tool for your median software-producing organization, who can’t just hire a team of engineers to do this, is update embargoes. You block updating packages until they’ve been on the registry for a month or whatever by default, allowing explicit exceptions if needed. It would protect you from all the major supply-chain attacks that have been caught in the wild.

> The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3

You’re looking a dependents. The core React package has no dependencies.

The system you’re proposing wouldn’t work, because without additional effort in the compiler and linker (which AFAIK doesn’t exist) there won’t be perfectly identical pages for the same static library linked into the same executable. And once you can update them independently, you have all the drawbacks of dynamic libraries again.

Outside of embedded, this kind of reuse is a very marginal memory savings for the overall system to begin with. The key benefit of dynamic libraries for a system with gigabytes of RAM is that you can update a common dependency (e.g. OpenSSL) without redownloading every binary on your system.

Rust ABI (as opposed to C ABI) dynamic libraries are incredibly fragile with regard to compiler/build environment changes. Trying to actually swap them out between separate builds is pretty much unsupported. So most of the benefits of dynamic libraries (sharing code between different builds, updating an individual dependency) are not achieved.

They’re only really useful if you’re distributing multiple binary executables that share most of the underlying code, and you want to save some disk space in the final install. The standard Rust toolchain builds use them for this purpose last time I checked.

Sequential read speed is attainable while still having a (small) number of independent sequential cursors. The underlying SSD translation layer will be mapping to multiple banks/erase blocks anyway, and those are tens of megabytes each at most (even assuming a 'perfect' sequential mapping, which is virtually nonexistent). So you could be reading 5 files sequentially, each only producing blocks at 3GB/s. A not totally implausible access pattern for e.g. a LSM database, or object store.

What is the nature of the architectural limit here? The bus between an individual core and the caches and/or memory controller?

That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make the default for a browser in China be to never even try to use ECH as well. Then they'll only annoy people trying to actively circumvent their system. They already do TCP sessionization to extract the SNI domain. Detecting ECH and then just dropping the connection at L3 is functionally equivalent.

In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.

It’s certainly due for an update, but it isn’t doing nothing at all. The friction it creates for unlicensed use at scale is enough to keep all the streaming services etc. afloat, which in turn are still funding the production of content. Maybe the anarchy that would follow its abolition would be superior to the old system creaking along, but that remains to be seen (and would be silly to accept on faith).

It’s not good evidence, because people issue false DMCA takedowns all the time. Which I presume they would point out in court.

In principle, it means you could run multiple sites from the same IP and someone intercepting traffic to that IP (but not the client’s DNS path) couldn’t tell what site each connection was to. It mostly makes sense for CDNs, where the same IP will be used for many sites.

If you don’t use a CDN at all, the destination IP leaks what site you’re trying to connect to (if the domain is well known). If you use a CDN without ECH, you send an unencrypted domain name in the HTTPS negotiation so it’s visible there. ECH+CDN is an attempt to have the best of both worlds: your traffic to the site will not advertise what site you’re connecting to, but the IP can still be shared between a variety of sites.

It’ll be interesting to see how countries with lighter censorship schemes adapt - China etc. of course will just block the connection.

It’s also how browsers detect a website supports HTTP3. Browsers will request it just to check if they should connect to an https:// URL via HTTP3 (though they generally don’t block on it - they fallback to HTTP1/2 if it takes too long).

I want even the most open AI company to guard my chats jealously. But guarding them from my mother’s estate after I’m already gone is another matter.

Would anyone have luck suing a person on some random bodybuilding forum who was similarly sycophantic? ChatGPT didn’t invent strangers on the internet flattering your psychosis.

I’m not sure square footage is what matters here, though comparing the overall market for datacenter/manufacturing jobs would be more useful than individual installations anyway. It’s not like the U.S. is hurting for physical space in which to put factories or data centers. Speed of light isn’t that slow — the big New York IXP is actually in New Jersey and it would be fine even if it was further away.

Yeah, and that’s my point. The problem is not technological, you can make a super readable HTML site by just putting text in <p> tags, and RSS readers for blogs that didn’t rug-pull their content still work fine. People lost interest in giving out something for nothing, so now the web is an ad-infested mess.

If someone makes a new tech that makes that impossible, 10 principled FSF-enjoyers will write content for it and nobody else. Web standard bloat is bad, but it didn’t cause this problem, and you can’t fix it by creating a new spec.

Look, it’s not that complicated. If you just build your software with gcc or whatever in a docker container with pinned versions, put the binary on your website, and call it a day, 5 minutes later someone is going to complain it doesn’t work on their 3 year old Linux Mint install. The balkanization of Linux is undeniable at this point. If you want to fix this problem without breaking anything else, you have to jump through hoops (and glibc is far from the only culprit).

You can see what the best-in-class hoop jumping looks like in a bunch of open source projects that do binary releases — it’s nontrivial. Or you can see all the machinations that Flatpak goes through to get userspace Mesa drivers etc. working on a different glibc version than the base system. On every other major OS, including other free software ones, this isn’t a problem. Like at all. Windows’ infamous MSVC versioning is even mostly a non-issue at this point, and all you had to do before was bundle the right version in your installer. I’ll take a single compiler flag over the Linux mess every day of the week.

Do you distribute a commercial product to a large Linux userbase, without refusing to support anything that isn’t Ubuntu LTS? I’m kind of doubting that, because me and everyone I know who didn’t go with a pure Electron app (which mostly solves this for you with their own build process complexity) has wasted a bunch of time on this issue. Even statically linking with musl has its futziness, and that’s literally impossible for many apps (e.g. anything that touches a GPU). The Linux ecosystem could make a few pretty minor attitude adjustments and improve things with almost no downside, but it won’t. So the year of the Linux desktop remains illusive.

RSS is just a list of links to webpages, maybe with summaries. The readers generally fetch those webpages and filter out the text, but every browser has equivalent functionality now. You can do it with literally any HTML page, though some websites try to fight it (since depending on the reader, it neuters ads).