Tinycore libraries

[Yleisajattelija]

I think TCE Q&A is just right place for this. Is there tinycore library documentation somewhere? (the "Q" part). Probably it is never made (the "A" part).

So, now we need the "S" part, too, which means "the solution".

Without library documentation, distribution development is vere difficult.

So, lets start of the beginning of unix:

1) -----------------  "/" -------------------------

This is basic unix statement, and it includes actually very strong, definite and dangerous decicions:

a) Everything on unix are files and are located below root "/" directory
b) Becouse of a), very strong "vertical isolation" is declared. All code layers are separated (=OSI), no information is delivered vertically (eg. all HW signaling to appication layer and back missing totally)
c) Becouse of b) all unix systems are inhertly non-real time systems.
d) File structure is "one dimensional", eg. there is no other way to separate code&data
e) Becouse of a), b), c), and d) unix is very difficult environment for HW implementations.
f) Especially for b), linus torvalds was cabable to utilize huge unix software just by implementing lowest HW-layer for unix.


2)  -- ------------ "/var", "/bin", "/sbin" and "lib" ------------------------------------------------

a) Executable parts of code (read.only ROM-memory parts on embedded environment) are separated on "/bin" , low lever system code  on "/sbin" directory
b) Variables (read-write data on embedded environments RAM) are separated on "/var" directory
c) Common code for different applications are separated on "/lib" directory

3) -------------------- "/boot", "/etc", "/dev", "/proc", "/usr" ------------------------------------------------------

a) Booting code is placed "/boot" (includes all code&data for boot)
b) Configuration files for all applications "/etc"
c) Device files "/dev"
d) Runtime environment "/proc"
e) Everything else "/usr", this is secondary directory for "/" (again "/bin", )

4) ------------------- "/root" and "/home" -------------------------------------------------------------
a) One user system runlevel (data&code&scripts),  for non-TC "/root"
b) Users personal data and scripts "/home"

Above list tells the basic unix/linux problem, application code, data, config files, scripts and libs are scattered around file system.
One application can modify other application config file, and there is no reasonable way to fix it. TC-squeeze-ramdisk protects
application and system for this corruption.

But, files have to be there anyway. And the main problem is libraries on "/lib" and "urs/lib".

--------------------------------------- The Issue Itself -----------------------------------------------------
For application maintainer is essential to know, which TC-libraries are avilable on TC.5X version:

a) /lib
     (new, wonderful list of libaries which are already installed)
b) /usr/lib
     (new, wonderful list of libaries which are already installed)
c) /usr/local/lib
     (new, wonderful list of libaries which are already installed)

[Juanito]

You can see the answer to your question by booting using the boot codes "base norestore" and looking under /lib, /usr/lib and /usr/local/lib

[bmarkus]

Decompress initrd and see what is in /lib and /usr/lib

/usr/local/lib is poulated by .tcz extensions

[Yleisajattelija]

This is "apriori" style problem. Looking for "/lib" helps to list solution, but what should be at those libararies is the problem.

And, debian has it all already, why not to use debian?

I did, and I found that there is "unix" decease added with "bash" decease and  finalized with "linux-gigantism" decease.

[bmarkus]

And, debian has it all already, why not to use debian?

Yes, debian has it. As well as CentOS, Slackware, ARCH, MINT. All thes have libraries. If you prefer Debian, use Debian. It is simple.

[Yleisajattelija]

I think TC has "healthy" linux distribution and among those few distributions which try to minimimize linux. One valuable property of TC is that it is made to be expandable. There is command line core, which you can expand to grafical environment. Even xterm/xorg grafical is small and efficient.

Of course, you can do that with other distroes, but they are not meant to be like that.

GNU-linux is free code environment, so programmers have free choise to use tools they want. So they do, and many popular applications are made by "strange" tools. And lot of work is made on universities with brand new programming languages. If you like to be install all apllications, you need huge variety of different shell script languges, compilers, window mangers, grafical libraries etc.

I think, if debian system would be efficiently designed, all applications would need at least 10 times less storage/memory. You wouldn't really need 15 pieces of almost identical grafical libraries, but becouse of free code, there is no way to force coders to use same tools/libraries.

So, in practice, to minimize linux you have to choose applications, it is only way to try to limit size/complexity of the system.

One valuable issues is scalabilty, it is very convenient first to boot only with kernel and minimum set of commands and tools. Next stage you typically need xterm/vesa and then Xorg.

At the other hand, sometimes I want use those many applications which are made for unix/linux, but then I have to accept terabits of unefficient code. Practical solution is to use separate TC USB-sticks with diffrent setup.

[Yleisajattelija]

As we know Debian is using FHS: https://www.debian.org/releases/stable/i386/apcs02.html.en

But that is not defining "/usr" internals.

TC uses "/usr/local" for installation point for .tcz packages and unfortunatelly some applications hardcode libraries and configuration files to "/lib" and "/etc".

I tried to compile "SANE", and only way to install it TC environment was to force independent library modules.

I read Fedora main developer paper for Fedora internals for this "application layers/libraries" issue and seems that it it universal problem for linux distributions, not just TC.

[Juanito]

I tried to compile "SANE", and only way to install it TC environment was to force independent library modules.

I'm not totally sure what you mean by this, but sane-{backends,frontends} compile to /usr/local against existing tinycore extensions without problems.

[Yleisajattelija]

It has some time when I tried to compile SANE, so situation may be better nowdays.

Tinycore main principal to reserve "/lib" and "usr/lib" directories for TC system is nice and clean but it is not possible becouse of bad application code. If is not possible to isolate .tcz packakes to "/usr/local" directory. If "lib", "usr/lib", "/etc" directories have to be opened to application stuff it must be controlled somehow.

Using subdirectories is not good idea (tried several times), library directories must be linear (dynamic linking problems).

Good solution this problem is obviously very difficult to find.

Is dCore The Solution for this problem?

[Juanito]

Tinycore main principal to reserve "/lib" and "usr/lib" directories for TC system is nice and clean but it is not possible becouse of bad application code.

I cannot think of any case where an extension needs to have libraries in /usr or /usr/lib - some, like hplip, are more difficult than others, but usually no problems are encountered.

Perhaps you could give an example?

[Yleisajattelija]

I cannot think of any case where an extension needs to have libraries in /usr or /usr/lib - some, like hplip, are more difficult than others, but usually no problems are encountered.

Perhaps you could give an example?

[/quote]

Sorry, i have very little experience with compiling linux applications, so I cannot give proper answer to that. I have compiled SANE source, and found that there is standard makefile/config system and libraries can be installed at desired installation point. That anyway requires some coding discipline and "hardcoding" is always possible.

I have few year professional experience with C/asm embedded coding, and I have build large programs and C-libraries, so I have some experience with problems in C-library maintenance.

But it is anyway up to linux community rules, technically it can be whatever wanted. And if 97% of applications are well coded and 3%  (flashplayer) is not, it is still problem.

Kernel itself is probably statically linked, so this "distro-problem".

I don't have found dCore documentation, but it it said to be "mountable extension system" whatever that means, is one possible way to solve this problem.

[Yleisajattelija]

Of course, linux-like workstation/server level multiprocessing environment is very complex.

Even command-line environment is very complex, but typically at X-term/grafical environment complexity explodes.

There are several API-layers, window manager libraries, many inter-process signaling systems and whatever-have-ever-invented qizmos.

And there are thousands of coders scattered over word using his/her favorite editor, compiler, language, programming style etc..

And I'm sure, there is still native C-code from -70:ies unix, (at least on sendmail source code...)

So, is there applications on "/lib" "/usr/lib"? Nobody knows, I think ...