LINUX.ORG.RU

Первый установочный образ Stali (static linux) от сообщества Suckless

 ,


8

8

Сообщество Suckless, широко известное своей философией разработки ПО, а также набором программ, среди которых dwm, dmenu, surf, tabbed, st и другие, представило первый установочный образ дистрибутива Stali (static linux).

Проект интересен, прежде всего, множеством нестандартных архитектурных решений, отсутствующих в других дистрибутивах и воплощающих философию suckless на уровне ОС.

Основные отличия:

  • статическая линковка всех программ;
  • игнорирование FHS, предлагается иная иерархия директорий;
  • установка и обновление при помощи git;
  • замена coreutils и util-linux на sbase и ubase собственной разработки;
  • использование musl в качества системной libc;
  • отсутствие systemd, используется sinit (suckless init).

Разработчики отмечают более высокое быстродействие системы и низкое потребление памяти.

В дополнение к образу доступна пошаговая инструкция по установке.

>>> Подробности

★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)
Ответ на: комментарий от intelfx

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

Вообще-то для решения подобной проблемы (изначально целили на кучу одинаковых виртуальных машин) изобрели KSM.

gag ★★★★★
()
Ответ на: комментарий от intelfx

Мой месседж в другом: в случае со статически слинкованными приложениями идентичным страницам вообще неоткуда браться.

Хм, значит надо пробовать.

gag ★★★★★
()

статическая линковка всех программ;
низкое потребление памяти.

Опять на ноль делят.

ptah_alexs ★★★★★
()
Ответ на: комментарий от ptah_alexs

Конечно низкое, в более-менее современные десктопы можно напихать 64гига озу. А потом они жалеют каких-то 20гигов на систему.

anonymous
()
Ответ на: комментарий от unt1tled

выпилили systemd

Они его как бы и не впиливали. systemd sucks же.

anonymous
()
Ответ на: комментарий от intelfx

Все достаточно просто - SLAB запрашивает страницу памяти, и часть её отдает под объект кеша. Потом пихает в неё следующий объект кеша. И ещё. В это время освобождается первый элемент кеша, и эта часть страницы помечается как свободная. Допустим, у нас есть страница памяти, занятая объектами только на четверть. И где-то есть ещё страница памяти, в которой свободна только четверть. В таком случае аллокатор утрамбует все в одну страницу, а ещё одну страницу освободит.

P.S. Про дефграментацию наврал - тот патч так до сих пор и не приняли.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)

stali = static linux

Реально неудачное сокращение. От того и шутки про сталина. Обычно принято сокращать по-другому. Скажем, statlin.

А так, suckless известные в узких кругах ребята. Dwm, дух plan9, вот это все. Статическая линковка как панацея от нередких проблем ломания софта при смене версий библиотек - нормальная идея в из стиле. Взлетит по-любому.

polozz
()
Ответ на: комментарий от kirk_johnson

Минуточку, а как он всё утрамбует, если он выдаёт адреса объектов?

При следующих аллокациях понятно, что будут сначала заняты существующие частично заполненные страницы, а уже потом запрошена новая.

В любом случае, это не означает, что в одной и той же странице могут оказаться объекты из разных kmem_cache.

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

Во многих случаях достаточно общего понимания, чтобы делать определённые заключения.

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Минуточку, а как он всё утрамбует, если он выдаёт адреса объектов?

https://lwn.net/Articles/371892/

В любом случае, это не означает, что в одной и той же странице могут оказаться объекты из разных kmem_cache.

А я этого и не говорил. Я говорил, что kmem_cache могут использовать из нескольких разных точек, и не всегда последовательность вызовов совпадает. Это я к тому, что называть память «идентичной» я бы не стал.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от gag

Почему бы не собрать всё, а потом уже при запуске динамически(!) определять, если ли та или иная зависимость как плагин.

Потому что тогда вообще никак нельзя понять, какие у той или иной программы динамические зависимости. ldd перестанет работать.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Почему бы не собрать всё, а потом уже при запуске динамически(!) определять, если ли та или иная зависимость как плагин.

Потому что тогда вообще никак нельзя понять, какие у той или иной программы динамические зависимости. ldd перестанет работать.

Он про символы, а не про shared objects. Тащем-то, оно так и работает.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

А, оно работает только для заранее известных видов объектов, для которых можно гарантировать, что в определённый момент ссылок на объект ни у кого не останется? Тогда понятно.

и не всегда последовательность вызовов совпадает. Это я к тому, что называть память «идентичной» я бы не стал.

Ага. Я сильно упростил всё. Хотя наверняка есть и такие kmem_cache, которые заполняются детерминистично.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Гм? Он вроде говорит про поиск динамических библиотек и хедеров конфигурялкой при сборке.

Ммм... Если я правильно понял, чувак предлагает не линковаться, а делать dlopen() / dlsym(). В случае с плагинами это действительно Ok.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Ну да. И предлагает это делать не только для плагинов, а вообще для любых динамических зависимостей. А я говорю, что если так сделать, то тогда настанет кошмарный ужас и ldd перестанет работать.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну, делать это с жесткими зависимостями (libc, libm, etc) действительно идиотизм, да.

kirk_johnson ★☆
()
Ответ на: комментарий от monk

Не осилил в своём дистрибутиве сборку пакета? Зря.

Там нечего осиливать, это тупая рутина. Я вышел из этого возраста. Система до сих пор засрана всякими -dev пакетами, надо было в чруте собирать.

FreedomFighter
()
Ответ на: комментарий от monk

другая, то в дистре придётся выбирать что-то одно?

Посмотри как эту проблему решили в 0install.

Или предлагаешь разработчику пособирать свою программу под всевозможные комбинации версий библиотек?

Нет. Посмотри как эту проблему решили в 0install.

Надеюсь, ты не хочешь поставить параллельно несколько версий coreutils?

Если надо, я не против. Кому-то может религия не позволяет, а нормальному пользователю пофиг. Ему плевать что там за догмы не позволяют устанавливать параллельно разные версии ПО.

FreedomFighter
()
Ответ на: комментарий от FreedomFighter

Это ты как firefighter, борец со свободой? Туда ли ты зашёл петушок?

anonymous
()

Вот это ынтырпрайз! Срочно ставлю в продакшн!

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от intelfx

А откуда в «static qt» shared-часть?

Я собрал статически только qt, остальные библиотеки и есть shared.

На private-данных ты выиграл всего лишь 23% (3 MiB). Теперь если ты запустишь хотя бы ещё одно приложение на Qt, статическая линковка уже будет в проигрыше.

Private + Shared = RAM used Program 10.2 MiB + 7.2 MiB = 17.4 MiB qtconfig (static) 12.2 MiB + 7.3 MiB = 19.5 MiB linguist (static)

5.0 MiB + 11.6 MiB = 16.6 MiB qtconfig (shared) 6.2 MiB + 11.7 MiB = 17.9 MiB linguist (shared)

Теперь shared выиграл 7% 2.4 MiB. Тоже не особо впечатляет.

А если учесть, что большая часть библиотек обычно не с кем не разделяется ...

ИМХО разумный компромисс: нижней уровень системы (glibc/Xorg) и основной тулкит оставить shared, остальное статикой.

Давно думаю собрать две системы с одинаковым набором приложений и сравнить, но все руки не доходят.

MihailZenkov
()
Ответ на: комментарий от question4

Вот исходники GNU true http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/true.c;hb=HEAD там и help и version есть, а ты вызвал команду оболочки

$ /usr/bin/true --help
Использование: /usr/bin/true [ игнорируемые аргументы командной строки ]
       или:    /usr/bin/true КЛЮЧ
Выходит с успешным статусом.

      --help     показать эту справку и выйти
      --version  показать информацию о версии и выйти


ЗАМЕЧАНИЕ: ваша оболочка может предоставлять свою версию true, которая
обычно перекрывает версию, описанную здесь.  Пожалуйста, обращайтесь к
документации по вашей оболочке, чтобы узнать, какие ключи она
поддерживает.

Оперативная справка GNU coreutils: <http://www.gnu.org/software/coreutils/>
Об ошибках в переводе сообщений «true» сообщайте по адресу <gnu@mx.ru>
Full documentation at: <http://www.gnu.org/software/coreutils/true>
or available locally via: info '(coreutils) true invocation'

llllllllll
()
Ответ на: комментарий от MihailZenkov

Давно думаю собрать две системы с одинаковым набором приложений и сравнить, но все руки не доходят.

скоро и так вместо системы будет только браузер собранный как один большой кусок говна, так что не торопися. Хотя не - 2 куска говна - системд (в него войдут со временем пульсаудиа, пинус и нетворманагер) и браузер.

anonymous
()

среди которых dwm, dmenu, surf, tabbed, st и другие

Раньше думал, что mutt — тоже их поделие.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Я могу предположить что выигрыш статической линковки идет еще за счет LTO. В свое время собирал так php, действительно было раза в 2 меньше.

anonymous
()

Вообще, очень интересно, реально suckless. Пришло время снова попробовать линукс.

iz_tabakerki
()
Ответ на: комментарий от Reset

Годнота!

Да ну, говно. Проблемы, которые они пытаются решить, действительно достали, но их метод не очень хороший.

anonymous
()

ачоуж ещё своё ядро не сделали? идиёты, они не понимают главного. Память жрёт не прикладные программы, а сайты! ДА, я сказал сайты, а не браузер! Ну ещё игры, но тут уже смысл не тот.

darkenshvein ★★★★★
()
Ответ на: комментарий от Deleted

Какой инлайн при динамической линковке?

Натуральный.

Waterlaz ★★★★★
()
Ответ на: комментарий от vostrik

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

Лучшее описание этой инициативы! Я хотел написать что-то подобное, но лучше просто подпишусь под каждым твоим словом :-)

Pinkbyte ★★★★★
()

статическая линковка всех программ

Очень интересное решение, по крайней мере поэкспериментировать в этой области стоит. Задолбали все эти пакетные менеджеры зависимостей которые при установке нужной пользователю программы тянут десятки а то и сотни мелких пакетов. Уж лучше слинковать это всё статически с нужной версией. В итоге однажды установленная программа не прекратит вдруг работать из-за обновления 10Kb пакетика до новой версии. Представляю сколько усилий прилагают мэйнтейнеры дистрибутивов на отслеживание версий всей этой мелочи. Для чего это всё? Что бы сохранить немного памяти? Сейчас она не настолько дорогая.

Ещё заметил что некоторые программы, например firefox по дефолту собирается с некоторыми своими мелкими библиотечками. Вот из `equery uses firefox`:

 - - system-cairo         : Use the system-wide x11-libs/cairo instead of bundled.
 - - system-icu           : Use the system-wide dev-libs/icu instead of bundled.
 - - system-jpeg          : Use the system-wide media-libs/libjpeg-turbo instead of bundled.
 - - system-libvpx        : Use the system-wide media-libs/libvpx instead of bundled.
 - - system-sqlite        : Use the system-wide dev-db/sqlite installation with secure-delete enabled

Думаю можно оставить воможность иметь динамически линкуемые библиотеки для крупных пакетов, например Qt, GTK, причём в слотах для разных версий. А всю мелочь линковать статически. Это сильно упростит зависимости.

iluha16
()

Когда-то очень хотел такой дистр. Но все мои мечты разбились о суровую реальность — слишком много говна, которое не линкуется статически.

Waterlaz ★★★★★
()
Ответ на: комментарий от Reset

Вот и говорю, что годнота, а быдло-куны не понимают и пишут «ненужно».

Waterlaz ★★★★★
()
Ответ на: комментарий от intelfx

Напротив, они заявляют, что динамическая линковка — безусловное зло.

Может быть и не безусловное зло, но создает больше проблем, чем решает.

Waterlaz ★★★★★
()

Пользователю совершенно без разницы будет ли софт устанавливаться в /bin/, /sbin/, /usr/local/bin, в /opt или домашний каталог. Главное чтобы собрано был нормально и этой проблемой занимаются мейтейнеры.

anonymous_sama ★★★★★
()
Ответ на: комментарий от FreedomFighter

Ему плевать что там за догмы не позволяют устанавливать параллельно разные версии ПО.

Нахрена это делать???

anonymous
()
Ответ на: комментарий от Deleted

на правах петросянства

Stalin

cannot be installed: missing dependency «СССР»

а вообще, похоже на вброс. пацанчики могли и бы до 1 апреля дотерпеть :)

Rost ★★★★★
()
Ответ на: комментарий от Waterlaz

гг, маньяки какие-то значит.

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

Rost ★★★★★
()
Ответ на: комментарий от anonymous

Нахрена это делать???

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

iluha16
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.