|
Re: HTTP-redirect-cloning distros a la Devuan [message #28 is a reply to message #9] |
Sun, 15 April 2018 17:02   |
alienbob
Messages: 1 Registered: April 2018
|
Junior Member Slackware Coreteam |
|
|
What you call "HTTP-redirect-cloning distros" is a way to mask that you are in fact using other people's bandwidth (and their work too of course). It is a practice that is not fair toward the people who pay money for that bandwidth.
For instance the Slackware mirror-network consists of university servers, company servers and private servers behind a residential DSL/cable connection. Like mine.
If binary Slackware packages and/or sources are being downloaded from my server at home, I want that to be for the benefit of Slackware, not for a group of people that re-uses the packages that were compiled by the packagers of another Distro but can't be bothered to arrange their own hosting.
Note that I am sympathetic to your goal, even though I do not share your view about what constitutes 'libre software'. By creating a 'libre' version of Slackware, you are filling a niche, which is appreciated by people.
And I know I am ranting, but this is not directed towards you - you are in fact hosting your own stuff on your own server. Great!
I just wanted to let you know my opinion about "HTTP-redirect-cloning distros".
Eric
|
|
|
Re: HTTP-redirect-cloning distros a la Devuan [message #29 is a reply to message #28] |
Mon, 16 April 2018 16:50   |
connie
Messages: 28 Registered: January 2017
|
Junior Member Freenix Ninja |
|
|
Quote:What you call "HTTP-redirect-cloning distros" is a way to mask that you are in fact using other people's bandwidth (and their work too of course). It is a practice that is not fair toward the people who pay money for that bandwidth.
I agree. Not only it's basically bandwidth leeching (when without a prior explicit agreement), in our case it would also probably violate FSDG, which seems to strongly imply that the project must not provide a repository which is already tainted or might probably become tainted in the future (i.e. with incorrect/unclear blacklist policy). This is not an interpretation of FSDG I would personally defend, but in Freenix' case there are also good technical reasons for keeping the repo completely separate. The main reason being, we cannot with a straight face claim to filter out proprietary software, while the Slackware project has the technical means to change the repo at will, and no spelled-out policy as to what may be included. We also need our own repo in order to provide the rsync interface. May be it's just my ignorance, but I don't see how we could possibly convince anyone to mirror our repo, if they also have to re-implement the blacklisting and the component replacement!
[Updated on: Mon, 16 April 2018 16:53] Report message to a moderator
|
|
|
|