Boot option "base" and /opt/tce

[helander]

Maybe this is not a bug, but intended behavior:

   When using the boot code "base" the extensions in /opt/tce is not loaded.

I have viewed the /opt/tce extensions as being part of the "base" and as such allowing us to create our own "bases". Current behavior prohibits this 

/Lars

[gerald_clark]

Please consult the Wiki.
http://tinycorelinux.com/faq.html#bootcodes
This is exactly what 'base' is supposed to do.

[helander]

I do not share your interpretation of what the wiki says.

The wiki says that "base" means that only the base should the activated.

I have seen no other use of /opt/tce than being able to create remastered bases, i.e. the extensions in /opt/tce should be considered to be part of a "base".

/Lars

[roberts]

'base' by definition does not load any tces.
This is to ensure that one can always boot to the officially published base system.

[helander]

'base' by definition does not load any tces.
This is to ensure that one can always boot to the officially published base system.

And that you can do if you use the bases supplied (tinycore.gz and microcore.gz). But what if you would like to create your own (remastered) base, e.g. a microcore with LXDE as an alternative to tinycore.gz?
What if you want to boot that "base" system?

Are there any known use cases of /opt/tce that would be impacted negatively if the loading of these extensions were not sensitive to the "base" boot code?


/Lars

[roberts]

If we have multiple definitions of a 'base' system it will reign confusion when there is an issue with no way to boot to the pristine state know as Tiny Core/Micro Core as officially published and which by defiintion is the purpose of the 'base' boot code.

[helander]

If we consider the extensions put in /opt/tce as extensions equal to the ones put in the tce dir, then it will likely create confusion when people are trying to update their extensions. Since the /opt/tce extensions are statically built into a load module that can not be modified by the system, these extensions must be excluded from the update mechanism.

If I want to create my own remastered I can do that by taking the wanted .tcz:s and "copy"-install them into the target file system locations of the remaster (rootfs). The downside of that is that they will then consume a lot more memory since they are fully unpacked and not just symlinks to a compressed "archive". That installation process should likely also not put anything under /usr/local/tce.installed in order to not confuse the system of what set of extensions that are installed in the system. On the other hand the extensions you "install" in this way might have an "tce.installed"-installtion script and that needs to be executed somehow.

/Lars

[bmarkus]

If we have multiple definitions of a 'base' system it will reign confusion when there is an issue with no way to boot to the pristine state know as Tiny Core/Micro Core as officially published and which by defiintion is the purpose of the 'base' boot code.

TC/MC is ideal to build custom systems with preinstalled and preconfigured applications (do not call them distributions) for user communities. For endusers such a system is the base. There must be (sooner or later) an official support for such use of TC/MC. Nothing wrong with the base option, but there must be another option to restore TC/MC base plus preinstalled/preconfigured base, similar to cold/warm reset.

I would warmly appreciate it as many others for sure.

[helander]

Bela,

I completely share your view on this

I have an idea on how this could be done and a simple prototype that supports that method. Since roberts has indicated some changes to extension management for the next release I would like to what and see what these changes are before I put more time on "my method".

(I made a post in another thread yesterday where I indicated the principle behind the method)

/Lars

[danielibarnes]

It sounds like you want to load extensions from /opt/tce but prevent extensions from automatically loading from any other location. For now, I'd suggest using "tce=" and point it to an empty directory instead of "base." I think what you saying though is that you want a clean method for achieving this (e.g., "tce=none").

This is a good discussion in that it explores the consequences of having two locations for loading extensions. I agree with Robert, though: "base" means TC as he released it -- without any extensions. That's been the definition since the beginning, and since it is so fundamental, changing it would be confusing. I consider anything in /opt/tce to be an addition to the core.gz files as included in the original release (and I even keep mine in a separate .gz), so I never thought of it as a "base."

Since roberts has indicated some changes to extension management for the next release I would like to wait and see what these changes are

Me too.

[tclfan]

Needless to say I am looking forward to the new promised by roberts...
My two cents on the terminology discussion of what is base:
Although 'base' has been defined by roberts from the very beginning as the minimal core TCL, and any additions are extensions on top of it, I would rather name it 'Core' of TCL, instead of 'Base', since it is pure minimal TC infrastructure, from which all starts evolving.
IMHO the terminology outlined by danielibarnes is practical for users, since after users put together basic infrastructure they need on top of TCL Core, such as Xorg, Openbox, Wifi, Browser, etc., and hopefully manage to 'remaster' or set up on usb, such laboriously put together system becomes a 'Base' for them, or call it 'baseline' from which they continue with additional fancies... SliTaz calls it 'flavours', unfortunately...

[^thehatsrule^]

I don't think that's what he's saying

I consider anything in /opt/tce to be an addition to the core.gz files as included in the original release (and I even keep mine in a separate .gz), so I never thought of it as a "base."

[tclfan]

I apologize that in a rush I confused contributors' names. I think the idea was raised by hellander and expanded/emphasized by bmarkus. At least this is how I understand... My intent was to emphasize the importance of recognition of 'user base' concept, which usually would be composed of TCL Core and basic infrastructure extensions, such as e.g. Xorg, windows manager, wifi, file manager and browser, with the understanding that arriving at such usable composition of modules is still time consuming to do every time. Ones such desired system is built, hopefully it is re-mastered on CD or set up on usb as the 'user base' on which other fancy stuff can be added at will. The great strength of TCL is modular architecture and flexibility of choice how such base system or ultimate target system is defined.
Sorry for confusing...

[danielibarnes]

I would rather name it 'Core' of TCL, instead of 'Base'

I like that name, but with the reverse meaning. What does everyone think of keeping the definition of base, but adding a keyword ("core", "base+", "notce", or something similar) which skips the search for a tce dir? This offers three options: 1) Boot with "base" to skip loading all extensions so you could load the /opt/tce extensions manually for debugging, 2) Boot with a new keyword (as discussed above) to load /opt/tce but skip any extensions on the hard drive, and 3) Boot normally, loading all extensions.

One thing which would really benefit TC is to have a "kernel + tinycore.gz + /opt/tce" set customized for the hardware of a specific system, like I do for VMware.  You could call this set of files (kernel + two gzipped cpio archives) a "Core." I already maintain a "VMware Core." Others can create a "Eee PC Core," "MSI Wind Core," "Aspire One Core," etc., so that a user of one of these systems can be up and running on TC with no extra effort. This would be a big plus for new users. So much so that I think I will put some effort into collecting information from users who have successfully got TC running on various netbooks in order to build these "Cores."

[tclfan]

I would not mind either choice, although 'Core' name appears to have already been chosen by roberts for the minimal TCL - reflected in the logo and screen background...
On the serious side: Apart from choice of terminology core vs. base, this idea appear to be used in SliTaz. They call it 'flavours', reflecting various compositions of SliTaz. These are being composed over time and published on SliTaz repository as ready ISOs. Exactly as you outline such idea... TCL is much better suited for this as it is more flexible and more modular...