Redundant disable_stratum in brl-copy

[hugglesfox]

Firstly thanks for all the hardwork from all the contributors of bedrock linux as it's a genius idea and it's exactly what I was looking for to manage disposable environments.

I was having a look through brl-copy and I noticed that on lines 56-58 it checks to see if the given path is a stratum and if so disables it. However in the block of if statements before that (lines 46-54) it checks to make sure that it's a stratum and is disabled otherwise it aborts. Therefore I don't think it's possible for the given path to not be a disabled strata when the lines 56-58 are ran?

https://github.com/bedrocklinux/bedrocklinux-userland/blob/f3e7d3b860c05290d4560d7d1d9650291b3236f3/src/slash-bedrock/libexec/brl-copy#L46-L58

[paradigm]

Agreed. Good eye. You're welcome to make a PR removing lines 56-58 if you'd like; if not, I'll get to it at some point.

Bedrock Linux 0.8 is planned to be a large rewrite. I've been exploring the possibility of writing a lot of it in Rust. Interesting to note here that the natural way to write this code in Rust, leveraging things like FnOnce, would type error on this mistake such that it would be caught at compile time.

[hugglesfox]

Oh wow I've actually been quietly working on rewriting brl in rust myself (hence why I was reading the brl-copy source) but haven't done much so far. I would love to help out with the rewrite if there's anything needing to be done.

As for brl-copy, it doesn't affect functionality and it's going to be replaced so I don't really see any reason to fix it.

[paradigm]

I would love to help out with the rewrite if there's anything needing to be done.

There is a lot that needs to be done, and I'd greatly appreciate any assistance.

My next immediate goal for Bedrock is to create a 0.8 branch with:

• A skeleton for the code base, including new build infrastructure that plays nicely with Rust.
• Documentation describing how the new architecture is supposed to work.

I don't know how feasible it will be to contribute to 0.8 until that is done, but once it is ready it should be quite possible to contribute to it based on the documentation. It may take a bit; I can't make any promises about when that branch will be created. Do check github occasionally to see if it's up.

Some of the core bits will be difficult to work on in conjunction with someone else, but possibilities I could hand off (once the above code skeleton/documentation is ready) include:

• pmm, which is a relatively self-contained part.
• brl fetch, which is a relatively self-contained part.
• Figuring out how to handle FUSE in Rust. There are a bunch of options to consider, including writing our own if none are suitable.
• Github actions to run things like static checkers, formatting enforcement, and tests. I have zero experience with Github actions, and so someone else might be better suited to do this than I am.
• System/e2e test infrastructure.

If any of those sound interesting to you, I can try to prioritize getting my thoughts down on those earlier.

[hugglesfox]

Brl fetch and GitHub actions are things I feel like I could probably do but for now I’ll wait around and keep an eye out for the 0.8 branch.