SCM Basics

[V.Krishn]

scm is quite similar to sfs modules for puppylinux, except that its more modular/dynamic.
Would it be good ides to have scm-build scripts for these scm instead directly of scm files.
Benefits:
1. Space save on server.
2.  Dynamic build on users end.
So while selecting a package, example, 'php' in appbrowser one can opt to install as usual or select 'build scm'.

[Jason W]

I am not familiar with Puppy and sfs files, but from what I understand the sfs is similar to the tcz in that it is files installed into PKGROOT/usr/, PKGROOT/usr/local/ and such.  And then the sfs is overlayed into the system with unionfs so it is as if they are being coped to the system but without the memory space being taken up. 

That is actually much different than the scm in that the scm apps are specifically compiled with --prefix=/apps/{appname}.  While some extensions would work to copy thier tcz contents to a directory in /apps, most would not work as most paths to config files, share directories, and all are set at compile time. 

I am assuming that by building an scm you mean copying the contents of various tcz's into the scm, which would not work as nothing is overlayed into the system when the scm is mounted, which allows for the clean loading and unloading the scm offers. 

[V.Krishn]

So sfs is overlayed at boot time while scm is sandboxed in /apps.
This is why it makes scm more modular/dynamic.

scm allows for the clean loading and unloading. 
Just to clear, what does it mean by clean unloading?

I have not tried to install, if scm /apps/leafpad is intalled and tcz leafpad also exist, which one gets entry in user menus?

[gerald_clark]

Both.

[Jason W]

Just to clear, what does it mean by clean unloading?

Meaning that nothing is installed outside of /opt or /apps, so no system area is touched.  Well, execpt for the freedesktop files and icons in /usr/local/share/applications and /usr/local/share/pixmaps that get created and removed by scm-load as the app is loaded and unloaded. 

[V.Krishn]

I think it might still be possible to have a 'scm-build' scripts for making scm directly from tcz(dynamically on user end).
Just few more questions:
How are the links to required files in tcz done?
I mean get all files in /tmp/tccloop/<tczA> and perform filesystem equivalent symlink, or something more.

[bmarkus]

I think it might still be possible to have a 'scm-build' scripts for making scm directly from tcz(dynamically on user end).
Just few more questions:
How are the links to required files in tcz done?
I mean get all files in /tmp/tccloop/<tczA> and perform filesystem equivalent symlink, or something more.

Why to convert tcz to scm? I do not see any reason. tcz is not the 'old' and scm is not the 'new' way of extensions, they are for different purposes. tcz is not obsolate and most cases for new extensions still the way is tcz while scm is for special cases.  No need to convert extensions to scm except it give benefits and cant't use tcz due to library conflicts or so.

Just my view on scm.

[V.Krishn]

Thats true. There is no 1 to 1 relation of tcz to scm. Proposed/current scm system would not exist without tcz, so tcz stays.
Example gtk2.scm contains following tcz rolled into one, except with a different method of compile:
atk
cairo
expat
fontconfig
gdk-pixbuf2
glib2
gtk2
hicolor-icon-theme
libffi
libjpeg-turbo
libxft
libxml2
pango
pixman
tiff

[gerald_clark]

Another good target for a scm might be compiletc.
It could be loaded to work on a project, and unloaded when done.

One thing to remember is that with scm, your memory usage may increase.
Libraries can be either statically compiled, linked from the shared libraries in /lib and /usr/local/lib,
or linked from /apps/extension/libs.
You may end up with multiple copies of the same libraries in memory, loaded from different locations.
multiple copies of libraries that could otherwise be shared.

[bmarkus]

One thing to remember is that with scm, your memory usage may increase.
Libraries can be either statically compiled, linked from the shared libraries in /lib and /usr/local/lib,
or linked from /apps/extension/libs.
You may end up with multiple copies of the same libraries in memory, loaded from different locations.
multiple copies of libraries that could otherwise be shared.

Exactly. This way preferred extension type must be .tcz and select carefully when scm is really needed.

[V.Krishn]

I would still like to have such a system though.
I have used microcore "http://insteps.net/pr/a/pmwiki/Apps/PmReader" to build this.
Think the portable document as explained on the webpage to contain Ad hoc module needed to view the document. Eg. Mimetex. Once the document is uploaded along with Mimetex.scm, its gets loaded. The document is viewable and later, document when deleted, its is scripted to be removed.

Does mimetex.tcz exist? :-)

[Jason W]

I have expected some concern over RAM use and duplicated libraries.  I myself wrestled with it as I was getting back involved in using a self contained approach, and I am finding the theory of it paints a much darker picture than what the reality is.  At first, I expected a much larger cost in terms of RAM and disk space than what I have actually been seeing upon experience.

Out of curiosity, I did a quick side by side test today of an scm-only system and a tcz-only one, with some of our popular and larger apps to see just how much difference we can expect when we open up many apps at once.   Both systems were booted with only loading these apps and their deps, as well as icewm.  Here is the list of apps that I installed and launched - Xchat2, gqview2, leafpad, transmission (gtk2 for tcz, gtk3 for scm), opera-11, midori, audacious (gtk2), audacity-1.3, epdfview, emelfm2, gimp2, geany, pidgin, minefield9, gtk-gnutella-gtk2, foxit-reader, and geeqie.  I opened the apps, and then cleared the memory cache.  Nothing scientific, but able to give a general idea.  Transmission-gtk3 is a gtk3 app which also brought in gtk3 to ram for the scm install which made a larger impact on the scm system than the gtk2 version would have, tcz install used gtk2 for transmission which is also shared among its other loaded apps.

Ext type       total RAM          total "du" size of /apps                         
                    used at idle        or /tmp/tcloop

tcz               333mb                     271mb

scm              326mb                    360mb

The total size of the scm files could be trimmed more, but they seem to hold their own in the memory use dept, at least on first launch.  I am not saying anything bad about the tcz, and there are many little factors that go into how much ram an app uses when launched.  But I am just throwing some numbers up to give folks an idea of expected system impact before they rule out an extension type before they try it.

[gerald_clark]

I was not ruling out scm. In fact I am using it presently for xchat and xmms.
I would really like to see a compiletc.scm.

[Jason W]

I didn't think you weren't ruling them out, ruling out was not a good choice of words for me.  But as system efficiency is one of the goals of TC (otherwise why be small) memory usage in particular is a valid concern in any undertaking here. 

[TheNewbie]

Correct me if I'm wrong, but to summarize the basic idea of scm packages, they're basically 100% self-contained binaries. They can require tcz dependencies or package their own libs, but there are no scm interdependencies, so scm packages can be loaded/unloaded cleanly with a Core util.

It sounds like a good idea if one wanted to try different window managers, browsers, etc., which all required the same basic set of deps (which could be loaded in tcz form), so that you could test each one and unload it without hassle. Definitely won't replace common dep packages, though, for the reason of memory efficiency as stated above.