101–110 of 112 posts
Earlier quoted context omitted.
All your positions seem to be US-based, though. Or am I missing something?
All the positions on the site currently are remote friendly. I work for Oxide remotely from the UK – you just need a reasonable overlap with PT, I overlap four hours most days.
Earlier quoted context omitted.
Sell you a few racks of servers, ready to use out of the box, I guess?
Wouldn’t an enterprise go with what they’ve always used? Like Dell, EMC, HP, etc…and most startups will use a cloud provider instead of on prem
The point of a startup is to disrupt the current market. And they are trying. Lets see how they do.
Earlier quoted context omitted.
Sure, the CPU may enter a power-saving state, but presumably for each box, there's a minimum level of power consumption for things like the motherboard, BMC, RAM, and case fan(s). The reason why AWS bare-metal instances are absurdly expensive compared to OVH dedicated servers is that AWS packs more computing power into each box. So for each core and gigabyte of RAM, I would guess AWS is using less power (edit: especi…
Interestingly, I believe that unused DIMM modules could be powered down if the hardware bothered to support that. Linux has to support memory hotplug anyway because it's long been in use on mainframe platforms, so the basic OS-level support is there already. Since it's not being addressed in any way by hardware makers, my guess is that RAM power use in idle states is low enough that it basically doesn't matter.
Each stick of DDR4 is going to consume on the order of 1.2w (idle CPUs can theoretically go lower than this).
I’d rather shut a whole machine down than go to the effort of offlining individual DIMMs, since the consumption is so low and quite static.
I'm currently reading up on this, but I'm struggling to match a use case. It's not Openstack. It's not VMware. It's not kubernetes. It's not proxmox. It's not Xen. It's not Anthos. It's not GCDE. It's not Outposts. So who and what is it for? Where is the use case that none of these other products fit the bill? Especially for an on premise use case.
This article is about technical details of the product that aren't user-facing. The business is fairly straightforward: we sell computers, a rack at a time. You as a customer can buy a rack, and put it in your data center. The rack offers an in-browser management console, built on top of an API you can use too. You use these tools to set up virtual machines. You can then use those VMs however you want. You get the cl…
How does this differ from what large players like Dell are offering under the "hyperconverged" moniker. For example, Dell's Vxrail[0] appears (from marketing speak, anyway) to be a single rack with integrated networking and storage that you can ask to "just start a vm".
[0]: https://www.dell.com/en-us/dt/converged-infrastructure/vxrai...
Earlier quoted context omitted.
All the positions on the site currently are remote friendly. I work for Oxide remotely from the UK – you just need a reasonable overlap with PT, I overlap four hours most days.
I'm curious how that works with the one-salary policy.
Earlier quoted context omitted.
No, you will hear back. We're trying really hard to keep to the 6 weeks thing but sometimes we don't succeed.
I would think that startups would want to bias for people that can make good decisions quickly, within a short decision time. Perhaps hardware startups want more conservative employees? Also in my experience, a fabulous candidate is sometimes only available for a very short time window (they either have become available due to unforeseen circumstances, or they are snapped up by a faster mover). Is six weeks fast in y…
The places I'd like to work seem to move slower and require more preparation. For instance Oxide has applicants put together a lot of written work and another company has a seemingly easy take-home project but which requires unfamiliar (to me) setup that I haven't had time to tackle. Then there are the faang-style interviews with loops scheduled perhaps weeks in the future.
I may send another round of applications soon, but I'm going to be more selective so I can manage the process better.
Earlier quoted context omitted.
We run Triton and individual SmartOS boxes in production. They have pretty much replaced all of our VMWare and linux-based hypervisors save some very specific use cases, mostly relating to GPU passthrough and NVIDIA. The case with OpenZFS does worry me as well. I fear the developers start slowly introducing linuxisms thus sacrificing portability and stability for the great penguin.
We also run Triton on our public cloud @mnx.io I would love to hear more about the replacement of VMware experience and any other Triton details good/bad.
Generally there hasn't been anything game breaking and our biggest issues have been with running out of logging space for the core services (went with too low capacity disks in the beginning, doh) and one failed upgrade which didn't even take down the whole cluster during fixing. Our clients can now also provision their own VMs with the Triton API unlike with VMware which required admins to do it. Bhyve like KVM before has also been rock solid in everything we run from simple web servers to kubernetes clusters.
For issues we've found the Joyent/SmartOS IRC channels to be excellent and they have helped us tremendously in debugging and fixing things. It's the best support I've encountered for a FOSS product by far and one of the biggest reasons I'm such an illumos advocate now.
Earlier quoted context omitted.
This article is about technical details of the product that aren't user-facing. The business is fairly straightforward: we sell computers, a rack at a time. You as a customer can buy a rack, and put it in your data center. The rack offers an in-browser management console, built on top of an API you can use too. You use these tools to set up virtual machines. You can then use those VMs however you want. You get the cl…
> There are a lot of organizations who want hyperscale style servers but aren't going to start a division to begin making them themselves. How does this differ from what large players like Dell are offering under the "hyperconverged" moniker. For example, Dell's Vxrail[0] appears (from marketing speak, anyway) to be a single rack with integrated networking and storage that you can ask to "just start a vm". [0]: https…
"hyperconverged" is a term used by VMware to describe a virtualized all-in-one platform. You get compute, storage, and networking, all virtualized as one appliance rather than as individual ones. VxRail is basically Dell EMC's implementation of this idea: you get one of their servers, vSAN and vSphere all set up and ready to go.
"hyperscale infrastructure" describes an approach to designing servers to begin with. A lot of folks moved toward commodity hardware in the datacenter a decade or two ago. And then you get more and more of them. The hyperscale approach is kind of top-down as opposed to that bottom-up style: how would we design a data center, not just a server. Don't build one server and then stick thousands of them in a building; think about how to build a building full of servers. This is more of an adjective, like RESTful, rather than a standard, like HTTP 1.1. That being said, the Open Compute Project does exist, but I still think it's closer to a way of thinking about things than a spec.
Okay, so all of that is still a bit fuzzy. But it's enough background to start to compare and contrast, so hopefully it makes a bit more sense.
The first difference is the physical construction of the hardware itself. If you buy VxRail, you're still buying 1U or 2U at a time. With Oxide, you're buying an entire rack. The rack isn't built in such a way that you can just pull out a sled and shove it into another rack; the whole thing is built in a cohesive way. This means that not every organization will want to own Oxide; if you don't have a full rack of servers yet, you don't need something like we offer. But if you're big enough, there's advantages to designing for that scale from the start. This is also what I meant by there not being a place to buy these things; other vendors will sell you a rack, but it's made up of 1U or 2U servers, not designed as a cohesive whole, but as a collection of individual parts. The organizations that are doing it this way are building for themselves, and don't sell their hardware to other organizations. This is also one way in which, in a sense, Oxide and VxRail are similar: you're buying a full implementation of an idea from a vendor. Just the ideas are at different scales.
The other side would be software, which of course is tied into the hardware. With VxRail, you're getting the full suite of software from VMware. You may love that, you may hate it, but it's what you're getting. With Oxide, you're getting our own software stack, which the article is about the details of. You may love that, you may hate it, but it's what you're getting :). That being said, I haven't actually used a full enterprise implementation of the VMware stack, so I don't know to what degree you can mess with things, but our management software is built on top of an API that we offer to customers too, so you can build your own whatever on top of that if you'd like. Another thing here is that, well... the VMware stack is not open source. All our software will be. That may or may not matter to you.
The last bit about software though, is I think a bit more interesting: even though you are buying a full solution from Dell EMC, you're also sort of not. That is, Dell and VMware are two different organizations. Yes, part of what you're getting is that they say they have pre-tested everything in the factory to make sure it all works together well, but at the end of the day, it's still integrating two different organizations' (and probably more) software together. With Oxide, because we're building the whole thing, we can not only make sure things work well together, but really take responsibility for that. We can build deep integrations across the entire stack, and make sure that it not only works well, but is debug-able. Dell EMC isn't building the hypervisor and VMware isn't writing the firmware. Oxide is writing all of it. We think this really matters for both reliability and efficiency reasons.
So... yeah. That's a summary, even though it's already pretty long. Does that all help contextualize the two?
Earlier quoted context omitted.
I'm curious how that works with the one-salary policy.
Everyone is paid the same, regardless of location.
In the first case, you would bill something and get a salary out of it. If you bill x, a) your income is in dollars rather than local currency, which from experience is not great, b) you cost less to the company than US employees who cost x times k, c) you have to pay your own overhead before making it a salary. So if you bill x, your salary is less than x, and you still have to pay taxes on that salary.
If GEO or other similar arrangement, you're usually paid in local currency, presumably an amount corresponding to x at a given date, and that has extra overhead for the employer different from what a normal employee would cost.
Either way, "everyone is paid the same, regardless of location" doesn't clarify much. Thus my original question.
Earlier quoted context omitted.
Everyone is paid the same, regardless of location.
I won't claim to know how salaries work in the US, but from what I know in some other countries, there is an employer overhead to salary, so for a salary of x, the employer is actually lining up x times k, with k larger than 1. However, if you're not in the US, you're either an independent contractor or an employee in a GEO or something of the sort. In the first case, you would bill something and get a salary out of…
Currently we are using a remote hiring platform with local legal entities, so you'll get paid in local currency and receive local benefits. I'm based in the UK, I don't have the overhead of medical insurance, but the platform itself has costs and I'm not sure how much the costs of a UK employee compare to other countries.
But, we don't have many international employees, so the setup might change in the future or depending on the individual. When I first started, I briefly worked part-time as an independent contractor.