Re: The big proposal

[Ben Arnold <benarnold@xxxxxxxx>]

Hi GoKhlaYeh --


I'm a +1 on the libre flavour. While I agree 100% with the intentions,
I can't see the justification when hardware support isn't here yet. We
would be turning users away as the libre doesn't allow for non-free
firmware. I would be included, my netbook requires it for the wi-fi
chip. Until the forum requests on installing non-free drivers/firmware
stop, I wouldn't recommend discarding this portion of users at the gate.

Part of freedom, in my opinion, is choosing whether one has freedom. I
understand completely that the FSF France aren't going to host non-free
software, and rightly so, but I can't see why get-* should be removed.
I see non-free software inclusion as a chance to educate users rather
than force alternatives upon them. They are known for their level of
quality anyways, since it is an additional download and obvious they
are outside SliTaz's control; I've had a couple of binaries that
wouldn't run thanks to some library version mismatches. Without get-*,
bye-bye goes my browser of choice, Opera, it's sync with my mobile
phone browser, and contacting some friends and family on *their* VoIP
system of choice, Skype. I don't think the juice is at all worth the
squeeze on this one.


Cheers,
Ben


On Mon, 25 Oct 2010 00:50:06 +0200, you (GoKhlaYeh) wrote:
| ===== SliTaz 100% Libre Proposal =====
| 
| The idea is to feet libre distribution requirement writted by GNU :
| http://www.gnu.org/distros/free-system-distribution-guidelines.html.
| Please note that's about libre distribution, not some libre flavor or
| so. So this means make a entirely free & independant distribution,
| not just an alternate version of a non-free distro.
| 
| **Why ?**
| Mainly because it's possible and it works. It's an ethical choice,
| is it shared by the team ? Support free software as well we can Make a
| really good quality distro (no more dangereous binaries) Be
| autonomous from privative software developpers **How ?**
|  
| Mainly by removing things :
|  Remove get packages
|  Remove packages with non-free content ( = something which don't have
| a free licence) It can be : nvidia, ati, firefox (logo is
| copyrighted, icecat can be used as an alternative), probably some
| other
|  Remove stuff which lead to install non-free content
|     Software : particulary some code in tazhw
|     Documentation : how to install non-free content 
| 
|  And an important thing :using linux-libre sources to build linux
| kernel (no more kernel binary blobs), see
| http://www.fsfla.org/svnwiki/selibre/linux-libre/index.en.html
| 
| **The options :**
| 1)
| Make slitaz 100%libre, obviously everyone is free to maintain it's
| own repository with what he want inside, but no non-free content and
| no instructions about installing non-free content in all SliTaz
| website/code is the rule. Implication : some hardware will be less
| well supported or totaly unsuported in the short term, in other hand
| we contribute to the pression on hardware producer to make free
| hardware, and we will no more distribute potentialy highly dangereous
| binaries (only potentialy highly dangereous free code :D)
| 2)
| Make a fork of SliTaz based on the same code-source. It's my
| alternative if the team don't want to make SliTaz 100% libre. In this
| case everybody here will be welcome to contribute in it and most code
| will be shared between the two distro to avoid force division.
| Implication : duplicate website maintainment effort, coding a
| free-da-wok-bot, slitaz keep a non free distro :'(
| **I write it twice because it's important** : in this case I will
| make the necessary to avoid force division, all receipts will still
| in slitaz wok then a bot will free them and recook all in a separate
| server.
| 
| **In addition :**
| I think that it can be the right time to create a space for
| communication and knowledge sharing between hackers in a large
| definition : intellectual hackers, craftsman hackers, social hackers,
| etc... I mean everyone who can share a libre & human ethic. Because
| we, hackers, don't need only something to tweak... we also need some
| turnips, right ? ;) I talk about some pages to talk gently about our
| autonomous wish and create some links to share what we do / what we
| need. It's about realize something together. I have nothing precise
| to propose yet but I think you understand what I'm write, so let's
| broke theses specialization borders :) All this makes a lot of sense
| for me, I hope for you too.
| 
| ===== Rolling-release proposal =====
| 
| Christophe Roger and me, maybe some others, are frustated by the
| annual release system and this long frozen, then this long
| breakage... I'm actually rewriting tazwok and adding theses feature
| to make rolling-release style possible in slitaz. Let's suppose
| everybody use cooking and most users want to be safe from breakage :
|  * When cooking a package, recook all reverse depends (maybe with
| some condition, like lib update) Put that in a sub-directory of
| packages repository, called incoming
|  * If the commit broke something, packages keep here labelled broken
| until all is fine If all is fine, packages are labelled incoming
|  * After a little delay - between 3 and 7 days ? it will be
| configurable so let's experiment what's the fine configuration- , if
| no changes are made to the incoming packages (including all
| classic/reverse depends/build_depends), move them to main packages
| repository You probably recognize the sid/testing method here...
| Here, the incoming repository act as an undigest repository and can
| be used by people who wants to be directly inside the tempest. Note
| we need to be organized (more communication on this list) because if
| you change a depends of something in incoming, even if all is fine,
| the delay will be reseted : mainly because we can't move something
| without his modified depends without a risk of breakage. It's why the
| delay must not be too long. It's also why we will need to wait a
| little if all is fine that packages move into main repository before
| tweak it a new time. So big updates - toolchain/base packages - will
| need tiny autonomous freezes : it's sport :) The idea behind this
| is : 
|  * Better correction support (we work one only one repository)
|  * Improvements goes faster to user
|  * User report is more efficient (no more case "fixed in cooking, but
| new problems with cooking")
|  * Keep on the road, less painfull update, less broke directly on
| main cooking
|  * It's possible to use the incoming repository as undigest, then
| unset it and come back to the classic repository if something broke.
| Using two different system is avoided. The code is on the good way, I
| come back soon on this subject with the proof-of-concept, hope you
| will love that. Note : An efficient way to recook toolchain is needed
| to make this works correctly, it will probably be the hardest part of
| the job... but for this part I have until april.
| 
| ===== Minimal chroot proposal ===== 
| 
|  Cooking in minimal chroot, already spoke about that on the list,
| proof-of-concept soon too since it's something I implement in tazwok
| in the same time (+ some other features)
| 
| ===== It's not the end, just the beginnin' ===== 
| 
|  Hope you have something to add/share about that. If you have some
| changes in mind, lets talk about and see if we can do it. IMHO SliTaz
| is not something frozen, it's more like a collective artistic
| creation : always in movement for ever more joy and passion. P.S.:
| Obviously, if you disagree I will not take it bad, Ho... And it's
| really not a critical about what SliTaz was/is, it's only the good
| possibilities I see. That's said. One love.


-- 
Ben Arnold
Chester, UK

e: ben at seawolfsanctuary.com @ benarnold at fsfe.org
w: seawolfsanctuary.com | linkedin.com/in/benarnold

nom = { :cookies => :mouth }
nom; nom; nom

Attachment: signature.asc
Description: PGP signature