A vote for a modular use of Puppy Linux
I believe targetting sfs usage as a method that inherently can easily break the system in a way that nothing else does was painting an inaccurate picture of the situation. A pet, deb, tgz rpm and even building from source can equally do exactly the same damage. Appdir may indeed avoid the possibility which would be a plus point but this childish smear campaign is getting a little tedious and not really contributing to anything constructive,
mike
mike
If an sfs is mounted in one of the main aufs layers, then it certainly has the ability to bork the system -at least temporarily. But one can also mount and union them in such a way to avoid that and isolate any problems. A file system image doesn't have to be unioned at all in order to be useful -but whether that will work for a given program depends on how flexible the program itself is.
And in the end, there is no hard criteria to distingush between an archive (pet, AppDir, etc) and a file sysetm image like sfs or s2fs files are. Any of them can be either mounted or extracted transparently to the user/system. The devil's in the details of which parts of the filesystem the program accesses. If it doesn't use anything under /etc or /usr/share, then it's very easy to make them work using wrappers which set the PATH and LD_LIBRARY_PATH -this is exactly what most AppDirs also do -or the programs are simply compiled to run from a non-standard location wherever you want them to be.
But if the programs need /etc or /usr/share -and many do, then the only way to work the program into the system is by using those normal paths -placing the software there, or use a union-mount unionfs which makes your wanted files appear to be in those paths. If the software must be available to any client at every level of the system, then your unioning needs to go in at the system level -and you would be well advised to not pursue this -that's where real, installed packages should be used.
OTOH, a unioned chroot provides a unique somewhat-secure environment for just the application you want. Any number of such mounts can be used at a time and can be mounted/unmounted on the fly without affecting the system at all. If you had to pick only one way to make software dynamically available on the system -modularly, that is, then the union-mount+chroot is the only way to be able to cover all bases. Puppy normally uses an underlying aufs with multiple layers which already stretch the sanity of such a system, I would not recommend trying to intervene in that system at all. And if you are talking about system-level software, then it is best made usable in the paradigm of an 'installed package'.
And in the end, there is no hard criteria to distingush between an archive (pet, AppDir, etc) and a file sysetm image like sfs or s2fs files are. Any of them can be either mounted or extracted transparently to the user/system. The devil's in the details of which parts of the filesystem the program accesses. If it doesn't use anything under /etc or /usr/share, then it's very easy to make them work using wrappers which set the PATH and LD_LIBRARY_PATH -this is exactly what most AppDirs also do -or the programs are simply compiled to run from a non-standard location wherever you want them to be.
But if the programs need /etc or /usr/share -and many do, then the only way to work the program into the system is by using those normal paths -placing the software there, or use a union-mount unionfs which makes your wanted files appear to be in those paths. If the software must be available to any client at every level of the system, then your unioning needs to go in at the system level -and you would be well advised to not pursue this -that's where real, installed packages should be used.
OTOH, a unioned chroot provides a unique somewhat-secure environment for just the application you want. Any number of such mounts can be used at a time and can be mounted/unmounted on the fly without affecting the system at all. If you had to pick only one way to make software dynamically available on the system -modularly, that is, then the union-mount+chroot is the only way to be able to cover all bases. Puppy normally uses an underlying aufs with multiple layers which already stretch the sanity of such a system, I would not recommend trying to intervene in that system at all. And if you are talking about system-level software, then it is best made usable in the paradigm of an 'installed package'.
In the traditional approach any additional software would be attached, mounted, installed, copied to /usr/local.... that was the purpose I believe.
I did once upon a time have an apps folder on a hard drive with a selection of self contained programs with various twiddles to get them to run. All that left in there now is a pile of wine software....too much messing about especially when the system changes.
The attraction is indeed convenience.... inserting into the core file structure will work for any application, and indeed that does raise the possibility of messing things up....I installed pet x and now application y no longer runs.... how many posts a week for that one?
I definately appreciate that 3rd party software keeping out of the core system is a good move... dsl took this approach IIRC though it did make the head spin with the knoppix file structure.
I suppose it a bit like the running as root argument.... its fine if common sense is used. Layering in a package that's built properly to an organised structure will not cause a problem. Having a distro with packages from every tom, dick and harry is perhaps more to the crux of the problem than how those items are installed.
No install method can be blamed for reckless package policies in the same way airbags are not really a cure for dangerous driving.
Chrooting ... not something I have dabbled in much apart from building busybox with ulibc... does it give a transparent system from a users point of view? In the busybox toolchain for example I was in a non puppy system for the duration.
One other thing... this ere puppy is supposed to be a live portable distro for use in odd places.... this does affect its design criteria... small, simple, stripped down, modular (it is really ) , rules get bent or conveniently forgotten.
Its not what I use by default only for experimenting on... those main distro features are a better bet for an installed system.
Trusting all your precious data to a pile of hacky scripts is not really a good policy but for a quick furkle its fine
mike
I did once upon a time have an apps folder on a hard drive with a selection of self contained programs with various twiddles to get them to run. All that left in there now is a pile of wine software....too much messing about especially when the system changes.
The attraction is indeed convenience.... inserting into the core file structure will work for any application, and indeed that does raise the possibility of messing things up....I installed pet x and now application y no longer runs.... how many posts a week for that one?
I definately appreciate that 3rd party software keeping out of the core system is a good move... dsl took this approach IIRC though it did make the head spin with the knoppix file structure.
I suppose it a bit like the running as root argument.... its fine if common sense is used. Layering in a package that's built properly to an organised structure will not cause a problem. Having a distro with packages from every tom, dick and harry is perhaps more to the crux of the problem than how those items are installed.
No install method can be blamed for reckless package policies in the same way airbags are not really a cure for dangerous driving.
Chrooting ... not something I have dabbled in much apart from building busybox with ulibc... does it give a transparent system from a users point of view? In the busybox toolchain for example I was in a non puppy system for the duration.
One other thing... this ere puppy is supposed to be a live portable distro for use in odd places.... this does affect its design criteria... small, simple, stripped down, modular (it is really ) , rules get bent or conveniently forgotten.
Its not what I use by default only for experimenting on... those main distro features are a better bet for an installed system.
Trusting all your precious data to a pile of hacky scripts is not really a good policy but for a quick furkle its fine
mike
The post was in thought to your post, no smear has ever been intended. Hope none is taken...
The union FS is hackish, and it will never be in the main stream kernel code.
But works fairly well all in all.... But if it`s not needed, why have it.?
amigo; My main worry about chroot unions is the cpu ( & maybe ram ) load of many of them.
Mike and I agreed running aufs seems to produce a load, but adding layers doesn`t so much.
This is just our observation, so it would have to be tested to really mean much at all...
Mike; A chroot-union is in a dir., same as a AppDir / RoxApp is. The shell instance jumps into the dir. and sets it as /.
You can look into the dir. and see a little copy of / running with the app in it. It works very well as amigo says.
I`d rather have relocatable apps, compiled that way, or some links is okay. Chrome needs only 1 link to work.
A few chroot-union apps that are troublesome and can`t be made to stand-alone easily is okay.
The union FS is hackish, and it will never be in the main stream kernel code.
But works fairly well all in all.... But if it`s not needed, why have it.?
amigo; My main worry about chroot unions is the cpu ( & maybe ram ) load of many of them.
Mike and I agreed running aufs seems to produce a load, but adding layers doesn`t so much.
This is just our observation, so it would have to be tested to really mean much at all...
Mike; A chroot-union is in a dir., same as a AppDir / RoxApp is. The shell instance jumps into the dir. and sets it as /.
You can look into the dir. and see a little copy of / running with the app in it. It works very well as amigo says.
I`d rather have relocatable apps, compiled that way, or some links is okay. Chrome needs only 1 link to work.
A few chroot-union apps that are troublesome and can`t be made to stand-alone easily is okay.
Ok.
The SFS P.L.U.S. stored in the Modularity Package was 3.9.3.
The RoxApp Builder stored in the Modularity Package was 0.9.0
Current Versions are 3.9.9-42 (SFS P.L.U.S.) and 0.9.9-8 (RAB).
So, as the Version Numbers may show: I've done a lot of improvements, bug-fixes and additions to the SFS Package.
I feared the Moment when entering a 'finshed' state, because of writing a documentation for all of this.
Even to present just a short and quick guide to each one of the 25+ Applications of the SFS P.L.U.S., would result in 25 (or even much more) Pages to have a completed quick guide documentation.
I really don't like to write documentations, I like to write applications!
So, I've made a step aside and took a look at what I've had done so far.
- all those Applications for the use on and work with SFS Modules
- RoxApp Builder to create automatically different types of RoxApps
- Application Kiosk, another GtkDialog-GUI based Application-Starter
- - which is inspired by and does look like SFR's IconFinder - just for the installed Applications
I thought to myself: there must be a way to use all of this -and what I've learned while developing these Applicatons- in a much smarter way; probably resulting in just a single Application.
Since everything is already in a Puppy Linux that would be needed for a really smart and useful Version of this all, and that would exclude everything what's LazY Puppy related or would need to have some LazY Puppy Specials installed, I felt in Love with the idea to write all this again - from scratch, but using some LazY Puppy SFS P.L.U.S. Code snippets.
So, I pointed my focus to realize a Version that would need only, what's already installed in a Puppy Linux:
- sfs_load (>=1.9)
- gtkdialog4 (>=0.8.0 - 0.8.4 was used at development and testings)
- Xdialog (should be in all Puppies)
- download_file (Puppy's download script)
That's all.
Before announcing results and features I need to make a remark.
This remark is related to all the discussions on the forum about what has to be changed/removed from a Puppy Linux.
Remove all the Liar-Stuff from Puppy Linux!
That actually means: remove those scripts and applications, that is telling the user, he/she can't download and use SFS Modules and would need to create a personal storage file and need to do a reboot at first.
These times are gone since sfs_load has been published!
At least, they are gone right now!
So, I'm announcing now:
SFS P.L.U.S. IS DEAD! LONG LIVE SARA!
Actually SARA B., the result of my work during the last weeks.
A (S)tand (A)lone (R)ox (A)pp (B)uilder!
SARA B. creates SARA R.S.D, the (S)tand (A)lone (R)ox (A)pp (R.)un (S.)cript (D.)irectory !
SARA B. is self-explanatory (by GUI ToolTips) and also self-configurable (by 'init_' script that removes everything not longer needed after it is configured including itself).
It also can be re-configured manually and easily by a config file.
It has a right-click menu with multiple options to edit the script and config file, add a menu entry or desktop button, unload the SFS Module etc.pp.
Currentlyt comes as: 81 K (25 files, 6 directories) and
it stays as: 37 K (16 files, 5 directories) in uncompressed sizes.
To recall, SFS P.L.U.S. 3.9.9-42 is currently at: 6246 K (1911 files, 437 directories). Of course it comes with some special tools to create SFS files from PET files and to patch the RunScrips etc.pp.
But SARA B. is much smarter related to the main parts of SFS P.L.U.S.: the RunScript-Builder and SFS to SFS P.L.U.S. Converter. SARA B. includes the SFS dependencies (its names) into the RunScript - SFS P.L.U.S. doesn't. So, the Converter is not longer needed and to add or to remove dependencies is way faster done manually in a text editor as it can be done by editing a SFS Module.
There are three ways to create a SARA R.S.D. for an existing SFS Module:
1. manually by editing the config file and renaming the SARA B. Directory (a copy of it)
2. automatically by drag'n'drop of a SFS Module onto the SARA B. Directory
3. automatically by drag'n'drop multiple SFS Modules onto the SARA B. Directory
Way No. 3 is a very special advantage because one can choose the main SFS Module in the SARA B. GUI and all other Modules listed are defined automatically as dependent SFS Module to the main SFS Module.
This means: it could be a real dependent SFS Module like Java or Python etc.pp. And it could be also just a collection of SFS Modules to be loaded when the main SFS Module is used.
Example on Graphics work:
- Main Application would be the GIMP
- Sub Application would be a Image Viewer like XnView
(or even reverted!)
Ok, that's it so far. Later more.
I need to do now translations from DE to EN plus some reboots to do some testings again. But since this whole thing is already tested in multiple
different puppies and already in use for a long time, I might be too LazY to do to many reboots.
Ah, and not to forget: it WORKS now in Wheezy!
Currently using it and posting from it. In use is a SARA R.S.D of LP2_Firefox7.sfs and also Go-OO-3.2.1-Lucid.sfs (not edited, just as it has downloaded). Could not test the GIMP, because of a installed lib-gimp version that conflicts to all my GIMP SFS Modules.
LP2_Gimp273.sfs
LP2_Gimp2611.sfs
LP2_Gimp2612.sfs
LP2_Gimp-2.7.1-1-w5.sfs
LP2_Gimp-2.7.1-i386.sfs
LP2_GIMP-2.8.4-Full.sfs
LP2_Gimp-2.8.10-precise.sfs
LP2_GimpFull2610.sfs
LP2_GimpPainter-2.8.7.sfs
RSH
The SFS P.L.U.S. stored in the Modularity Package was 3.9.3.
The RoxApp Builder stored in the Modularity Package was 0.9.0
Current Versions are 3.9.9-42 (SFS P.L.U.S.) and 0.9.9-8 (RAB).
So, as the Version Numbers may show: I've done a lot of improvements, bug-fixes and additions to the SFS Package.
I feared the Moment when entering a 'finshed' state, because of writing a documentation for all of this.
Even to present just a short and quick guide to each one of the 25+ Applications of the SFS P.L.U.S., would result in 25 (or even much more) Pages to have a completed quick guide documentation.
I really don't like to write documentations, I like to write applications!
So, I've made a step aside and took a look at what I've had done so far.
- all those Applications for the use on and work with SFS Modules
- RoxApp Builder to create automatically different types of RoxApps
- Application Kiosk, another GtkDialog-GUI based Application-Starter
- - which is inspired by and does look like SFR's IconFinder - just for the installed Applications
I thought to myself: there must be a way to use all of this -and what I've learned while developing these Applicatons- in a much smarter way; probably resulting in just a single Application.
Since everything is already in a Puppy Linux that would be needed for a really smart and useful Version of this all, and that would exclude everything what's LazY Puppy related or would need to have some LazY Puppy Specials installed, I felt in Love with the idea to write all this again - from scratch, but using some LazY Puppy SFS P.L.U.S. Code snippets.
So, I pointed my focus to realize a Version that would need only, what's already installed in a Puppy Linux:
- sfs_load (>=1.9)
- gtkdialog4 (>=0.8.0 - 0.8.4 was used at development and testings)
- Xdialog (should be in all Puppies)
- download_file (Puppy's download script)
That's all.
Before announcing results and features I need to make a remark.
This remark is related to all the discussions on the forum about what has to be changed/removed from a Puppy Linux.
Remove all the Liar-Stuff from Puppy Linux!
That actually means: remove those scripts and applications, that is telling the user, he/she can't download and use SFS Modules and would need to create a personal storage file and need to do a reboot at first.
These times are gone since sfs_load has been published!
At least, they are gone right now!
So, I'm announcing now:
SFS P.L.U.S. IS DEAD! LONG LIVE SARA!
Actually SARA B., the result of my work during the last weeks.
A (S)tand (A)lone (R)ox (A)pp (B)uilder!
SARA B. creates SARA R.S.D, the (S)tand (A)lone (R)ox (A)pp (R.)un (S.)cript (D.)irectory !
SARA B. is self-explanatory (by GUI ToolTips) and also self-configurable (by 'init_' script that removes everything not longer needed after it is configured including itself).
It also can be re-configured manually and easily by a config file.
It has a right-click menu with multiple options to edit the script and config file, add a menu entry or desktop button, unload the SFS Module etc.pp.
Currentlyt comes as: 81 K (25 files, 6 directories) and
it stays as: 37 K (16 files, 5 directories) in uncompressed sizes.
To recall, SFS P.L.U.S. 3.9.9-42 is currently at: 6246 K (1911 files, 437 directories). Of course it comes with some special tools to create SFS files from PET files and to patch the RunScrips etc.pp.
But SARA B. is much smarter related to the main parts of SFS P.L.U.S.: the RunScript-Builder and SFS to SFS P.L.U.S. Converter. SARA B. includes the SFS dependencies (its names) into the RunScript - SFS P.L.U.S. doesn't. So, the Converter is not longer needed and to add or to remove dependencies is way faster done manually in a text editor as it can be done by editing a SFS Module.
There are three ways to create a SARA R.S.D. for an existing SFS Module:
1. manually by editing the config file and renaming the SARA B. Directory (a copy of it)
2. automatically by drag'n'drop of a SFS Module onto the SARA B. Directory
3. automatically by drag'n'drop multiple SFS Modules onto the SARA B. Directory
Way No. 3 is a very special advantage because one can choose the main SFS Module in the SARA B. GUI and all other Modules listed are defined automatically as dependent SFS Module to the main SFS Module.
This means: it could be a real dependent SFS Module like Java or Python etc.pp. And it could be also just a collection of SFS Modules to be loaded when the main SFS Module is used.
Example on Graphics work:
- Main Application would be the GIMP
- Sub Application would be a Image Viewer like XnView
(or even reverted!)
Ok, that's it so far. Later more.
I need to do now translations from DE to EN plus some reboots to do some testings again. But since this whole thing is already tested in multiple
different puppies and already in use for a long time, I might be too LazY to do to many reboots.
Ah, and not to forget: it WORKS now in Wheezy!
Currently using it and posting from it. In use is a SARA R.S.D of LP2_Firefox7.sfs and also Go-OO-3.2.1-Lucid.sfs (not edited, just as it has downloaded). Could not test the GIMP, because of a installed lib-gimp version that conflicts to all my GIMP SFS Modules.
LP2_Gimp273.sfs
LP2_Gimp2611.sfs
LP2_Gimp2612.sfs
LP2_Gimp-2.7.1-1-w5.sfs
LP2_Gimp-2.7.1-i386.sfs
LP2_GIMP-2.8.4-Full.sfs
LP2_Gimp-2.8.10-precise.sfs
LP2_GimpFull2610.sfs
LP2_GimpPainter-2.8.7.sfs
RSH
- Attachments
-
- image-1.jpg
- SARA B. running and in use in Wheezy 3.5.2.1
- (141.48 KiB) Downloaded 533 times
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
as a developement technician thats the bit that loomed in the background.I feared the Moment when entering a 'finshed' state, because of writing a documentation for all of this.
Bit like having a school trip and then having to write an essay about it
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Actually looking at your posts i doubt if technical documentation is a big problem for you
![Smile :)](./images/smilies/icon_smile.gif)
I was going to send out a search party for yourself and karl godt but in your case I really just need to learn to speak more than 10 words of german...
mike
What is a search party?mikeb wrote:I was going to send out a search party...
Why this?mikeb wrote:...for yourself and karl godt but in your case I really just need to learn to speak more than 10 words of german...
Is my English that kinda ugly?
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
Yeah, as you might know, the Girls, the Girls, the Girls...not seen yourself either for some time
Just felt in Love with SARA B.!
![Laughing :lol:](./images/smilies/icon_lol.gif)
Last edited by RSH on Tue 14 Jan 2014, 20:27, edited 1 time in total.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
Hmm using sex to sell operating system structures...it might just work ![Wink ;)](./images/smilies/icon_wink.gif)
'A vote for a sensuous use of Puppy Linux'
mike
did you happen to notice a low compression build of mksquashfs... seems like a speedy number with only a small size penalty.
http://murga-linux.com/puppy/viewtopic. ... 88&t=89173
![Wink ;)](./images/smilies/icon_wink.gif)
'A vote for a sensuous use of Puppy Linux'
mike
did you happen to notice a low compression build of mksquashfs... seems like a speedy number with only a small size penalty.
http://murga-linux.com/puppy/viewtopic. ... 88&t=89173
Yes. It did already work for almost all products that has tried to sell that way.mikeb wrote:Hmm using sex to sell operating system structures...it might just work
Did you have a look at the Icon?
If you could not come trough it (when resizing): it is made from a picture of a 20 year old Girl, that I was luckily allowed to take some beautiful pictures of in beginning of 2006. She is sitting on a chair, legs wide opened and holding my bass guitar between her legs.
I do like to do photographs from time to time and creating art works from such photographs or even parts of it. In case you have missed this (of course, I think you did), I had posted a few examples of my work here much earlier, at Nov. 2012.
Yes, thanks for the link. Saves me to do a search.mikeb wrote:Did you happen to notice a low compression build of mksquashfs... seems like a speedy number with only a small size penalty.
http://murga-linux.com/puppy/viewtopic. ... 88&t=89173
It's already on my list to be used in my LazY Remaster Suite and my version of pizzasgood's Edit-sfs which has already option to create GZ and/or XZ compressed SFS Modules.
mikeb wrote:'A vote for a sensuous use of Puppy Linux'
![Very Happy :D](./images/smilies/icon_biggrin.gif)
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
- matiasbatero
- Posts: 60
- Joined: Fri 12 Oct 2012, 01:27
- Location: Mar del Plata, Argentina
Hi RSH...
I see some topics talking about the potential incompatibility with shared libraries.
I found some linux distro, GoboLinux. That have a No traditional unix folders, with the purpose of allow to install programs with different versions, and expand compatibility.
You can see, how it works..
German: http://www.gobolinux.org/index.php?lang ... t_a_glance
English: http://www.gobolinux.org/?page=at_a_glance
If its applicable (in some way) you can do a lot of things.. but the more important thing is.. that SFS apps, doesn't needs maintenance in the future, because all versions still functional on any distro version if libraries are present. Maybe, extrapolating the actual SFS concept.. you can mount in layers like now, but over this best directory organization.
For me, it is a great way to expand modularity..
-----------
I don't know it is according to the post, but..
For the main purpose of this distro, I think that Puppy x64, with a real-time Kernel. is the best combination. And.. for older machines.. x86+PAE+RT kernel.
------------
I see some topics talking about the potential incompatibility with shared libraries.
I found some linux distro, GoboLinux. That have a No traditional unix folders, with the purpose of allow to install programs with different versions, and expand compatibility.
This is interesting, because the system can manage versions of same libraries. how concept is different, there isn't obligation to have only a unique version of libraries. Like all distros.GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux you don't need a package database because the filesystem is the database: each program resides in its own directory, such as /Programs/Xorg-Lib/7.4
You can see, how it works..
German: http://www.gobolinux.org/index.php?lang ... t_a_glance
English: http://www.gobolinux.org/?page=at_a_glance
If its applicable (in some way) you can do a lot of things.. but the more important thing is.. that SFS apps, doesn't needs maintenance in the future, because all versions still functional on any distro version if libraries are present. Maybe, extrapolating the actual SFS concept.. you can mount in layers like now, but over this best directory organization.
For me, it is a great way to expand modularity..
-----------
I don't know it is according to the post, but..
For the main purpose of this distro, I think that Puppy x64, with a real-time Kernel. is the best combination. And.. for older machines.. x86+PAE+RT kernel.
------------
Hi, matiasbatero.
Thank you very much for this information and the links.
After reading this I found it very very interesting, so I will have definitely a look at this. But I can't say if I would be able to do anything on this/like that. Might need to learn much more for this.
Currently I'm just still happy with the solutions I have created and if I'm running into modules including conflicting libraries, I do unload the conflicting Module. At the time I do have 443 SFS Modules in my SFS directory and only two or three happen to get in conflict with another. One of them is kdenlive-0.7.8, which conflicts with my vlc-1.1.7 version. I don't care on this because: when I'm using kdenlive I usually do not watch movies by using vlc.
RSH
Thank you very much for this information and the links.
After reading this I found it very very interesting, so I will have definitely a look at this. But I can't say if I would be able to do anything on this/like that. Might need to learn much more for this.
Currently I'm just still happy with the solutions I have created and if I'm running into modules including conflicting libraries, I do unload the conflicting Module. At the time I do have 443 SFS Modules in my SFS directory and only two or three happen to get in conflict with another. One of them is kdenlive-0.7.8, which conflicts with my vlc-1.1.7 version. I don't care on this because: when I'm using kdenlive I usually do not watch movies by using vlc.
RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
Ok.
Thanks to the new sfs_load 2.0.2 by shinobar I can re-edit the SFS P.L.U.S. RunScript Builder, to make the SFS P.L.U.S. completely working in Dpup Wheezy and MacPup 550 (wherein it has failed to work properly).
All testings using the new sfs_load 2.0.2 are going very well so far.
So, it might be worth the effort to do again some work on this.
RSH
Thanks to the new sfs_load 2.0.2 by shinobar I can re-edit the SFS P.L.U.S. RunScript Builder, to make the SFS P.L.U.S. completely working in Dpup Wheezy and MacPup 550 (wherein it has failed to work properly).
All testings using the new sfs_load 2.0.2 are going very well so far.
So, it might be worth the effort to do again some work on this.
RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
Resurrection of Underdog
Hi RSH & all,
matiasbatero's mention of gobolinux, in which modularity is enabled by an "unpuppy-like" technique, reminded me of underdog. Underdog enabled puppy to run the applications of an entirely different distro. Which, of course, means that conflicts between applications and libraries isn't a problem. It seemed to have two draw-backs: (1) the distro had to have been installed on Puppy's home partition; and (2) it required a reboot. The latter may have been the reason for the absence of application and library conflicts.
Barry K developed underdog in Puppy's early days. Today, the art of squashfiles has significantly advanced, and you guys (and girls) know a lot more. [To expand on Sergeant Hanz Schultz: "Ich weiß nichts und sprechen nicht Deutsch."] Recently, jrb successfully experimented with it. http://murga-linux.com/puppy/viewtopic.php?p=733079. Perhaps some further exploration can produce a vehicle for avoiding both application/library conflicts and the need to reboot.
And "low-compression" squash files are a great idea. Today, hard-drive (even USB-Key) space is cheap, while using CPU to decompress files as needed is wasteful.
mikesLr
matiasbatero's mention of gobolinux, in which modularity is enabled by an "unpuppy-like" technique, reminded me of underdog. Underdog enabled puppy to run the applications of an entirely different distro. Which, of course, means that conflicts between applications and libraries isn't a problem. It seemed to have two draw-backs: (1) the distro had to have been installed on Puppy's home partition; and (2) it required a reboot. The latter may have been the reason for the absence of application and library conflicts.
Barry K developed underdog in Puppy's early days. Today, the art of squashfiles has significantly advanced, and you guys (and girls) know a lot more. [To expand on Sergeant Hanz Schultz: "Ich weiß nichts und sprechen nicht Deutsch."] Recently, jrb successfully experimented with it. http://murga-linux.com/puppy/viewtopic.php?p=733079. Perhaps some further exploration can produce a vehicle for avoiding both application/library conflicts and the need to reboot.
And "low-compression" squash files are a great idea. Today, hard-drive (even USB-Key) space is cheap, while using CPU to decompress files as needed is wasteful.
mikesLr
Last edited by mikeslr on Fri 24 Jan 2014, 17:06, edited 1 time in total.