I would second the black bar for Kidder -- The Soul of a New Machine constitutes the literary foundation of our craft: it is our Odyssey. Speaking personally, I have spoken and written about Soul many times ([0][1][2]) -- and I know that its impact from me is far from unique.
RIP Tracy Kidder -- and thank you for giving us all permission to feel passion for the machine.
There's a lot of confusion here about the way VC operates (or companies, for that matter), but just to clarify one point: an IPO is not an "exit" -- it is a public offering. That is, an Oxide IPO, were we to be so lucky, would be a milestone towards being the generational company that we aspire to be.
Well, a couple of things. First, the Jonathan Blow episode[0] was over six years ago. Second, it was nearly a three hour conversation -- I don't think I can be accused of not letting him talk? Third, I definitely remember that I felt I had to interrupt him to move the conversation along. Fourth, I had to pee really badly, I was absolutely freezing, and I was quite concerned about missing my flight to New Zealand that evening with my family for Christmas (which I damned near did) -- and I have no doubt that I was not at my best!
I do try to get better at this stuff, and I re-listen to our episodes to improve as an interviewer. If it's been "a few years", maybe you haven't listen too much to Oxide and Friends? I think we've had some wonderful guests and great conversations over the span of the podcast -- though I also have no doubt that it's imperfect, for which you have my profound apologies!
I appreciate the reply and that it's been a while; I will give your podcast another listen.
It wasn't just the Jonathon Blow episode; that was just the point where I said "this is frustrating." For what it's worth, frustration came from knowing that this could be really good: your perspective is valuable, your topics were interesting, and your guests were excellent.
I find this a common mistake that people with strong opinions have when doing interview/guest style podcasts or shows. There's really an art to it; it's not easy to engage guests, keep the show interesting, and let the talk move in interesting ways. That's why Terry Gross and Howard Stern, in very different ways, have had such long and storied careers.
But it's something that people definitely get better at, and I have no doubt that you have. Again, I'll give it another listen.
Is this only based on On the Metal? (If so, those are all from six years ago -- even the ones that were released a mere five years ago.) Please do check out Oxide and Friends[0] -- and feedback always welcome!
These sort of transparent answers are what make oxide and the people behind it such a fantastic company. Thank you for your wonderful contributions to the software and hardware community!
Ha ha -- there are definitely voices that I know I have been implicitly inspired by over the years, but I can safely say that Chad the Bird is new to me! I'm enjoying listening to some of Chad the Bird's work now; my apologies in advance if it rubs off on me!
I meant it in a very positive way. Chad rocks! And so do you and the 0xide team -- what you guys are building is amazing to watch from the sidelines and I wish you and the team great success.
You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to be fair, of interest to you): postmortem debuggability, service management, fault management, etc. These things don't matter to you, but they matter to us quite a bit -- and they are absolutely meaty topics.
Now, in your defense, an update on RFD 26 is likely merited: the document itself is five years old, and in the interim we built the whole thing, shipped to customers, are supporting it, etc. In short, we have learned a lot and it merits elucidating it. Of course, given the non-attention you gave to the document, it's unlikely you would read any update either, so let me give you the tl;dr: in addition to the motivation outlined in RFD 26, there are quite a few reasons -- meaty ones! -- that we didn't anticipate that give us even greater resolve in the decision that we made.
I did indeed read your document (twice, as I explicitly reported). I didn't address those parts because I found them better-supported. Instead, I addressed the parts I found confusing, and since your rebuttal here is just whining about what you think my behavior is, I continue to be mystified. That's okay; nobody expects you to explain yourself to me. If I thought it would help, I would suggest that perhaps a more effective defense would involve answering literally any of the questions I already asked. However, I don't appreciate accusations of bad faith based on your unwarranted assumptions about what I did or did not do and, bizarrely, what you imagine my motivations are. I'll just assume that the answers to the "why" questions I asked are rooted in similar wild-ass speculation.
There is a reasonable explanation for the "foregone conclusion" flavour of the RFD that doesn't cast aspersions (quite as much as you are) on the authors:
It is simultaneously an assertion of the culturally determined preferences of a group of people steeped in Sun Microsystems engineering culture (and Joyent trauma?), and a clinical assessment of the technology. The key is that technology options are evaluated against values of that culture (hence the outcome seems predictable).
For example, if you value safety over performance, you'll prioritise the safety of the DTrace interpreter over "performance at all costs" JIT of eBPF. This and many other value judgements form the "meat" of the document.
The ultimate judge is the market. Does open firmware written in Rust result in higher CSAT? This is one of the many bets Oxide is making.
Frankly, I don't think Oxide would capture so much interest among technical folks if it was just the combination of bcantrill fandom + radically open engineering. The constant stream of non-conformist/NIH technology bets is why everyone is gripping their popcorn. I get to shout "Ooooooh, nooo! Tofino is a mistake!" into my podcast app, while I'm feeding the dog, and that makes my life just a little bit richer.
i'm not sure if Dtrace interpreter was safer than EBPF. I guess in theory it should be because a JIT is just extra surface area but I'm not sure in practice. Both EBPF and DTrace had bugs. Also, I always thought EBPF JIT was just a translation to machine code and it didn't do any kind of optimization pass so should be very similar to how DTrace works. They both ship byte code to the kernel. But I guess the big difference is EBPF relies more on a verification pass while I think most of DTrace safety verification was performed while executing the bytecode. I remember there was a lot of stuff in EBPF where the verifier was meant to be able statically determine you were only accessing memory you were able to. I think there was a lot of bugs around this because the verifier would assume slightly different behaviour than what the runtime was producing. But this is also not necessarily a JIT problem you could have an interpreter that relied on a static safety pass as well.
...but your top post didn't ask any questions; certainly not ones that would justify a detailed answer.
It was several assertions, plus your admission of confusion. I mean, there are no stupid questions, but there wasn't even a question there, so I don't blame anyone for thinking you're communicating poorly.
I wasn't accused of communicating poorly. I was accused of lying about reading a text file and having some kind of ulterior motive for my own opinions.
Furthermore, advanced readers are generally able to infer from "I am not sure why x" that a similar flow of discussion might be as feasible as if it were phrased "why x?".
As though that were necessary. There's plenty of room in this comment box for questions better fleshed out than "why x?". Are you expecting advanced readers, or clairvoyant ones?
One point of clarification: the C version does not have (and never had) a hash table; the C version had a BST (an AVL tree). Moreover, the "Rust hash table implementation" is in fact still B-tree based; the hash table described in the post is a much more nuanced implementation detail. The hash table implementation has really nothing to do with the C/Rust delta -- which is entirely a BST/B-tree delta. As I described in the post, implementing a B-tree in C is arduous -- and implementing a B-tree in C as a library would be absolutely brutal (because a B-tree relies on moving data). As I said in the piece, the memory safety of Rust is very much affecting performance here: it allows for the much more efficient data structure implementation.
I wouldn't consider implementing a B-tree in C any more "arduous" than implementing any other notable container/algorithm in C, nor would making a library be "brutal" as moving data really isn't an issue. Libraries are available if you need them.
Quite frankly, writing the same in Rust seems far, far more "arduous", and you'd only realistically be writing something using BTreeMap because someone else did the work for you.
However, being right there in std makes use much easier than searching around for an equivalent library to pull into your C codebase. That's the benefit.
I don't often do this, but I'm sorry, you don't know what you're talking about. If you bother to try looking for B-tree libraries in C, you will quickly find that they are either (1) the equivalent of undergraduate projects that are not used in production systems or (2) woven pretty deeply into a database implementation. This is because the memory model of C makes a B-tree library nasty: it will either be low performance or a very complicated interface -- and it is because moving data is emphatically an issue.
Yes, the point I was making (and as you point out, have been making for the last quarter century) is that we err when not making this realization -- and indeed, I think the linked piece is exactly backwards because it doesn't understand this. That is, the piece views a world of LLM-authored/-assisted software as "industrialized" when I view it as the opposite of this: because software costs nothing to replicate (because the blueprints are the machine!), pre-LLM ("handcrafted") software is already tautologically industrialized. Lowering the barrier to entry of software with LLMs serves to allow for more bespoke software -- and it is, if anything, a kind of machine-assisted de-industrialization of software.
> Lowering the barrier to entry of software with LLMs serves to allow for more bespoke software -- and it is, if anything, a kind of machine-assisted de-industrialization of software.
Instead of people downloading / purchasing the same bits for a particular piece of software which is cookie cutter like a two-piece from Men's Suite Warehouse, we can ask LLM for custom bit of code: everyone getting a garment from Savile Row.
Appreciate the love, but I think you are drawing the wrong conclusion here: Sun failed to endure not because it loved its customers, but to the contrary because it lost track of them: the company was disinterested in the mechanics of running a business.[0]
As for Oracle and its putative endurance, I would liken it to the Berlin Wall: despite the seeming permanence, it is in fact an artifact that history will be eager to forget when given the opportunity.
Per above, it seems like Sun had a core architectural, technical, and engineering failure with SPARC failing to keep pace with x86, and a business failure dealing with the fallout:
> x86 boxes were starting to smoke the hell out of UltraSPARC.)
> we spent too much time trying to help save microprocessor management from an unmitigated disaster of their own creation (UltraSPARC-III, cruelly code named "Cheetah"
In contrast, HP mostly (though it eventually split into two companies) managed to survive Itanium and compete with Dell. IBM continued to evolve Power and its other architectures and still sells AIX as well as Linux systems. Cray still exists as part of HPE. Apple migrated from PowerPC to x86 before hitting a home run with their own version of ARM.
In an alternate timeline, I imagine Sun still existing as an independent company and being the leader in RISC-V systems. But I guess Oxide is something of a successor?
If Sun couldn't design a good SPARC processor then they couldn't design a good RISC-V processor either. x86 was really their only hope but they didn't succeed there either, maybe because of the same old over-engineering.
Well, RISC-V is likely easier to implement efficiently than SPARC (no register windows, etc.) and has many of the same RISC-derived advantages.
Sun had some very smart people (what is Marc Tremblay doing at Microsoft btw?), and they could also have acquired more of them, perhaps like Apple acquiring PA Semi or Qualcomm acquiring Nuvia.
Also I wonder what might have happened if OpenSPARC had happened earlier, been more open, etc. (Indeed, a main reason why RISC-V exists is that there were IP issues with other architectures.)
Given how Fujitsu was able to make competitive SPPARC64 models for Oracle, it was unlikely to be an ISA issue, and more a design and manufacturing issue....
> As for Oracle and its putative endurance, I would liken it to the Berlin Wall: despite the seeming permanence, it is in fact an artifact that history will be eager to forget when given the opportunity.
Sparkling wine bottles are sometimes popped when the last installation of Oracle gets retired in an organization.
RIP Tracy Kidder -- and thank you for giving us all permission to feel passion for the machine.
[0] https://speakerdeck.com/bcantrill/oral-tradition-in-software...
[1] https://bcantrill.dtrace.org/2019/02/10/reflecting-on-the-so...
[2] https://bcantrill.dtrace.org/2019/12/02/the-soul-of-a-new-co...
reply