Tiny Core Base > Final Releases
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:
--- Quote from: roberts on January 06, 2013, 10:19:05 AM ---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.
--- End quote ---
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:
--- Quote from: roberts on January 09, 2013, 04:22:31 PM ---
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 ?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version