Support for unionfs

[V.Krishn]

As one gets to use TinyCore regularly having more than 500mb extensions,
would it possible to have an option to create UnionFs sfs out of existing extentions.
unionfs.lst - this can exist along with copy2fs and onboot.lst
 Extentions in unionfs.lst would be layed as unionfs and not symlinked thus speeding boot time.

Another usage - quick/neat packaging of a custom distro.

[curaga]

Unionfs/aufs have different drawbacks to symlinks, mainly bugs and constant file opening overhead. We intentionally avoided them.

You're welcome to send an extension for unionfs though.

[V.Krishn]

Would it be possible to have aufs support in kernel / core.gz (increase in size ~170kb)

[curaga]

No.

[roberts]

Would it be possible to have aufs support in kernel / core.gz (increase in size ~170kb)

If you cannot accept the design of our system then why use it?
There are 700+ other distros for you to peruse many use unionfs/aufs.

[V.Krishn]

@roberts
I am not much into kernel and module compiling.
But what does the following mean:

You're welcome to send an extension for unionfs though.

Query: Will such extension have progs to mount/create aufs fs?

The above questions are not imposing but are just queries.

I think I have understood the design principles.
So much to like that I have already created a prototype appliance.
I had also send a nice usage idea in personal message long before.

In fact I would want it to be slimmer.
Idea: remove kernel modules that targets old hardware and make them available as core-ohw.gz.

Roberts are you trying to shy away users?

Request: Extension tcz available in single package for most used kernel modules, reason its lengthy to download the development environment and compile modules against it for every tc release.
Query: Is such package available?

[roberts]

Why would you ask me about a quote from someone else? Should if not be directed at the individual who posted it?

Regarding unionfs/aufs from the beginning I decided not to use such and opted for a much smaller more simple solution. It is fundamental and as such most for the Core programs are built for it.

Now, if you wish to dicard what is Core and view this as solely a kernel, modules, and a few libraries  and start over with a new foundation then perhaps so. But that would be a different distribution. As I previously stated there are many distros that offer unionfs/aufs. To twist my words to make it that I want users to shy away misses the point.

Don't try to make me swim in the sea of sameness. If you cannot appreciate or celebrate that which is unique and fundamental to this distro then my question remains why use something that you wish or desire that its foundation was something other than it is?

[V.Krishn]

@roberts
I appreciate tc, and  stick to what the current kernel+core.gz is. :-)

Request: Extension tcz available in single package for most used kernel modules from tc core team, Is this ok?

[V.Krishn]

Regarding unionfs/aufs from the beginning I decided not to use such and opted for a much smaller more simple solution. It is fundamental and as such most for the Core programs are built for it.

Was not asking aufs support in kernel only for its boot time layering usage. Just that one of my appliance build on tc needed it.

[curaga]

Idea: remove kernel modules that targets old hardware and make them available as core-ohw.gz.

How to decide the cutoff point? Someone will miss it regardless.

Request: Extension tcz available in single package for most used kernel modules from tc core team, Is this ok?

Again, how to decide "most used"? It's very hard to do one-size-fits-all when it doesn't fit anyone really.
I don't think there'd be much point in having duplicate contents in the repo.


If you have some specific hardware in your deployment, it is easy to target that hw and remove unnecessary modules.

But what does the following mean:

It means that if you want to build the module and the utils, you can send them to the repo, in my opinion.
Such would be restricted to after-boot usage, unless you want to create your own remaster.

Query: Will such extension have progs to mount/create aufs fs?

Entirely up to the extension creator. I have no interest in aufs/unionfs.

[V.Krishn]

Hi Curaga,
Reading forum posts on TC looks more like its a locked down personal development platform.
For your above queries please let me know which is likely to be considered and I am ready to have discussion to possible solution.

Regards.

[curaga]

Sorry, I don't understand?

[V.Krishn]

Nevertheless

whether likely to be considered or not
ISSUE 1: remove kernel modules that targets old hardware and make them available as core-ohw.gz.
Solution 1: Who decides the current cutoff point for core.gz, What are the reasons? - partial answer lies here.
Solution 2.
 a. What is the minimal hardware support for tc 4.4 - Ram (48), Processor? - based on these any hardware that likely not to run properly on lesser configs can safely be rejected.
 b. Built two Core/Tinycore(not CorePlus) - one with newer hardwares + more used modules and other with core-ohw.gz+core.gz(both) - (hope this can be done and its not a problem with depmod)
   eg. Core-4.4.iso - has core-ohw.gz+core.gz - this means there might be 1 to 2 mb increase in size.
       and Core-4.4n.iso - has core.gz - this might be 1 to 2 mb less in size.
 c. Based on core.gz(n) success, phase out modules gradually and mark them as old or less used.
 d. Results ie. complains versus success from n releases can serve ground for next releases.
 e. Users can always switch to regular downloads.
 f. Someone will miss it regardless
    -- adding notes in download section or in documentation helps, Main download links should point to regular iso.
 

I hope this to be considered
ISSUE 2: Extension tcz available in single package for most used kernel modules from tc core team
Solution 1: most used - live admin distros(eg. pmagic, sysrescucd, finnix, knoppix) are best to see what is needed. Range (compressed 5mb to 25mb)
Solution 2: Why bother - go for most i.e 25mb (knoppix kernel modules compressed size), as tcz packages are not minor version tagged, updating it to include more can be done on request.

Query: Can you point to any existing extension that has a kernel module to be loaded on boot or demand?

[curaga]

Solution 1: Who decides the current cutoff point for core.gz, What are the reasons? - partial answer lies here.

That'd be upstream linux kernel, we basically support everything the 3.0 kernel does, barring some exceptions like unstable code.

I still miss the point, because separating older drivers would only benefit newer systems. Those newer systems are likely to have much more ram, so the 1mb saved is rarely critical.

I hope this to be considered
ISSUE 2: Extension tcz available in single package for most used kernel modules from tc core team
Solution 1: most used - live admin distros(eg. pmagic, sysrescucd, finnix, knoppix) are best to see what is needed. Range (compressed 5mb to 25mb)
Solution 2: Why bother - go for most i.e 25mb (knoppix kernel modules compressed size), as tcz packages are not minor version tagged, updating it to include more can be done on request.

See original-modules-*.tcz. All of the modules from our build come to a total of 17mb?

Query: Can you point to any existing extension that has a kernel module to be loaded on boot or demand?

Not sure I got that right, but for example the xf86-video-intel driver loads the graphics modules.

[V.Krishn]

If you cannot accept the design of our system then why use it?

If you cannot appreciate or celebrate that which is unique and fundamental to this distro then my question remains why use something that you wish or desire that its foundation was something other than it is?

I would apologize.
Can someone point me to urls describing the intended usage, target audience and accepted forum topics for discussion.
I am using TC to build some appliances and just had few problem. Would try to be within the context.