Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: tclfan on October 28, 2010, 10:42:13 AM
-
As modular architecture of TCL is an unquestionable asset which sets TCL apart from other systems, one issue appears to be growing in my mind (and my poorly documented, for the lack of time testing...):
The core TCL (3.2) system appears to be solid as a rock, however when you add complexity (various extensions) compatibility between these extensions and/or between such combination and the core appears to arise and require solutions or chosing other combination.
Last night I was able to spend some time trying to test (again) various windows managers, such as openbox, hackedbox, jwm, icewm, LXDE, XFCE (after setting up Xorg), then configured Firefox, and then loaded ezmaster to try re-mastering...
With various combinations, even of such limited complexity I was facing various issues, some of which are well known, such as Hackedbox corrupting Wbar, etc... Often experienced symptoms were menues of WMs becoming unresponsive and the entire desktop freezing... I was never able to get ezmaster to start (which was loaded 'On-Demand) or XFCE to start successfully. However my testing was not methodically organized and exact steps were not documented to isolate issues, so I cannot tell what caused what...
I tend to believe this was my unlucky day to test, but for the end user compatibility issues might present quite an obstacle on the road to composing a dream system.
If compatibility issue is a legitimate, and not just my bad luck, would this not emphasize the importance of creating a 'showcase' flavor of ready-to-go TCL system, containing best of breed apps, in order to bring TCL closer to audience of users wider than tech savvy and developers?
-
Tiny Core has come a long way in a short time.
Robert and the team have done an outstanding job.
The features that have been implemented, are a higher priority than the features that have not been implemented.
However, there are some applications which are incompatible with others, and cause malfunctions if both are run at the same time. (I don't know about any of those mentioned above.)
At some time in the future, as time permits, it would be a good idea to introduce a system which prevents applications which are incompatible with each other from being run at the same time - with some kind of message, so the user knows what is happening.
With Tiny Core the challenge is even greater than other operating systems, as there is the on demand feature. Technically, both could be installed and run at different times, but there should be some method of preventing them from both being run at the same time.
It is even more challenging, as extensions are made by many different people.
But the idea is to make the system fool proof. So users cannot crash the system.
-
Completely agree. For TCL this challenge is far greater than for other (pre-packaged) systems, where integration tests have been done and compatibility issues resolved before gold version is posted.
This necessitates a pre-packed ready-to-go, integration-tested flavor of TCL for wide audience of users, alongside with the current strategy of sticking to start-from-base modular architecture for techs and developers.
Otherwise a typical user will sooner or later face a frustrating task of resolving these compatibility issues himself. This could be an obstacle to wide popularity and recognition TCL deserves.
-
Aside from alsa and OSS, and the various Mplayers, I don't think there are many truly conflicting extensions whether due to file conflict or runtime issue.
And any incompatibilities that do exist would have to get solved at the extension level whether those extensions are in the repo or part of a prepackaged set. The same with bugs within an extension.
If there are conflicting extensions besides those mentioned above I would like to hear of them so they can be resolved or simply marked as conflicting with another package. As the goal of the repo is not for extensions to conflict with each other, I don't think that we have enough true conflicts among extensions to warrant an automated approach to prevent installing conflicting packages.
-
Fairly obvious
Some of the internet browsers are incompatible with each other. Particularly those which are variations of the same thing.
-
I think the first step is to somehow have them marked as conflicting with each other, so users know.
I don't think that we have enough true conflicts among extensions to warrant an automated approach to prevent installing conflicting packages.
I think, at this stage, this is not the top priority.
I think, in the long term, Tiny Core should be fool proof. It should be designed so it is not possible to run incompatible applications at the same time.
-
As for the web browsers, if you are referring to the Firefox's, they are intentionally installed into their own self contained directories so they can all be installed at once without file conflicts. The official Firefox and old Minefield conflict, but the rest don't.
EDIT: Actually, I changed the install dir of Firefox a while back so it does not conflict with old minefield.
-
I am referring to those based on Firefox.
It has been months since I noticed this, and have not checked since.
I don't think the problem was the directories.
If you started two at the same time, malfunctions occurred.
From memory, I think it was not only minefield.
This can be easily checked.
Run two at the same time and see what happens.
-
That will happen with any Linux distro. Each Mozilla based browser is going to try to use some of the same files at the same time.
-
What is being noticed when trying to run two Firefox's at the same time is that a new window of the same firefox is being launched using the currently running firefox session. Though their files do not conflict, but as noticed you can't have two versions running at once.
-
I think the first step is to make information about incompatible applications available for users. Possibly starting in the info file.
All incompatible applications, not just these.
At some time in the future, as time permits, it would be a good idea to introduce a system which prevents applications which are incompatible with each other from being run at the same time - with some kind of message, so the user knows what is happening.
-
I moved this post as it has nothing to do with the base system.
Seems tclfan's original post was premature. Apparently out of frustration from trying to use a custom (unofficial, i.e., not supported by Team Tiny Core) remastering script.
Instead of asking questions with specifics in the appropriate topic area so that progress could be made, a sweeping and generally negative post was made in the base topic area.
Looks like an answer was posted in the appropriate topic section: http://forum.tinycorelinux.net/index.php?topic=6645.msg40771#msg40771 Apparently ondemand is not currently support in the remastering script.
I have repeated stated remastering is not the goal of this project. To say "best of breed" applications, says who? For me it would be flwm and fltk apps, others would be JWM, and GTK, still others it is LXDE, or XFCE, or ... OOo or Abiword, or Opera or Chrome or ..
To force application decisions on others is not what I want to promote. There are hundreds of other turnkey Linux distribution that will gladly make application decisions for you.
If you have a specific instance(s) of inoperable extension(s) that is reproducible then post it in the appropriate topic area and it will be gladly addressed.
There can be no answer to sweeping generalities.
-
To add to the list of incompatible extensions (not by my own experience, but merely from reading this forum): 'cups.tcz' and 'cups1311.tcz'
On the more general question I have to say that I disagree that TC is lacking the facilities to make it "idiot-proof". I'm pretty confident that I can find ways (and have accidentally probably done so) to screw up the "heavy-weight" dependency tracking systems (like 'apt'). No system is really safe from users doing silly things (like installing multiple WMs without proper cleanup etc.). Using a system like 'apt' would "destroy" all what TC / MC stands for IMHO. The world has already seen enough Ubuntu/Debian/WhatEver "clones". The development effort to create another 'apt' is beyond what the Core team can do. And what would be the point anyway?
And whilst I'm on it ...
[rant]- Stop complaining that TC / MC is not a "turn key" system (or trying to turn itself into one). That has been answered many time by Robert: it's a design decision not to do it.
- When raising issues (or bugs) be precise and comprehensive in reporting what you've done, and what the results were. If they can't be reproduced (by someone else) it is as if your problem didn't happen.
- For your own testing use virtual maschine (like QEMU or VBox), that is an efficient way for giving things a go quickly. I for one create new ones several times each day (often only operating in "cloud mode"). I create just a script inside the VM of what I'm doing, to be able to repeat any test. In the end I just have to get this script back to the host and could repeat a scenario (or a variation thereof) within a minute. For those involving or requiring persistency I use small (e.g. 20-50 MBytes) virtual disks.
- Keep your own repository of those extensions that you use for your tests. That's much faster then downloading every time again, or spending time in "nurturing" a small number of larger, carefully crafted virtuall disks.
- Don't mix up WMs too much within the same system. Create a fresh VM for each test dedicated to the one you want to play with. Bear in mind that the TC repository offers several WMs as extensions, but most are not directly supported by the Core team. So it's not always the Core team which could or should fix things, but rather the extension maintainer. Some of them have not had much TLC, so expect some bit rot.
- If there is such a wide range of incompatible extensions do a proper job and carefully document your findings (e.g. create a Wiki page that summarises your specific issues). IMHO the .info files should only contain warnings for those well known directly "competetive" issues (e.g. OSS vs. alsa).
[/rant]
-
Regarding the conflicting extension subject, some distros use a field entry in a package file to either prevent the installation of a package if a conflicting one is present on the system or issue a warning. That would deal with stuff like alsa and oss, preventing the installation of both at the same time. Here, we would more likely use a file like a dep file that contains a list of conflicting extensions if we were to go down that road. It would be another file to deal with, and be of limited use to things like cups, cups-1311, the various gtk1 and gtk2 apps like gnu-gnutella, mplayer, etc. I don't think that there is a real demand for it, and since each extension along the dependency chain would have to have that file parsed, it would slow down performance if only a little. Most folks likely would rather stick to leaving that information in the info files. Also, the result of having an extension maker determine which extensions are conflicting is making decisions for the user that most users would like to make for themselves. There are some extensions that may not play well running at the same time, yet it is perfectly ok to have both installed and run them one at a time.
But I don't really consider the Firefox's as conflicting extensions though they can't be run all at the same time. No corrupted data or even temporary system damage will come from launching more than one Firefox version, unlike alsa and oss installed at the same time which will produce strange results. I could create wrappers that check for a running instance of firefox and spit out an xterm with a warning, but I think that is going a bit far in trying to protect the user from himself and a harmless result of another firefox instance.
-
I have a thumb drive with both alsa and oss 'on-demand'.
I use it in 2 different laptops.
I also have some TCL multiboot systems with multiple tce directories and symlinked optional directories.
I would not mind if on-demand would not allow me to run both,
but I certainly don't want anything to prevent me from installing both to the drive.
-
Seems tclfan's original post was premature. Apparently out of frustration from trying to use a custom (unofficial, i.e., not supported by Team Tiny Core) remastering script.
I want to confirm that roberts is right (as always), that my post was triggered by frustration with desktop freezing often, WM's menues not working, apps not starting, etc...
I apologize that from the lack of abundance of time my testing was not methodically organized, testing script and results not documented in order to isolate issues and pinpoint what was the primary cause of incompatibility in each case. One was previously documented that Hackedbox corrupts Wbar.
As soon as time permits I will try to re-do this, isolate the issues and document better with exact script of test steps. I have also felling that most of freezing and disabled WM menues could have been related to on-demand ezmaster, pointed out by roberts as unsupported.
I do not see the original post as generally negative but on the contrary: The rock solid stability of the tiny core should not quickly disappear in user's practice when adding apps to make such core useful. E.g. I do not see most users completely happy with the default WM, so changing at the minimum to Hackedbox or Openbox should not cause corruption of the (included with core after all) wbar. This is just an example. Yes, it can be remedied by selecting another combination of WM but...
Also some sort of safeguards would be good to prevent app (such as functionally good program - ezmaster) from effectively (and inadvertantly) disabling WMs and in effect freeze the entire system.
From the user's perspective I do not think one can be completely happy with the havoc in the system as long as the core run by itself is rock solid.
On the other hand I can quote someone 'Apps are just nuisance and detrimental to system's performance'...