I have to say: That what RSH did implement, also covers this field of management and would be really very good but reduces the freedom for amateur coders to change heavily the system because they are dependant of a perfect working download depository and a very strong organisation of the depository would be needing to cover the terrible wide scope of visions of all Puppy coders! And organisation is probably that what the Puppy world is missing more...tronkel wrote:@oui wrote:
Yes, that's a good point.in my eyes, Puppy has already reached 10 years now and it continues to use only ONE main sfs file
In the early days when the Puppy ISO's were small, nobody really thought about the fact that with one sfs you are loading everything into memory whether or not you need all that software that you might never use.
Now that Puppy has got bigger, this would certainly be more of an issue than before - but not too serious as yet. Would be cool if some developer could look at this and implement what Oui has suggested in his previous post.
I read somewhere that Linus Torvalds is also not happy about the ever-expanding size of the Linux kernel. Seems not to know what to do about it though. New hardware is appearing at an ever-accelerating rate and inevitably has to be catered for within the kernel. So it's a real concern nowadays.
"My" (*1 way with pre defined subdir is more flexibel... Only the subdir are predefined, correspond to parts of the old main.sfs and the content can be free as each author will wish after that (name, size, content of the file itself: the system has only to collect and concatenate the parts one after the other, hopping that that works harmonic ; SliTaz does that since version 4.0 with 4 little *.sfs-segments but without subdir's so that the names and interdependences are rigorous!) and realize itself. it makes the remastering different and probably more complicated (*2 but can also simplify parts of the system: you don't need «load SFS on fly» any more: that what is in the correct subdir will be taken, the system has nothing to search any more! And it would be possible to mark what goes into RAM and what has to be read from HD or other slow memory on system poor concerning RAM equipment (*3 .
kind regards
(*1 My way is not my way: It is copied from the Linux system management with the fixed name of the main dir of tree
(*2 must not be so: to install the 4 SliTaz *.sfs file fragments frugal, you only need to concatenate them with the command «cat» to a only one big sfs file! I suppose that the system does about that, or somewhat with the same effect internally loading the system and continue to work with a bigger file or memory content as the fragments handled at development time and beeing to find in the ISO!
I did realize very big SliTaz.sfs file on my laptop having very more RAM as my PC's but I were always limited with a proportion 1:3 (if size of compressed file is 1 you need 3 time this size of RAM)... after that, kernel panic follows! for coders having yet old hardware, often young people with good formation and ideas as well as a lot of energy because they don't have family to care of etc., but low budget, it is extremely limitativ!
(*3 a simple flag file, also empty, named f. ex. «please.ram», placed in the concerned subdir, would be enough! I usually don't need to put libreoffice into the RAM to enter individual letters slowly hit clumsy on my keyboard each after the other, but I need some applications in RAM needing all the calculation power of my system to build some big pictures or convert sounds using a complicate algorithm...