openQA VS min-sized-rust

I use Tumbleweed since years and although rolling, its more stable than Pop ever was for me. Stable in the sense of daily use and upgrading in particular. Every update you get on OpenSuse is, as a TLDR version of an explanation, run through an automated AI process that checks if everything works, only then the update is pushed out. The AI analyzes pictures of the OS to check. For example, it goes through the boot process and sees if it works, then clicks on certain apps like yast and see if they open, comparing whats shown on screen with a reference picture. You can see whats currently going on in terms of testing here.

For development, I really like Arch Linux because of the freedom and AUR¹, for gaming, I prefer openSUSE because of the rock solid performance and reliability out-of-the-box, and their automated QA platform helps to ensure new updates don't break the system, so, sometimes, openSUSE delivers the latest package first (while Arch Linux waits for the first patch version).

Yes it does, my Tumbleweed installation already got 6.0, but most of Tumbleweed testing is fully automated so they have some advantage there, even though I did not expected openSUSE to have a more up-to-date kernel.

for gaming I would use tumbleweed (rolling release) version as then you will get latest stuff (but unlike on Arch (-based), so its more tested / stable thanks to openQA and obs)

Yes, openQA is also use for Tumbleweed as well.

openSUSE Tumbleweed already does all of that using Zypper, openQA and Snapper respectively.

The daily Tumbleweed snapshots are tested in openQA

openSUSE Tumbleweed follows a rolling-release model. A new "version" is automatically tested (with openQA) and released every few days. Security updates are distributed as part of regular package updates (except in emergencies). Any package can be updated at any time, and new features are introduced as soon as the distro maintainers think they are ready. The user experience can change due to these updates, though we try to avoid breaking things without providing an upgrade path and some notice (usually on the Factory mailing list).

This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust

This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind...

The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded development it’s definitely important, but for most use cases, does it matter?

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30

Are you saying that at that point the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every resulting binary.

I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't rake Rust seriously because of that. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berate and ignore Rust on that basis alone (so the author is quite right to call this out as a factor).

Looking at the https://github.com/johnthagen/min-sized-rust repo, final binary size of 51 KB when compilation / linking / stripping takes stdlib into account (and not just blindly copy-pasting the 4MB binary blob) is acceptable and much more reasonable. I wouldn't care for further micro-optimizations e.g. going to 20KB or even 5KB (further down the README file).

I also don't use nightly in my Rust work so I guess I'll have to wait several more years. :(

My go to reference when I want to reduce rust binary size is the excellent https://github.com/johnthagen/min-sized-rust, a set of guidelines on how to reduce size with explanations of the consequences

Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust. By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.

This is not quite what you're asking, but it does also address the underlying concern: https://github.com/johnthagen/min-sized-rust

And what about the binary size? Applying some cheats found in the Unofficial Bevy Cheat Book and in the Minimizing Rust Binary Size article I’ve achieved to fit the whole wasm binary in less than 10M, which become 2.8M when gzip compressed.

Rust binaries are so huge because the default settings turn off most size optimizations to reduce compile times. Read through this page.