ahl

available here https://share.transistor.fm/s/e2538f7d

Uprobes has—I believe—DTrace USDT-like functionality. This seems interesting and different: sending the tracing facility into the traced/victim process. Whereas DTrace and ePBF typically trap into the kernel to execute and event, this approach allows for potentially much less overhead.

How important is enabled probe effect? Of that I’m less sure.

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

It’s wild that we built it with 60 people!

It won't. In the same way that AWS customers aren't debugging hypervisor, or Dell customers aren't debugging the BIOS, or Samsung SSD customers aren't debugging the firmware. Products choose where to draw the line between customer-serviceable parts and those that require a support call. In this case, expect Oxide to fix it when something doesn't work right.

Much appreciated!

Do we think it would be possible to replace the real Bryan Cantrill with this? Asking for several friends.

I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.

Some of the OpenTF team joined us on Oxide and Friends to talk about the project. It was a great conversation:

https://oxide-and-friends.transistor.fm/episodes/fork-in-the...

Clearly we need to do much more self-promotion!

Your point is well-made: the status quo is safe! Introducing any new product into an organization takes both a recognition of pain and some courage. In the case of Oxide, the pain is apparent: extant systems are expensive, vendors gaslight and squabble when issues arise, these heterogeneous solutions are surprisingly brittle. This is true even when dealing with what is ostensibly the same company! Try getting Dell, VMware, and EMC to agree whether a problem is due to the server, hypervisor or SAN!

In addition, app teams (i.e. the folks who deliver revenue to the business) are more productive on public cloud. They don't file tickets, they make VMs. Oxide is intended to bring the hardware, software, and interface innovations of the cloud into enterprise data centers with greater reliability and lower TCO.

... but with more inner beauty.

That episode was a bunch of work—glad to hear that it was beneficial! And, yes, YouTube is just convenient for posting recordings. We added the podcast in early 2022. There’s usually a delay between YouTube and the podcast in the hope that we get some show notes submissions (and to shake out the occasional audio screw up).

Open offer for Oxide and Friends stickers for anyone dropping a PR: https://mastodon.social/@ahl/109598726893101647

OpenAPI can be used to describe the vast majority of extant APIs in the wild today. It was build to describe APIs. AsyncAPI, like GraphQL, imagines a new ecosystem. This article constructs straw man arguments against OpenAPI without making a particularly concrete case for AsyncAPI.

Unfortunately I've been completely out of the loop on the draid stuff.

You mean the total lack of comments didn't help? ;-)

SPARC has two attributes (I hesitate to call them features) that this code interacts with: register windows and a delay slot. Register windows are a neat idea that leads to some challenging pathologies, but in short: the CPU has a bunch of registers, say 64, only 24 of which are visible at any moment. There are three classes of windowed registers: %iN (inputs), %lN (local), %oN (output). When you SAVE in a function preamble, the register windows rotate such that the callers %os become your %is and you get a new set of %ls and %os. There are also 8 %gN (global) registers. Problems? There's a fixed number of registers so a bunch of them effectively go to waste; also spilling and filling windows can lead to odd pathologies. The other attribute is the delay slot which simply means that in addition to a %pc you have an %npc (next program counter) and the instruction after a control flow instruction (e.g. branch, jmp, call) is also executed (usually, although branches may "annul" the slot).

This code is in DTrace where we want to know the value of parameters from elsewhere in the stack, but don't want to incur the penalty of a register window flush (i.e. writing all the registers to memory). This code reaches into the register windows to pluck out a particular value. It turns out that for very similar use cases, Bryan Cantrill and I devised the same mechanism completely independently in two unrelated areas of DTrace.

How's it work?

We rotate to the correct register window (note that this instruction is in the delay slot just for swag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...

Then we jmp to %g3 which is an index into the table of instructions below (depending on the register we wanted to snag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...

The subsequent instruction is a branch always (ba) to the next instruction. So:

%pc is the jmp and %npc is the ba. The jmp sets %npc to an instruction in dtrace_getreg_win_table and %pc is the old %npc thus points to the ba. The ba sets %npc to be the label 3f (the wrpr) and %pc is set to the old %npc, the instruction in the table. Finally the particular mov instruction from the table is executed and %pc is set to the old %npc at label 3f.

Why do it this way? Mostly because it was neat. This isn't particularly performance critical code; a big switch statement would probably have worked fine. In the Solaris kernel group I remember talking about interesting constructions like this a bit around the lunch table which is probably why Bryan and I both thought this would be a cool solution.

I'm not aware of another instance of instruction picking in the illumos code base (although the DTrace user-mode tracing does make use of the %pc/%npc split in some cases).

I have a uniquely soft spot for SPARC, having written and disassembled a bunch of SPARC early in my career. If this is its swan song, I'll take the moment to share some code the takes advantage of the odd (today) delay slot architecture to implement instruction picking:

https://github.com/illumos/illumos-gate/blob/master/usr/src/...

The trick uses a branch in the delay slot of a jmp--a decidedly unusual construction. At the time I found this to be extremely clever and elegant... but apparently not so clever as to warrant a comment.

What is the latest on RAID-5/6 support for BTRFS. RAID-Z has its issues (saying this as the triple- and double-parity author), but it's been stable.

@dlurton since you seem to be speaking for the PartiQL team on this (congrats on the launch!): The reference implementation is open source; what's the plan for the language spec? Is that something that AWS is going to own and control? The website references the PartiQL Steering Committee -- is that just AWS folks or is the intention to make it more broadly composed of members of the community you build?

I'm interested in adopting PartiQL for our product, but would we get to participate in the evolution of the language or would we purely be downstream of the decisions made to benefit AWS products and services?

Really cool project, @wing328hk. Congrats on the new release.

I'm Tina's (the author) co-founder at Transposit; happy to answer any questions about what we've built!

Biased, but also extremely excited for this. What catches our collective attention are systems we hate, systems that suck, systems that fail--or systems too new to know. It's refreshing to consider systems established and clever enough to love. There are wheels we don't need to reinvent, systems that can teach us.

The author (me) isn't a Rust expert, but has played with it a bit. Rust, I think, suffers from a lack of empathy with a novice audience. I'm a big fan of Rust and I think it introduces some novel, valuable, and fascinating new concepts. It should be taught in every CS program alongside procedural, OOP, and functional programming.

Once you understand the paradigms, Rust error messages make sense. It's like the folks who describe git by starting with a exposition on merkel trees: technically precise, but incomprehensible if you only know cvs.

FWIW this is the project that pulled me down this golang rabbit hole: https://news.ycombinator.com/item?id=12211754

Engineers who have worked on HFS+ believe that it actually is losing data left and right. I'm inclined to believe that they're right and that most people simply don't notice.

That use of multiple partitions I think qualifies as uncommon which is not to suggest that it's not useful.

The author (me) isn't dismissive; he's skeptical. Siracusa did a great job of upbeat, critical, accurate reviews. Conversely, the coverage of APFS has been inane. A video, a PDF, and some high level docs were shuffled and reworded; that's not a review. Tech journalists live in a tough world where the details are obscure and hard to evaluate with deadlines that are becoming ever shorter and a reward system that values views over depth. My skepticism was meant to counterbalance the fluffy, fawning tone of what I had seen.

I stood around with Giampaolo, Tamura, and other Apple folks. I had a significant leg up on journalists; I know the subject well and the Apple folks know and respect me based on technology I've worked on. (And they didn't kick me out when I revealed that I didn't actually have a conference pass). I knew (some of) the questions to ask, and they were remarkably open with their answers.

Also: https://twitter.com/ahl/status/747074195192832001

COW is great. It has applicability around on-disk consisteny, and it makes snapshots much more coherent. It's also not without downsides such as fragmentation--though that's far far less important on SSDs than HDDs. Apple's fast file copy mechanism also uses COW. I would suggest that it's an instance of listening to what your customers say rather than providing them what they need. They say file copies are too slow, but what they really want is a way to track versions, retain old ones, etc. It would be cool if Apple built on their existing approach with regard to file versioning.

I'm inclined to agree that 3 years to squeeze out a perfect file system is ambitious to say the best. That said, consider the robustness of HFS+; APFS is blessed with desperate, captive users.