Hey Steve, I read your recent blogpost on the ERSC site - have you or David (or anyone else at ERSC) felt like there's a Rusty-enough topic around what your startup is doing to give a talk at Rust NYC/Rust conference soon?

There's not really a VCS meetup in NYC, but I got to hear David and others at Rust NYC wax eloquent about Sapling vs Piper and Buck vs Bazel a couple of times, so I think the audience is there!

Rust NYC is certainly one of the things I have missed since moving to Austin :)

Maybe, we'll see. I think one thing that's tricky these days with startups is that being super transparent technically about what you're up to is much harder to justify. Look what happened with Origin: tobi vibed up a copy over the weekend after it was announced. Obviously there's balance to be found here, but that's partially why we play our cards a little closer to our chest.

I've used Photopea for small editing before, and even though it's not my daily driver, it's a really cool project.

The "peer review" comment in the original seems particularly bizarre given the errors https://en.wikipedia.org/wiki/Scholarly_peer_review

This post by Marc Brooker on (meta-)stability might be a fun and explanatory read: https://brooker.co.za/blog/2021/05/24/metastable.html

Murat is also an amazing writer and distsys researcher, so basically anything he writes about I find interesting.

Oh, very interesting. I've ran into problems like this in queuing systems and had no idea that this is what they were called.

Going in and just dumping the queues can solve it, but can be tricky depending on the complexity of the system.

Is there anything I can read about the fixes to make it more stable? Or just a place to check out recent developments?

At the moment, no. Beyond just fixing problems I've found, for the last year I've been doing a lot of haphazard development inside of Sprite itself, so "fixes to bugs in released Sprite" are intermingled with "features I've added". The bigger problem is that getting data in/out of Sprite is ... harder than you'd imagine.

I am hoping to make a big writeup "soon", since there's a lot of interesting information about Sprite that's mostly been lost to time, where Sprite is mostly remembered as having "process migration" and "LFS". Meanwhile, it's mostly forgotten that Sprite was (apparently) one of the first OSes to adopt a mostly-GNU userland, had a modern event-loop style abstraction in C for handling I/O and timers (Fs_Dispatch), had a userspace filesystem abstraction akin to FUSE (PFS), implemented a PTY-like system entirely in userspace (the Td* functions in libc), and overcommitted memory by default.

That would be very interesting to read, other systems like Plan 9 get talked about a lot but I didn't know almost anything about Sprite until today.

It's the first book I read about computer history and made me interested in tech, a career I love doing every day :) this talk made me very happy.

I loaded credits into Tinfoil the other day and have had zero issues, thanks to smart folks around here and the security space recommending it.

It's now my open weight inference provider of choice, since on top of the privacy/security characteristics it's also reasonably cheap.

I think so. Maybe dang or tomhow could switch the link :)

The social rules work so well that I wish tech cos would just adopt these as baseline. They make interacting with other technical folks much more enjoyable.

@dang, I'm not sure what's changed with the Show HN lately, but it's been much more lovely to read. Thank you for whatever changes which were made.

I'm glad to hear you liked the post!

Looking at https://news.ycombinator.com/show , it's definitely no longer a raw feed of show HN: from /new.

It's not clear what the change is, whether it is curation by hand or some other metrics, but it's a positive change, the old Show HN was getting flooded, as recently discussed. ( Although I can't work out how to find that discussion. )

Huge and positive change from the old “Show HN: Another vibe coded filesystem that I won’t even use but it was done with an LLM!”

I suppose the main thing so far is https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu.... The hope is to be welcoming to new users while also nudging them toward the intended use of the site. I don't know how well this is going to work over time so your comment is encouraging!

Another anecdatum: it definitely seems better to me in the last few days.

Thanks again to you and tomhow for all your stellar work on keeping the site as close to its original intent as practical these days

Where do you think my confusion came from? All it says is that ai assists in resolving the gyroscope lock path, not why they decided to model the gyroscope lock path to begin with.

Please, keep your offensive comments to yourself when a clarifying comment might have sufficed.

Even worse, the other child comments are speculating (and didn't RTFA either) when the answer is clear in the article.

> We found this defect by distilling a behavioural specification of the IMU subsystem using Allium, an AI-native behavioural specification language.

That's the opposite of clear to me.

Has the article been updated?

2nd paragraph starts with: "We used Claude and Allium"

And later on: "With that obligation written down, Claude traced every path that runs after gyros_busy is set to true"

This is the original article text. It just looks like users skimmed and then flamed the author.

> distilling

A.k.a. as fabricating. No wonder they chose to use "AI".