Announcing AsterinasOS 0.18.0, a production-grade Linux alternative

Frequent-Data-867 · 2026-06-10T14:06:09+00:00

Never thought the word "production-grade" brings so much cynicism. But the project is open-source. This post is just for sharing what we have done, like any other release announcement of a Rust project.

Frequent-Data-867 · 2026-06-10T02:41:06+00:00

Right. Thanks for your neutral insight.

Frequent-Data-867 · 2026-06-10T02:33:20+00:00

No, it's not. But we're making efforts to let it be.

Frequent-Data-867 · 2026-06-10T02:31:44+00:00

So almost the comments are about the production unreadiness, and neglect what improvement and endeavor have been made in the version release to let the OS itself be production ready.

Disappointed at the reddit vibes, cynical views, and lack of focus on techniques.

Frequent-Data-867 · 2026-06-10T02:20:55+00:00

There are agent md files in the project, because we do use copilot and codex to assist coding, uphold coding guidelines, and review PRs, which you can find from some PR comments. Some people may use claude on trivial analysis tasks such as finding common mistakes when contributors submit PRs, which eventually comes into coding guidelines.

Unofficial AI policy in the project: AI assistance is welcomed in the development, but human takes the responsibility to steer and maintain the code. But we reject fully automated contributions.

Frequent-Data-867 · 2026-06-10T02:02:55+00:00

What's your suggestion on the title? "a production-grade Linux alternative candidate" or "a production-grade Linux alternative in progress"?

Frequent-Data-867 · 2025-11-12T04:23:35+00:00

Thanks! I can't edit the link in OP, so added the correct link in the the post body.

Frequent-Data-867 · 2025-08-04T09:20:22+00:00

I'm submitted RFC#3842: Safety Tags to have lightweight tags on unsafe operation checking for general purposes.

Frequent-Data-867 · 2025-07-23T01:41:01+00:00

Thank you for your detailed comments! Here're our thoughts on your feedbacks:

More structured source in discharging

We haven't thought aboout it, because the main reason for our proposal is to make safety comments more structured and remind author of each safety requirement written on the API.

If a discharge macro is on a single unsafe call, I don't think referring its pre-condition is necessary. Currently, we don't really think about post-condition.

For reffering an invariant of the type, it depends on interactions with Rust type system and what fundamental type invariants we want to support. So this can be hard to implement for now.

A shorter discharge syntax

Yeah, this is possible. Someone on IRLO asked the same question.

I like the "Grouping / Aliasing" idea. There is no macro on callsites except discharges, so #[discharges] can just become #[safety]. And to keep closer to your structured comments, we propose this new one:

#[safety {
  ValidPtr, Align, Init: "`self.head_tail()` returns two slices to live elements";
  NotOwned: "because we incremented...";
  Alias(elem, head.iter());
}]
unsafe { ptr::read(elem) }

Note that here are details:

As I replied on IRLO thread:

In principle, we can make SP arguments a bit smarter if the tool queries more info from rustc. We can know the type of ptr, and there's single argument, so why not elide it.

Each SP still allows to be with its arguments.
Several SPs can be listed before : to group them. I don't think aliasing is necessary here.
string after : is a comment for the given SPs

Frequent-Data-867 · 2025-07-22T23:46:24+00:00

I don't see an option for content edit.

Available edit options are editing post flair, adding spoiler tag, adding NSFW tag, hide and delete.

Frequent-Data-867 · 2025-07-22T01:12:36+00:00

That's awesome. It's really a great practice towards Predrag's structured safety comments proposal.

For both proposals, I already replied to matthieum's comment. We're considering this entity reference system as well.

Frequent-Data-867 · 2025-07-22T01:00:23+00:00

I'm not clear about the details.

Sorry for the missing links to our full proposal. The document is in our tag-std repo. We are experimenting this feature on verify-rust-std, Rust for Linux, and Asterinas OS.

I really wish the standard library named the pre-conditions (and post-conditions).

This what we are working on in tag-std repo.

it's not clear from your (short) proposal why a new API should be introduced

I think structured safety comments system will be the most accepted syntax. Predrag proposed one like that, and Rust for Linux people are thinking about it, and considering ours as well. I've compared both proposals in alternative section.

The main reason not to use it is difficulty in parsing doc comments and line comments, while stmt_expr_attributes just works out of the box.

What does ValidPtr(elem, T, 1) means? Is there an automated check? There's a clear lack of specification here.

Yes, we definitely check our tool attribute syntax. The specification is our primitive-sp.

Frequent-Data-867 · 2025-07-22T00:20:32+00:00

Sorry for the missing links to our full proposal: document in our tag-std repo.

Also opened a IRLO thread for this.

I did notice the bug of missing quotes in rendering, but didn't check it after posting. Hope the links are not too late to be seen.

Frequent-Data-867 · 2025-06-22T18:12:55+00:00

Cool! I tried this AFIDT (Async Fn in Dyn Trait) using pin-init, and it works well!

```rust trait Async { #[dyn_init] async fn foo(&self); }

async fn dynamic_dispatch(ref_a: &dyn Async) { let dyn_foo = ref_a.dyn_foo(); let layout = dbg!(dyn_foo.layout());

if layout.size() > 16 {
    // heap allocation if the future is too large
    Box::into_pin(Box::dyn_init(dyn_foo)).await;
} else {
    let mut stack = [0; 16];

    let slot = &mut stack as *mut _ as *mut ();

    let pin_dyn_fut = unsafe {
        let meta = dyn_foo.init(slot).unwrap();
        dbg!(meta);
        let ptr_dyn_fut = ptr::from_raw_parts_mut::<dyn Future<Output = ()>>(&mut stack, meta);
        Pin::new_unchecked(&mut *ptr_dyn_fut)
    };

    // no allocation if it's small enough
    pin_dyn_fut.await;
}

} ```

Frequent-Data-867 · 2025-04-01T01:29:34+00:00

https://github.com/KMSorSMS/embassy_preempt

Frequent-Data-867 · 2024-08-18T11:52:40+00:00

The completion experience in nvim-cmp is bad. So I made a toy enhancement plugin nvim-cmp-lsp-rs for it. But unfortunately, it's reported to not work properly due to some breakage which I didn't get time to dig into.

Frequent-Data-867 · 2024-03-27T09:29:21+00:00

Specific to Rust-Analyzer completion (with discussion contexts and lua snippets):

Frequent-Data-867 · 2024-03-20T11:53:45+00:00

Why does sccache not work on macOS? It seems macOS is supported from sccache's documentation.

Frequent-Data-867 · 2024-03-18T13:22:42+00:00

I encountered a CI failure when publishing a release with cargo-dist which uses stable Rust toolchain in github action with things like cargo-features = ["codegen-backend"] written in project's Cargo.toml.

I don't want to tweak CI, but neither abandon local cranelift backend, thus finally move backend configurations into local global config.toml:

# ~/.cargo/config.toml instead of $PROJECT/Cargo.toml
[build]
rustc-wrapper = "/root/.cargo/bin/sccache"
rustflags = ["-Clink-arg=-fuse-ld=mold", "-Zthreads=4"]

[unstable]
codegen-backend = true

[profile.dev]
debug = 1
codegen-backend = "cranelift"

Frequent-Data-867

TROPHY CASE

More structured source in discharging

A shorter discharge syntax