Re: [GNU-linux-libre] ION Project

[Jason Self]

On Sat, 04 Nov 2023 19:14:11 -0300
d1nc...@ion.lc wrote:

> I would ask you to review the system or some 
> of it's components

To be sure are you looking to have ION GNU/Linux added to
gnu.org/distros? In that case on this list we evaluate the entire
distro - not just pieces of it.

Outside of the distro review process an option for individual pieces
can be the Free Software Directory at https://directory.fsf.org/

In terms of reviewing the entire distro I was able to quickly find
programs that would need to be either modified or removed entirely.

The nonfree VMWare Workstation
Brave browser (non-free add-ons)

I don't intend for this to be an exhaustive list. Given that I was
able to locate these so quickly I recommend doing a review of all of
your packages and other aspects of the distro for compliance with the
GNU FSDG, making appropriate removals or modifications and re-submit
the distro at that time.


pgplbKuGcOP8B.pgp
Description: OpenPGP digital signature

[GNU-linux-libre] ION Project

[d1nch8g]

Good afternoon!

Firstly, would like to apologize for a possible misunderstanding. 
English is not my first language. I hope possible lexical difficulties 
will not affect the transmission of the presented concepts.


For last year i've been working on an arch-based distribution with some 
features that I'd like to share with the GNU/Linux, FOSS, and 
development communities. The project is currently in prototype stage; 
some functionality is relatively crude, but on this premise, at least 
some ideas might have a good use.


If that would be possible, I would ask you to review the system or some 
of it's components, since they address different issues, each of which 
can only be fixed through collaborative efforts.


The main goal of the project is to integrate diverse free software 
components to better fit with each other. That would simplify the end 
user's experience, reduce existing network effect and will make the 
system easier to understand for new users.


1. Decentralized Package Manager

The majority of application stores, package managers or tools that work 
on top of package managers (AUR-helpers) are eventually linked to 
specific centralized institution. These include both entirely closed 
proprietary repositories: 'Apple Store', 'Play Market', 'Steam', and 
platforms that deliver primarily free software or components: 
'Spanstore', 'NPMJS', 'Crates', 'AUR'.


Centralized software hubs frequently incorporate proprietary backend 
and infrastructure components, resulting in a network effect in which 
users publish their work in a single place. This causes the following 
issues:


- Software and component developers delegate too much responsibility to 
a single point of failure
- Often, centralized nodes introduce extra barriers in the form of the 
necessity for software package or dependency component moderation
- Owners of software hubs hold far too much control over those who rely 
on them, especially when the software is mostly proprietary


In contrast, certain systems, such as git, docker, and go, use a 
decentralized model by default. Without unnecessary intermediate 
regulatution those systems are far superior in terms of practicality. 
This enables software and component providers to deliver their packages 
or libraries directly to users without causing needless annoyance.


Project includes a pacman-based decentralized package manager 
prototype. It allows software developers to provide packages directly 
to users without intermediary regulation. Additional command to push 
packages directly to the package registry can simplify the process of 
package delivery. Furthermore, embedded registry handles package 
database files automatically in specific user/organization scope, 
eliminating the need for manual package database file maintenance and 
lowering the amount of potential errors.


The final objective is to build a bridge between the package manager 
and the CI/CD system by simplifying package delivery via API endpoints, 
alongside adding additional CLI interface for package distribution in 
decentralized manner. If I knew C, I'd probably just modify Pacman, but 
if the ideas are useful, there's nothing stopping me from learning it 
to apply required modifications, or create an entire new solution.


Source code: 
Gitea registry PR: 

2. Project home is a public Gitea instance

Most of the software products use their own technological solutions for 
the same purposes, although the functionality often strongly 
intersects: blogs, Q systems, registries for software packages, 
documentation hosting, GPG key-servers, and so on. People spend a lot 
of effort solving the same problems, while small companies and startups 
may not have enough resources to maintain a large number of specialized 
web services. Additional maintanance takes extra effort, which is often 
unnecessary, if the end-goal is to solve specific specialized problem.


Integration of a particular solution into existing git-hosting / CI-CD 
system might be harder from development perspective, but may then be 
used by a wider audience because integrated functionality, when 
provided in accesible manner, is more likely to be utilized.


Also, that might reduce the number of centralized services for specific 
tasks, since functionality can be provided within existing 
decentralized free solution like Gitea. For example, embedding Q 
system into Gitea might reduce the network effect of StackOverFlow, 
more users will receive an access to freedom respecting integrated 
functionality.


Modified gitea allows package maintainers to publish the source code 
alongside packages in a single place without being tied to a specific 
instance, as there is a simple straightforward approach to deploy new 
instances under different domains. As a result, this provides users 
access to the code base and software updates in a unified manner.


Configurations and deploy