flatbub

This sounds like the process of multiple stakeholders going through the tough work of forming consensus.

I'm glad you are a part of the community, championing for ease of installation across all distros.

Which other manufacturers provide any feedback channel, or engage with the community during manufacturing?

Nice. I've migrated to flakes and much prefer it.

Flakes provides abstractions at a per-repo level.

Guix offers abstractions all the way down: an OS contains a bootloader, which is also its own type.

> The default NixOS machine does literally nothing so I don't have to worry about that.

The default NixOS machine chooses a bootloader, enables nscd, has default users, enable DHCP, ...

... and those are just the parts I was able to guess at, and then confirm by checking whether their 'enable' option defaulted to true.

It's unclear how to determine (from the source code) what a default machine does in NixOS.

It was only when I tried Guix that I had the visibility into what my machine was actually composed of.

AFAICT, NixOS has no equivalent to the type https://guix.gnu.org/manual/en/html_node/operating_002dsyste... , which makes it clear what an OS contains, and allows you to query the OS.

Instead, NixOS has many options, whose only structure is that they form a tree. When trying to understand a host, it's unclear how to begin to analyze this tree: no option is at a higher level of abstraction than any other, or if it is, it's difficult to infer that.

Arguably I could just look at my host's config, and that will tell me what this host does, but it doesn't. It actually describes my how machine differs from the default NixOS machine. (How do I learn what a default NixOS machine do? Query for all services "enabled" option is set to true?)

With Guix, I follow the code: how is this host's OS "services" field populated.

What makes the SDM845 more power efficient than the SoC in PPP (RK3399s?)?

I've seen this process of replacing an "off-the-shelf binary" with a "custom binary that uses an off-the-shelf library".

It allows you to better fit your particular functional and operational needs.

No, since I can cycle while going other activities (commute, shopping), and the consequent fitness adds value to other parts of life.

Nice! Bravo for your contributions!

After using and contributing NixOS for 3 years, I appreciated that I understood far more how Guix worked after just one 1-2 weeks of using it.

Guix introduces abstractions, such as operating-system that has defined fields that make it clearer what structures are being built. NixOS, on the other hand, does not have such abstractions (or perhaps just not as well documented/discoverable).

Alas, I found Guix a bit slow and a bit difficult to contribute to (mailing list workflow, and fewer reviewers), and don't have the capacity to help improve that, and so I'm back to NixOS.

Guix is tackling multiple fronts: a blob-free kernel, a non systemd init, mailing list development, bootstrapability, no non-free software, high standards for commit messages.

If they reduced the number of fronts they were tackling, they might increase contributions, but the current contributors seem to value their existing fronts. That's fair.

That's not a nice way to treat contributors.

Bugs are the community's responsibility. Anyone who works on them (reporting, fixing, testing) should be commended.

I doubt we'd have anywhere near what we have without Martijn and Megi.

I'm a bit concerned that Manjaro is getting a bit of hate recently, and that this might impact the morale of contributors.

I'm glad Linux has a diversity of distributions, and I trust that users are selecting distributions that provide value to them, and I'm thankful for the work that goes into the development of Manjaro.

Let the rough collaboration/competition play out.