SliTaz Forum
You are not logged in.
The origins of the problems SliTaz is facing today go back a long time. Here's an excerpt of just one of the many battles that happened ages ago...
https://forum.slitaz.org/topic/slitaz-5-slitaz-for-newbies-now/page/2#post-26510
https://forum.slitaz.org/topic/slitaz-5-slitaz-for-newbies-now/page/3#post-26514
... and at the root of it all? In my opinion it's an attitude issue of someone who never seriously engaged in debates, who craftily evaded any controversial issues and who kept on pushing through the ubuntufication of SliTaz and a general dumbing-down all round.
Regarding size ... I think it would be good if SliTaz went back to small, modular configuration tools instead of TazPanel. And why not have just Openbox, an older version of LXPanel and SpaceFM instead of a full LXDE desktop (which depends on an awful lot of unneeded stuff)?
Offline
I've tried to limit the volume of packages as much as possible, but the problem is that the new versions require many more dependencies, and in the end they are also 10-15 times larger than in the past.
A practical example: X.Org X Server 1.12.4 has a 1.7Mb binary versus X.Org X Server 1.20.10 which has a 15.9Mb binary.
The same proportions can be found in many graphics packages, not to mention midori or pcmanfm...
In my build I used spacefm, but the usability is not even close to a pcmanfm-0.5.2.
Building the old packages with the new compilers is not easy at all, not to mention that there is always someone who will throw in your face that it is not the latest available!
Ho provato a limitare il più possibile il volume dei pacchetti, ma il problema è che le nuove versioni richiedono molte più dipendenze, ed alla fine sono anche 10-15 volte più grandi del passato.
Un esempio pratico: X.Org X Server 1.12.4 ha un binario di 1,7Mb contro X.Org X Server 1.20.10 che ne ha uno da 15,9Mb.
Le stesse proporzioni si ritrovano in tantissimi pacchetti della grafica, per non parlare di midori o di pcmanfm...
Nella mia build ho usato proprio spacefm, ma l'usabilità non è paragonabile nemmeno lontanamente ad un pcmanfm-0.5.2.
Costruire i vecchi pacchetti con i compilatori nuovi non è per niente semplice, senza considerare che c'è sempre qualcuno che ti sbatte in faccia che non è l'ultimo disponibile!
Offline
@Darjeeling:
I see your point but don't share your harsh judgements (frankly, I believe that "Deliberate obfuscation" and "malicious behavior" is a wording beyond a constructive discussion).
Personally, I am trying to contribute to a usable and up-to-date version of my favorite stable and fast distro with a step to the state-of-the-art architecture.
I understand your critics against the switch to a web-server-based central configuration dialogue that I personally didn't use for years since I configure almost everything from the cli, having deinstalled libwebkit and lighttpd without any problems leading to a lzma-compressed rootfs of 43MB (but additionally using seamonkey from a squashfs image).
For the time being, I will not take part in a debate about underlying script philosophies (yet) but concentrate on delivering the packages, eventually building a rootfs for my personal use...
... but if you could contribute to an alternative script system, it will surely be welcome to be tested...
@gibor:
I am not sure how comparable the package sizes really are, but my wok created a x86_64 xorg-server package of 1.20.10 with ~990kB (saying nothing about additional dependencies, you might be right here in the end...)
Offline
To a user who calls himself Darjeeling. The answer to this: https://forum.slitaz.org/topic/slitaz-future/page/10?replies=154#post-49991
Although I have not been involved in development for many years, I am still interested in what is happening on the project. I am, the one who practically single-handedly moved the development for a year or a couple of years in a row when others turned away, and I am offended to read your words.
Remember, I've never done any malicious activity on a project.
As for scripts in the distribution like init or tazpkg. The distribution from the very beginning declared itself as a tiny system. And therefore, measures were constantly taken to make the size of the distribution smaller, even by a few bytes. If these scripts look strange to you, know that comments and extra spaces have been removed from them in order to make them a couple of kilobytes less. If you want to understand the work of these scripts, then refer to the source code, they are open source, well-designed and well commented. Obfuscation is not applied. Try not to write unfounded accusations and not mislead other people next time.
As for GitHub. This is not a fork, but a backup copy. About the reasons why I created this copy, about my vision and my expectations, I wrote on this forum one year ago: https://forum.slitaz.org/topic/slitaz-on-github
All I know about the DDoS attacks was what Pascal Bellard told us. But it is completely pointless to suspect of organizing an attack on one of us, come to your senses.
Finally, a wish — put things in order in your head — everything is mixed up there, and stop making unfounded statements — get used to being responsible for your words.
Offline
@Filou
I'm missing something... probably I have some library too many.
Indeed the package you compiled on the server has the uncompressed executable of 1.8 MB (/usr/bin/Xorg), but if I compile it with the same sources, and always using the same options of the receipt, it comes out if 15.9 MB...
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--mandir=/usr/share/man \
--localstatedir=/var \
--with-module-dir=/usr/lib/X11/modules \
--with-xkb-output=/var/lib/xkb \
--with-serverconfig-path=/etc/X11 \
--enable-install-setuid \
--enable-xorg \
--enable-kdrive \
--enable-kdrive-kbd \
--enable-kdrive-mouse \
--enable-kdrive-evdev \
--enable-xfbdev \
--enable-xephyr \
--enable-config-udev \
--disable-config-dbus \
--disable-docs \
--disable-devel-docs \
--with-fontrootdir=/usr/share/fonts/X11 \
--with-os-name="SliTaz GNU/Linux" \
--with-vendor-web="http://www.slitaz.org/" \
--with-builder-addr=$MAINTAINER \
$CONFIGURE_ARGS
configure: WARNING: unrecognized options: --enable-kdrive-kbd, --enable-kdrive-mouse, --enable-kdrive-evdev, --enable-xfbdev, --disable-config-dbus
note that I also compile Xwayland and Xephyr... even if I don't install them.
Offline
@gibor:
I think what you miss might be in the functionality of the wok. I try to explain what my understanding of the cooking process is:
1.) the source code is downloaded to /home/slitaz/src
2.) it is unpacked to /home/slitaz/wok/<package>/source/<package>-<version>/
3.) it is compiled in the created subfolder
4.) it is installed to /home/slitaz/wok/<package>/install
(-> HERE you will probably find your 15MB)
5.) SOME of the files are added to the respective package
(-> the development files are created with <package-dev>, some might be part of <package-tools> and so on).
So what the wok most of the time does is extract only (!) the necessary files into one package, maybe some other to "sub"-packages and leave out the rest. (Especially the documentation part is left out almost all of the time, what is quite sensible for a minimal target).
Maybe this could explain the difference?!?
Or does your BINARY have a size of ~15MB? Could it then be, that it is compiled statically instead of using dynamic libraries? (--disable-static might help then?!?)
Offline
Or does your BINARY have a size of ~15MB?
Yes it's the size of the BINARY that is too big!
The -disable-static and -enable-shared options are already active in all compilations as per BLFS instructions.
export XORG_PREFIX="/usr”
export XORG_CONFIG="--prefix=$XORG_PREFIX --sysconfdir=/etc --localstatedir=/var --disable-static"
The official instructions for xorg-server also state
./configure $XORG_CONFIG \
--enable-glamor \
--enable-suid-wrapper \
--with-xkb-output=/var/lib/xkb
But almost nothing changes, the final size is always too big.
I can't figure out where the difference is in getting a smaller BINARY up to that point.
Offline
Although I doubt that the difference is THAT big, did you strip the binary after compilation?
Offline
If by strip you mean removing what you don't need, yes (like the one on the receipt under Remove static libs and split Xnest). But you can't remove anything else directly from the executable (/usr/bin/Xorg).
se per strip intendi levare quello che non serve sì (tipo quello sul receipt alla voce Remove static libs and split Xnest). Ma togliere altro direttamente sull'eseguibile non mi risulta si possa fare (/usr/bin/Xorg).
Offline
I mean by using [c]strip --strip-unneeded <binary>[/c] which should remove any non-needed relocation and debugging symbols ...?
(see https://man7.org/linux/man-pages/man1/strip.1.html )
Offline
@Filou. Yes it is. Stripping unneeded symbols reduces filesize. It works automatically when you run
strip --strip-unneeded
It works on shared libs, executable file, and even kernel modules.
Offline
I wasn't familiar with that command, nor did I understand why it isn't described in the LFS guides.... Anyway Xorg striped goes from ~15Mb to ~2Mb! I have no more words to add.
Thank you very much.
Non conoscevo quel comando, e nemmeno ho capito perché non è descritto nelle guide LFS... Comunque Xorg sottoposto a strip passa da ~15Mb a ~2Mb! non ho altre parole da aggiungere.
Grazie mille.
Offline
You're very welcome!
But I think you might just have overlooked LFS Chapter 7.14.1:
http://www.linuxfromscratch.org/lfs/view/stable/chapter07/stripping.html
;-)
Offline
Thanks Aleksej.
al@865 1 #!/bin/sh
@gibor
Ref:
# compressor - module of the SliTaz Cook
cookutils annotate modules/compressor @ rev 1146
al@865 1 #!/bin/sh
al@865 2 #
al@865 3 # compressor - module of the SliTaz Cook
al@865 4 # Copyright (C) SliTaz GNU/Linux - GNU GPL v3
....
al@865 757 # Find and strip: --strip-all (-s) or --strip-debug on static libs as well
al@865 758 # as removing unneeded files like in Python packages. Cross compiled binaries
al@865 759 # must be stripped with cross-tools aka $ARCH-slitaz-*-strip
al@865 760 # Stripping can be disabled with COOKOPTS="!strip"
al@865 761
al@865 762 strip_package() {
http://hg.slitaz.org/cookutils/annotate/db1cfeb9ac36/modules/compressor#l757
# Cook - A tool to cook and generate SliTaz packages.
cookutils view cook @ rev 701
# Find and strip: --strip-all (-s) or --strip-debug on static libs as well
# as removing unneeded files like in Python packages. Cross compiled binaries
# must be stripped with cross-tools aka $ARCH-slitaz-*-strip
strip_package() {
http://hg.slitaz.org/cookutils/file/1d55332252d7/cook#l436
Offline
At last I have a significant step ahead again (though still a LONG way to go ...!)
I have a bootable base 64bit system (though not cleanly finishing the bootup process yet), that features a functional X-windows (on three screens, internal + HDMI + VGA), lxpanel, pcmanfm, GPicView, Geany, leafpad, mtpaint and is able to run externally delivered browser images like (my preferred) seamonkey.
The bare rootfs ([EDIT] https://people.slitaz.org/~filou/rootfs/210619_rootfs64.gz ) has a size of 34.1 MB. The Kernel (I use a 4.4.254 kernel built for my wok at the moment ( https://people.slitaz.org/~filou/rootfs/bzImage , which might lack drivers for your hardware config), the later versions should contain a 5.* kernel) comes on top of course, in my case 12MB for the moment, but for daily use on my 32bit-system I have a customized kernel of 2.9 MB + 5.3 MB of modules.
For the displayed seamonkey browser, I downloaded the applicable .tar.bz2 file, extracted it and was ready to go without any further adjustments...
... Coming to the "NOT WORKING" -part:
- the bootup process signals a missing libiconv.so (though it's installed), so somehow the "prebootup" is not sane yet.
you can login with "root/root" though and afterwards call
[c]/etc/init.d/rcS start[/c]
again, then (at least on my machine), the bootup is finished as expected.
- startx starts X (surprise), but lxpanel fails to start up correctly (dunno why yet). If you launch an xterm with a right-click and enter
[c]killall lxpanel && lxpanel &[/c]
lxpanel is launched correctly and the system starts to be usable...
Memory usage seems to me to be very similar to the 32bit version, being around 200MB in idle...
... will report on further advance...
Cheers!
Offline
Mi fa piacere che continui nell'impresa, era da un po' che non avevo tue notizie ;-)
I'm glad you're continuing with the project, it's been a while since I've heard from you.
>the bootup process signals a missing libiconv.so
to solve add /sbin/ldconfig and then ldconfig
another issue
wget https://people.slitaz.org/~filou/rootfs/210615_rootfs64.gz
lzma -d '210615_rootfs64.gz' -c | cpio -idv
......
289760 blocks
lzma: 210615_rootfs64.gz: I dati compressi sono danneggiati <<<<<!!!
Offline
Hi gibor,
thank you so much for the nice feedback! I'll try ldconfig right away...
For the download: I checked the file by downloading it again from people.slitaz.org and copied your command. I didn't get any error message but the file decompressed fine...
I use standard lzma V4.57 in the slitaz32 cooking distro...
Could you recheck, please? From my perspective, the file seems to be ok...?!?
[EDIT]: ldconfig did the job. Thank you so much!
I uploaded the corrected image https://people.slitaz.org/~filou/rootfs/210619_rootfs64.gz , which I hope will be downloadable without any errors...
[EDIT]: I could reproduce the decompression error now:
Using xz-derived lzma V5.2.5 lead to the same error you experienced saying data is corrupt.
Using "[c]busybox lzma -d '210619_rootfs64.gz' -c | cpio -idv[/c] " does NOT complain.
Could you please check, if this is the same for you?
Anyway, I will have to patch my repacking routine to use xz-lzma rather than busybox-builtin...
Thank you for both the valuable and helpful feedback!
Cheers!
Offline
> Using xz-derived lzma V5.2.5 lead to the same error you experienced saying data is corrupt.
> Using "busybox lzma -d '210619_rootfs64.gz' -c | cpio -idv " does NOT complain.
yes it's the same for me
other bugs that I had already found on the first version
chmod 4755 /bin/busybox
Xorg.0.log > dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)
I use openbox session, and I can't help you on lxsession. However, it seems to be a configuration issue with lxpanel.
lxpanel -p slitaz
Config files are not found
Offline
Thank you for these first (and partly repeated - sorry for that ...) hints.
But all in all you could get X running and it was usable for you too, right?
If yes, the path forward for me will be
1.) continue to build the most important packages (I am playing around with LibreOffice but have a good way to go starting with Java-JDK and others)
2.) search for bugs and their reasons and step by step eliminate them....
But for the time being it seems to me that we're on the right track...
Do you share this impression?
Gracie mille!
Offline
To summarise: I ran the tests with my kernel and its firmware.
Booting up falters on network and login, but that's characteristic of the unknown tazpanel & company.
The drivers are detected with good accuracy, although I didn't pay much attention to them (they were sufficient for the quick test).
The double-spaced font that appears in the terminal (/usr/share/fonts/truetype/noto) I immediately replaced with ttf-dejavu.
In my opinion I would say to concentrate first on building a complete live (kernel firmware, slim, lxpanel pcmanfm session and openbox) with which others without great knowledge can do the first tests, and then develop the rest of the packages that you consider useful for common use.
In any case, congratulations on the result so far.
IMHO of course!
Riassumendo: i test li ho eseguiti con il mio kernel e relativo firmware.
L'avvio tentenna su network e login, ma è caratteristica dell'incognita tazpanel & company.
I driver vengono rilevati con una buona precisione, anche se non vi ho prestato particolare attenzione (sono stati sufficienti per il rapido test).
Il font a doppia spaziatura che compare nel terminale (/usr/share/fonts/truetype/noto) l'ho immediatamente sostituito con ttf-dejavu.
Per mia opinione direi di concentrarti prima sulla costruzione di una live completa (kernel firmware, slim, sessione completa di lxpanel pcmanfm e openbox) con cui altri senza grandi conoscenze possano fare i primi test, e poi sviluppare il resto dei pacchetti che ritieni utili all'uso comune.
In ogni caso complimenti e grazie per il risultato fin'ora ottenuto.
A beninteso IMHO!
Offline
Thanks again for testing and the feedback.
You're absolutely right concerning the way ahead, LibreOffice turns out to be quite a "big fish" with many dependencies on the way, although it will be one of the first bigger ones once we have a stable base.
Concerning the font, I somehow didn't manage to find the right setting to change it, .Xdefaults tricked on me. As DejaVu-ttf is installed, where did you change the xterm setting? (I seem to be a fool here....)
The Login Manager and a correct start of lxpanel will be the next steps. I'm not sure if we should stick to SliM, as it's already rather outdated. Maybe we will have to go for an alternative... We'll see...
I'll try to produce a produce a fully functional 5.x kernel afterwards (or could you deliver that one?); I'm not sure though, if the tazwok receipt is really helpful, generically compiling could be much better than "cooking in the wok" here (I am running generic, hardware-customized 64bit kernels behind 32bit Slitaz for years...).
Will report on further progress...
Offline
Hi, for the font DejaVu-ttf
remove the folder /usr/share/fonts/truetype/noto
make a new folder
mkdir /usr/share/fonts/truetype/ttf
wget http://sourceforge.net/projects/dejavu/files/dejavu/2.37/dejavu-fonts-ttf-2.37.tar.bz2
extract and copy the file DejaVuSans-Bold.ttf DejaVuSansMono.ttf DejaVuSans.ttf on new ttf dir
cp -a DejaVuSans-Bold.ttf DejaVuSansMono.ttf DejaVuSans.ttf /usr/share/fonts/truetype/ttf/
enjoy!
[attachment=50115,3097]
Il kernel che uso non ho idea se ha compatibilità su altre macchine, purtroppo ancora non ho avuto modo di testarlo su altri pc. Poi ha quel difetto sulla gestione memoria che non so chi la generi (il kernel, il config file, o gcc...) in ogni caso mettendo ignore_rlimit_data salta il limite e funziona.
Volendo provarlo puoi scaricarlo dalla distro che ho messo in condivisione e lo estrai https://disk.yandex.com/d/wMssAlByFcPIZA
o ricompili da zero con il config file che posto qui.
https://paste.slitaz.org/?e398866a5d251d2a#A4ZPGmj3IWJGmT+xFNwBUS7uFvRlCgwNeCryyEwk6YE=
The kernel I use I have no idea if it has compatibility on other machines, unfortunately I haven't had the chance to test it on other PCs yet. Then it has that defect on memory management that I don't know who generates it (the kernel, the config file, or gcc...) in any case putting ignore_rlimit_data skips the limit and it works.
If you want to test it you can download it from the distro I've shared and extract it https://disk.yandex.com/d/wMssAlByFcPIZA
or recompile it from scratch with the config file I post here.
https://paste.slitaz.org/?e398866a5d251d2a#A4ZPGmj3IWJGmT+xFNwBUS7uFvRlCgwNeCryyEwk6YE=
Offline
AGAIN you've been very helpful!
For the font: I thought I had a configuration issue with DejaVu but in fact the (seemingly installed) ttf-dejavu.tazpkg was broken. After re-cooking (after correcting the receipt) I decided to use the smaller ttf-bitstream-vera package and now everything is fine with xterm. So I was a fool but otherwise than I had thought... ;-)
The next good hint was that lxpanel was missing a config file (or to be more precise: a PROFILE). Deleting the designated slitaz profile call in the autostart file did the trick and lxpanel comes up directly after starting X.
So: next should be the kernel, which will be another BIG one, since I think I will have to use the receipts in order to come up with the experienced modularity in tazpkg.
Up to then, you might all play around with the sum of more than 2400 packages... There will be more! (... after the kernel.... :-/ )
I uploaded the corrected rootfs:
https://people.slitaz.org/~filou/rootfs/210621_rootfs64.gz
Offline
So, all you need to do to contribute is download this rootfs you linked to?
Offline
All in all - yes.
If you have a 64bit linux kernel+modules that suit your hardware or virtual machine (for example from another slitaz version), you can just use the linked rootfs to boot.
I have tested network connections via Ethernet, wpa is available, but I haven't tested it yet...
Since I haven't finished a graphical login manager yet, you have to login via command line (you can use root/root). "startx" starts X and you're there.
From the terminal (xterm) you can "tazpkg recharge" and "tazpkg install {pkg}" packages, that are provided from https://people.slitaz.org/~filou/cooking64/ , where you will find all the packages that I have built up to now (many of which are libraries and smaller tools we'll need on the way forward).
But if you'd like to help, you might now install any packages, play around with them and give feedback.
Please refer only to things missing (libraries that are missing, packages that don't start up...) and not to how programs have to be configured. If you'd like to know how to setup nginx as http server, there are other places to go, but if nginx fails because some library is not available (either not installed as dependency or not available at all), that would be helpful...
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]