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.
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.)
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.
This is one of the biggest changes to hit GitHub in many years. I'm really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn't even know about before.
If you buy the idea that stacking produces better software, then this also has the opportunity to really help out quite a few people.
Stack management: automatically rebasing all dependent PRs on any downstack change.
Ability to view & navigate the stack in the reviewer UI.
Ability to merge a whole stack with one command.
> You can't have mac/windows/linux/whatever all locally simultanously.
Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So even testing on one platform can raise your confidence very high.
> Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly"
Again why? I wouldn't care about the dev's local branch. But what is send to the main repo can be easily scripted to run the CI on every commit. You just send the result back with each commit that fails. They can replicate the same workflow on their local workspace as a pre-push process.
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.
Heh, it's a fun reminder that different people work on different things.
Sure, I could load up my build machine with mac/windows/linux/android, with multiple versions of each. Emulating x86+x86_64+arm32+arm64+aarch64+... is also doable, sort of.
But considering that the real CI runs several thousand hours of tests total across all platforms, I think I won't.
Also, my Electron-based IDE needs those 10s of GB to edit text. How can you possibly edit a 1KB text file with less than 1GB of RAM?
Not to mention clangd that needs to do its ultra-important work Right Now so I can invalidate it all with my next edit. That's probably the biggest RAM hog of them all.
This analysis is great, and I don't mean to knock it, but one of the things that it doesn't capture is, what choices does the frontend make that impact the amount of work that the backend does. That is, some of the work attributed to the backend could be improved without touching the backend.
That is of course true, but if anything that just proves more what I said. Also that too is part of the "common wisdom" (that as I said, is not always true).
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
reply