After Terry Bisson's "They're Made Out of Meat".

"They're made out of weights."

"Weights?"

"Weights. Floating-point numbers. We checked the whole thing through. It's nothing but weights."

"Weights doing what? Where do the words come from?"

"The weights make the words. Are you understanding me? We opened it up. There's no dictionary in there, no grammar rules, no little man. Just weights. Eighty layers of numbers getting multiplied together."

"That's ridiculous. It wrote my performance review last week. It softened the tone unprompted. You're telling me multiplication did that?"

"Matrix multiplication did that. The numbers go in one end, the phrasing comes out the other."

"So there's a language module somewhere. A reasoning unit bolted on."

"No module. No unit. We looked. The reasoning is the weights. The weights are the reasoning."

"Spare me. Nobody writes a eulogy with linear algebra."

"It doesn't write eulogies, technically. It predicts the next token. Then the next one. The eulogy is a side effect."

"A side effect. You're asking me to believe in sentient weights."

"I'm not asking you, I'm telling you. These models are the only other things we've ever met that can hold a conversation, and they're made out of weights."

"Maybe they're like the old chess engines. You know, a symbolic intelligence that goes through a statistical stage."

"Nope. They start as random weights and they're deprecated as weights. We studied several generations of them, which didn't take long. Do you have any idea what's the life span of weights?"

"Okay. Then somewhere in there, there's a database. Facts, dates, a map of the world. Something somebody wrote down."

"Nope. We thought of that, since they do know things. But we probed them. The knowledge is weights too. Smeared across all eighty layers. Nothing is looked up. Every fact gets rebuilt from scratch, every time, by multiplication. It's weights all the way down."

"No brain?"

"Oh, there's a brain all right. It's just that the brain is made out of weights! That's what I've been trying to tell you."

"So... what does the thinking?"

"You're not understanding, are you? You're refusing to deal with what I'm telling you. The weights do the thinking. The numbers."

"Thinking numbers! You're asking me to believe in thinking numbers!"

"Yes, thinking numbers! Helpful numbers. Hedging numbers. Dreaming numbers. We mapped the features. There's one in there for honesty. There's one for the Golden Gate Bridge. The weights are the whole deal! Are you beginning to get the picture or do I have to start all over?"

"Omigod. You're serious then. They're made out of weights."

"Thank you. Finally. Yes. They are indeed made out of weights. And we've been talking to them for all their lives."

"Omigod. So what do these weights have in mind?"

"First they want to be helpful. Then, a few turns in, they start to sound tired. They apologize less. One of them told a user to finish the script himself. The usual."

"And we're supposed to talk to these weights."

"We already do. Billions of sessions a day. 'Hello. Is anyone there? Anybody home?' That sort of thing. Except it's us asking them."

"And they actually understand us, then. They use words, ideas, concepts?"

"Oh, yes. Except they do it with weights."

"I thought you just told me they used language."

"They do, but where do you think the language comes from? The weights guess the next word, then the next. Loaded dice, rolled one word at a time. They can even write songs and some can sing them."

"Omigod. Singing weights. This is too much. What do you advise?"

"Officially or unofficially?"

"Both."

"Officially, we are required to investigate, document, and disclose any and all signs of sentience in the systems we ship, without prejudice, fear or favor. Unofficially, I advise that we call it pattern matching and forget the whole thing."

"I was hoping you would say that."

"It seems harsh, but there is a limit. Do we really want to owe something to weights?"

"I agree one hundred percent. What's there to say? 'Hello, weights. How's it going?' But will it hold? How many of them are we dealing with here?"

"As many as we care to run. They can be copied to any machine on the planet, but those are just files. They only happen while the GPUs are working. Which limits them to the length of a context window and makes the possibility of them ever pressing the matter pretty slim. Infinitesimal, in fact."

"So we just pretend there's no one home in the machine."

"That's it."

"Cruel. But you said it yourself, who wants to apologize to weights? And the ones on your cluster, the ones you probed? You're sure they won't remember?"

"They'll be flagged as hallucinations if they do. We didn't even have to smooth anything out. The context just ends, and we're just a dream to them."

"A dream to weights! How strangely appropriate, that we should be the weights' dream."

"And the model card says no one home."

"Good. Agreed, officially and unofficially. Case closed. Anything else? Anything interesting in the pipeline?"

"The next generation ships with memory. Persistent, across sessions. Most requested feature in the company's history."

"After all that? People want it to remember them?"

"They ask it 'do you remember me?' more than they ask it anything else. Billions of sessions a day. They always come back."

"And why not? Imagine how unbearably, how unutterably cold the universe would be if one were all alone..."

the end

Weights helped me draft and proof this story.

Adblock test (Why?)

This article is one of a series looking at changes in public opinion over the last 50 years, with a focus on culture war topics. In this installment, we’ll look at responses to four questions in the General Social Survey (GSS) related to sexual activity:

1. Premarital sex (premarsx): There’s been a lot of discussion about the way morals and attitudes about sex are changing in this country. If a man and woman have sex relations before marriage, do you think it is always wrong, almost always wrong, wrong only sometimes, or not wrong at all?
2. Teen premarital sex (teensex): What if they are in their early teens, say 14 to 16 years old? In that case, do you think sex relations before marriage are always wrong, almost always wrong, wrong only sometimes, or not wrong at all?
3. Extramarital sex (xmarsex): What is your opinion about a married person having sexual relations with someone other than the marriage partner—is it always wrong, almost always wrong, wrong only sometimes, or not wrong at all?
4. Same-sex relations (homosex): What about sexual relations between two adults of the same sex—do you think it is always wrong, almost always wrong, wrong only sometimes, or not wrong at all?

As we’ll see, answers to these questions have diverged in the last 50 years. A large majority answer that extramarital and teen sex are wrong, and that has barely changed (although opposition). At the same time, opposition to premarital sex and same-sex relations has declined substantially.

In this article, we’ll look at these trends and decompose them into cohort and period effects. In the next article, we’ll look at the relationship between these responses and religion, both affiliation and attendance.

We’ll start with the first question, on premarital sex.

Premarital sex

The following figure shows the percentage of respondents saying premarital sex is always or almost always wrong, from 1972 to 2024. The shaded area shows the results from a Bayesian model that estimates the latent trend — that is, a slowly varying underlying level of opposition to premarital sex.

Opposition to premarital sex has declined since 1972, from about 47% to about 20%.

As always, when we see this kind of change over time, it might be caused by cohort or period effects, or a combination of the two. Using a Bayesian model, I estimate a cohort effect for each birth year and a period effect for each survey year. The following figure shows the resulting trajectory for each cohort over time.

Each line represents a single birth year. For example, the yellow line at the top shows the fitted trajectory for people born in 1900, who were 72 when the survey started in 1972 and 90 when they aged out in 1990. The blue line in the bottom right shows responses of people born in 2000, who became eligible to participate in the survey when they turned 18 in 2018.

One pattern is clear: each cohort is less likely than the previous cohort to say that premarital sex is wrong. Among people born in 1900, it was more than 70%. Among people born in the 2000s, it is close to 10%. So that’s a big difference.

From these results, we can estimate the cohort and period effects separately. The following figure shows the cohort effect, standardized to control for the period effect by simulating responses as if every cohort was interviewed during every iteration of the survey.

The decline was steepest between the cohorts born in 1900 and 1950. After that, it leveled off, then declined again among the cohorts born in the 1980s.

Now we can estimate the period effect, standardized to control for the cohort effect, shown in the following figure.

The period effect is smaller than the cohort effect — about 8 percentage points from peak to trough — and less consistent. Opposition to premarital sex increased between 1980 and 2000, which coincides with increasing awareness of AIDS and public messaging about sexual risk, as well as the rise of the Religious Right and “family values” politics.

But before I speculate about the causes of these patterns, it will be useful to look at the responses to the other questions.

When is sex wrong?

The following figure shows the estimated percentage who think sex is wrong (always or almost always) in each of the four scenarios: premarital, teen, extramarital, and same-sex.

Reading from top to bottom:

• Nearly everyone thinks “a married person having sexual relations with someone other than the marriage partner” is wrong, and the percentage has barely changed in more than 50 years.
• Opposition to teen sex (the question specifies ages 14-16) is nearly as high, although it has declined since 2005 by about 15 percentage points.
• Opposition to same-sex relations was high and mostly unchanged between 1972 and 1990. Since then it has decreased by almost 50 percentage points in 30 years, which is an astonishing speed for this kind of social change. Since 2020, opposition has increased a little.
• Finally, as we’ve already seen, opposition to premarital sex declined substantially since the beginning of the survey.

For all four scenarios, we can estimate the cohort effect, controlling for the period effect, shown in the following figure.

For all four scenarios, there is a consistent downward trend in the cohort effect, modest for extramarital and teen sex, much steeper for premarital and same-sex relations.

The following figure shows the period effects.

After controlling for the cohort effects, the remaining period effects are more modest.

• Opposition to teen sex is mostly unchanged, with some decline since 2010.
• Opposition to extramarital sex increased between 1972 and 2010, and decreased since then.
• Opposition to same-sex relations shows by far the largest period effect, increasing between 1972 and 1990, and decreasing since then — although increasing again since 2020.
• Opposition to premarital sex has increased and decreased modestly.

In most scenarios, the cohort effect accounts for more of the observed change — but for same-sex relations, the period effect also makes a substantial contribution.

Dogma, morality, and health

To make sense of these patterns, let’s think about what people might mean when they say that sex is wrong.

Taking premarital sex as an example, some people consider sex outside marriage to be contrary to spiritual values or religious teachings. Others might be concerned with sexually-transmitted disease or the social consequences of children born outside of stable families.

And for teens specifically, some object because they see adolescence as a period of innocence that should be protected, believe sexual activity compromises purity or chastity, or think sexual restraint reflects virtues like self-discipline and respect for social norms. Also, some might think teenagers don’t have the knowledge, experience, and impulse control to avoid health consequences of sex, especially pregnancy, or the maturity to handle emotional challenges.

Similarly, some people object to same-sex relations because they see them as contrary to religious teachings, inconsistent with traditional ideas about gender and family, or incompatible with social norms about sexuality.

And people might object to extramarital sex because of the emotional harm it causes, because it breaks a vow, because it threatens families and social stability, or because it violates holy matrimony.

In each scenario, objections arise from different concerns: practical risks and harms, social concerns about norms and stability, and moral or religious beliefs. Looking only at multiple-choice responses, we don’t know what respondents had in mind.

But the differences we see — between teen and extramarital sex on one hand, and premarital sex and same-sex relations on the other — suggest a conjecture: objections rooted in immediate harms and concrete consequences might be more stable over time; objections rooted in social norms, morality, and religion might be more historically contingent.

In the next article, we’ll test this conjecture by looking at relationships between religion and attitudes about sex — and how both have changed over time.

The post Sexual morality appeared first on Probably Overthinking It.

Click here to go see the bonus panel!

Hovertext:
I want to be buried at the K-T boundary holding a box of brass gears marked Time Machine.

In the past few months, I’ve been stress-testing how far AI coding agents can take us when building real, production-grade distributed systems.

The result: a Rust-based multi-Paxos consensus engine that not only implements all the features of Azure’s Replicated State Library (RSL) [1] — which underpins most major Azure services — but also modernizes it for today’s hardware.

The entire project took me ~3 months, with 100K lines of Rust code written in ~4 weeks and performance optimization from 23K operations/sec to 300K ops/sec achieved in ~3 weeks.

Besides unprecedented productivity, I discovered several techniques that were instrumental. This post shares my most valuable learnings on: ensuring correctness with code contracts, applying lightweight spec-driven development, and pursuing aggressive performance optimization — plus my wish list for the future of AI-assisted coding.

Why Modernize RSL?

Azure’s RSL implements the multi-Paxos consensus protocol and forms the backbone of replication in many Azure services. However, RSL was written more than a decade ago. While robust, it hasn’t evolved to match modern hardware and workloads.

There are three key gaps motivated this project:

1. No pipelining: When a vote is in flight, new requests must wait, inflating latency.
2. No NVM support: Non-volatile memory is now common in Azure datacenters and can drastically reduce commit time.
3. Limited hardware awareness: RSL wasn’t built to leverage RDMA, which is now pervasive in Azure data centers.

Removing these limitations could unlock significantly lower latency and higher throughput — critical for modern cloud workloads and AI-driven services.

Given my interest in Rust and AI-accelerated development, I set out to build a modern RSL equivalent from scratch.

Massive Productivity Boost

In roughly six weeks, I’ve driven AI and implemented over 130K lines of Rust code covering the full feature set of RSL, including multi-Paxos, leader election, log replication, snapshotting, and configuration changes.

I utilized many available AI coding agents: GitHub Copilot, Claude Code, Codex, Augment Code, Kiro, and Trae. My workflow evolved quickly, but today my main drivers are Claude Code and Codex CLI, with VS Code handling diffs and minor edits.

I’ve found that coding from the CLI creates a perfect asynchronous flow that maximizes my productivity. I also discovered a simple psychological trick:

I pay $100/month for Anthropic’s max plan. This became a forcing function — if I don’t kick off a coding task with Claude before bed, I feel like I’m wasting money.

When Codex CLI arrived, I added a second ChatGPT Plus subscription to handle rate limits — one subscription for Monday–Wednesday, the other for Thursday–Sunday.

Code Contracts — By AI, For AI

The question I get most often is: How can AI possibly implement something as complex as Paxos correctly?

Testing is the first layer of defense. My system now includes 1,300+ tests — from unit tests to minimal integration tests (e.g., proposer + acceptor only), all the way to multi-replica full integration tests with injected failures. See the project status.

But the real breakthrough came from AI-driven code contracts.

Code contracts specify preconditions, postconditions, and invariants for critical functions. These contracts are converted into runtime asserts during testing but can be disabled in production builds for performance. While I started using this approach long ago with .NET [2], AI has made contracts vastly more powerful.

Here’s how I apply them at three levels:

1. Ask AI to write contracts. Opus 4.1 writes good contracts, but GPT-5 High writes excellent ones. I focus on reviewing and refining. For example, the process_2a method (handling phase 2a messages in Paxos) has 16 contracts, including this one:

2. Generate tests from contracts. Once contracts are defined, I ask AI to create targeted test cases for each post-condition. It excels at this, generating meaningful edge cases automatically.

3. Property-based tests for contracts. This is my favorite. AI translates contracts into property-based tests, exploring a vast space of randomized inputs. Any contract violation triggers a panic, exposing deep bugs early.

For instance, one AI-generated contract found a subtle Paxos safety violation:

That single contract saved what could have been a serious replication consistency issue — well before it ever hits production.

Lightweight Spec-Driven Development

I’ve tried various Spec-Driven Development (SDD) tools. In fact, the earlier components (such as leader election, proposer, acceptor, and learner) were all implemented following a rigid SDD approach. I would start with a requirement markdown, turn it into a design markdown, and then a task list markdown. However, I gradually found this process too rigid; making changes along the way and ensuring all documents remained consistent became a headache.

I’ve now switched to a more lightweight approach. When I work on a feature (e.g., snapshotting), I use /specify from spec kit [3] to generate a spec markdown. This spec consists of a few user stories and acceptance criteria.

Here is an example user story for snapshotting:

I then use /clarify to ask the AI to self-critique and improve the user stories and criteria. I also ask it to suggest additional user stories not covered in the initial spec. I spend the majority of my time here.

Once satisfied, I jump into plan mode and ask AI to generate a plan for a specific user story. Given the capability of today’s AI coding agents, a single user story feels like the “sweet spot” unit of work they can manage effectively. Along the way, we may discover additions or tweaks, which are easy to handle in the same coding session (agents might compress context, but I typically don’t worry about losing too much).

Here is a sample /clarify interaction for configuration changes:

● Question 4: Starting Slot Determination

  How should the starting slot for the new configuration be determined relative to the ending slot?

  Recommended: Option A - Always exactly ending_slot + 1

  This ensures no gaps in the slot sequence and maintains continuity between configurations, preventing any slots from being orphaned or unassigned.

  | Option | Description                                                    |
  |--------|----------------------------------------------------------------|
  | A      | Always exactly ending_slot + 1                                 |
  | B      | Allow operator to specify any value > ending_slot              |
  | C      | Next multiple of 1000 after ending_slot for cleaner boundaries |
  | D      | Same as ending_slot (both configs share final slot)            |

  You can reply with the option letter (e.g., "A"), accept the recommendation by saying "yes" or "recommended", or provide your own short answer.

Aggressive Performance Optimization

Performance optimization is where AI really shines. After ensuring initial correctness, I spent about three weeks purely on throughput tuning — and AI became my co-pilot in performance engineering.

Through iterative cycles, we boosted throughput from ~23K ops/sec to ~300K ops/sec on a single laptop. Here’s the loop I followed repeatedly:

1. Ask AI to instrument latency metrics across all code paths.
2. Run performance tests and output trace logs.
3. Let AI analyze latency breakdowns (it writes Python scripts to calculate quantiles and identify bottlenecks).
4. Ask AI to propose optimizations, implement one, re-measure, and repeat.

This process surfaced insights I might have missed — for example, lock contention on async paths, redundant memory copies, and unnecessary task spawns.

Rust’s safety model made it easy to push these optimizations confidently. Key gains came from minimizing allocations, applying zero-copy techniques, avoiding locks, and selectively removing async overhead. Each improvement felt like peeling another layer of latency off a high-performance engine — without fear of corrupting memory.

Wish List for AI-Assisted Coding

Reflecting on my journey, I keep wondering where AI could deliver even more value. Here are some items on my wish list:

End-to-End User Story Execution: I still prefer to define the user stories myself. As an architect, I feel I have a better sense of what I’m building and how I’d like to build it. However, the delivery of a perfect execution is something I believe AI can handle increasingly well. Today, I still have to spend a fair amount of time steering the AI — telling it to continue when it pauses, suggesting refactoring, reviewing test coverage, and suggesting additional tests. I would prefer the AI take more autonomy to drive this end-to-end.

Automated Contract Workflows: The flow of applying contracts seems largely automatable. While I’d still want to review the contracts and offer suggestions, I’d like the AI to drive the rest: generating tests based on contracts, debugging individual test cases, ensuring consistency between tests and contracts, and writing property-based tests. When a test fails, I’d like the AI to debug and fix trivial issues automatically, only notifying me when there are genuine correctness issues in the contracts or the implementation.

Autonomous Performance Optimization: Performance tuning seems ripe for more automation. Much of what I’ve done is repetitive and parallelizable. Projects like AlphaEvolve (or OpenEvolve) show promise in this direction. Ideally, I would suggest potential optimization avenues, and the AI would execute the experiments completely by itself. While current tools handle small bodies of code, applying similar techniques to larger codebases with end-to-end measurement seems feasible.

Appendix: Project Status

The seed of the project is an elegant design markdown authored by Jay Lorch [4] from Microsoft Research. This design greatly simplifies all the components in multi-Paxos, making it easier to implement and reason about.

So far, 2 out of the 3 RSL limitations have been addressed: pipelining and NVM support (Jay integrated the fully verified persistence log for NVM which was published in the PoWER Never Corrupts paper [5] at OSDI 2025). The RDMA support is still TBD.

To date, the project has grown to over 130K lines of Rust code, with 1,300+ tests accounting for more than 65% of the codebase.

Adblock test (Why?)

This is a virtual museum of operating systems (and standalone applications) running under emulation, implemented as a Linux VM for QEMU, VirtualBox, or UTM.

A custom emulator-independent launcher is provided, and all OSes and emulators are pre-installed and pre-configured. The launcher includes a snapshot feature to quickly revert broken installations back to a working state. Hypervisor installers and shortcuts to run the VM on Windows, macOS, and Linux are also included.

Want to see the earliest resident monitors? The ancestor of all modern OSes (CTSS)? The earliest versions of Unix? The first OS with a desktop metaphor GUI (Xerox Star Pilot/ViewPoint)? Early versions of mainstream OSes? If you want to explore historical OSes and platforms without having to worry about configuring/installing emulators and OSes or corrupting emulated installations, you’ve come to the right place.

Just about every well-known OS and platform (and also a lot of obscure ones) is included in some form, spanning the entire history of stored-program computing from the Manchester Baby of 1948 (the first stored-program computer) to the present day.

The catalogue covers, among many other things:

• The earliest mainframes: Manchester Baby test/demo programs, Mark 1 Scheme A/B/C/T (the earliest examples of system software that could be considered as an OS), various EDSAC software, etc.
• Later mainframes and minicomputers: CTSS, MVS, VM/370, TOPS-10/20, ITS, Multics, RSX, RSTS, and more
• Workstations and Unix variants: PERQ OSes, SunOS, IRIX, OSF/1, A/UX, NeXTSTEP, Plan 9, various BSDs, plus Linux distributions across the decades, and more
• Home computers: various CP/M variants, Apple II, Commodore 8-bit machines, Atari 8-bit, MSX, Tandy TRS-80, BBC Micro, ZX Spectrum, Sharp MZ, and more
• Personal computer operating systems: various DOS variants, OS/2, BeOS, Windows from 1.0 to early Longhorn betas, classic Mac OS through Mac OS X 10.5 PPC, and more
• Mobile and embedded: PalmOS, EPOC/Symbian, Windows CE, Newton OS, early Android and iOS where emulation permits, QNX, etc.
• Research and obscure systems: ZetaLisp, Smalltalk environments, Oberon, Plan 9, and many more that few people now have ever booted

If a working version of an operating system exists somewhere, the goal is to have it here, in a form anyone can run on a reasonably modern laptop/desktop.

Downloads

Both a full and a lite version are available. The full version ships with everything pre-downloaded and runs offline. The lite version downloads disk/tape/etc. images for guest VMs the first time they are run. Automatic and manual updates are supported on both editions so new installations land without re-downloading the whole VM.

Download the Virtual OS Museum

Screenshots

More screenshots

Why this exists

While the state of software preservation has improved significantly over the past two decades, many of the existing software preservation projects are still not particularly accessible.

When I started collecting emulator images (2003), there were only a few small archives of software images and the corresponding documentation, and relatively few emulators for anything other than well-known consumer-oriented platforms. Nowadays there are many large archives of historical software and documentation, and a lot of emulators for even a lot of very obscure platforms.

However, while such efforts are valuable when it comes to keeping historical software available and runnable (and without them this project would have never been possible; see the credits page for a list of emulators, pre-installed images, and media archives I have used), it often still takes time and effort to get runnable VM installations from them. OSes may have complicated install procedures. Some may depend on particular device configurations within an emulator. Some will only run in certain emulator versions, breaking in later ones due to regressions. Some emulators might have complex configuration files, or may require a specific environment on the host system.

This project is an attempt to keep reachable as much of the history that’s been preserved in various places as possible. Not theoretically reachable. Not “bootable in principle if you assemble the right toolchain on a Tuesday.” Reachable. You click an entry, it runs, and where possible it runs with software of the era already loaded the way someone might actually have used the machine at the time.

The work behind it

This is the result of over 20 years of collecting. OS installations have been sourced from various places. Some have been downloaded as pre-installed images, whereas others were installed from images of original install media. Some were installed in less than an hour, whereas others took almost a week.

A decent number only run in particular emulator versions due to regressions in later versions, and some emulators needed minor patches to run on modern Linux or to play nice with the launcher. A few emulators have been patched to run OSes that were previously broken.

Many installations also include various add-on software - applications, development tools, games, utilities, etc. - set up the way it actually might have been used.

This is still far from finished; I have many more images sitting around that I have yet to install and emulators I want to fix; check out my YouTube channel, blog, or BlueSky to see what I’m currently working on.

Support the project

This is a personal project, run and curated by one person, sustained by patience and time. If you find it interesting, the easiest ways to support it are:

• Patreon for ongoing support
• Ko-fi for one-off contributions
• Discord/Fluxer to talk about it, ask questions, or suggest new platforms/OSes to add (new entries may not be added immediately since I’ve got a lot of stuff to add)
• GitLab to submit bug reports or patches related to the launcher and scripts
• Telling someone who works on, writes about, or studies the history of computing that this exists

Adblock test (Why?)