Posted: Tue 31 Mar 2020, 15:55
Mike Walsh, "to disentangle the KDEnlive stuff from the Openshot stuff, hopefully resulting in a 'standalone' SFS of current, 2-series Openshot that anyone can just load, and it'll run.....I don't think that someone is going to be me, somehow... (*shakes head*) Mikeslr, d'you fancy attacking this one with P.A.D.S and a copious supply of coffee...? 
"
Not me.
O.F.I.N.S.I.S's build has, apparently, overcome the primary reason for NOT simultaneously having both Openshot and KDEnlive one's system: the previous incompatibility of the python modules they employed.
Here's the thing which I've yet to completely get my head around. The computing environment has changed and somewhere along the line of Puppy's evolution something may also have changed; or maybe I always misunderstood. A couple years ago I ran some experiments comparing the amount of available RAM with applications installed as pets, loaded as SFSes or merely linked as portables. At that time having only 512 Mbs of RAM or less was common. The thinking was SFSes were superior to pets because by unloading an SFS it would obviously use No RAM; while a pet, occupying space in a SaveFile would always need some RAM. That concept held true. However, what the exploration revealed was that even the then RAM hog LIbreOffice, however deployed, only required what in today's computing environment is an insignificant amount of RAM WHEN THE APPLICATION WAS NOT IN USE. By way of illustration LibreOffice at that time required 768 Mbs of Space on Storage and/or in a SaveFile: if installed but not opened it only required about 11 Mbs of RAM more than the same Puppy booted to desktop without LibreOffice installed. What's 11 Mbs of RAM when you now have 2 Gb or more? Especially under Bionicpup64 which, itself, requires at least 1 Gb for satisfactory performance.
My recent exploration of nic007's technique of substituting an adrv for a SaveFile reveals similar results. An adrv created from a SaveFile which exceeded 1 Gb had hardly any impact on the available RAM at bootup.
I used to think this phenomena had to do with the creation of inodes which pointed to files on Storage rather than copying them into RAM. But, explorations with using an adrv and removing the USB-Key from which Puppy was booted confirmed william2's proposition that 'everything' was copied into RAM on bootup. So I guess it has to do with caching and buffering --which I don't understand.
At any rate, its hardly likely that removing those files in O.F.I.N.S.I.S' 284 Mb SFS which are only required by KDEnlive would make a significant difference in the amount of available RAM for doing anything.
"Not me.
O.F.I.N.S.I.S's build has, apparently, overcome the primary reason for NOT simultaneously having both Openshot and KDEnlive one's system: the previous incompatibility of the python modules they employed.Here's the thing which I've yet to completely get my head around. The computing environment has changed and somewhere along the line of Puppy's evolution something may also have changed; or maybe I always misunderstood. A couple years ago I ran some experiments comparing the amount of available RAM with applications installed as pets, loaded as SFSes or merely linked as portables. At that time having only 512 Mbs of RAM or less was common. The thinking was SFSes were superior to pets because by unloading an SFS it would obviously use No RAM; while a pet, occupying space in a SaveFile would always need some RAM. That concept held true. However, what the exploration revealed was that even the then RAM hog LIbreOffice, however deployed, only required what in today's computing environment is an insignificant amount of RAM WHEN THE APPLICATION WAS NOT IN USE. By way of illustration LibreOffice at that time required 768 Mbs of Space on Storage and/or in a SaveFile: if installed but not opened it only required about 11 Mbs of RAM more than the same Puppy booted to desktop without LibreOffice installed. What's 11 Mbs of RAM when you now have 2 Gb or more? Especially under Bionicpup64 which, itself, requires at least 1 Gb for satisfactory performance.
My recent exploration of nic007's technique of substituting an adrv for a SaveFile reveals similar results. An adrv created from a SaveFile which exceeded 1 Gb had hardly any impact on the available RAM at bootup.
I used to think this phenomena had to do with the creation of inodes which pointed to files on Storage rather than copying them into RAM. But, explorations with using an adrv and removing the USB-Key from which Puppy was booted confirmed william2's proposition that 'everything' was copied into RAM on bootup. So I guess it has to do with caching and buffering --which I don't understand.
At any rate, its hardly likely that removing those files in O.F.I.N.S.I.S' 284 Mb SFS which are only required by KDEnlive would make a significant difference in the amount of available RAM for doing anything.
