Overlay initrd files using cat

[hiro]

I just saw that ahci is not a module. I have to use it with my SATA controller.

[tinypoodle]

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

Personally I would not have any reason to try, because whatever the differences in boot time possibly could be could never outweigh the priority of the criterium of memory usage.
Now if it is just for the hell of benchmarking per se, have fun  

[tinypoodle]

I just saw that ahci is not a module. I have to use it with my SATA controller.

Phew, that would explain why it did not ring a bell here  

[gerald_clark]

Tinypoodle is right. .gz will consume more memory than loop mounted .tcz.

Some thoughts:
Instead of using .gz files to update mc to tc, they should be made into tcz extensions. ( Poodles suggestion )
The .gz loads before .tgz issue could be resolved with an xincludes.lst similar to onboot.lst if necessary.

This optimizes for memory at the expense of the flexibility of including the .gz files in the initrd definition in the boot loader.
Is this a concern? Do we need X loaded with the kernel?  I don't think so.  Tc-config should be able to handle loading X.

[hiro]

But you yourself said earlier:

Since wbar is a part of TC core, it needs to NOT be an onboot extension.

With that logic: Since Xorg is a part of TC core, it needs to NOT be an onboot extension.

And well, roberts seems to have some other reasons I guess.

I would like to hear any reason why e.g. X is release sensitive. What do you even mean with "release sensitive"?

[tinypoodle]

Tinypoodle is right. .gz will consume more memory than loop mounted .tcz.

Some thoughts:
Instead of using .gz files to update mc to tc, they should be made into tcz extensions. ( Poodles suggestion )
The .gz loads before .tgz issue could be resolved with an xincludes.lst similar to onboot.lst if necessary.

This optimizes for memory

The way you put it makes it somehow like a choice of the lesser evil; the one at the expense of the other.
Perhaps a way could be found so that needn't be so.

This may sound odd to some but...
What if taking one of those extensions in question and placing them into /opt/tce/optional into a gzip'ed cpio archive?

With the status quo, as an example, say if a user prefers the newer Xvesa.tcz version and one of the former default wm's (jwm.tcz, flwm.tcz [original]), it would not be anything uncommon to use "dynamic remastering" (see wiki) and load these extensions from an additional cpio archive.

In such a way the memory optimization provided by squashfs could be gained without being

at the expense of the flexibility of including the .gz files in the initrd definition in the boot loader.

[gerald_clark]

I am merely presenting views and observations from several different angles in order to draw out discussion.
.gz and .tcz both have advantages and disadvantages.
I'm all for making MC the core with TC an add-on.
The question is how.
Currently, the ugrade from MC to TC is a mixture of .gz and .tcz.  I feel they should all be one or the other.
I personally don't like the wbar.tcz and flwm.tcz as the tce-update downgrades them for release candidates.
Perhaps the core X .tcz files should not be in optional so extension updates don't touch them.
This would allow Xlibs and Xprogs to be loop mounted .tcz files with the associated RAM savings.

[hiro]

What I like in poodles suggestion of creating a .gz of /opt extensions is that it would be compatible to my practice of putting Xorg in /opt
Only the user doesn't notice, because it's hidden in the .gz

Also for people wanting to remaster it serves as a great example for what opt might be for.

[roberts]

I am merely presenting views and observations from several different angles in order to draw out discussion.
.gz and .tcz both have advantages and disadvantages.
I'm all for making MC the core with TC an add-on.
The question is how.
Currently, the ugrade from MC to TC is a mixture of .gz and .tcz.  I feel they should all be one or the other.

This would heavily favor tcz for the additional option of mounting and update (zsync see below).

I personally don't like the wbar.tcz and flwm.tcz as the tce-update downgrades them for release candidates.

IMHO Testing release candidates should not weight heavily in such decision.

Perhaps the core X .tcz files should not be in optional so extension updates don't touch them.
This would allow Xlibs and Xprogs to be loop mounted .tcz files with the associated RAM savings.

I would think that the "check for updates"  process these tczs should be included. It would make for an easier system update. Again sans any consideration of release candidate testing.

tczs also have the update advantage of zsync which would make their download time much quicker to perform a system update.

[gerald_clark]

I agree with all those observations.

[curaga]

To clarify, zsync works with any kinds of files, but for tcz ones there's already automation.

[jerramy]

I had no problem converting Xlibs Xvesa and Xprogs from gz to tcz files, and loading them from /tce/optional using onboot.lst instead of /tce.  I don't quite get in what way Xlibs and Xvesa are release dependant, but I see how Xprogs is (it has Fluff, for instance).

One thing I noticed while poking through microcore.gz is that a fair part of it relates to getting networking up (drivers for various network adapters, for instance).  Would there be an issue with seperating out the network drivers into a tcz, and modprobing what's needed later?

[hiro]

Networking has to be included at least in one way or another, because internet connectivity is important for any other app you want to load with the appbrowser.

IIRC to use NFS tce dirs you need a working LAN before loading your extensions. I'm not sure if this is solvable by using the /opt/tce dir for these extensions.

[tinypoodle]

Networking has to be included at least in one way or another, because internet connectivity is important for any other app you want to load with the appbrowser.

IIRC to use NFS tce dirs you need a working LAN before loading your extensions. I'm not sure if this is solvable by using the /opt/tce dir for these extensions.

IMHO debatable if modular NIC support should be included in base, while at the same time the firmware (for all those NICs which require such) is missing.

Loading firmware for NIC and/or loading wireless modules and wireless tools - optionally as onboot - in /opt/tce with an additional cpio archive works fine at current.

[hiro]

Well, you have to draw a line if you don't want to include *all* these fancy networking devices, right?

If I wanted to strip the base down I wouldn't start with NIC support, because current way just works so great. Put in your cd and cable, download your wireless extensions and get going...
In this regard base is very much base already, there's not much left to throw out besides X (at least measured in bytes).