Alpine 3.10.3

«По умолчанию, Alpine Linux во время запуска полностью
загружается в оперативную память.»

Значит это не мой вариант, памяти-то всего гигабайт

Написано же по умолчанию, а если и так, то чем это мешает, если «всего гигабайт»?

из которых четверть отжирает видюха Nvidia ion.
четверть отжирает
Nvidia ion

Ну, вы же сами покупаете всякие наглухо проприетарные костыли, которые ещё и дропнуты бывают в поддержке от производителя, кароч эталонный ССЗБ!

«Размер базовой системы Alpine Linux составляет
всего лишь 4-5 Мбайт (исключая ядро).»

Т.е. там нихера нет драйверов

По вангованию, на основе размера БАЗОВОЙ системы, судят о сборке ядра, это что-то интересное?!

100% вайфай не взлетит, а кабеля у меня нет

Ну так, опять же кто виноват, если вы приобрели такое железо, и кто виноват что кабеля нет? Или вы ищите дистрибутив, который вам кабель организует?

Я пробовал и другие дистрибутивы, даже с non-free,
не все были лояльны к железу.

Вы делаете выводы не с той стороны, это ваше железо, точнее его производитель, не лояльны к линуху.

Поэтому остаюсь на antiX-core. Там все в шоколаде

Ради бога, разве кто-то заставляет уходить, или вы для какой-то иной цели нас тут информируете об этом?

просто не люблю deb.

Бывает

Почему? хз, не могу аргументированно объяснить.

И такое бывает, тут таких в достатке.

Работает он не быстрее. Алгоритмы конечно проще, но не значит что лучше. То что убрали такую ненужную сущность как локали - хорошо конечно, но вот asan/ubsan сэкономили бы кучу времени при отладке/портировании. Итог - для тестирования и отладки musl не годится. Даже gdb хуже работает, а про затирание кучи - реальный случай. Прсото пропадала половина односвязного списка через неделю работы сервера из-за переполнения буффера в куче. Для того чтобы развернуть компактное уже отлаженное окружение - вполне годится.

Живи сейчас, потом будет недоступно.

Вот я говорю — пустая трата времени, эти твои Альпы-шляльпы.

«Alpine Linux стала использовать библиотеку musl, которая является частично бинарно совместимой с glibc.»

вот тут я хочу спросить: а там есть gcompat (это такая шняга для повышения совместимости бинарей между musl и glibc)? типа, она предоставляет заглушки или адекватные замены для тех функций, которые в musl отсутствуют, а в glibc часто используются.

памяти-то всего гигабайт из которых четверть отжирает видюха Nvidia ion.

у меня с musl система на старте отжирает 118 мегабайт (ну, чуть меньше, на самом деле). но это уже с WM и всеми демонами и всякими утилитами. у меня их больше, чем у среднестатистического юзера. так что загрузка таких систем в память - это не страшно. сейчас реально много отжирает только браузер и всякая мультимедия. на старое железо можно поставить Slitaz и там будет ещё меньше отжирать. я его на виртуалках с 256 метрами памяти запускала.

а если ядро поднастроить и выкинуть всё ненужное, то там ещё меньше будет. я на 16 метрах памяти линь запускала, при правильной настройке работает. но, конечно, без браузера.

ну так косяки в софте - не проблема musl. понятно, что с кривыми руками к нему лучше не приближаться. там, где glibc понаделает всяких подушек и заглушек, musl просто честно выполнит инструкцию. если программист написал фигню - фигня и выполнится. и поэтому, без всяких проверок на каждый чих, он работает быстрее.

конкретно про распределение памяти - это зависит от кучи параметров. от компилятора (причём повторяемые компиляции - это ещё отдельная сложная тема), от библиотек, от реализации выделения памяти, от архитектуры процессора. так что то, что при ошибках не падало две недели, потом вдруг может упасть сразу, или вообще не упасть, или упасть только при выполнении на нескольких ядрах, или только на одном. но память-то портится. и это просто баги софта. но для отладки, внезапно, не нужно, чтобы софт прямо шлёпнулся с явным сегфолтом. для этого есть другие средства. тот же valgrind прекрасно справляется. и не надо никакой попсы. есть средства отладки в сложных условиях, на серверах, когда ошибка может вылезать раз в полгода. я не буду углубляться. но по хорошему, просто надо писать код с умом. тогда и такая отладка не понадобится.

musl реализует стандарт. всё остальное - на разработчике.

я ещё добавлю, что самая частая проблема современного софта - косяки синхронизации. доступ к общей памяти, залочивание ресурсов. и это никакие упсаны не найдут. многопоточная разработка - вопрос квалификации программиста. сейчас вдвойне актуально, потому что вся производительность зависит только от умения грамотно распараллеливать задачи.

кстати да. Сейчас с этим столкнулся. Купил плеер с сырым портом rockbox, а он раз через запуск начинает жрать процессор. Вот и не угадаешь, проживёт плеер 5 часов или 10. Что-то с таймерами намудрили, уже 3й день код изучаю в попытках разобраться, быстрее бы наверно с нуля плеер написал

asan/ubsan - не фича glibc. Просто они зависят от какого-то функционала отсутсвующего в musl. Насколько он важен - отдельный вопрос, но думаю, что не только asan/ubsan на этом завязаны.

я понимаю, что не фича glibc. я их (фичи) знаю более-менее. в glibc есть всякие дополнительные плюшки, на которые годами навешивался разный функционал. но мне из без них нормально. я могу простыми средствами отладить что угодно. наверное, и в musl разные счётчики добавить несложно, но просто никому не надо.

гдеб скачать такой «сделанный с любовью» дистр?)

люди хотят «дистр», а у меня частная сборка. я не задаюсь целью превращаться в майнтейнера (для этого у меня нет времени). просто делаю настройку системы под свои хотелки.

Отличный дистр, хотя у их дерева портов нету лицензии.

Вообще никакой, ноль. По закону это максимальный копирайт, никто просто ещё не начал бить в колокол.

Ввести лицензию нельзя, потому что нужно будет спросить тысячи контрибуторов

Разрабы об этом не подумали в свое время, потому что они Васяны

Хорошо, когда знаний и умений хватает, а что делать обычным смертным?)) Этож пока одну хотелку, Бог даст, реализуешь, уже другие хотелки неактуальными становятся)))