we are so very very far from https://www.slitaz.org/en/doc/scratchbook/ !
1 word:
WHY?
and probably also from that:
https://doc.slitaz.org/en:cookbook:toolchain
what happens if I try to do that actually? (no) success (in which version of SliTaz)?
@oui
why not!
I didn't use any of those guides, because they are all too old. As no version of slitaz supported 64bit fully.
Read the previous posts and you will find on what basis I developed the LFS-BLFS.
perché no!
Non ho usato nessuna di quelle guide, perché sono tutte troppo vecchie. Come nessuna versione di slitaz supportava i 64bit in modo completo.
Leggi i post precedenti e troverai su quali basi ho sviluppato la LFS.
Hi Gibor
You are asking
«@oui
why not!»
simply because it is not SliTaz any more if does not works according the old documentation from Christophe any more :-) !
if I remember right, Chritophe did show us the way to build SliTaz not from some LFS+BLFS, not from Debain, not from Slackware, not from other distributions but directly from the sources being on each of the official sites of the creators of the used and selected applications!
it is a totally different way and purpose and it is or it not SliTaz any more at all.
following your logic, Puppy Linux would be SliTaz! Puppy Linux was officially made using Slackware...
the logic from Christophe was completely different:
- he did look for the minimal set of applications needing,
- he did search the "original" source codes
- he did compile them after shrinking from the ballast (his distribution did immediately but only contain French, his language, German, Italian and English, not more - it was a factor how to shring some sources from very important among of not often used code and annexed documentations)
his compatriot Thierry Nuittens, also a initially only French speaking Swiss man, did do parallel the same matter as probably you: he did create the distro Nutyx, see https://nutyx.org, from LFS book! and you, you copy only, and bad, Nutyx now...
SliTaz us an acronym and it has to do with "be independant" from LFS etc.
If dependant, I would prefer a kind of SliTaz dependant from Debian/Devuan sources!
(it is the limit of NuTyx: after NuTyx, difficult to get more... But NuTyx did become in the time a very complete but limited standard distribution, where only one is not available, the 30.000 thousand and more Debian applications!)
For me it is only important to have a distro that boots quickly and has no unnecessary parasitic routines.
The system I have created uses the slitaz init.d scripts and works as I wanted.
It is well known that many distributions are basically clones with few differences between them, and this is the habit of many.
So think what you want, but the system to give it a definition is based on slitaz, then if it bothers me I can just call it "build" or any other name, but the substance does not change. as does the construction of many competing distros.
Per me è importante solo avere una distro che avvii in tempi rapidi e che non abbia routine parassite inutili.
Il sistema che ho creato usa gli script init init.d di slitaz e lavora come volevo.
Poi che molte distribuzioni siano in fondo tutte dei cloni con poche differenze fra loro questo si sa, è abitudine di molti.
Quindi pensala come vuoi, ma il sistema per dargli una definizione è basato su slitaz, poi se la cosa da fastidio posso chiamarlo solo "build" o con qualsiasi altro nome, ma la sostanza non cambia. come non cambia la costruzione di molte distro concorrenti.
... if I may ...
as far as I remember, the underlying idea and first scripts for SliTaz had been derived from LFS, since LFS is nothing more than a documentation about how to set up a working Linux system from source code.
If I am not mistaken, this is also the reason why a couple of package receipts still contain LFS patches.
The main contribution on top of that was the minimalistic adaptions - as oui described - that turned a quite big LFS system into SliTaz by replacing many functionalities by busybox and some more by shell scripts and stripping all components down to the bone.
I agree that a "true" LFS system is not identical with a SliTaz system, but what some of us try to achieve is updating this faboulous tiny system to recent libraries and 64 bit in order for SliTaz to be usable with recent mainstream software like browsers, office suites etc.
I myself used LFS in order to have a functioning recent basement for a new SliTaz wok.
I am using a patched wok and by that compile the packages the "SliTaz-way". Is this "orgiginal SliTaz"? I don't know, but I am open for a better alternative.
As far as I can see in the forum activity of the last months, there is a VERY small group of us who dedicate ANY time into this. My own intention was to CONTRIBUTE, not to lead or compile everything on my own, but it seems that the "elder's advice" is sparsely available.
If you have any suggestions on how we could better - or faster - or slimmer - or ??? - proceed on our way to a "64 bit SliTaz-like distro" I would be glad to hear and eventually support them.
I don't think though, that a blame of "badly copying" anyone's work is a very constructive step ahead...
> I myself used LFS in order to have a functioning recent basement
> for a new SliTaz wok.
... which is exactly what is needed at this stage. But once all the problems with the resulting SliTaz base system have been ironed out, this system should itself be used to run the wok and everything that comes with it, so the system becomes self-hosting. I think, this is what Oui was referring to.
Hello everyone,
Filou wrote:
"As far as I can see in the forum activity of the last months, there is a VERY small group of us who dedicate ANY time into this. My own intention was to CONTRIBUTE, not to lead or compile everything on my own, but it seems that the "elder's advice" is sparsely available."
I follow the development of the topic https://forum.slitaz.org/topic/slitaz-future with great enthusiasm, as I believe that we see in the progress and development of this topic a "Future of SliTaz". I would like to help, but unfortunately I don't have technical knowledge, what I can do is help test the ISOs, either via the USB device (Live USB) or by installing SliTaz on a hard drive and reporting the test results.
If the "advice of the elderly" does not persist, then there are some doubts:
Who is the person or people who create a new SliTaz 5.0 Release ISO (weekly) and publish it?
The most recent ISO is from the 18th of July 2021. What's the point of that, publishing a new ISO, then another and another... Has the current ISO solved the problems of the previous one? Or does the new ISO have the problems of the old one and now have new problems?
Can you understand my doubt?
marcelocripe
----------
Olá a todos,
Filou escreveu:
"As far as I can see in the forum activity of the last months, there is a VERY small group of us who dedicate ANY time into this. My own intention was to CONTRIBUTE, not to lead or compile everything on my own, but it seems that the "elder's advice" is sparsely available."
Eu acompanho o desenvolvimento do tópico https://forum.slitaz.org/topic/slitaz-future com muito entusiamo, pois acredito que vemos no andamento e no desenvolvimento deste tópico um "Futuro do SliTaz". Eu gostaria de pode ajudar, mas infelizmente eu não possuo conhecimentos técnicos, o que eu posso fazer é ajudar a testar as ISOs, seja executando através do dispositivo USB (Live USB) ou instalando o SliTaz em um disco rígido e reportar os resultados dos testes.
Se os "elder's advice" não respondem, então ficam algumas dúvidas:
Quem é a pessoa ou quem são as pessoas que criam uma ISO nova do SliTaz 5.0 Rolling release (semanalmente) e a publica?
A ISO mais recente é do dia 18 Julho de 2021. Qual é o sentido nisso, publicar uma ISO nova, depois outra e outra ... A ISO atual resolveu os problemas da anterior? Ou a nova ISO possui os problemas da anterior e agora possui novos problemas?
Conseguem compreender a minha dúvida?
marcelocripe
You must log in to post.