SliTaz Forum

Slitaz future?

(278 posts) (29 voices)

• Started 4 years ago by guest_account
• Latest reply from alanyih
• This topic is not resolved

Tags:

No tags yet.

1. 

   Darjeeling
   

   offline

   Member

   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)?

   Posted 3 years ago #
2. 

   gibor
   

   offline

   Moderator

   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!

   Posted 3 years ago #
3. 

   Filou
   

   offline

   Moderator

   @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...)

   Posted 3 years ago #
4. 

   Aleksej
   

   offline

   Coder-hobbyist

   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.

   Posted 3 years ago #
5. 

   gibor
   

   offline

   Moderator

   @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.

   Posted 3 years ago #
6. 

   Filou
   

   offline

   Moderator

   @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?!?)

   Posted 3 years ago #
7. 

   gibor
   

   offline

   Moderator

   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.

   Posted 3 years ago #
8. 

   Filou
   

   offline

   Moderator

   Although I doubt that the difference is THAT big, did you strip the binary after compilation?

   Posted 3 years ago #
9. 

   gibor
   

   offline

   Moderator

   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).

   Posted 3 years ago #
10. 

    Filou
    

    offline

    Moderator

    I mean by using strip --strip-unneeded <binary> which should remove any non-needed relocation and debugging symbols ...?
    (see https://man7.org/linux/man-pages/man1/strip.1.html )

    Posted 3 years ago #
11. 

    mistfire
    

    offline

    Member

    @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.

    Posted 3 years ago #
12. 

    gibor
    

    offline

    Moderator

    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.

    Posted 3 years ago #
13. 

    Filou
    

    offline

    Moderator

    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

    ;-)

    Posted 3 years ago #
14. 

    alanyih
    

    offline

    Administrator

    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

    Posted 3 years ago #
15. 

    Filou
    

    offline

    Moderator

    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
    /etc/init.d/rcS start
    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
    killall lxpanel && lxpanel &
    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!

    Attachments

    1. 210619_SliTaz64_screenshot_Screen3.jpg (52.6 KB, 301 downloads) 3 years old
    2. 210619_SliTaz64_screenshot_Screen2.jpg (78.8 KB, 278 downloads) 3 years old
    3. 210619_SliTaz64_screenshot_Screen1.jpg (193.4 KB, 338 downloads) 3 years old
    4. 210619_SliTaz64_screenshot.jpg (148 KB, 292 downloads) 3 years old

    Posted 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.