I think it isn't eventually good idea to reject all public lib bindings like .scm format does.
That is complicated issue, but with current and future MMU, uP, memory types (mass storage, flash memories, fast cashes etc.) and multicore uP structures shared libs are still need.
Shared libraries (and dynamic lib loading) are efficient on large systems where is sufficient memory. mass storage and capable MMU-system. Especially at applications like flashplayer it is good because of applications temporary nature, user wants first to play video and next to close video and start surfing with tinycore forum. It waste of memory and resources to keep all libs loaded, and eventually is impossible as continuous manner if number of applications is not limited somehow. It is reasonable in some cases to keep several copies of same libs (it think this is The Idea behind .scm format), and when loading same lib differently for different applications is indeed isolating lib conflicts, but this flashplayer problem is good example of difficulties encountered with that approach.
Static loading is good idea for embedded systems, and typically dynamic loading is used only when other choices are not possible.
I agree, that TC base system should be on busybox and even fully statically linked, if needed. Actually I have large embedded scientific application, which will run on linux platform. Maintaining proprietary embedded linux is nightmare, and TC is one option. I'm looking for solution, where target system is lightweight embedded TC and development environment is workstation with fully capable TC installation.
I think TC should be dedicated library management to handle different type situations and should include different libs handling. There should be smooth transition from static memory model CLI running small Armcore uP to full powered all-MMU multicore/GPU machine with advanced dynamically loaded libs.
Welcome
FAQ
Downloads
Wiki
