Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: Ulysses_ on April 22, 2011, 01:33:22 PM
-
This must be happening with other extensions too. What happens when open-vm-tools-x tries to use one of its features that is implemented in one of the extensions it depends on, and which is not loaded by default?
Does the missing extension get loaded quietly? Or does it just fail in a user-unfriendly manner?
-
If an application depends ( requires ) on other extensions, they will be in the dep file and will be loaded when the application loads.
If the application trys to use an optional ( not required ) extension, it is up to the user to be sure it is loaded onboot.
-
Then why doesn't the open-vm-tools-x extension get marked as ondemand, but only its required extensions are silently treated as ondemand?
-
If you think something is not working properly, state specifically what the problem is.
If you do not understand the difference between on demand, and dependencies, I suggest
you spend some more time reading the online docs and the wiki. Then ask specific questions.
-
I should avoid using proprietary tc terms like on demand and on boot because they distract from the essence of things. Put simply, what is the benefit of allocating memory to a software function when that memory is not enough for the function to operate.
It's like defining a C local variable outside the function where it is used so it is taking up stack space that could be free for other uses.
-
You still have not clearly stated a question.
How much memory do you have?
Are you loading into filesystem insteadof loop mounting?
What exactly do you think is being allocated that you don't have enough memory for?
-
How much memory do you have?
2 GB. But the memory available to TC is not fixed, TC runs in VM's. And it is desirable to run as many TC VM's as possible within the 2 GB minus the host's usage.
Are you loading into filesystem insteadof loop mounting?
I'm doing what TC does by default. Probably loop mounting.
What exactly do you think is being allocated that you don't have enough memory for?
I think a VM with open-vm-tools-x allocates memory for this extension, and therefore has less memory available for browsing or other tasks.
Maybe we ought to wait for danielbarnes who knows what is going on in this extension. I'm now guessing he's doing things this way because frequently used features of open-vm-tools-x work stand-alone (without the required extensions), and these features are needed during the boot (eg the Virtual line in xorg.conf) so it makes sense to load the extension without loading its required extensions.
-
The info file lists some optional features, and the extensions that must be preloaded if you wish to use them.
-
I don't have a clear understanding of your issue. What are you are trying to do that you cannot? If something doesn't work please give me step-by-step details to reproduce any problems.
-
I don't have a clear understanding of your issue. What are you are trying to do that you cannot? If something doesn't work please give me step-by-step details to reproduce any problems.
Can't reproduce the predicted issue because I do not know what usage would cause all of this extension's required extensions to be loaded. The predicted issue is an out-of-memory failure of, for example, a diskless browser appliance (no swap).
-
It is a bit difficult to answer undefined hypothetical questions.
Can we close this?
-
Then why doesn't the open-vm-tools-x extension get marked as ondemand, but only its required extensions are silently treated as ondemand??
I have not observed this, but neither did I test for it. If it does occur, then it must be a generic issue and not particular to any one extension. The "onboot" property of an extension must be propagated to its dependencies. Anything else is a defect. If I discover something, I will post to the 3.6 rc thread or elsewhere in the TCB bug section.
-
The "onboot" property of an extension must be propagated to its dependencies. Anything else is a defect.
That's useful info. This browser appliance here looks otherwise and it's only default installs of extensions plus a xorg configure and no other messing with, and what you see when you select OnBoot in AppsAudit is in the attachment:
-
It looks otherwise, but it will load open-vm-tools-x and its dependencies as expected.
Here is my test:
1) Boot tinycore with "base norestore" options.
2) Load Xlibs.tcz as "OnDemand."
3) Load open-vm-tools-x.tcz as "Onboot."
4) Observe that Xlibs.tcz is automatically loaded as expected even though it appears in the "OnDemand" list.
-
When tce-load loads an extension, it loads dependencies first based on the dep file.
Each of those dependencies have their dependencies loaded . . . etc.
It makes no difference whether it is onboot or ondemand.
There is no property to be propagated.
-
Alright, thanks, I'll do the recommended check later. You are confirming ondemand works as expected, but I am seeking whether the install puts all dependencies on the left or the right of the OnBoot table.
-
I am seeking whether the install puts all dependencies on the left or the right of the OnBoot table.
If you download an extension as "OnDemand" it will be on the left. If you download an extension as "OnBoot" it will appear on the right. This will never change unless you do so explicitly.
-
Gone through the instructions with fresh downloads instead of loads to eliminate anything local. And started with a fresh install of current release TC 3.5.1. This is not the one you're working on, and where maybe you've got just one table for both onboot and ondemand whereas in 3.5.1 there are two separate tables.
Attachment 1 is the table of OnDemand, which is as expected: all on the left, except Xlibs on the right.
Attachment 2 is the table of OnBoot. All dependencies of open-vm-tools-x are on the left! Whereas open-vm-tools-x, is alone on the right! They should all be on the right!
As it is now, arbitrary screen resize does not work, some glitch maybe. Right-clicked on the desktop menu under ondemand and Xlibs and it still does not work. After a reboot with backup, it now works. Maybe other features do not work if Xlibs is missing?
Typing "free" now reports 383200 kB free in the second line, whereas if we now go to OnBoot and click on all the extensions so they go to the right together with open-vm-tools-x, and reboot with backup, "free" reports 381400 kB free in the second line.
That is a difference of 1800 kB. It says to me the dependencies are not loaded the first time, or they are not functional. But they should be, because then you know how much memory you've got left for the browser etc and therefore how many VMs you can run in a given host. This is important if you want to sandbox several internet-facing applications so any infection is contained but you can still run as many of them as possible simultaneously.
-
Do you not read any of the replies to your posts.
Dependencies do not get set to anything.
They are automatically loaded WHEN the program that needs them is loaded.
They do NOT get added to onboot.
They do NOT get added to ondemand.
-
How do you explain the memory difference then? ;) I bet you didn't read that far.
-
To make it even more clear: dependency resolving works all the same on systems with PPR where onboot and ondemand are not used at all.
P.S.: Attachment of type "tif" are not of high compatibility, "png" is preferable ;)
-
Installing extensions does not consume significant memory if the extensions are loop mounted.
libraries and binaries are not loaded into RAM until they are executed.
-
To make it even more clear: dependency resolving works all the same on systems with PPR where onboot and ondemand are not used at all.
It might be useful to NOT show required extensions in onboot or ondemand tables because this is misleading. People might click on required extension names and think something useful is happening when extensions change side from left to right on either of the two tables.
Installing extensions does not consume significant memory if the extensions are loop mounted.
Open-vm-tools-x is supposed to run at all times, loop mounted or otherwise. It requires an executable in memory at all times. It is not like firefox that only uses memory when you manually launch it.
libraries and binaries are not loaded into RAM until they are executed.
So what do you think was done differently the second time that made open-vm-tools-x load more libraries into RAM?
Note: I didn't use copy-paste, and time sync by default is off. Didn't resize the screen just before noting the "free" readings, the resize was a test that open-vm-tools-x is working in separate sessions. You can do the same and do exactly the same in both cases.
P.S.: Attachment of type "tif" are not of high compatibility, "png" is preferable ;)
That's easy then, png from now. Was the tif viewable at least?
-
The left panel in AppsAudit is just the downloaded extensions that are not currently in onboot or ondemand.
It is not AppsAudit's job to filter out extensions that you may not want to select.
It is simply a GUI extension to command line tools that is intended to make it easier for YOU to make selections.
-
The left panel in AppsAudit is just the downloaded extensions that are not currently in onboot or ondemand.
It is not AppsAudit's job to filter out extensions that you may not want to select.
It is simply a GUI extension to command line tools that is intended to make it easier for YOU to make selections.
AppsAudit does not filter out the dependencies of extensions already in either OnDemand or OnBoot. Whether or not it should is a user interface issue because it does not affect the operation. Dependencies of OnBoot extensions will still be loaded "OnBoot" and dependencies of "OnDemand" extensions which are not already loaded will be loaded "OnDemand."
-
The left panel in AppsAudit is just the downloaded extensions that are not currently in onboot or ondemand.
That's not the left that we're looking on here. We are looking on the left of the OnBoot table and the left of the OnDemand table (3.5.1) or the two sides of the joint table in (c.r.candidate). Required extensions are misleading there. Only top extensions are logically expected there, if required extensions are loaded automatically.
Otherwise you click on required extensions in those/that tables/table and your clicks and movements left to right have no effect.
-
We are talking of the same left panel.
The left panel of both onboot and ondemand is all downloaded extensions not explicitely included in onboot or ondemand.
Dependencies are not considered here. You may include some or all dependencies as you see fit, but you must do it manually.
-
We are talking of the same left panel.
The left panel of both onboot and ondemand is all downloaded extensions not explicitely included in onboot or ondemand.
Dependencies are not considered here. You may include some or all dependencies as you see fit, but you must do it manually.
Is that 3.5.1 or the c.r.candidate you're looking at (never seen the c.r.cand.)?
Either way, it is not logical that you can click on dependencies and move them to the right. Doesn't anyone see the misleadingness of this?
-
Hell this thread wouldn't ever had existed if those darned dependencies were hidden from onboot and ondemand tables in 3.5.1. They have no place in these tables.
-
You seem to overlook that one and the same extension could as well serve
A: as a standalone app (e.g. it could make sense to have TC base and gpm being the only extension just to have a console mouse)
B: as an optional dep to some apps (e.g. gpm with irssi)
C: as a hard dep to some other apps (e.g. gpm and links)
As for the tif attachments, opera would prompt which app to open them with.
-
I'm through here, as Ulysses appears to be more interested arguing than solving a specific problem.
-
You seem to overlook that one and the same extension could as well serve
A: as a standalone app (e.g. it could make sense to have TC base and gpm being the only extension just to have a console mouse)
B: as an optional dep to some apps (e.g. gpm with irssi)
C: as a hard dep to some other apps (e.g. gpm and links)
Why not derive from the total tree of all extensions, a list of extensions that fall under one or both of A or B, and treat them differently.
Perhaps allowing them to appear in onboot/ondemand tables as an exception.
Or, allow them to appear in the tables only when NO extension has them as a hard dep. This is simpler.
-
I'm through here, as Ulysses appears to be more interested arguing than solving a specific problem.
The problem is very specific, it looked like deps were not automatically loaded, and that looked so because of a user interface fault.
-
I am unaware of any
total tree of all extensions
Any extension could potentially be a hard dep of any 3rd party app, and therefore be desirable by some users to be onboot or ondemand.
-
I am unaware of any total tree of all extensions
Meant all extensions in the repo.
Any extension could potentially be a hard dep of any 3rd party app, and therefore be desirable by some users to be onboot or ondemand.
Can't some extensions be marked by their creator as "application, always show in onboot/ondemand table" or something like that?
-
Or maybe split the tables in the middle and show top extensions on top, and dependencies at the bottom. And when you click on a top extension it moves across together with all its dependencies which move across on the bottom pane.
This automatic movement would show graphically the automatic-ness of extension loading.
And clicking would not be allowed where it would make an invalid setup.