Overlay initrd files using cat

[gerald_clark]

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.

That is precisely the problem.
When testing release candidates, tce-update keeps updating wbar to the last release, breaking the release candidate.
Since wbar is a part of TC core, it needs to NOT be an onboot extension.

The wbar.tcz extension can still exist for people using alternate window managers that still want wbar.

[hiro]

What if we just call that base wbar extension different on each update?

[roberts]

We? Oh please, a .gz together with the release makes it clear, simple and archive able.
Placing .gz in /tce directory is also trivial for the user.

[hiro]

I was Just thinking aloud. But I think I don't see some of the complications you guys do. Perhaps because I always used microcore instead of tinycore.

[jur]

I like what I read.

Extending this concept, perhaps all of the supported wms could become .gzs as well, not only flwm. Then you place your wm of choice in along with the other bits. So onboot could be obsoleted this way - anything onboot could be converted to gz.

Would such a process be faster than loading extensions onboot?

A base system script for converting onboot .tczs to .gz could do the job. This would eliminate the necessity of having two sets of extensions in the repo.

[hiro]

I don't see why this should be faster? Faster in which way?

[jur]

I wouldn't know, I am asking. Would loading a series of gz at boot be faster than loading those extensions a bit later as onboot loop mounts?

[hiro]

You're of course free to try it, but I don't expect any great outcome.

[gutmensch]

I really like the ideas and would love to see this...

But one thing leaves me troubled. The more I think about this whole difference in relationship "Xvesa/Xorg gz/tcz Xprogs/included Xlibs/tc base" I don't find it very clear. Of course mc/tc should be a toolkit but what about simplicity here? A lucid simple solution for everyone to understand would be:

mc + Xvesa(.gz|.tcz) + wm/wbar stuff = Tinycore desktop variant 1
mc + Xorg(.gz|.tcz) + wm/wbar stuff = Tinycore desktop variant 2

Right now it would be something like (if I'm correct):

mc + Xvesa.gz, Xlibs.gz, Xprogs.gz in ../tce + maybe Xorg-7.5-lib.tcz in ../tce/optional + wm/wbar stuff = Tinycore desktop variant 1
mc + Xlibs.gz in ../tce + Xorg-7.5.tcz, Xorg-7.5-lib.tcz, ... in ../tce/optional + wm/wbar stuff = Tinycore desktop variant 2

IMHO that's too complicated.

I'm not saying that I can provide a better solution here, but graphical user interface "bases" like "minimal Xorg with libs and progs" or "Xvesa with libs and progs" could be each offered in a single file instead of ripping it apart since they are mutually exclusive when it comes to running. Of course that would mean redundancies and maybe bigger files (redundant libs etc.), but it would also produce benefits by avoiding problems (like forum entries: "libX... not found, what should I do?"). I'm guessing Xvesa.gz would be about 3-4 MB including Xprogs.gz and Xlibs.gz, Xorg.gz would be about 8-10 MB (only vesa driver, sw renderer, but also Xlibs.gz included, etc.). Xvesa.gz is not extendable either way, Xorg.gz would be extendable through repo.

[jerramy]

What's the minimum set of files to get tce-load up and working?  Everything else can go in a tcz.

(ahem) it seems to me.

[gutmensch]

that's a question of design... you don't need a gui to use tce-load, microcore alone is enough, but tinycore should be usable by people without shell skills too. so an initial small desktop environment for tinycore is definitely better than leaving the (unexperienced) user with a prompt.

[tinypoodle]

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

Oh really?
Not recalling what 'ahci' would be, I had to look the term up.
I have never seen that module being loaded in TC, so I wonder, could there be any benefits of attempting to manually load it?

(By the way, current ethernet support in base is limited to NICs which don't require firmware.)

[hiro]

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

Oh really?
Not recalling what 'ahci' would be, I had to look the term up.
I have never seen that module being loaded in TC, so I wonder, could there be any benefits of attempting to manually load it?

(By the way, current ethernet support in base is limited to NICs which don't require firmware.)

You're right, it was a very bad guess

[tinypoodle]

I like what I read.

Extending this concept, perhaps all of the supported wms could become .gzs as well, not only flwm. Then you place your wm of choice in along with the other bits. So onboot could be obsoleted this way - anything onboot could be converted to gz.

Would such a process be faster than loading extensions onboot?

A base system script for converting onboot .tczs to .gz could do the job. This would eliminate the necessity of having two sets of extensions in the repo.

I couldn't see the benefits, and had actually in mind that the exact opposite, i.e. having as much as possible mounted in squashed .tcz's rather than to extract them from cpio.gz archives, such could save quite a bit of memory.
Also basically there already exists a method of 'copy to fs' to use .tcz extensions but leading to same result as when using cpio archives.

My expectation would be that for the same data to be gunzip'ed from cpio  archives at boot time it might take  significantly longer than for just mounting squashfs.

Influence on boot time might highly depend on hardware (CPU and storage medium).

[hiro]

Why not just try it? I'll see if I have the time later today.