sunshowers

Lots of people want to buy our stuff!

I mean, really no one is fully independent — we are all dependent on each other for the necessities of life. But in this context "independent" means "not a subsidiary of another company".

Right -- customers don't have to port their stuff to a new platform or arch or anything. It's just normal x86_64 Linux/Windows VMs, or Terraform if they're so inclined.

We are trying to build a sustainable long-term business! It's just that you need enormous amounts of money to get there when shipping this large a product.

The idea behind VC funding generally is that you need large infusions of capital to get to the point where the business becomes sustainable long-term. The first one is the most expensive, and so on. Hardware is capital-intensive compared to SaaS, and especially so in the current environment.

It's not actually secret — it's open source! We talk openly about our architecture.

Bryan has a good take on the incentive structures holding back commodity hardware vendors: https://m.youtube.com/shorts/O8GSWKpK79s

That's wonderful! Good luck.

Indeed, and I happened to have been part of the creation story for one of them :) https://lobste.rs/s/ghdv6w/i_see_future_jj#c_nx6flj (not otherwise affiliated, though)

GitHub has a chance to get a generation of developers on to better coding practices. LLMs make it more feasible than ever to maintain high-quality patch series/stacked diffs — they can take care of all the mundane things like rebase conflicts for you. If I were in charge I would take this responsibility very seriously.

I guess the next best thing would be to port spr to this. (Probably time to start looking at this to be honest!) This makes me quite sad.

I use `spr` which translates a local rebase + amend workflow into a GH-friendly new-commit + merge on the remote (which is then squashed). They are kind of equivalent from a 30k foot view but the dev experience when working with source control locally is dramatically different. And in particular I regularly have stacks of dozens of commits in flight -- if each commit were a series of commits then I would probably lose it.

The seeming lack of engagement with prior art is so frustrating.

You don't have to expose change IDs in the UI other than as a secondary thing! The current integer index would work just fine.

That is nowhere close to the experience Gerrit and Phabricator have, where you can diff two arbitrary versions in history. Comments on previous versions also get lost along the way.

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs?

The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge workflow, which is simply worse than an amend + rebase workflow. Basically every other review system in existence -- Gerrit, Phabricator, what Google and Meta have internally, the LKML -- works around stacks where people amend and rebase their commits when changing them. All of these have some notion of a "diff", with "versions" that are each tracked separately, and the ability in the review tool to do diffs between those versions. My hope with stacked PRs was that for once GitHub would use this as an opportunity to modernize its review system and bring it in line with all of these other ones. But sadly that just doesn't seem like it's on the cards.

Like all things in life, there is a balance :) I didn't remove the cattle vs pets analogy but I did replace "terminate" with "handle".

Look, you can either let people make a living and manage their own lives while contributing to society, or you can not let them make a living and ensure they're housed and fed. You can't be angry at A and also be angry at B.

Nextest does run tests in lexicographic (binary, test name) order by default, so first executions tend to be staggered. Unfortunately this is a known problem that is much larger than nextest, and it is why Windows introduced Dev Drive with a mode to disable AV/EDR on those drives entirely.

I wish I had a better answer here — it is frustrating how poorly behaved the EDR stuff tends to be. Maybe I should try and network a bit to get in touch with the people working on this stuff. (Planning to be at DEF CON this year, so come find me if you work on this stuff and will be there!)

From what I can tell, a big part of the problem in Europe is that people seeking asylum are prohibited from making a living (due to widespread belief in the lump of labor fallacy) and so have to be dependent on welfare.

The benchmarks are against non-doctest cargo test runs. (But you should measure against your own project, of course!) Unfortunately Cargo doesn't provide enough information for nextest to run doctests reliably with.

I think in practice you're right that GitHub Actions' caching slowness can end up dominating performance. I don't have any great tips other than to measure.

> Can you run tests serially in the (horrible) case when tests need to build on one another?

Yes: https://nexte.st/docs/configuration/test-groups/ (edit: though tests that build on each other is a bit harder — test groups are meant for when tests need access to a shared resource)

> How are you querying for the tests? Is that just built into rust's test stuff?

Just running --list against test binaries.

> Would it be possible to fork the test process? It'd be pretty interesting if you could spawn a test process, and then fork it for each test to save both on memory and any static state stored within the test.

This is possible in principle, but nextest doesn't really inject itself into tests like that (injection can cause reliability issues in practice, and a big focus of nextest is reliability). Forking is also not possible in multithreaded programs.

Thanks! BTW you might enjoy setting CARGO_TERM_COLOR=always in your environment :) dtolnay/rust-toolchain does this automatically but it looks like you aren't using that action.

Oh gosh, were we to be so lucky :) just aiming to solve problems my coworkers and users see, and doing it with care, is all.

The How it works [1] and Why process-per-test? [2] pages should answer your questions.

[1] https://nexte.st/docs/design/how-it-works/

[2] https://nexte.st/docs/design/why-process-per-test/

Yeah that was indeed the inspiration (though I'm pretty sure it predates Kubernetes!) but the juxtaposition with "terminate" is unfortunate.

That's fair! I'll find a way to rephrase it.

edit: Updated to "Detect and handle slow tests". Thanks again!

That is indeed the pun =)

Thanks for posting about this! I'm the main author of nextest, and it represents my best foot forward for how Rust testing should be done. Happy to answer questions though I might be a bit intermittent.

I'm sure you're aware there's a huge amount of computation that isn't matrix multiplication :)

My successful application took around 12 hours of writing and editing across 3 days, though I was lucky that most of my portfolio was already open source or otherwise public. Some people spend more, some spend less.

It is worth keeping in mind that we write a _lot_. If you don't enjoy the process of writing, you might not like working here.

We have a number of TLA+ models at Oxide. Here's one:

https://github.com/oxidecomputer/omicron/blob/8b0886dbd02229...