New package manager

[wysiwyg]

It seams that TC developers think that users initially search for apps, then users settle with some apps and updates seldom.

That's pretty much what I do.  I have recently started doing occasional extension updates but I haven't exactly made a habit of it.

In a future version pax will have the ability to alert and/or automatically perform this task.  I just needed to iron out what needed to be done beforehand.  Most people don't do updates if they don't know they are available.  Actually most people don't install updates even when they're told they have them.  This is obviously unsafe and leaves you subject to exploits...

[Leee]

I follow the forums here pretty closely, so if there's an update to an extension I use, I'll usually know about it that way and update as needed.  Not a big fan of automatic updates in general.
That's not say I;m not interested in pax - but at this point it's really just a curiosity to me.

[wysiwyg]

I completely understand.  I'm also not a big fan of automatic updates (which is why I didn't mandate them in pax).  To me freedom is better than anything.  Although freedom comes with responsibility.  If the user chooses not to update their system, then the consequences fall on them.

I do appreciate your curiosity for the project, and look forward to hearing any feedback you can provide.  I want the software to be as useful to people as possible, of course.

[nick65go]

looking into https://github.com/cliquesoft/pax/blob/main/bin/pax it seams it is a /bin/sh script, which is OK.
- An 'html' output option: it needs a "small browser" to see this output (you can be inspired by how fluff.tcz shows its help)
- A graphical interface: FLTK is in the base. [not GTK1/2/3 neither QT4/5/6. nor Xdialog when Wayland is the future].
As https://mirrors.dotsrc.org/tinycorelinux/17.x/x86_64/tcz/pax.tcz.tree shows, pax depends on "many" other tcz

Code: [Select]

pax.tcz
   coreutils.tcz
      gmp.tcz
   squashfs-tools.tcz
      liblzma.tcz
      lzo.tcz
      libzstd.tcz
      liblz4.tczThe package-manager belongs in the base, the base must / should be small, but pax+deps is not small size for now by "TC developers standards". Maybe I am wrong, but I know how hard / long was the discussion on TC boot / config parameters: a 4 byte file (containing just a boot option as text) have 4KB (a page) in RAM etc.

I wish you success, because I want TC to evolve. From my point of view the "libs dependency hell" was solved by an AWK engine or can be a C-compiled software (like in Arch-linux or Alpine-linux ). Maybe your focus is in download speed, or parallel sources; where is the bulk CPU consumption, in server or client, etc. I mean do you want to "protect" the web-server energy/bandwide by transferring the energy bill to the client-user, etc. I just ask...

If I may: It will be nice to define first what you improve (in Tinycore!), to measure what we have already (for a common user) and then you state by how much you WANT (not necessarily to achieve for now) to improve (in KB size, KB/second, or % or whatever).

[nick65go]

I am a novice in terms of software licensing. But I saw that "pax" has a "Cliquesoft Public License [CPLv2]".
I try to do not agree / obey (shame on me) with IP (intellectual property, aka new feudalism), the only acceptable license is something like this https://landley.net/toybox/license.html ; YMMV

[wysiwyg]

Hey nick65go, thanks for adding to the conversation!

looking into https://github.com/cliquesoft/pax/blob/main/bin/pax it seams it is a /bin/sh script, which is OK.
- An 'html' output option: it needs a "small browser" to see this output (you can be inspired by how fluff.tcz shows its help)
- A graphical interface: FLTK is in the base. [not GTK1/2/3 neither QT4/5/6. nor Xdialog when Wayland is the future].
As https://mirrors.dotsrc.org/tinycorelinux/17.x/x86_64/tcz/pax.tcz.tree shows, pax depends on "many" other tcz

Code: [Select]

pax.tcz
   coreutils.tcz
      gmp.tcz
   squashfs-tools.tcz
      liblzma.tcz
      lzo.tcz
      libzstd.tcz
      liblz4.tczThe package-manager belongs in the base, the base must / should be small, but pax+deps is not small size for now by "TC developers standards". Maybe I am wrong, but I know how hard / long was the discussion on TC boot / config parameters: a 4 byte file (containing just a boot option as text) have 4KB (a page) in RAM etc.

I wish you success, because I want TC to evolve. From my point of view the "libs dependency hell" was solved by an AWK engine or can be a C-compiled software (like in Arch-linux or Alpine-linux ). Maybe your focus is in download speed, or parallel sources; where is the bulk CPU consumption, in server or client, etc. I mean do you want to "protect" the web-server energy/bandwide by transferring the energy bill to the client-user, etc. I just ask...

I completely agree with everything you said.  I'll tackle them one at a time...

1. Yes the project is a shell script to make is portable to all CPU architectures without having to compile anything.  It's not as efficient as a compiled binary, but there is no gain this way since the tce-* package manager is also scripts.

2. The various output options are so that pax can be integrated into various software and not just for command line usage.  Currently there is the default text, and two XML options that can be used with any web-based GUI.  There is also a fifo option so that pax can run in a "client control mode".  This will allow pax to basically work in a network where an administrator can perform software admin tasks on the clients without having to visit them (e.g. remotely installing, uninstalling, updating, etc).  I still have to build the server-side, but one can be put in place by a savvy admin.  I plan on expanding to include two more options: html and json.

3. The graphical interface for pax will be a web-based interface.  I just have to port several other applications into TC before I can get that going. However, if any other developers on here are interested in building a different type of interface (e.g. GTK, QT, FLTK, etc), I will be at their disposal to assist.

4. The coreutils dependency is required because pax needs the 'stat' binary to perform some tasks.  Unfortunately the busybox applet is not part of the TC ramdisk, so it requires that dependency.  If pax were the default package manager in TC, it could just install a single file out of the coreutils package and leave the rest, but the default tce-* scripts don't have this ability, so I'm stuck installing the entire package.  The squashfs-tools dependency I'm actually going to remove in the next version of pax.  It's only used when building from source code or packaging pre-compiled software, of which the vast majority of users do not do.

5. Yes, everything should be as small as possible.  If the TC team wants to add in the 'stat' busybox applet, that can reduce one of the two dependencies.  I can remove the other one in a future version.

If I may: It will be nice to define first what you improve (in Tinycore!), to measure what we have already (for a common user) and then you state by how much you WANT (not necessarily to achieve for now) to improve (in KB size, KB/second, or % or whatever).

This is a great point.  So there are several items:

1. Efficiency.  Unless the code has been updated, the tce-* scripts install each package (and their dependencies), then call ldconfig, udevadm, and then the package installation script. While this is not a big deal when installing a package at a time in a running system, it's inefficient during the boot process when everything is getting loaded.  pax doesn't do this.  It installs all the requested package (and dependency) files, then executes those calls only once.
There is also an install option to load packages in a single or dual-stage process when booting the system.  This can allow the device to boot faster while loading supplemental software in the background.  This is also not possible with the tce-* package manager.

2. Uniform execution. I'm not sure about the tce-* scripts, but the syntax with pax is uniform across commands.  For example, to copy, extract, or install packages from a different source (to an optional target directory) all has the same syntax with different actions:

Code: [Select]

pax -S /path/to/packages -{cei} PACKAGE(S) [TARGET DIRECTORY]

3. Single file. With pax there is one script to call, not many to perform different tasks.  This has an advantage and a disadvantage.  The advantage is that there's one program to learn, not multiple.  It also enables synergy among it's switches (as defined above).  The disadvantage is that the entire script must be loaded to perform a task, vs smaller individual script that do specific things.

4. Versatility. For example, pax can take a space separated list, list in a text file, or a directory as the parameter to use when performing an action:

Code: [Select]

pax -c package1 package2 package3
pax -c textfile.txt
pax -c /path/to/packages
This is not possible with the tce-* scripts.

5. Features. The feature set in pax is larger than that of the tce-* equivalents.  There are only one or two features not yet implemented (one of which is searching) because I needed to see how TC performed this task beforehand so that it could be designed properly.  It takes a long time to code, test/debug, and document all of this (4 months for the latest version of pax).

I think I've addressed the improvements in this reply - reduction of dependencies (which will require the TC team for coreutils) and the addition of a few outstanding features.

If you have anything else nick65go, feel free to reply.  I enjoy the conversation!

[wysiwyg]

I am a novice in terms of software licensing. But I saw that "pax" has a "Cliquesoft Public License [CPLv2]".
I try to do not agree / obey (shame on me) with IP (intellectual property, aka new feudalism), the only acceptable license is something like this https://landley.net/toybox/license.html ; YMMV

I'm a big fan of Rob Landley!  I do agree that the 0BSD is one of the best licenses for freedom.  The CPLv2 is basically the GPLv2 without some of its clauses making it less restrictive.  So I'm actually making the software more free than by using the GPLv2 (which is a very widely used license for freedom).  See https://www.cliquesoft.org/#Licenses for more information.

BUT as I stated in the prior response, it takes a long time to build software.  That means I have to donate my time to do so instead of doing something else to make money.  It's expensive to build free software!  Again, it took me 4 months to re-design and re-build pax without earning a penny of revenue for my time spent.  As a way to potentially earn some money, I offer the ability to re-license the software using a version of the BSD for a fee (under the CPLv1).  This will probably never materialize, but it is an option to earn back some money.

[nick65go]

@wysiwyg: please let me clarify few things. I am a user not a developer. Tinycore is one of my hobbies, but not the only one. I freely and shameless express my controversial / personal opinions on this forum, taken the risk to be banned by admins.

For now I use CachyOS (KDE plasma) and I have fun with Archlinux or Alpinelinux. I keep an eye on Tinycore development, but I do not currently use it as my main OS, because my (pseudo) obsession with security (TC does not sign tcz packages, it used md5 instead of SHA*, default X* server as root, slow patch vulnerability, etc.).

I would like to recommend you to spend a little more time to analyze tce* scripts. Mostly tc-config and tce-load. Because if I am not wrong, about efficiency:
1. udevadm is used at boot-time (and stays in RAM) and one/two times when you load a device (sound card, wifi, etc). but not for usual tcz apps.
2. I had the impression that ldconfig is loaded one time (at boot-time for all onboot.lst), and then one-time after each user-chose selected/nominated tcz LIST.

I see you very passionate/ determined, so I do not wish to diminish your achievements. Especially, if you read the forum, you will see that  many (good in my opinion) proposals were rejected just because TC started and is committed for low resources aka 486 CPU, 64-128MB RAM etc. In this restricted environment every bytes count and improvements are hard to design (for core/base). In base is kernel + libc + busybox, so playground is just sh scripts...and ideas recycled from 2009-2025.

[wysiwyg]

Hey nick65go, thanks for the continued conversation!

What's your draw to Arch and Alpine?

I have analyzed the tce-load script, which is what pax was originally forked from.  It is no longer a fork and is its own project.  In regards to your points, they are both wrong. udevadm is what is used to trigger udev to basically re-examine the attached devices and bring any new ones onboard, or discard removed ones from the device.  ldconfig is used when libraries are added or removed.  This is why those commands have to be executed (sometimes) depending on particular files that get installed in packages.  As I stated, pax only (potentially) runs these commands once per execution regardless of how many packages are being installed, whereas the tce-load script calls them repeatedly (if applicable) per package being requested to install.  Thus, pax is more efficient in this manner.

I do agree that there are parts that get dismissed due to their goals of being small.  This is why I was "shocked" about how package searching was handled.

And no offense was taken.  I am passionate about my projects.  I have spent a considerable amount of my life working on all of them lol

[Rich]

Hi wysiwyg

... As I stated, pax only (potentially) runs these commands once per execution regardless of how many packages are being installed, whereas the tce-load script calls them repeatedly (if applicable) per package being requested to install.  ...

Except when using:

Code: [Select]

tce-load -bwhich tells it you are booting. Then depmod, ldconfig, and tce.installed get run in the end.

I mention some of that here:
https://forum.tinycorelinux.net/index.php/topic,27231.msg175177.html#msg175177

Run these two commands to see where some of this takes place:

Code: [Select]

grep -n BOOTING /usr/bin/tce*
grep -n "/etc/sysconfig/newmodules" /usr/bin/tce*

[wysiwyg]

Hey Rich!

Was the code updated at some point to include that?  The original fork from tce-load was back somewhere around 2017 (almost 10 years ago) and I don't think that was the case.  But then again, it was very long ago...

Just out of curiosity, why not have that functionality at all times?

[Rich]

Hi wysiwyg
I don't know when it was enacted. This is from TC10 x86:

Code: [Select]

tc@E310:~$ grep -n BOOTING /usr/bin/tce*
/usr/bin/tce-load:10:unset WGET INSTALL COPYINSTALL BOOTING ONDEMAND DOWNLOAD_ONLY LOAD_ONLY SUPPRESS
/usr/bin/tce-load:41:   if [ "$BOOTING" ]; then
/usr/bin/tce-load:56:           b) BOOTING=TRUE ;;
/usr/bin/tce-load:92:   [ "$BOOTING" ] || rmdir /mnt/test
/usr/bin/tce-load:96:   if [ "$BOOTING" ]; then
/usr/bin/tce-load:107:          if [ "$BOOTING" ] ; then
/usr/bin/tce-load:132:                  if [ ! "$BOOTING" ]; then
/usr/bin/tce-load:146:                          if [ ! "$BOOTING" ]; then
/usr/bin/tce-load:154:          [ "$BOOTING" ] && [ "$SHOWAPPS" ] && echo -n "${YELLOW}$APPNAME ${NORMAL}"
/usr/bin/tce-load:241:if [ "$INSTALL" ] && [ ! "$BOOTING" ]; then
/usr/bin/tce-load:292:[ "$BOOTING" ] && exit 0I think that's from around 2019.

[wysiwyg]

Hey Rich!

Ok, if it was implemented around that time, that would probably explain why I didn't see it in the version I originally forked from (which was 7.x in 2017).  When browsing through the source, I didn't understand why it was being called the way it was.  Obviously I adjusted that in my own project.  If that update was made in 2019, that would most likely have been TC 9.x...

Thanks for the tidbit!

[Rich]

Hi wysiwyg
I don't know when it was implemented. I took a look at
rootfs.gz for TC5 (2013/2014) and found this:

Code: [Select]

tc@E310:~/TinycoreISOs/RootfsTC5$ grep -n BOOTING usr/bin/tce*
usr/bin/tce-load:10:unset WGET INSTALL COPYINSTALL BOOTING ONDEMAND DOWNLOAD_ONLY LOAD_ONLY SUPPRESS
usr/bin/tce-load:50:            b) BOOTING=TRUE ;;
usr/bin/tce-load:108:   if [ "$BOOTING" ]; then
usr/bin/tce-load:119:           if [ "$BOOTING" ] ; then
usr/bin/tce-load:144:                   if [ ! "$BOOTING" ]; then
usr/bin/tce-load:159:                           if [ ! "$BOOTING" ]; then
usr/bin/tce-load:167:           [ "$BOOTING" ] && [ "$SHOWAPPS" ] && echo -n "${YELLOW}$APPNAME ${NORMAL}"
usr/bin/tce-load:223:if [ "$INSTALL" ] && [ ! "$BOOTING" ]; then
usr/bin/tce-load:304:[ "$BOOTING" ] && exit 0
At least some of this was already in place back then.

[nick65go]

What's your draw to Arch and Alpine?

I will not buy/repair OLD devices anymore, I have some of them already FULL functional (if you forget their heat/noise, dead battery etc). Most with 1- 4+GB RAM, 100-250+ GB HDD, i686+ CPU, starting from year 2006 (20 years ago!).

Today I can only buy x86-64 NEW devices. So, compatibility with 486 CPU is not useful for me for the future. A USB stick is 17-40 EUR for a 150-400 MB/s speed and 64-90GB, with a live span of 2-5 years (aka one beer/year). Compare this with all tcz packages at 4GB total. Even a full Archlinux is 20GB storage.

Capitalist markets force me to buy, every 5-8 years (because planed obsolesce), a device with more RAM/HDD than I really need, therefore my focus shifted to security. This means distro with more developers, faster patching, better secured channels for updating, etc. Yes, this means undesirable bloat/fat, but I already paid for not-need hardware. It depends what someone use the software for. I spend money to gain time, for things that matter to me. (Tinycore is still on my list).