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)

Добавил в меморис, надо будет потыкать

Deleted
()

игнорирование FHS, предлагается иная иерархия директорий

Ожидал увидеть нечто в духе Gobolinux.

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

Ты даже не знаешь как в винде. :)

Я верю, когда-нибудь наступит светлое будущее, в котором ни один человек не будет знать, как в винде.

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

dwm

Это для гиков, потому, что

cause dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

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

т.е. со временем .git распухнет до безобразия? (или я ошибаюсь?)

В генте дерево портажа так обновляется, просто клонируется с depth 1

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

Я конечно не уверен, нужно проводить детальный анализ конкретных случаев. Но ИМХО глобальных переменных все стараются избегать, так что их не много. А вот статических переменных очень много и выбрасываются они очень легко вместе с функцией.

По поводу умного компоновщика - все уже давно придумано и отработано (-ffunction-sections,-fdata-sections, --gc-sections).

MihailZenkov
()
Ответ на: комментарий от I-Love-Microsoft

откуда у тебя Linux растет? 8)

Я имел в виду не отказался даже если бы Линукс отсосал у меня.

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

А если судить по дате исошника

Я судил по

http://morpheus.2f30.org/0.0/packages/

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

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

Это для гиков

Хуже. Для илитных гиков.

anonymous
()

... широко известное своей философией разработки ПО, а также набором программ, среди которых dwm, dmenu, surf, tabbed, st и другие ...

«Кто все эти люди?»

anonymous
()

и воплощающих философию suckless на уровне ОС.

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

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

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

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

Мне

Но зачем? Конечно, как и любой софт, сделанный евангелистами, stali мог бы сойти за proof of concept. Мог бы доказать, например, возможность построения юзабельной системы на succless-идеологии или профит от повальной статической линковки. Впрочем, он не доказывает первого, ибо вряд ли является юзабельной системой, и не доказывает второго, ибо вменяемых бенчмарков создатели выкатить даже не попытались.

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

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

«Мальчик, ты дурак?» Возьми уже какой-ниюудь букварь и прочитай как оно работает.

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

А вот статических переменных очень много и выбрасываются они очень легко вместе с функцией.

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

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

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

Уверен? У kmalloc'а (если более точно, у SLAB/SLUB аллокатора) нет проблем с отдачей тебе второй половины страницы. Память не обязательно будет выровнена по началу страницы.

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

Это если исходить из того, что все аллокации происходят в том же порядке и с тем же результатом (SLAB/SLUB отдает объекты в том же порядке, в чем лично я не уверен).

P.S. Куда интереснее другое:

KSM only operates on those areas of address space which an application has advised to be likely candidates for merging, by using the madvise(2) system call: int madvise(addr, length, MADV_MERGEABLE).

The app may call int madvise(addr, length, MADV_UNMERGEABLE) to cancel that advice and restore unshared pages: whereupon KSM unmerges whatever it merged in that range. Note: this unmerging call may suddenly require more memory than is available - possibly failing with EAGAIN, but more probably arousing the Out-Of-Memory killer.

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

Это они же отказались от bool.h. Ну такое.

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

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

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

P. S.: разве одна и та же страница может быть отдана под два разных slab'а? Сомневаюсь. С-но, о том и речь, что хоть и какие-то недетерминистично заполняемые таблички будут отличаться, совпадать тоже много что будет.

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

P.S.: разве одна и та же страница может быть отдана под два разных slab'а? Сомневаюсь.

Достаточно одного SLAB cache размером меньше 4k.

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

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

tiandrey ★★★★★
()

Вариант для arm есть?

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

Как я уже сказал - нужно пробовать и проверять.

Что бы не быть голословным попробовал собрать qt-4.8.6 и сравнить используя ps_mem.py.

Private + Shared = RAM used

13.5 MiB + 7.0 MiB = 20.6 MiB qtconfig (shared qt)

10.4 MiB + 7.0 MiB = 17.4 MiB qtconfig (static qt)

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

Это когда от библиотек, которые зависят от GovnoSSL.

Когда тело функции находится в заголовочном файле.

Речь о линковке, никаких заголовочных файлов уже нет.

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

в идеальном мире оно так
но стоит, например, в GTK+ окружении запустить браузер (лису, например) и приложуху на Qt - и вот у тебя полторы сотни одиноких либ подгрузилось, которые ничему больше не нужны кроме этих двух
что примерно на сотню меньше общего количества либ (т.е. где-то 100 используется больше одного раза)

причем самый жыр, типо libxul.so или libicudata.so или libQtGui.so, больше никто не хочет на данный момент

ткчто, IMHO, в другом идеальном мире могло бы быть с точностью до наоборот

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

Так о том и речь: обновишь динамическую библиотеку (*.so файл), а те функции, которые целиком были в заголовочных файлах при сборке программы, останутся старыми. Единственный вариант повторная сборка всей программы.

Короче grep -rn inline /usr/include в помощь.

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

Значит, библиотека не заботится об ABI. Мы же сейчас о видах линковки говорим, нет? Это личные проблемы сишки/крестов.

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

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

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

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

Когда ты в GTK'шном окружении что-то на Qt запускаешь - понятно дело, что Qt никому, кроме того одного приложения, не нужен. Однако libgtk используется многими приложениями.

Аналогично в Qt'шном окружении тяжёлые libQt* используются многими приложениями.

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

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

То есть как в винде? Ненужно!

А если как в маке? )

snaf ★★★★★
()

А я приветствую! Если бы systemd не выпиливался бы из Jessie (Debian), я сидел бы на одном из 3-х вариантов (Гента, Слака, ФриБСД - ни один не нравится). Появился 4-ый.

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

Поэтому - успехов новорожденному!

(d - спасибо)

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

Ну мне показалось, что речь как раз про такое направление мысли. С другой стороны - статическая линковка с LGPL приложений под MIT, BSD и иже с ними.

h4tr3d ★★★★★
()

Идеи забавные, но когда утверждают улучшение перформанса, аргументируя фразами уровня «we believe that...», не приводя никаких пруфов, возникают смутные сомнения. Новизна тоже сомнительна — кажется, что-то подобное было ещё в Plan9, да и вообще в разделе rocks на этом их suckless пиарят веб-сервера на select, называя их «fast» и вызывая сомнения в адекватности всей этой движухи, несмотря на то, что софтины у них в общем-то неплохие.

С другой стороны, вызвав срач на лоре, ребята, возможно, достигли цели — их идеи обсуждают, значит, они пошли в массы :D

И да, структура файловой системы правда норм, хочу себе такую в арче (учитывая, что всё равно /sbin давно симлинк в /usr/bin — кажется, разумнее было наоборот).

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

По линку всё же более крассический дистрибутив. Кстати, рекомендую для любителей арчика без systemd ;-) особенно тем, кто пакетированием занимается - будете приятно удивлены.

h4tr3d ★★★★★
()

На ЛОРе слышали про alpine, docker, unikernel? Судя по комментариям, люди вообще не в тренде.

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

На их сайте в разделе people

хорошая шутка

Статическая линковка. Хм, как-то напоминает Plan 9. И да, один из пиплов на скриншоте Uriel. Был причастен к Plan 9, поэтому я его и запомнил. Но не знал, что и к suckless тоже. Очень жаль, что скоропостижно скончался.

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

А git, типа, не sucks.

Должны были взять fossil, т.к. там как раз и объясняют, что у них есть всё что нужно, но без git-магии.

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

То есть как в винде? Ненужно!

в винде не статик, в винде 95% аппов таскают с собой 95% либ.

А те, что не таскают, могут страдать от DllHell.

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

А ещё у их проектов отличный код. Ничего лишнего, всё просто и юниксвейно,

согласен, кстати, но вот есть и плохие стороны этой простоты, типа патчей вместо плагинов

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

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