Max tcz mounts

[Jason W]

Appsaudit is in base and is the official way of dealing with deleting packages. 

And for the second time, this is not the thread to discuss uninstalling.  Do so in the relevant threads.

[Guy]

You are all doing a great job. I like the improvements you are making in Tiny Core. I don't want to add any extra work. However, here is something to think about.

At the present time, there are over 160 dependencies which are only required by one program.

Some of these may be required by future programs.

Some are unique to one program.

In future, these unique extensions could be combined.

For example, iptables and firewall are only used together, and could be combined.

I know there may be a graphical firewall interface in the future.


A bit of trivia. Dependencies required by the most others are:

expat2.tczl
fontconfig.tczl
glib2.tczl
graphics-libs-1.tczl
libxml2.tczl
pixman.tczl
pango.tczl
cairo.tczl

These are all dependencies of over 100 extensions.

Some are duplicate, that is dependencies of dependencies.

[Jason W]

When two items are practically never used apart from one another, like SDL, tck/tk, ogg-vorbis, and such, there is some leeway in how the extension maker decides to package it.  I normally prefer the modular approach, unless an extension is self contained.

As to how this relates to the mounted loop limit that is apparently in place, I see no need for us to alter our course when it comes to modularity.  It appears the last commit in loop.c in the kernel was the one that did away with the loop limit:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=history;f=drivers/block/loop.c;hb=73285082745045bcd64333c1fbaa88f8490f2626

Even if the limit was reimposed before 2.6.29, my hunch is that it will be raised or done away with in the near future.  It is of interest given our modular system with the option of loop mounting, but having a limit of 256 is not a cause for alarm.  

EDIT:  FWIW  2.6.31 allows mounting more than 256 loops, tried it on my Lunar box.  So the limit has been dealt with on the kernel end and will not be a concern in the long run.