Comments (11)
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.
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.
Related Issues (20)
- Folly build broken
- Oxide (tarnish) missing reboot-guard dependency
- Uninstalling fails HOT 1
- rm2fb flag not modifying rpath
- Splashscreens don't replace properly
- Fingerterm icon incorrect
- rmfm crashes if there is a broken symlink HOT 1
- innernet package doesn't disable/stop services on uninstall
- Add hook to automatically systemctl daemon-reload
- Binary modification fills root partition until xochitl restart HOT 3
- Automated testing
- toltecctl generate-opkg-conf should have -y flag
- Add systemd generator for entware init scripts to toltec HOT 2
- rmfakecloudctl: set-upstream does not validate that URL is valid HOT 7
- rmfakecloudctl is missing from toltec-completion
- Bootstrap creates /opt when installing toltec-bootstrap HOT 1
- linux-stracciatella: add 'CONFIG_MODULE_UNLOAD=y' HOT 14
- Changing shell to anything but /bin/sh and /bin/bash breaks SSH HOT 1
- The 'strings' utilty is missing libbfd HOT 3
- 3.x support HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from toltec.