-
Notifications
You must be signed in to change notification settings - Fork 68
A: We use static linking for critical system components. That means components that are used at boot-time and could make your system unusable if they don't find a dynamic library dependency.
A: Unfortunately, some libraries in the stack are extremely bloated and badly factored, so linking against them statically will make any binary using it huge. An example is libressl/openssl - if you link against it, you can expect to have a 0.5-1MB bigger binary. since libressl is a dependency of dozens of programs, the disk usage would highly increase if all of them linked it statically. The same applies to all apps using X11 and GUI toolkits like GTK+2.
A: Regarding the toolchain, we prefer "tried and true" over "latest and greatest". An additional reason is that GCC 4.7.4 is the last GCC version before the C++ conversion, that means GCC 4.7.4 is the latest GCC version that can be bootstrapped with only a C compiler. Since (for simplicity and speed reasons) our Stage0 bootstrap-compiler is GCC 3.4.6, if we wanted to use a newer compiler we would have to build 4.7.4 anyway as an intermediate compiler to get a halfways-recent C++ compiler so we can compile GCC 4.8.x+. UPDATE: GCC 6.3.0 has hit the repo and is now the default compiler.
A: We use a custom version of busybox that was heavily patched and tuned so all of its built-in commands like awk, sed, grep, sh, etc are sufficiently bugfree and POSIX conforming that we can build the entire distro on top of it. Security fixes have been backported as well.
Q: I looked into KEEP/, and it appeared to be a mess of unsorted files. Why don't you put a package's recipe and patches into a separate directory like most other distros do ?
A: KEEP/ is not meant to be beautiful to a human eye. It's there so your computer can rapidly find files. Making one directory per package has a much higher cost in terms of storage and also when writing recipes since you have to type more. It's also one click more per package when you navigate around in a webbrowser or filebrowser. Additionally refactoring the file tree would make looking at a package's/patch's history with git log much more effort.