WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Core file suggestions  (Read 2495 times)

Offline uggla

  • Sr. Member
  • ****
  • Posts: 438
Core file suggestions
« on: February 15, 2011, 05:24:46 AM »
Hi,
With recent changes in 3.5 I came up with a few suggestions:

1. Would it be possible to split Xprogs.tcz into several extensions (fluff.tcz, editor.tcz, controlpanel.tcz etc.) then one could add them as ondemand items and wouldn't need to load them all on boot.

2. Is tinycore.gz really needed anymore? Wouldn't it suffice to create a tc-remaster based on microcore.gz with additional extensions?

3. Would it be possible to automatically unload an extension when the ondemand item has stopped executing? An ondemand script could look something like this:

Code: [Select]
#!/bin/sh
SAVE_ARGS=$*
2>/dev/null read TCEDIR < /opt/.tce_dir || exit 1
if [ ! -e /usr/local/tce.installed/evince ]; then
  tce-load -is $TCEDIR/optional/evince.tcz
fi
[ $(which evince ) ] && exec evince  ${SAVE_ARGS} && tce-unload $TCEDIR/optional/evince.tcz

Regards
/Uggla
« Last Edit: February 15, 2011, 05:27:23 AM by uggla »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11049
Re: Core file suggestions
« Reply #1 on: February 15, 2011, 07:06:18 AM »
1. When you get to packing 10kb binaries by themselves, the advantage in separation tends to disappear. There is some overhead per loop mount, generally unnoticable, but if one started to mount many 4kb .tcz extensions the overhead might be more than the extensions themselves.
There's lost compression (= more disk usage, having them together should compress better than separated), and I'd wager a guess that the gained boot time from dropping 4kb from the initrd is less than the time it takes to mount one 4kb extension (a net loss, that is).

2. It is faster to boot than MC + extensions. It's good to keep choice and a fast X build, and its creation from MC + the extensions is automated.
It's also "just two files", one point that may be appreciated by some.
« Last Edit: February 15, 2011, 07:08:31 AM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline uggla

  • Sr. Member
  • ****
  • Posts: 438
Re: Core file suggestions
« Reply #2 on: February 15, 2011, 08:55:29 AM »
Good points! I won't argue with that  ;)

Offline uggla

  • Sr. Member
  • ****
  • Posts: 438
Re: Core file suggestions
« Reply #3 on: February 15, 2011, 10:43:54 AM »
...It is faster to boot than MC + extensions... and its creation from MC + the extensions is automated.

Could that process be used by users to create their own customtinycore.gz?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11049
Re: Core file suggestions
« Reply #4 on: February 15, 2011, 11:26:42 AM »
Sure, it's called remastering ;)

You can even extract extensions like that with the ezremaster gui. Note that there may be some issues with startup scripts, you should read each one and decide which way it should be run (the gui gives you some choices on when to run it).

I take you haven't yet checked the remaster page on the wiki out?
The only barriers that can stop you are the ones you create yourself.

Offline uggla

  • Sr. Member
  • ****
  • Posts: 438
Re: Core file suggestions
« Reply #5 on: February 15, 2011, 12:57:08 PM »
No, I haven't read the remaster page (I thought remastering TC was just like other distros, a snapshot saved as iso). I'll take a look. Thanks.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: Core file suggestions
« Reply #6 on: February 18, 2011, 08:45:07 AM »
Quote
3. Would it be possible to automatically unload an extension when the ondemand item has stopped executing?

I don't think you should.
Extensions can also include non-graphical apps or at least multiple binaries.

Contrary to what I've said before I now think ondemand shouldn't get much more functionality. Having ondemand scripts in PATH creates inconsistent, seemingly non-standard shell behaviour. Other scripts might also get complicated if they use ondemand with sh features like pipes or stdin/stdout.

I stopped using the ondemand PATH again, because my window manager (or app launcher) is better suited for this task. It doesn't intervene with the shell environment, is also usable when I have my flash drive unmounted and doesn't create permission problems like ondemand on FAT32 fs.

But this in mind, you could still change individual ondemand scripts as you like  to create just the behaviour you proposed.