steveklabnik

You are mistaken about what your parent is saying: they're saying that if you want a system untouched by LLMs, you must provide alternatives to those things, because those things have LLM-generated code in them.

The reason people like to work this way is that it lets you very effectively respond to review. You address them by amending the commit to incorporate the feedback.

This enables good interdiff review, so you can re-review just the new stuff in the new version of the commit and not the entire thing all over again.

Why is that a dodge? that's the expected way to work in this system, and it should be able to show you the interdiff between those amends.

When you work this way, each commit is expected to be able to land independently.

This is standard practice in the "stacked diffs" world: one review, one commit.

These technologies are cool and good and useful but they do something different than Rust: they catch problems at runtime and mitigate the bad effects, rather than preventing them at compile time.

My understanding is that `git history` was started after seeing jj, yes. I don't have a citation for you though, I could be wrong, that's just what I remember.

I'm glad, I meant it in semi-jest, because it's true, but also just a very funny thing to "well actually" about.

I would also be surprised that the RFD site breaks screen readers, generally they're pretty good about that.

And yeah, you also can use react with no client side JS as well.

(To answer one of your specific questions, "hubris" is an embedded RTOS and is what runs the BMC-like service processor, and illumos is the host operating system.)

I wrote this back in 2022, but it's still relevant https://news.ycombinator.com/item?id=30678324

Extreme nit: because you purchase a rack at a time, you don't actually rack it. You wheel it in, plug in network and power, and hit "on".

React is one way of generating HTML.

I was talking about regular old today's Rust, not the specifics about become.

Ten minutes used to be the cutoff where you could provide an interstitial advertisement. This sort of turned into a sort of wive's tale, where people thought the algorithm would push such videos. It's not the case today.

The reason that 20 minute videos are more popular these days is that more people are watching youtube on larger screens, like on their TV on the couch, and so more reliably watch longer videos than in the past.

> In rust the borrow checker would guard against reordering such things

It doesn't even get that far: Rust guarantees that things drop in reverse order of declaration, full stop.

One interesting wrinkle here: for struct members, Rust does the opposite of what C++ does. We debated changing it to match, but

> there might be unsafe code relying on drop-order which the borrow checker would be oblivious to.

There was no super real compelling argument to choose one direction over the other in the abstract, and "be the same as C++" was not considered important enough to risk breaking unsafe code that relied on the (what was at the time) implementation defined behavior.

> It's hard to argue that it isn't an optimization, because it doesn't affect the semantics of the program.

Depends on the semantics of the programming language itself. For some languages, it is truly an optimization, for some, it is required, and does meaningfully change observed semantics.

(2025)

Hacker News has a wide variety of people in it, but certainly leans more toward software expertise.

"attestation" not "attenuation," thank you autocorrect :/

(Former oxide)

Yes, custom hardware is a significant part of Oxide. You have to build your own to do that stuff, and that’s why they did. I alluded to some of the things upthread.

I found out about this round from this thread, just like everybody else, but

> Oxide having to raise money multiple times might be a hint

That’s not the only reason to raise a round, by far, especially when you, you know, are building custom hardware. It isn’t a SaaS business.

EDIT: here’s another commentor with an example of this: https://news.ycombinator.com/item?id=49176704

(Former Oxide)

An in-house team is most likely competing with something like Dell or VMware, not really Oxide. A significant part of Oxide’s value proposition is that you’re buying hardware and software purpose built for each other. Unless you’re also going to go so far as to do all of that, which companies like Google do, of course, it’s not really the same thing.

This matters when your various vendors start pointing at each other when something goes wrong. Oxide is truly “one throat to choke” in a way others just aren’t, and stand by that quality.

(Not to mention other various efficiencies, like power, or removing things like the BIOS and BMC junk that’s in basically every other server you buy right now. And the ability to send attenuation from boot up through the host OS. Just tons of things they’re differentiated on that your in house team just isn’t going to do.)

Exactly what I said here: https://steveklabnik.com/writing/i-see-a-future-in-jj/

I am still a huge fan and supporter of Oxide, and I'm really glad to see them still doing well.

Regardless if it's still true or not, the original purpose was not to re-write Gecko.

From the presentation announcing Rust inside of Mozilla: https://venge.net/graydon/talks/intro-talk-2.pdf

> We are not “rewriting the browser”. That's impossible. Put down the gun.

I can't add on to my comment because it's been too long, but a great thread on how much work this is: https://x.com/sameenkarim/status/2083237928092721646

This is roughly the current state of things as I know about it, that said I haven't read a lot of git's mailing list lately so it's possible that there have been some other developments.

This feature was brought up amongst GitHub for years, possibly even a decade. And it was something that they didn't want.

It was new leadership back in October that decided to build this, so it took them 9 months or so. To be clear, I am not saying this is a long amount of time, they had a LOT of work to do to get it to this point, just being clear about timelines.

You can't run MacOS in a VM on non-Mac hardware without violating Apple's EULA.

> But what is send to the main repo can be easily scripted to run the CI on every commit.

Sure, this could work. I didn't say it was impossible, just more difficult. You have to build all of this support on top of the system that already does it for you: have your forge run CI on every commit.

Here is an example of a guide from OpenAI on how you should prompt 5.6 differently than their previous models.

https://developers.openai.com/api/docs/guides/latest-model#p...