SliTaz Forum
You are not logged in.
Pages: 1
Hello
I was just wondering if Slitaz users could be interested in implementing self-contained application modules, of the kind that has been recently done in TinyCore Linux (in the form of SCM extensions). In short, you will have an application that is self-sufficient in terms of dependencies, at the cost of having duplicate libraries on your system, but with the certainty that no dependency will ever go missing or be screwed up by something else. The big advantage is in terms of total reliability.
TinyCore has recently implemented in Linux this mode, which has been used extensively for years in Mac OS X (where app directories are the standard mode), in Windows (portable applications within their own directory) and PC-BSD.
Is there any chance that Slitaz may also embrace the idea? Not as a replacement of the current package system, of course, but as an option, for the benefit of those users who really prize reliability over everything else. It would be nice.
What do you guys think about this proposal?
Baka
Offline
It's bad-bad-bad practice.
Why? Cause you cannot update all libraries at once when critical security issue is found.
Offline
Yes, you cannot update all libraries at once... But what do you call it when all of a sudden you find that many of your applications have been screwed up, in one go, precisely because there is some problem with the update of a shared library? And it does happen, as you know. I see this as much more threatening and potentially disastrous as compared to having some applications with a security issue.
By the way, fixing a security issue in a self-contained application can easily be done manually.
You do a search of which directories contain that library file, and then you change it manually. I don't it as much of a problem.
Offline
I'm with devl547 on this. This is a HORRIBLE idea. Also, TinyCore wasn't the first to do this and it's been around for a while. Puppy has been doing this for YEARS and many projects online have complete stand-alone pre-compiled binaries. I know there is a whole project dedicated to created packages like this.
Let me highlight some of the problems:
1.) Packages will be LARGER to download because of the included (localized) requirements. Take packages like games into account. Would you rather download 700MB or 1,8GB version of the game?
2.) You will have to REDOWNLOAD packages EVERYTIME a new version comes out or a bug/security if is done to ANY of it's requirements. This will also leave other packages with similar requirements with the same security issue still in place.
3.) Most packages (as shown with Puppy and TinyCore) will ONLY have the minimal requirements used to make it run and not work fully functional.
4.) Installing every requirement for every application locally means the total HDD space used by the Linux would be about 3-5 times larger than usual.
5.) Loading separate daemons for same requirement will means the system will use more CPU and RAM to run. This is BAD.
In other words, it'll use more space, be bigger to upgrade and install, not work as well as a properly done package, will be insecure and use more of your CPU and RAM to work. Now ask yourself, is it really worth all that trouble instead of having to install small shared requirements?
Offline
Well, we must not use a majority of packages like this. But some, at least, are useful with this idea. At present my main problem is that I lack an easy method to check out why such a portable package (that runs under 3.0) does not work under cooking or with RC2.
Any help/idea for that?
@Trixar_za:yes, I agree with the nucleus of what you are telling. But a small distro like Slitaz with a limited manpower cannot offer a big amount of software as own packages. Plus: I tried to install LibreOffice with get-LibreOffice. It never worked, because I have only 1 GB RAM so any effort to install it is obsolete.
Therefore my guess is: limit such portable apps to a certain number, but that should be somehow reasonable. For a school or university environment you need a suitable html-editor (with GUI) and, of course, LibreOffice. A ,,LaTeX-motor" would be nice so that one can use LyX, Gummi (where Slitaz-packages are still there).
Offline
@michaelbischof To the extent that most Puppy and Tinycore people go, it would be a waste. Some applications however can work well self-contained like LibreOffice and Firefox (and pretty much all Mozilla products). The problem I have with it is that it doesn't work for the majority of programs.
I, myself, prefer making hybrid packages that do a bit of both. I add in the requirements not included in SliTaz into the packages I make (only those requirements become global instead of localized) and I still make them pull the requirements that SliTaz does have in the repository. This is better than localized packages and is generally smaller.
Offline
I agree with the points that Trixar_za made. They are all true.
However, the points I made at the beginning of the thread still remain. You cannot deny that reliability is, and should be, a top priority in some particular cases. And nothing can beat self-contained application when it comes to reliability.
Moreover, in the example of the very big game, cumbersome to download... etc... Well, this obviously was not the type of cases I had in mind for self-contained applications.
As I said in my first post, self-contained applications ARE NOT MEANT TO REPLACE the standard package system and the shared libraries. They would merely be an addition, an option. And that option would be particularly useful for *some* critical applications, which you really don't want the package manager to screw up. For instance: email client, newtwork manager, text editor, etc.
So, although the objections that have been made so far are fair, and I agree with them for the most part, I still insist that a more balanced view should take into account the usefulness of self-contained applications in some cases. Even at TinyCore, SCM (Self-Contained Mountable) applications are just a *subset* of the available packages - and I find that this approach makes a lot of sense. Much more than the hard and fast rule-based approach of all-or-none.
Offline
Well, I still think it's a bad idea. It's one thing to include requirements not included or provided by the distribution itself. This is useful to me and works pretty well with my packages.
It's a totally different thing if you have to include everything with the application that it requires to run (not fully) even IF the system has one or more of these requirements already installed.
Offline
Think of duplicate libraries as to some junk media files that you have stored on your disk. You know, some movies, pics, etc. I can assure that duplicate libraries will take MUCH LESS space than media files. A single movie that you keep 'stored' on your system will typically be 600 MB. How about that for junk?
The stumbling block to get the idea accepted is the fact that most people think in terms of mere efficiency, as if nothing else mattered. And that is an inflexible, almost ideological approach. Efficiency should not be the sole consideration in this game. Reliability is also a legitimate concern, a top priority for some, and in some cases it should get the upper hand over efficiency. This argument is also validated by well-accepted concepts in computer science. Ever heard of redundancy, for instance?
Offline
@Baka,
You asked in your first post about what people think. You should not get upset because some of them do not agree with your idea.
;-)
Offline
I am cool, man 
Offline
Redundancy systems are sub-systems developed in case of hardware failure. This isn't comparable to this. What you are proposing won't be more reliable, stable or secure, it will just be bloated applications with the minimum subset of functionality compiled in so it works. Note I said works, not work well.
But let's rather look at how Windows does it. When an application gets installed, it uses resources already provided by the system itself, like the windowing system, maybe DirectX and of course the media codecs. For everything not installed, it adds - normally on a global level so other applications (probably by the same company) can benefit from it. If it can't find it's requirement (say you don't have DivX or the newest DirectX installed), it will not install the program at all and will inform you to go out and find it or download it for you. Sound familiar? Kind of like my Hybrid packages work? That's because I based it on that model.
Now your way download locally installed requirements for everything. This means the packager needs to locate and pack EVERY requirement so you can use it. Say the application is written in python and uses SDL, MAD, pyGTK, PIL and pygame to work. This is about 250MB of requirements. Now image you have 10 applications like that. That's 2,5GB. Compared to installing each once (and some even come with SliTaz) and then install each application of max 100kb. Hmmm, 251MB compared to 2,5GB - the choice is pretty simple to me - I will use Hybrid or Repository packages instead of a Self-contained ones. This is probably why Windows doesn't do it this way either...
Offline
Let us be more specific.
I thought it would be an idea to use Gnotes - as an AppRun, such a self-dependant programm. You can make notes and export them easily as html as well. But this
- took 39 MB to download and use
- stores in a specific file format - not good for platform independence
Screenlets were the next effort. Quite an amount of extra dependencies from the Gnome system to get - and then there were no real useful screenlets. Ok, to help a young enthusiast. He learned that such thing may be done under Slitaz. Fine.
LibreOffice as a self-contained portable AppRun I prefer over an installed one. It looks the same on all platforms and this is important for use in schools.
As a general concept I would not join the idea of self-contained programs. 231 MB towards 2,5 GB is quite convincing.
Offline
Don't get cross for me asking, but... how does Mac OS X manage it so well, then?
They have the best engineers that money can buy, and they have adopted a package system based on self-contained directories. Or am I missing something?
Offline
Macs use a similar process to what Windows uses. The majority of dependencies are supplied by the OS itself and the applications add anything else that may be missing. There, however, are rare cases where you must download the requirement yourself to make an application work. This is still hybrid packages and applications and not self-contained ones.
Offline
Pages: 1
[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.57 MiB (Peak: 1.77 MiB) ]