Ігнорування FSHS — зло, статичні бінарники — зло, не використання systemd — фігово, musl — повільніший за glibc, відсутність LD_PRELOAD — не фіча, оновлення через git — зло, маленький розмір — не грає ролі якщо це не роутер якийсь.
Ну, незнаю, вам видніше, бо ці чуваки (і чувачки) пишуть у своєму фак’ю що не так усе і погано — http://sta.li/faq . Зокрема там пояснюється чому їхні маленькі "статичні" бінарні файли не є зло,
і чому вони віддають перевагу отому "muscl",
і чому-це оновлення через GIT_HUB зло?
Централізація, так, але , ну скажімо так, у випадку коли ти у РФ/Україні, то це навпаки вигідніше, Я гадаю...
Як по мені, то статична фішка у пам’яті із "динамічниою адресацією" виглядає прикольно. Мені, як не обізнаному у даній темі, важко щось розсудити, але 34 МБ, дуже заманливо для мене!
Нічого не зрозумів.
Статичні файли були ще у версії Лінукс 0.0.1. Від них відмовилися по дуже простій причині: вони жруть пам'ять: дискову пам'ять, ОЗП, кеш процесора. Особливо цінна пам'ять — це кеш процесора другого-третього рівня, який один на всіх і котрого всього 0,5-6Мб. Коли кеш процесора заб'ють кілька копій однієї й тієї ж функції з різних бінарників, то частота процесора(-ів) впаде до частоти пам'яті — тобто всі n процесорів сидітимуть і чекатимуть поки пам'ять їм щось пришле на виконання. На іграшкових системах це швидко — бо кеш вміщає все, а на завантажених системах настає торба.По друге, статичне лінкування підпадає під дію ліцензії LGPL, яка вимагає щоб у такому випадку бінарник теж був під дією (L)GPL, що далеко не всім підходить. (Це стосується і docker-а).
Aren’t statically linked executables consuming more memory?We believe that due to the small size of the base system the opposite will be the case. First of all, the kernel will load each static executable’s .rodata, .data, .text and .comment sections only once for all instances into memory. Second, because each static binary has only been linked with the object files necessary, it has already been optimized at linkage time for memory consumption. When loading it, we don’t require the kernel to map all dependent dynamic libraries into memory from which our binary might only use 5% of the functions they provide. So, in reality, the memory footprint is becoming less, and the dead code hold in memory (or paged) reduces overall consumption. This is also true for programs, like surf, which don’t use all webkit/gtk/glib functions.
muscl в два рази повільніший за glibc. Розмір бібліотеки на диску мене не турбує, так як в пам'ять витягується лише те, що використовується (сторінками по 4Кб).
POSIX threads refers to threads with real POSIX semantics, not the historical broken LinuxThreads (where each thread behaves like a distinct process) or similar implementations.
Тому що github — це приватна контора. А git не призначений для роботи з бінарниками і його кеш об'єктів буде пухнути при кожному оновленні. Якщо вас так хвилює місце на диску, то вас повинно хвилювати те що git витрачатиме в кілька раз більше місця під зберігання даних про цей дистр, чим сам дистр. І ця пропорція з часом буде тільки рости.Що саме вигідніше? Оновлення дельтами? Так воно є і у Федорі чи ЦентОС.
Cryptographic authentication of history The Git history is stored in such a way that the ID of a particular version (a commit in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a Merkle tree, but with additional data at the nodes as well as the leaves.[32] (Mercurial and Monotone also have this property.)
Periodic explicit object packing Git stores each newly created object as a separate file. Although individually compressed, this takes a great deal of space and is inefficient. This is solved by the use of packs that store a large number of objects in a single file (or network byte stream) called packfile, delta-compressed among themselves. Packs are compressed using the heuristic that files with the same name are probably similar, but do not depend on it for correctness. A corresponding index file is created for each packfile, telling the offset of each object in the packfile. Newly created objects (newly added history) are still stored singly, and periodic repacking is required to maintain space efficiency. The process of packing the repository can be very computationally expensive. By allowing objects to exist in the repository in a loose, but quickly generated format, Git allows the expensive pack operation to be deferred until later when time does not matter (e.g. the end of the work day). Git does periodic repacking automatically but manual repacking is also possible with the git gc command. For data integrity, both packfile and its index have SHA-1 checksum inside, and also the file name of packfile contains a SHA-1 checksum. To check integrity, run the git fsck command.
Цитата: OzySTS275Ma від 2016-03-29 05:46:01Як по мені, то статична фішка у пам’яті із "динамічниою адресацією" виглядає прикольно. Мені, як не обізнаному у даній темі, важко щось розсудити, але 34 МБ, дуже заманливо для мене! Нічого не зрозумів.
Another argument often heard is that static functions have predictable addresses, whereas dynamic linking provides the ability of address randomization. We have two answers to this. The first is: it is simple to use position-independent code in static executables and (assuming a modern kernel that supports address randomization for executables) fully position-independent executables are easily created on all modern operating systems. The second is: In reality, address randomization is predictable and we usually see the same addresses when a dynamic library is loaded or has been pre-loaded again and again. Thus we consider this as an issue with low impact and this is not a real focus for us.
... А тут , можливо, майбутній Бох світу машин — Озі, "роздупляється" із лінкуванням .
