Add philosophy/principles about toltec HOT 11 CLOSED

I do agree on the necessity to document the reason behind each principle. By the way, please feel free to suggest new principles or changes to them right now, as they will we harder to amend later on.

the repo is aiming to build software without relying on rm's toolchain so all packages should build without it

This fits in a wider principle of “We should be able to build all packages from source without relying on pre-built binaries”. The reasoning behind this guidance is to ensure the auditability of the packages. It’s hard to audit binaries, but less hard to audit source code. Auditing source code is sufficient as long as we can ensure that it matches the built binaries (see “Reproducible builds” principle higher in this thread).

The scope of this principle includes the toolchain that is used for building the packages (otherwise we need to trust yet another unauditable set of binaries). Unfortunately, it’s not possible to rebuild the exact same toolchain as provided by the reMarkable company, because its sources were not distributed. So, the Docker images aim at recreating a similar build environment which can itself be built from source.

A current limitation of this guidance is with the closed-source libqsgepaper Qt plugin that is distributed with the reMarkable toolchain. Since there’s no free equivalent of this library currently, we’re forced to use it as-is.

from toltec.

We should probably ask remarkable for the source of the toolchain, since most items in it are under GPL. We could at least get source/configs for enough of it to keep what we build close.

from toltec.

• should there be a non-free repository?

I find that a good idea. Might also be a way to safely incorporate the rm hacks which a lot of people use nowadays. That could also offer people who don't really care how they build their software to use the rM toolchain or other binaries of questionable source.

We could also add non opensource packages for e.g. template management or others could provide packages for their solutions that can't be checked well (example with the recent distro and the new tool). Looking at sourceforge being still a thing, I guess that many Windows or output focused developers who don't care about their source code or automatic building could add their software binaries there from their website or whatnot.

A question I would have is then, whether we do a nonfree-testing and nonfree-stable or have a common testing branch.

• do we prioritize software freedom or ease of use? i really think a statement should be taken on ease of use, because if this repo prioritizes software freedom, it might make it hard to create a nice end to end experience.

I fully agree with our opinion on this. The package manager should enable an easy ecosystem especially for people who don't care about checking the origin of every line of source as long as they have access to fun mods and don't catch malware.

We should still try to encourage freedom, security, scruteny and so on, but ease of use should really be the first priority here. People who really care about the source can usually still build that project from source anyways. We should mainly distribute this software and not recompile everything without any exception. At the end most users won't care anyways.

• do we lean towards debian model of stability or archlinux model

I'm pretty much torn on this one. I guess that comes back to how sophisticated we want the testing -> stable transition to be. I guess that makes this point another topic we already started elsewhere.

• how seriously do we take this effort?

I would say: Best-effort community driven but no guarantees.

There will be packages that get dormant either because of lack of interest, no more releases from the dev or other reasons. We should strive to be as active as possible but don't make end users think that we "will be perfect".

Only time can tell.

from toltec.

There will be packages that get dormant either because of lack of interest, no more releases from the dev or other reasons. We should strive to be as active as possible but don't make end users think that we "will be perfect".

If we package something we should probably also put in place some sort of automation to open a task when a new release has been pushed for it. That would at least help us keep an eye on what needs to be done, and let others pick up on it.

from toltec.

There will be packages that get dormant either because of lack of interest, no more releases from the dev or other reasons. We should strive to be as active as possible but don't make end users think that we "will be perfect".

If we package something we should probably also put in place some sort of automation to open a task when a new release has been pushed for it. That would at least help us keep an eye on what needs to be done, and let others pick up on it.

Agreed. I’m moving this suggestion to a separate issue.

from toltec.

• Reproducible builds

from toltec.

Lets make sure to document the "Why?" as well as the "What?" when documenting the philosophy/principles. I'd specifically like to fully understand the "Why?" on the following:

the repo is aiming to build software without relying on rm's toolchain so all packages should build without it

from toltec.

By the way, please feel free to suggest new principles or changes to them right now, as they will we harder to amend later on.

Things I think we should think about:

• should there be a non-free repository?
• do we prioritize software freedom or ease of use? i really think a statement should be taken on ease of use, because if this repo prioritizes software freedom, it might make it hard to create a nice end to end experience.
• do we lean towards debian model of stability or archlinux model
• how seriously do we take this effort?

from toltec.

• should there be a non-free repository?

I find that a good idea. Might also be a way to safely incorporate the rm hacks which a lot of people use nowadays. That could also offer people who don't really care how they build their software to use the rM toolchain or other binaries of questionable source.

We could also add non opensource packages for e.g. template management or others could provide packages for their solutions that can't be checked well (example with the recent distro and the new tool). Looking at sourceforge being still a thing, I guess that many Windows or output focused developers who don't care about their source code or automatic building could add their software binaries there from their website or whatnot.

A question I would have is then, whether we do a nonfree-testing and nonfree-stable or have a common testing branch.

I’m not in favor of a non-free repository for now, for two reasons:

• I don’t think we have enough contributors to maintain two separate repositories currently.
• There’s no non-free software that I know of currently for the reMarkable, and I’d like to encourage it to stay this way.

We can always package the rM hacks safely by only distributing the binary patches. Anyway, making a non-free repository will not instantly enable us to redistribute xochitl, as we’d need to get an agreement with reMarkable AS first, which I doubt we’ll get. Is there a non-free template management tool that runs on the reMarkable?

• do we prioritize software freedom or ease of use? i really think a statement should be taken on ease of use, because if this repo prioritizes software freedom, it might make it hard to create a nice end to end experience.

I fully agree with our opinion on this. The package manager should enable an easy ecosystem especially for people who don't care about checking the origin of every line of source as long as they have access to fun mods and don't catch malware.

We should still try to encourage freedom, security, scruteny and so on, but ease of use should really be the first priority here. People who really care about the source can usually still build that project from source anyways. We should mainly distribute this software and not recompile everything without any exception. At the end most users won't care anyways.

I don’t see where freedom conflicts with ease of use in this case. I think we should prioritize both.

• how seriously do we take this effort?

I would say: Best-effort community driven but no guarantees.

There will be packages that get dormant either because of lack of interest, no more releases from the dev or other reasons. We should strive to be as active as possible but don't make end users think that we "will be perfect".

Only time can tell.

Agreed.

from toltec.

Can we close this issue? (Is the README or other place documenting free software principles enough?)

from toltec.

please open if you think this needs re-addressing

from toltec.