Overlay initrd files using cat

[roberts]

Does Xvesa change release to release? No.
Does Xlibs change release to release? No.
Does flwm_topside change? Rarely.
Wbar? Rarely.

Why download over and over code that has not changed?
Modularity results in less to download faster to upgrade.

Modularity is great with the extensions but not with the base?
You don't download all your extensions over and over, only the ones that change.
So why not for the base?

The arguments against modularity in the base escape me.

[gerald_clark]

The Ibiblio messup has me bored, so I decided to do sone testing.
I converted the Xvesa.tgz ( Yes i use it instead of the stock ), flwm_topside.tgz and wbar.tgz to .gz cpio archive files ( with proper /etc/sysconfig entries ).
Everything loads and runs fine.

[danielibarnes]

Michael: What is the impact to you of putting the various .gz files in your /tce directory and using microcore.gz instead of tinycore.gz in grub? Is there a one-time or recurring (per version change) cost? I agree that maintaining tinycore.gz on the distribution_files page is a good idea, at least for the lifetime of the 3.x series.

I cannot think of a recurring cost from this adjustment. If there are any, they should be noted and discussed. It will be necessary to do a one-time adjustment of a currently-installed grub-based installation or a one-time update of instructions for performing a grub-based installation, but those aren't recurring.

I like the increased transparency. That is, instead of using tinycore.gz you use a smaller base and add in specific files to get the features you want. I'd like to see microcore.gz broken down into a smaller "core + kernel modules" (or maybe further), but that's just me wanting to see how far the rabbit-hole goes.

[Michael Wells]

Why download over and over code that has not changed?
Modularity results in less to download faster to upgrade.

Modularity is great with the extensions but not with the base?
....
The arguments against modularity in the base escape me.

Roberts: I misread your post the first time I responded but I think that I agree with your basic argument that removing parts of the base that could be made modules elsewhere is a good thing if it results in less downloading when updating or upgrading and seems like a good idea.

I remember the first time I ever tried TC and my surprise to see a 10MB distro boot up so quickly into a GUI WIMP environment in which I could then tack on the apps that I wanted, all so relatively easy without the need to repartition.  In comparison to the work I put into Gentoo and LFS to get from console to GUI TC was a dream come true.

If you can remove the more stable parts in the base and put them elsewhere, while retaining the same user friendly characteristics of TC, I am all for it.  If the ease of setup and the 're-occuring costs' of upgrading to a new build can be kept simple so that newcomers to TC can retain that sense of amazement at TC's awesome simplicity ... then having one and only one base instead of the current two (TC and MC) would definitely seem like a step in the right direction.  Let's see what can be done ... :-)

[frimical]

(NOTE: sorry text formatting is not working.)

Roberts said: "The arguments against modularity in the base escape me".
I add: Me too and more!

Just a 'tiny' flashback.
 1- Tinycore started by being tiny and modular, so faster to load and download.
 2-  then came Microcore, a natural step towards greater modularity, and more identifiable core.
 3-  then the concept of 'kit' came loudly to surface, and part of the logo.
 4-  then... this thread... Can 'Tinycore' reach the 'core' ?

I think we're getting closer to what 'Tinycore' had to be: a collection of bricks that can be glued together, easily, instantly. A morphing, elastic Linux distro. With a result that's only decided by the user-builder.

We all know that this approach is not new. Many had already done it in a way or another. But they failed somewhere. Let me rather say they didn't reach what TC can accomplish now: total modularity. From top to bottom.

It's not a market, segment or niche problem. ( anyway I think it's a hobby in the first place, and after all if an identifiable market is necessary to survive, by being a brick, glue and distro builder, TC can be served and satisfy nearly any niche/segment/market...).

That's why I urge you to don't hesitate longer to split anything that can be splitted and modularized.
I suggested that the base be splitted into what's TC and what's not.
Either it is a gz a tcz or whatever. The most important thing is that a 'brick' could be replaced by another one that can do similar or improved functionnality in the chain. ( Is it feasable to split that much? yes it is, ).

I see a re-construction of Mc as:
  LnxBase+TCBase

I see a re-construction of Tc as:
  LnxBase+TCBase+Xserver+XWm+Xprogs+...
or
  Mc+Xserver+TCX+...

So Updating/changing or replacing one brick of the chain is straight and  will bring instantly a different flavor to life.
Actually the only bricks that are not yet one are LnxBase and TCBase.

Finally, those who are worried about Tc/Mc iso, etc... I think these can be easily provided on a page on the web site, with 'the flavor of the day'!. 

Regards

[hiro]

Before splitting up everything into atoms there's still work to do, i.e. tidy up the remaining kernel modules from core, so that only the absolutely necessary ones get included.
But it's difficult to know every kernel module's function, so all users should be encouraged to make recommendations.

I might be a bit tired these days, but what was the reason again for having to use cpios instead of extensions in the case of the window environment?

Could they be placed into /opt for a tinycore.iso ?

[hiro]

I like the increased transparency. That is, instead of using tinycore.gz you use a smaller base and add in specific files to get the features you want. I'd like to see microcore.gz broken down into a smaller "core + kernel modules" (or maybe further), but that's just me wanting to see how far the rabbit-hole goes.

This should be trivial to test if I understand you correctly. Just remaster microcore.gz and remove unwanted modules.

But beware, most people will want ahci, fat, ethernet card support in core...

[robc]

I might be a bit tired these days, but what was the reason again for having to use cpios instead of extensions in the case of the window environment?

I agree, why can't wbar, flwm_topside, Xvesa, Xlibs, and Xprogs be tcz instead of cpio.gz?

If TC is going to be truely modular then these pieces should be extensions as well.

[hiro]

* Easier to remaster as no need to unpack tinycore.gz to remove unneeded component(s).

I don't understand, isn't there still a microcore.gz which you might want to repack? What exactly gets easier now?

It will however be constructed from microcore.gz, Xlibs.gz, Xvesa.gz, Xprogs.gz, flwm_topside,gz, and wbar.gz

You might ditch the confusing micro and call it core.gz


The strongest benefits in my view:
less confusion, aims are more clear.

[roberts]

I might be a bit tired these days, but what was the reason again for having to use cpios instead of extensions in the case of the window environment?

I agree, why can't wbar, flwm_topside, Xvesa, Xlibs, and Xprogs be tcz instead of cpio.gz?

If TC is going to be truely modular then these pieces should be extensions as well.

They are not extensions because they are release sensitive. Unlike true extensions which are not.

[roberts]

* Easier to remaster as no need to unpack tinycore.gz to remove unneeded component(s).

I don't understand, isn't there still a microcore.gz which you might want to repack? What exactly gets easier now?

It will however be constructed from microcore.gz, Xlibs.gz, Xvesa.gz, Xprogs.gz, flwm_topside,gz, and wbar.gz

You might ditch the confusing micro and call it core.gz


The strongest benefits in my view:
less confusion, aims are more clear.

Typically tinycore is the target for remastering to remove Xvesa, flwm, and or wbar.

[hiro]

From an other thread:

Since you would otherwise have a catch-22 loading the extension, add the scsi extension to a separate initrd:

I guess in order to modularize even more (who doesn't wish to have a self-updating "make localmodconfig" kernel) the most important thing we'd have to care about is this.

We have to simplify the process of adding/converting an extension to initrd.

[roberts]

gzs are loaded before extensions!
gzs are loaded to typical nix file system locations.

[robc]

I might be a bit tired these days, but what was the reason again for having to use cpios instead of extensions in the case of the window environment?

I agree, why can't wbar, flwm_topside, Xvesa, Xlibs, and Xprogs be tcz instead of cpio.gz?

If TC is going to be truely modular then these pieces should be extensions as well.

They are not extensions because they are release sensitive. Unlike true extensions which are not.

I understand that Xprogs, Xvesa, and Xlibs would be release sensitive, but how are wbar and flwm_topside? Also, if some of these (perhaps not all) are moved to extensions then they can be updated as an extension rather then having to wait for a new final TC release. Also this may be a goal for 4.x rather then 3.x.

[roberts]

(NOTE: sorry text formatting is not working.)

Roberts said: "The arguments against modularity in the base escape me".
I add: Me too and more!

Just a 'tiny' flashback.
 1- Tinycore started by being tiny and modular, so faster to load and download.
 2-  then came Microcore, a natural step towards greater modularity, and more identifiable core.
 3-  then the concept of 'kit' came loudly to surface, and part of the logo.
 4-  then... this thread... Can 'Tinycore' reach the 'core' ?

I think we're getting closer to what 'Tinycore' had to be: a collection of bricks that can be glued together, easily, instantly. A morphing, elastic Linux distro. With a result that's only decided by the user-builder.

We all know that this approach is not new. Many had already done it in a way or another. But they failed somewhere. Let me rather say they didn't reach what TC can accomplish now: total modularity. From top to bottom.

It's not a market, segment or niche problem. ( anyway I think it's a hobby in the first place, and after all if an identifiable market is necessary to survive, by being a brick, glue and distro builder, TC can be served and satisfy nearly any niche/segment/market...).

That's why I urge you to don't hesitate longer to split anything that can be splitted and modularized.
I suggested that the base be splitted into what's TC and what's not.
Either it is a gz a tcz or whatever. The most important thing is that a 'brick' could be replaced by another one that can do similar or improved functionnality in the chain. ( Is it feasable to split that much? yes it is, ).

I see a re-construction of Mc as:
  LnxBase+TCBase

I see a re-construction of Tc as:
  LnxBase+TCBase+Xserver+XWm+Xprogs+...
or
  Mc+Xserver+TCX+...

So Updating/changing or replacing one brick of the chain is straight and  will bring instantly a different flavor to life.
Actually the only bricks that are not yet one are LnxBase and TCBase.

Finally, those who are worried about Tc/Mc iso, etc... I think these can be easily provided on a page on the web site, with 'the flavor of the day'!.  

Regards

I am fine with futher split. But could be debatable on which is tcbase. Perhaps you meant extension related? Otherwise base system would become unusable. And finally how useful is Core without extensions?