Tiny Core Linux

Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on February 23, 2015, 08:18:29 AM

Title: Core v6.1rc2
Post by: Juanito on February 23, 2015, 08:18:29 AM

Team Tiny Core is pleased to announce that Tiny Core 6.1 rc2 is available for public testing:

http://repo.tinycorelinux.net/6.x/x86/release_candidates/
http://repo.tinycorelinux.net/6.x/x86_64/release_candidates/

This is a release candidate. If you decide to help test, then please test carefully. We don't want anyone to lose data.

We appreciate testing and feedback.

Changelog for 6.1 rc2:
* busybox-1.23.1 patched for modinfo, modprobe, wget and dc

Changelog for 6.1 rc1:
* busybox updated to 1.23.1
* tce-load: apply awk patch from forum member aswjh
* settime.sh: fix systems with default year not 1970
* tce-load: remove unused depi variable
* search.sh: awk patch from aswjh
* search.sh: move common part to a function
* tce-audit: awk patch from aswjh

Also in conjuction with the above in Xprogs:
* apps: quote the search argument, patch from aswjh
* apps: reload the list on an empty search
* apps: Set a minimum size to the window
* apps: Nicer resize behaviour

Title: Re: Core v6.1rc2
Post by: aswjh on February 27, 2015, 12:47:24 AM

Found a bug in loading dep file which line contains whitespace character, e. g. vim-locale.tcz.dep.
Fixed and suggest several improvements.
Perhaps it isn't necessary to umount a empty extension? It spends more than one second checking in coreplus.

Title: Re: Core v6.1rc2
Post by: curaga on February 27, 2015, 04:23:31 AM

Thanks, the spaces parts and the echo/printf change applied.

Unmounting an empty extension saves a loop and the accompanied RAM, ~64kb from memory. Also the changed modules check is wrong, the majority of module extensions contain the modules in a different dir than /lib/modules.

Is there an advantage to the getbasefile change? It is called quite rarely.

Title: Re: Core v6.1rc2
Post by: aswjh on February 27, 2015, 05:24:09 AM

Empty extension is not common, so I think it is not much significance to check, but increase boot time. But even so, the line using ls should be redundant.
In tce-setup line 182: depmod checks only /lib/modules by default? I'm not sure.
Current getbasefile is too slow, spends about 1.2s at boot time of coreplus. It only appears in tce-load and tce-update,  tce-load calls it  frequency.
In tce-load, line 249,273, F="${F##*/}" have removed the path string, so can only use %.*.

Title: Re: Core v6.1rc2
Post by: curaga on February 27, 2015, 05:34:19 AM

Yes, depmod also handles /usr/local/lib/modules. It's also possible the extension has modules elsewhere and copies them to either dir.

What is your test hw?

Title: Re: Core v6.1rc2
Post by: aswjh on February 27, 2015, 05:44:48 AM

Use virtualbox. Add date "+%s.%N" to function process_CD in tce-setup.

Title: Re: Core v6.1rc2
Post by: aswjh on February 27, 2015, 05:48:44 AM

Using find modules spends 0.5s.

Title: Re: Core v6.1rc2
Post by: curaga on February 27, 2015, 05:51:07 AM

Is that with virt extensions (hw accel) or sw mode?

I benched getbasefile vs the one in the patch in Qemu sw mode, it was 1.85 times faster. I'll apply that part. I agree the ls seems extra, will remove.

The modules must always be found, so the check cannot be removed.

Title: Re: Core v6.1rc2
Post by: aswjh on February 27, 2015, 05:57:10 AM

with virt extensions.
Using find for checking is slow too :)

Title: Re: Core v6.1rc2
Post by: curaga on February 27, 2015, 07:16:02 AM

Yes, but is there a better option when it can be anywhere?