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?

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

I imagine the 10 nm process (compared to the 28nm process of the RK3399s) probably is the biggest efficiency advantage of the SD8M45.

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.

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

NixOS had plenty of abstractions, so I don't quite understand this. All of NixOS is a compilation of abstractions for building an operating system environment. Could you elaborate on what abstractions are not present?

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

Except for the last one, all of these are noble achievements perhaps within a subset of an ecosystem, like Nix or Guix, but the deliberate and unwavering stapling of these goals to the ecosystem makes Guix unpalatable.

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.

The type problem is starting to be solved by flakes; the equivalent to the type `operating-system` is the type `nixpkgs.lib.nixosSystem`.

To analyze a NixOS system configuration, I look for all modifications to the `services` attr (representing all the services of the system, e.g. `services.mpd.dir = "~/Music"`). If I want to know even more I can look for all the `.enable` keys to see if any hardware/program/etc options have been enabled, and the sources are easy to read so I can open the corresponding module file in Nixpkgs if I want to know what a particular option does. The default NixOS machine does literally nothing so I don't have to worry about that.

Guix does look really cool, and I would try it if it had more support for nonfree software (I depend on some nonfree software in my day-to-day.)

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.

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.