On Mon, Oct 25, 2010 at 5:50 AM, GoKhlaYeh
<gokhlayeh@xxxxxxxxxx> wrote:
After some month of playing with SliTaz - and too less commit in this regards, but it's never too late - and some conversation with other contributors - mainly Christophe Roger and Julien Rabier - I wish to make some proposal to the whole team. It's about hudge changes in SliTaz in middle-term, so it's collectives choices and I hope that everybody has something to tell about.
As it's not about little hacks, important contradictions or too low enthousiathm will lead to abandon theses ideas as something realizable in SliTaz soon. Anyway I work on proof-of-concepts and tools, so it will lead to something in a way or another.
I want to open three subject here :
1- Transform SliTaz in a 100% libre distribution
2- Transform SliTaz in a rolling-release distribution
3- Cook all packages in minimal chroot
===== 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.
--
GoKhlaYeh <gokhlayeh@xxxxxxxxxx>
---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/