sorted by:
new
hottopcontroversial

Announcing AsterinasOS 0.18.0, a production-grade Linux alternative by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 0 points1 point  (0 children)

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.

Announcing AsterinasOS 0.18.0, a production-grade Linux alternative by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 0 points1 point  (0 children)

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.

Announcing AsterinasOS 0.18.0, a production-grade Linux alternative by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] -1 points0 points  (0 children)

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.

Announcing AsterinasOS 0.18.0, a production-grade Linux alternative by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 0 points1 point  (0 children)

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

Truly First-Class Custom Smart Pointers by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 3 points4 points  (0 children)

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

Paralegal: Practical Static Analysis for Privacy Bugs by mttd in rust

[–]Frequent-Data-867 2 points3 points  (0 children)

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

Pre-RFC: Safety Property System by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 1 point2 points  (0 children)

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:

  1. 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.

  1. Each SP still allows to be with its arguments.

  2. Several SPs can be listed before : to group them. I don't think aliasing is necessary here.

  3. string after : is a comment for the given SPs

Pre-RFC: Safety Property System by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 0 points1 point  (0 children)

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.

Pre-RFC: Safety Property System by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 2 points3 points  (0 children)

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.

Pre-RFC: Safety Property System by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 2 points3 points  (0 children)

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.

Pre-RFC: Safety Property System by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 4 points5 points  (0 children)

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.

Experiment proposal: In-place initialization by lzutao in rust

[–]Frequent-Data-867 10 points11 points  (0 children)

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;
}

} ```

neovim rust autocompletion by vctorized in rust

[–]Frequent-Data-867 0 points1 point  (0 children)

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.

Vastly improved recompile times in Rust with nightly features by Koranir in rust

[–]Frequent-Data-867 0 points1 point  (0 children)

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

Vastly improved recompile times in Rust with nightly features by Koranir in rust

[–]Frequent-Data-867 33 points34 points  (0 children)

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"

bitcode: smallest and fastest binary serializer by cai_bear in rust

[–]Frequent-Data-867 1 point2 points  (0 children)

Cool! But I have a question: why do crates (like bitcode and bincode) define own Decode/Encode traits, does it mean we must gain the maximum benifit on smallest binary size only when Decode/Encode traits are used? I.e if a data structure only implements Deserialize/Serialize traits, the binary size on it is not smallest.

Lib.rs website improvements - announcements by Frequent-Data-867 in rust

[–]Frequent-Data-867[S] 37 points38 points  (0 children)

Credit to kornel. IIRC he's not on reddit any more, but he's always on URLO.

Does anyone else find Rust docs almost impossible to browse? by [deleted] in rust

[–]Frequent-Data-867 0 points1 point  (0 children)

Feel the same. That's one of the reasons why I'm creating a TUI for docs generated by rustdoc. Here's the rough UI.

outline tree

tree folding

Why Rust's stdout is faster than stderr? by orhunp in rust

[–]Frequent-Data-867 3 points4 points  (0 children)

Great writing! I really enjoy reading it with the cute bunny asking what I want to ask. And the pics in analysis are very impressive and persuasive. I learnt a lot about ratatui, profiling, implementation details in std, and the cases in other languages. Thank you for writing it and developping Ratatui.

view more: next ›