Is this maintained

[brrock]

I would be happy along with others to help @Hardolaf

[paradigm]

Yes, this is maintained. There isn't much visible development on the current 0.7.x Poki series as most of the development is offline work on the future 0.8.x Naga series.

It will be difficult to split up the work and delegate parts of the Naga's core until it is further along, but there are a few efforts that haven't had a meaningful start yet that we could absolutely use help with if you have the background:

1. Poki's brl fetch does not verify the packages it pulls, which is very bad for security. I want Naga's brl fetch to resolve this. This means we need some kind of distro package public key management system. The next step should be a small example program (in any programming language, as a proof-of-concept/prototype) that:

• Gets an initial set of public keys somehow
• Can check for a public key update and, if there is one, use the existing set of public keys to update the local set of public keys.
• Can use public keys to verify downloaded packages

for every brl fetch supported distro.

2. Poki's /bedrock/cross transforms various files found in strata into versions of those files that are portable in a Bedrock context. The simplest example is /bedrock/cross/applications/*.desktop files - if you look at those, you'll find Bedrock injected strat into their Exec= lines. I want to do a similar transform for various service definitions, e.g. systemd unit files, runit run directories, etc. The next step should be a small program (in any programming language) that:

• Can read in service configuration files (for various service managers, e.g. systemd, runit, openrc, etc) and converts them to some internal service manager agnostic format.
• Can convert the internal format into a portable version of any supported service manager configuration.

This will require some R&D not only to transform between formats, but to figure out how to make services run across stratum boundaries.

3. Poki's pmm can only run one package manager operation at a time. I'd like Naga's to be able to run multiple operations in parallel. The tricky part here is the UX, as many package manager operations raise a prompt the user needs to interact with to continue. We need R&D on Linux terminal magic needed to show some kind of progress bar indicating things like how many package manager operations are running in the background which does not interfere with existing package manager terminal magic. Think something like apt's progress bar (https://149366088.v2.pressablecdn.com/wp-content/uploads/2014/04/apt-progress.png). Next step here should be a small program (again in any programming language, as a proof-of-concept/prototype) which:

• Runs multiple package manager commands in parallel
• Shows the UI of one, including wiring up both input and output
• Shows some progress bar on the bottom of the screen of the currently completed command (i.e. package manager exited) divided by total commands running
• Once the user-facing program completes, supports user hitting ENTER to clear it and wire up the progress of the next program

Let me know if you're interested in and believe you have the ability to tackle any of these.

[brrock]

what branch is the naga version on? and do mean in one term i can install a package while installing another in another terminal or in the same command

[brrock]

I think for 3 to work i think a pmm rewrite in something like c, rust or python would make a lot of sense as bash scripts maybe would make this a lot harder. I also think the core brl elements should be as well, c would make it a lot easier to maintain

[brrock]

I like the challenge of 2 quite a lot of after a lot of thought, I like new challenges!

[brrock]

https://github.com/brrock/bedrock-prototypes
Some of my prototypes so far. Could you please explain how cross fs works please, as I want to see how I could integrate my prototype into this

[paradigm]

what branch is the naga version on?

No Naga code is currently publicly available. I want to avoid bike-shedding arguments and having to explain incomplete in-progress work. Once it's far enough along I'll throw it up and announce the location.

and do mean in one term i can install a package while installing another in another terminal or in the same command

One pmm command often runs multiple package manager commands, such as updating the repositories of multiple strata at once. Currently, it's serialized. I'd like the next-gen version to be able to parallelize it, but otherwise have a comparable experience.

I think for 3 to work i think a pmm rewrite in something like c, rust or python would make a lot of sense as bash scripts maybe would make this a lot harder. I also think the core brl elements should be as well, c would make it a lot easier to maintain

The plan right now is for Naga to be primarily written in Rust.

I like the challenge of 2 quite a lot of after a lot of thought, I like new challenges!

:)

Could you please explain how cross fs works please, as I want to see how I could integrate my prototype into this

The goal I set out above is to figure out the business logic, which is in part why I don't care what language it is in. The expectation is it'll be rewritten or adjusted as necessary for Naga's equivalent of crossfs, once it's ready. The plan is for it to offer an interface (or more specifically, a Rust trait) which will be a clearly documented method of integration.

Poki's crossfs is difficult to integrate with; its code hasn't aged well. Moreover, it lacks the ability to actually place the generated files in a location service managers would look, which is another reason Naga is needed.

You could test by having your prototype read service manager config files from one stratum and install the generated ones in another. A quick reboot into the other stratum's init could then see if they're working. While crossfs' ability to generate the files on-the-fly isn't needed at this point.

[brrock]

Thanks, that really helps me! Have you checked out the repo I sent?

[brrock]

Tbh I might make a prototype of crossfs rewritten in rust, and I'll integrate the services. I'll spin a fresh bedrock vm and test it out by replacing the current cross fs by mounting it. It will be a drop in replacement for it.

[paradigm]

Thanks, that really helps me! Have you checked out the repo I sent?

It'll be a while before I get the chance. I'm juggling quite a lot at the moment.

Contributing to Bedrock at this point in time is going to require some degree of independence, working towards the delegated goal while I split focus on other tasks.

Tbh I might make a prototype of crossfs rewritten in rust, and I'll integrate the services. I'll spin a fresh bedrock vm and test it out by replacing the current cross fs by mounting it. It will be a drop in replacement for it.

Keep in mind Naga's crossfs equivalent architecture is largely locked at this point, and so it's very unlikely anything from your prototype outside of the resource translation logic is going to be upstreamed.

That said, I do see how this could aid with figuring out the business translation logic, and so provided the cost-benefit there works for you, do feel free.

[brrock]

ok, can I help you with anything else?

[paradigm]

Fully completing the R&D on any of the three things I've listed would be tremendously beneficial. Absent those, the only other way to help I currently foresee to help would be to become deeply and broadly knowledgable about Bedrock then assist with answering questions in various community locations. However, the effort to build enough knowledge to ensure one is answering questions correctly rather than unintentionally spreading misinformation is substantial.

[brrock]

I know it has been a while and I now have some time to work on this. What is left to be done.
Thanks again
Friendly ping @paradigm

[paradigm]

I continue to focus on Naga's core components, which isn't work easily shared. The previously discussed items remain the best ways to contribute.