AlotOfReading

What does flyover country have to do with the present discussion? Kalshi is just as big a problem (or bigger even) in Nebraska as New York. Taxes going to Anduril happens whether you live in Malibu or Missouri.

    I didn't say anything about leaving society, I alluded to leaving their society. That's the thing: people keep giving these guys money and attention. If you take that away, they become more than irrelevant.

Can you explain how to do that without either drawing attention to them via discussions like this or leaving society altogether? I don't personally fund a16z, but my taxes do. Calls to coordinated action to stop giving them money also count as attention.

The parent comments are talking about how the game is negatively impacting society. Your suggestion is to check out and leave society to them. One of the many problems with that suggestion is that it's hard for your best self/life to emerge in a bleak future.

Honestly, you get used to it. I find hierarchial binomial/trinomial naming system used in biology a lot more clear than the TLAs so common in engineering. Half of the terms are pretty uncommon as well.

I've almost never seen the trade-offs you're describing cause the slowness being discussed.

Take slack for example. It's not fast, it's not correct, it's not stable, it's not memory efficient, and it's not particularly secure. There's a reasonable argument that it's usable, but that doesn't seem to have much to do with tradeoffs in their technology choices.

The parent is just failing to explain a more fully developed concept called the "urban revolution", which classically has 10 characteristics of which writing is one and not all of which need to be present [0].

This entire discussion stems from the fact that the word "civilization" is essentially defined to fit the societies people already consider civilizations. There are technologically, politically, and socially complex societies that aren't "civilizations". My recommendation is to avoid the word entirely. Trying to use it scientifically leads to confusion.

[0] https://en.wikipedia.org/wiki/Urban_revolution

5 years ago was Apple M1/M2 and AMD Zen 3. What RISC-V cores are remotely competitive with that?

The final proof you get from formal methods is often irrelevant in my opinion. Most of the benefit comes from architecting the system so as much as possible can be verified and forcing yourself to make intentional decisions on the edge cases. The results are for other people.

I'm not sure you want to create a record of intentional decisions if you're at Facebook though.

Haven't seen anyone sending partiful invites here.

    For example poor people who have never thought about rising out of it...

I obviously don't have numbers on this, but I strongly doubt there's a poor person on this planet who's never thought about "rising" out of it. That's the dream the lottery sells, that's why so many kids want to be basketball stars / celebrities / influencers, etc.

My personal experience is that the required difficulties of my life have decreased in direct proportion to my income, leaving mainly the self-imposed difficulties. It's not hard to extrapolate that line a little further to billionaires.

You can probably get better angular resolution with lenticular sheets. You see one image if you're dead on, and the other images if you're off to the left or right.

Some napkin math says a couple inches of precision should be achievable at reasonable distances?

Then it crashes in a nice, obvious way as soon as you execute one of them? Illegal instructions aren't usually that hard to debug unless they're related to memory safety issues.

     Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.

It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores between versions or product lines, and I might need performance in this one system vs specific interfaces in another. So even if I know what core I'm using today, I don't know what core I'll be using in a year or five. I may also be writing a library or other reusable component and have no idea what core will run things today.

    Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.

Let's take the bitfield instructions the author complains about for similar reasons. If bfi/bfx takes multiple instructions, optimal structure packing isn't necessarily a win for performance or memory usage. The programmer needs to trade off how often the structure is instantiated vs accessed. Even they can make the right decision today, it might not be the right decision tomorrow. And if they get it wrong, that might not be apparent until later (when it will be somewhat obscured in superficial memory usage analysis). Or the ISA can get it right the first time and also make things easier for compilers/humans in the process.

    "Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.

I can easily imagine this happening. When you change embedded platforms, the typical approach is to take the existing system and compile it for the new platform without carefully revisiting every decision made in the old system. If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens. The metadata in the blob will hopefully catch the issue at link time, but it was an avoidable error.

It's a little weird to truncate the history [0] of your open source project and lock the v1 commits in a separate repo with limited access [1]. Are the authors embarrassed of the commit history?

[0] https://github.com/RayforceDB/rayforce/pull/166

[1] https://github.com/RayforceDB/rayforce2/blob/master/README.m...

The description you've given for apt just sounds almost exactly like SAT, a problem that's very efficiently approximated. That's exactly how the --solver 3.0 flag on recent apt versions works [0].

[0] https://blog.jak-linux.org/2024/05/14/solver3/

The challenge of hard rules like this is that they're always overly restrictive. I've made multi-thousand file PRs that needed two lines of description including the title, and 5 line PRs that needed a 1hr presentation to fully explain them.

My personal guideline is that writing for humans should be done by humans.

Part of the point was to hand out copies to wealthy allies as a visible sign of favor. Physical arches are a little bit harder to dole out that way, or distribute around the nation. It was also cutting edge technology in a way simple arches weren't.

The general answer to this is Byzantine consensus, which cryptocurrency blockchains are designed to solve. If your nodes are willing to fail a little more politely (e.g. no lying, immediately crashing, etc) you can use something cheaper like raft/paxos.

But yeah, it's a lot cheaper to build a reliable system than it is to be resilient.

States have been individually regulating gambling within their borders since they were English colonies. No one interpreted it as interstate commerce until PASPA in 1992, which was gutted by Murphy.

I think it's better to think of the hutter prize as a challenge to see how close people can get to efficiently approximating AIXI without the exponential cost of AIXItl. The fact that winners don't generalize well is just that they're not great approximations, because the behavior is different in the limit.

It might not be optimal, but it's not wrong to call it the best available guess. That's basically assuming Occam's razor / Solomonoff induction. Hutter published a bunch of work about what it means to have an "optimal" compressor and famously spent the past couple decades running a compression contest on the idea that it'd lead to insights in AI.

It's a self-fulfilling prophecy. If police treat every situation as a potentially dangerous engagement, they're actually actually increasing the likelihood that dangerous engagements occur.

Most of that volume is air, and I use vacuum bags for storage/laundry organization. My jackets only take up the volume of a few t-shirts en route. Sweaters are more difficult, because I don't want to put handknit fabric into a vacuum bag, so the times I've needed to travel with those I wear them onto the plane as normal clothing, or slung over an arm.

The description is a bit exaggerated, but I regularly see families with a large overhead suitcase + personal bag + secondary bag per person waiting at the carousel. I don't think many of them are diving in the places I go to, but who knows.

I'm not sure what you're considering "heavier" clothes, but my layers work just fine to about -20C. It was a bit chilly the times it was <-40C, but I don't think that's what you meant?

The comment covered special gear, so not really sure what you want me to add there. I use a slightly larger bag that fits in overhead.

I really don't understand what people are putting in the 2-3 large suitcases I see them struggling to shove in overhead. For one, rolling luggage is usually a mistake for anyone who's not flight crew.

I bring a week's worth of thin clothes that layer. If I need more, I'm either washing by hand or using a service. Basic toiletries, an e-reader, phone, keys, charger bricks, a notebook/pens, daypack. It fits into an underseat backpack with room to spare.

This has scaled fine all the way up to multi-month scientific expeditions in remote locations. Sometimes I need to accommodate specialized equipment like formal clothes/shoes, camera bodies/lenses, excavation equipment, tent, water purification, sleeping pad/bag, etc, but that's solved through the magic of bringing a slightly larger bag.

What are the proper permissions for an agent? An agent shouldn't be able to read ~/.ssh, but that means a bash tool that spawns `cat` is different than one that spawns an ssh client. I don't allow my agents to use git commit, except sometimes I ask an agent to split up a complicated branch that I can't be bothered to split myself. rm'ing intermediary files is fine, but rm'ing committed files is bad, unless the agent has done *.bak renaming and is cleaning up itself, etc.

I don't think "proper" permissions are possible without dramatically limiting the way people use these tools.

I'm also not sure you can really learn chip production from widely available public information. It's a hugely complex industry where the details tend to shape larger strategies. For example, you can't really understand the relationship between Micron and TSMC without some awareness of the trade-offs of memory processes for peripheral transistors.

You can do better than O(N^2) if your changes are monotonic /independent (or you're able to cache for basically the same reason). This usually requires either luck, a huge amount of programmer discipline, or very different programming languages than we're used to like unison.

    integration tests (which can be trickier when it requires a hardware test bed.)

I use this as a fizzbuzz-type test when I'm interviewing at hardware companies: do they have development hardware in a rack with programmable power supplies and mini-PCs (or similar)? It's a low, low bar for testing, and rules surprisingly many companies.

They'll often just have The Guy running manual tests instead.