Core v4.7.3

[roberts]

Team Tiny Core announces Core v4.7.3, a minor adjustments and bug fix release, is now available.
See; http://tinycorelinux.net/downloads.html

Change log:

• Improved system integrity by updating Core scripts to directly call busybox ash and useBusybox function
• Updated tce-load to improve module detection.
• Updated filetool.sh dryrun report for handling spaces in filename,

Note:
This should be a transparent change for all exising ports.
I have tried to make Core's main support scripts be protected.
Thus the scripts now explicitly call #!/bin/busybox ash and the useBusybox function.

This should improve the situation where one loads bash and wishes external scripts to function with the usual #!/bin/sh

Same should apply for gawk and such. Even loading extensions to the traditional locations should not break Core's base functionality.

This change also improves support for the import project that I am working towards.

[Yleisajattelija]

Even loading extensions to the traditional locations should not break Core's base functionality.

This change also improves support for the import project that I am working towards.

Could you inform us more about this, please?

[roberts]

I changed many (43)  core scripts to ensure that they would run, as if booted with base norestore.

That is each script that runs after boot now calls busybox ash and that each utility called from such script be it, sed, awk, grep, etc., also calls its busybox applet via the use of aliases via the useBusybox function.

Therefore even if extensions overwrite sh, awk, grep ... with their GNU counterparts the base core scripts should continue to function and not be affected by incompatible or unsupported GNU options.

Additionally I now look for extension modules in all the typical places, .e., no longer limited to /usr/local/bin
Of course base modules are protected as well as all base files as the dynamically created links are only additive, unless the -f flag (force) is used with tce-load.

These changes enchance the base system in supporting TC non-compilant applications which, of course, means better support of imported packages.

I am trying to support an additional option for the users with the import suite. Currently I am focusing on the Allwinner SOC. Its development will easily extend to any platform. As we can see there are already other more powerful arm socs available. It would not be possible to try to create and maintain many multiple extension repositories for each platform, be it another arm soc, or mips, or ?

At the same time, I trying to keep a common base Core system to support both current tcz and scm community developed extensions.

While there are some that disagree with my approach, I feel it is only an advantage to offer an additional option and is most timely given the current fast pace of new Linux compatible hardware.

[Yleisajattelija]

Thanks, very important information.

a) "Hardened" core scripts. I don't fully understand linux/TC HW init/boot sequence (it is always quite complicated issue in multiprocessing uP:s environment) but I'm sure that it is very good idea to keep it simple and minimum. I have to start to learn those scripts.
b) Sed, awk, grep, sh, bysybox  etc. tool chain is essential
c) a) and b) are basis for efficient non-x86 uP port. Arm is very effective architecture, and I'm very pleased that it supported.
d) .scm and .tcz both supported in future. Important for library structure
e) Extension module loading from other places than /usr/local/bin. I think this only is for .tcz. I don't fully understand .tcz package structure, but obviously this gets more flexibility
f) Allwinner SOC is unfamiliar to me, have to study that, too (sound good idea, because already used on Android)

For me, TC future seems to be great. Basic development principles are very healthy.

I hope that there would be at least one more guidelines for future development. I think for community developed extensions is very important to define "lib stack" on TC. There is set of standard libs (gcc, fltk etc.) already on "/lib" but for example gcc-X-fltk-firefox-flashplayer need stack of libs to work. And that lib stack needs to maintained somehow. If one application maintainer on that stack is loading lib differently, all apps which are depended on that lib won't work, so rules needed to maintain libraries.

Is there any visions how lib stack should be handled?

[bmarkus]

It would not be possible to try to create and maintain many multiple extension repositories for each platform, be it another arm soc, or mips, or ?

mips is an interesting point. Before I started to work on the Raspberry Pi I was thinking on mips. Unfortunately mips lost its popularity. No really available up to date boards to target with TC. It is used mainly in small routers. These devices equipped with small RAM, usually 16-32 (64) M, no USB or SD card slot to expand hw and connectivity is limited.  Only possible target is the RouterBOARD product line. As I see, mips is out of scope at the moment for us due to lack of modern, widely available and used hw platform.

Referring to import, I aware only OpenWRT as LINUX available on these systems.

[roberts]

Current Debian v6, squeeze, supports the hardware as shown in this link
http://www.debian.org/ports/mips/

Loongson and Yeelong laptops were popular before Android invaded the Far East.
Not sure if Android is running on the Loogson but...

Just recently announce is Ingenic JZ4780 SoC Features a Dual Core MIPS CPU

Read more: http://www.cnx-software.com/2013/01/05/ingenic-jz4780-soc-features-a-dual-core-mips-cpu-and-powervr-sgx540-gpu/#ixzz2HgPjL1IB

So it seems more than just routers. I have been contacted via email to consider port to Mips.
Alas so much to consider.

[gerald_clark]

Tomato USB also runs on mips routers.
The Asus RT-N16 router has 5 Network ports, two USB ports, 8M of flash and 128M of RAM.
My $25.00 Belkin Share Max N300 is identical hardware except for 4M flash and 64M RAM.
There are additional packages available from sources such as optware.
tomatousb.org has more info.

[bmarkus]

Well, I'm not saying that you can't find MIPS based product with more resources, but their availability and popularity. Also this target group looks segmented. Of course targeting a specific platform specially in collaboration with the hw vendor would make it entirely different