Live data from Hacker News

The Cloud Computer

oxide.computer

981–990 of 994 posts

Re: The Cloud Computer

#981
post #684
post #544

Earlier quoted context omitted.

When Apple supports OSX for consumers, they don't exactly surface the fact that there's BSD semi-hidden in there somewhere. That's because they own the whole stack, from CPU to GUI and support it as a unit. That's the benefit of having a product where a single owner builds and supports it as a whole. My impression of Oxide is that that's the level of single source of truth they are bringing to enterprise in-house clo…

Funny how you mentioning BSD got me to thinking of Sony Playstation and Nintendo Switch. Which are proprietary and not user serviceable. A Steam Deck, Fairphone, or Framework laptop is each less proprietary and more FOSS stack, and user serviceable. Which a user may or may not want to do themselves; at the very least they can pay someone and have them manage it. Also, Apple is just the one who survived. Previously I'…

IBM mainframe, they survive in specific category

Re: The Cloud Computer

#982
post #878

Earlier quoted context omitted.

Linux grew up in the bedrooms of teenagers. It was risky in the era of 486 and Pentiums. The environment and business criticality of a $1-2M rack-size computer is quite different.

It was totally a risky choice for companies in the 1990s and early 2000s to put all their web stuff onto Linux on commodity hardware instead of proprietary Unix or Windows servers. Many did it when their website being up was totally mission critical. Lots did it on huge server farms. It paid off very quickly but it's erasing history to suggest that it didn't require huge amounts of guts, savvy and agility to even att…

Indeed, for me GNU/Linux was always a cheap way to have UNIX at home, given that Windows NT POSIX support never was that great.

The first time I actually saw GNU/Linux powering something in production was in 2003, when I joined CERN and they were replacing their use of Solaris, and eventually alongside Fermilabs came up with Scientific Linux in 2004.

Later at Nokia, it took them until 2006 to consider Red-Hat Linux a serious alternative to their HP-UX infrastructure.

Re: The Cloud Computer

#983
post #89

Earlier quoted context omitted.

Similar in some ways different in others. But in terms of not being a PC architecture. Yes it is. But in many other ways its not at all like a Mainframe.

I’m not sure if “not PC architecture” is really an advantage for many customers.

Every PC has millions of lines of firmware code that often fails and causes problems. Case and point, pretty much all hyperscalers rip out all the traditional vender firmware and replace it with their own, often partially open source.

The BMC is often a huge problem, its a shifty architecture and extremely unsafe. Meta is paying for u-bmc development to have something a bit better.

Doing things like rack attestation of a whole racks worth of firmware if stacked PC is incredibly hard and so many companies simply don't do it. And doing it with the switch as well is even harder.

Sometimes the firmware runs during operations and takes over your computer causing strange bugs, see SMM. If there is a bug anywhere in that stack, there are 10 layers of closed source vendors that don't care about you.

Costumers don't care if its PC or not, but they do care if the machine is stable, the firmware is bug free and the computer is safe and not infected by viruses. Not being a PC enables that.

Re: The Cloud Computer

#984

Earlier quoted context omitted.

> ... code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. So, Humility is like MC/DC? https://en.wikipedia.org/wiki/Modified_condition/decision_co...

Humility is a debugger, not a code coverage tool.

I think 'throw-DO-178C' was being less literal than you are assuming here. Note that they quoted the comment about extremely high quality. What gives Hubris/Humility that level of quality?

When I see the concept of "extremely high quality" applied to software in the aerospace domain, I tend to think of methods like formal proofs and "semi-formal" methodologies like DO-178C (including MC/DC, not as a tool, but as a critical sub-process). It does appear that Humility adheres to some traditional ideas used in even "safety conscious", real-time embedded work:

> However, Hubris may be more interesting for what it doesn't have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. [1]

Oxide surely didn't invent all these concepts, we were applying some of this in the early '90s on human-safety-critical embedded projects, and they were most likely used before that. The attack surface eliminated is more than just security, e.g. even self-induced "attacks" from task priority inversion. Maybe the concept of applying them to rack mount servers is novel, but I have no experience there. Techniques like DO-178C go farther and do things like trace requirements to object code and strict coverage criteria.

When you are considering where Hubris/Humility might be applied in aerospace, also note that it would most likely be denied at the proposal stage of talking to a regulatory body like the FAA if you said, "The methodology for our brake controller is cloning a Github repo written by 100X S/W engineers in the Rust language, then modding that to fit." It's a process you have to follow in a documented fashion, from the start. Who knows--I certainly don't know everything--if you do have a identify reproducible process that improves S/W quality, the FAA might be interested.

And as far as eliminating debuggers goes, Boeing did actually do a joint academic/industry project on a zero-bug reduced (subset) Ada compiler (Zbra), which itself would be qualified as a tool instead of the more laborious process of mapping requirements to object code directly. [2]

In the spirit of humor shown on this topic, I would suggest considering a reduced subset of Rust called Iron. :) Regards, and best of luck!

[1] https://oxidecomputer.github.io/hubris/

[2] http://www.sigada.org/conf/sigada2002/SIGAda2002-CDROM/SIGAd...

Re: The Cloud Computer

#985

Earlier quoted context omitted.

100%. I’m actually extremely impressed. I want one. I haven’t worked in a data center in years, but I’d be tempted to do it again just to get my hands on one.

I wish they’d sell a tabletop version for hobbyists, but realize this is probably a distraction. But… the problem with a lot of these systems (including the old Sun boxes and things like ibm mainframes and the AS/400) is that they sound cool but there’s no real way for the typical new developer to “get into them” for fun and, as a result, you lose the chance for some developer selling it to their company based on his…

Apparently (I don't remember it, although I probably did read the Byte magazine at the time) there was a rumor in the early 1980s that IBM's PC was going to be a shrunken 370, called the 380. [1][2]

I wish IBM would shrink their LinuxONE Rockhopper 4 Rack Mount down to at least an "under the desktop" model. To my knowledge, IBM still makes quality products and has excellent customer service. They have fun names too (Rockhopper and Emperor are types of penguins!) and they even have 3D models of their rack mount cloud computers with shadows. [3] In fact, when I first read about Oxide a year or two ago, I searched for "IBM cloud server", and left it at that. So IBM, could you please send someone from the LinuxONE down to Boca Raton to create our new PC? :) Thanks!

P.S. I would even accept a shrunken 370. :)

[1] https://en.wikipedia.org/wiki/IBM_Personal_Computer

[2] https://archive.org/details/byte-magazine-1981-01/page/n313/...

[3] https://www.ibm.com/demos/it-infrastructure/ux/product.html#...

Re: The Cloud Computer

#986
post #559

Earlier quoted context omitted.

> It would be interesting to sell a data center in a container. Sun did that experiment: https://en.wikipedia.org/wiki/Sun_Modular_Datacenter

Yeah, I'm aware, but I didn't think they were serious about it.

That's entirely fair: Sun wasn't serious about most of the products they rolled out... and customers noticed.

Re: The Cloud Computer

#987
post #766

Earlier quoted context omitted.

If everyone had this mindset we would be running our workloads on Microsoft Windows by now. GNU/Linux was also "risky" at some point.

Linux grew up in the bedrooms of teenagers. It was risky in the era of 486 and Pentiums. The environment and business criticality of a $1-2M rack-size computer is quite different.

This is a skewed view - the critical piece that made Linux "enterprise-ish" was the memory management system that was contributed by IBM, part of the SCO lawsuit

Re: The Cloud Computer

#988
post #159

I always had a feeling that Bryan and people around kinda took the tech first approach and it never really came to a proper fruition. I think the ambition behind the engineering marvels they did over time was certainly bigger. Dtrace, Fishworks, Joyent, then this... so why is that? Perhaps the fierce refusal of joining the mainstream side (Linux)? Fingers crossed, but...

You've been downvoted to oblivion, but let me add a personal rebuttal for anyone else that finds themselves here: I don't agree at all about "not coming to proper fruition": DTrace was an absurdly outsized success by any metric; Fishworks was if anything too commercially successful (we did nearly $100M of business our first year!); Joyent represented a successful exit to Samsung, etc. I have been extraordinarily bles…

You can sleep well at night knowing you made Oracle a lot of money.

Re: The Cloud Computer

#989

Earlier quoted context omitted.

Then your salary is recalculated - it's something which is explained by default during the interview process (as it invariably comes up)

I am personally not a fan of this: early in my career, a colleague moved from the Bay Area to Boston to try to save his marriage (which sadly didn't work) -- and our employer adjusted his salary down accordingly. As you might imagine, the difference between the Bay Area and Boston is minimal -- they adjusted his salary down something like 4% -- but I just recall how dispiriting it was for him to have this massive, st…

Whilst I completely understand your viewpoint, I have a more nuanced take on it (understandably, as I work there). Firstly, we don't pay peanuts. We have never taken outside funding; it has always been a company goal to grow organically. As such, we don't have as much cash to go throwing around like VC-funded startups. However, as I said we still pay well; yes I could make more by taking a job in London (I'm in the UK), but then I sacrifice so many intangible things. Working remotely has allowed me to be present whilst my 18 month-old grows up, and a 4 day work-week has helped even more too. Unlimited holidays, very flexible working hours and being treated like an adult about how you organise them, a flat company structure, a company which genuinely cares about employees and their wellbeing - all of these things add up. Salary isn't everything. Whilst no job will ever be perfect, this company is by far the best place I have ever (and will likely ever) work. Employee satisfaction is always very high and salary is rarely even a factor (let alone the main reason) if people decide to move on.

Re: The Cloud Computer

#990

I'd like to add that their open source code is also EXTREMELY high quality. If you're an embedded developer go take a look at Hubris and Humility. I ended up using those to GREAT effect for this custom one-off aerospace device and it was a fantastic experience to integrate with. Definitely a change from what I was used to that took a bit of getting used to.

Is that the same extremely high-quality open-source code that currently has a failing build? https://github.com/oxidecomputer/hubris And, that one underscore-delimited folder name in this repo just catches the eye, huh? https://github.com/oxidecomputer/humility

With respect to Hubris, the build badge was, in turns out, pointing to a stale workflow. (That is, the build was succeeding, but the build badge was busted.) This comment has been immortalized in the fix.[0]

With respect to Humility, I am going to resist the temptation of pointing out why one of those directories has a different nomenclature with respect to its delimiter -- and just leave it at this: if you really want to find some filthy code in Humility, you can do much, much better than that!

[0] https://github.com/oxidecomputer/hubris/commit/651a9546b20ce...

Post reply on HN