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

Ну был Столлман. Есть suckless. Что плохого к размахиванию плакатом? Я вот читал, что ты ярый приверженец systemd. Какая разница? Используй то, что удобно. Но! Если появятся последователи? Что плохого? Выйдем на новый уровень. Я только за. И за статику, и за никсос. Я - за альтернативу! А некоторыми программами парней ну очень удобно пользоваться. И как пособие - ну прелесть. Писали бы так чаще, эх...

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

К сожалению ничего знакомого.

Попробуй. Что-то есть в них такое...

Не нужно философского словоблудия. Я написал про конкретный технический недостаток статической линковки.

Название дистра и некоторых каталогов нелепое и никто всерьез не полезет это юзать.

свой дистр выпустить можно со своим названием. а название каталогов - ну на то так и названо чтобы например в /sucks не было желания ничего совать.

Не спорю. Эти идеи однозначно получили продолжение, и меня бесконечно радует, что всё больше крупных проектов понемногу приходят к понимаю того что код надо упрощать и старый и неиспользуемый функционал выкидывать. Но в текущем виде - я вообще не вижу как этот дистрибутив можно использовать в любых рабочих и тем более крупных проектных целях, кроме как показать своим коллегам - «смотри как они офигенно сделали». Их идея, один (и только один) инструмент для решения одной задачи - идея очень смелая и прогрессивная, но в текущих реалиях неприменима, просто потому что объективно сложно решить какой инструмент лучше, а какой хуже для конкретной задачи, совместимость между разными тулзами и компонентами не стопроцентная, а это значит что любой крупный программный продукт так или иначе будет зависить от конкретных инструментов и окружения (дело ведь не только в зависимостях от библиотек). Использование гита вместо пакетного менеджера - это уже вообще лютый зашквар и перегиб, что они вообще курили перед тем как решили использовать систему контроля версий в роли пакетного менеджера ? А по их идеологии, другого инструмента для данной задачи не будет. Так что я пока-что не вижу никаких других применений для этой их поделки кроме как пропаганда и продвижение их идей в массы, и это уже тоже достаточно на самом деле. Может для каких-то встраиваемых систем тоже можно использовать. Но всё-таки не массовое применение.

вижу фанбои systemd засуетились. это радует - значит всё авторами дистра делается правильно.

Строгий и наглядный код ? Не смеши мои седые волосы. Я читал этот «строгий» и «наглядный» код. Когда там имена переменных x, y, z объявлены. Кода вроде 2к, а читать его можно если только очень хотеть этого. При этом, если я хочу почитать этот код, с целью добавить в него функционал, нужный мне, - то это «недостаточно хотеть». Рассказать тебе про патчи, которые написаны с той же идеологией «строгого» и «наглядного» кода, которые так же используют в своих функциях x, y, z ? Которые после патченья можно разобрать лишь трасируя код в дебагере. Это ты называешь строгим и наглядным кодом ? Имхо, идеология саклесс такая: мы упираемся в slockx, где будет минимальный функционал. Там конечно есть баги, но это правильные баги и если вам надо - вы их поправите. А если вам нужно добавить функционал нужный вам, - вы сможете прочитать написанный нами строгий и наглядный код. Иначе - вы не нужны. Идите читайте книгу по си, читайте и дебажьте. Если вы не смогли это сделать - идите нафиг. Потому что мы пишем код для программистов, а не для юзеров

Строгий и наглядный код ? Не смеши мои седые волосы. Я читал этот «строгий» и «наглядный» код.

+1

Копался в коде sandy, их текстового редактора. Кривой, тормозящий, нерасширяемый код, требующий решительного рефакторинга. suckless, ага.

Взяли бы минимальное у бсдшников или у миникса.

То есть при следующей баге в какой-нибудь либе пол-системы пересобирать? А они там не поехали?

там всё равно из собранных статически будут только suckless tools, а большие штуки будут в /sucks, слинкованные с глибц, и ваще всё как у нормас людей

А, ну то есть как обычный дистр, но все бинарники в /sucks?

Как это мило.

/sucks для того, что сосёт

т.е. для всего кроме их мегакрутых тулзов. скорее это нечто вроде /usr, но только для нормальной части системы

И будет не нужно в квадрате.

Только вот многий софт прибит к FHS, нужно бы как-то из упрекать в этом. А то не работают адекватно.

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

LGPL требует возможности перелинковки:

Для проприетарщины. LGPL, насколько я понимаю, совместим с GPL и не мешает распространять что-то статически под GPL.

А чем эта штука лучше, чем http://morpheus.2f30.org/ ?

В морфеусе хоть пакеты есть. И даже графика. И всё статически.

В том числе косвенно, т.е. my point still stands.

«Косвенно» это как ?

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

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

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

А как они это делают, если у них библиотечный код продублирован в куче бинарников?

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

Все не так просто: динамические библиотеки (как и приложения) имеют разделяемую (shared) зону памяти и не разделяемую (private). Для больших библиотек private может быть соизмеримым (а то и больше) private самого приложения.

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

Как я уже говорил, проще всего запустить ps_mem.py и самому понять имеющийся выигрыш от shared.

так а там есть какой-то ДЕ?

Ты так говоришь, как будто в случае статической линковки private-часть (то бишь секция данных) куда-то денется.

Вся команда в поте лица 10 лет трудилась над тем, чтобы почти все(хи-хи) тузлы из busybox со статической линковкой сделать и прикрутить свой sinit.

Там WM.

Да, так как мало вероятно, что приложение каждое отдельное приложение будет использовать более 50% библиотеки.

Грубо говоря: используем 10% библиотеки, получаем 10% от ее private.

низкое потребление памяти.

А как они это делают, если у них библиотечный код продублирован в куче бинарников?

У них вместо glibc используется http://www.musl-libc.org/. Кроме того нормальные статические библиотеки линкуются не целиком, а только используемые куски.

В общем, смотри сам: http://git.sta.li/rootfs-x86_64/tree/bin

cat — 26K. dd — 46K. Для сравнения в Debian cat — 52K, dd — 72K. Несмотря на то, что динамические.

Если речь про stali, то там даже иксов нет.

Но как система будет без демона системы?

GNU true такой же:

me@jet ~ $ true --help
me@jet ~ $

Хех, у них /root-а отдельно нет. Чем они мотивируют такую иерархию?

Чем он лучше /home/root ?

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

Мелькают в разных идеологических спорах. В Gentoo в официальном дереве 21 пакет с их сайта. Список интересует?

справедливости ради: /bin/true --help

Ради интереса проверил на osx

$ ls -al /bin/cat /bin/dd
-rwxr-xr-x  1 root  wheel  23520 Dec  3 09:34 /bin/cat
-rwxr-xr-x  1 root  wheel  31856 Dec  3 09:34 /bin/dd

/ - the root home
/bin - all executables
/sbin -> /bin # softlink pointing to /bin
/boot - all boot files
/etc - system configuration
/home - user directories
/var - spool, run, log, cache
/share - man pages, locales, dependencies
/include - include/headers

Слишком часто в инклюды ходят, что нужно срочно из usr в корень положить.

/lib - static libraries for building stuff
/mnt - mount points
/usr -> / # softlink pointing to /

Съэкономил 3 байта - молодец. Хотя погодите, инклюды уже в корне, а теперь они уже в корне 2 раза.

Based on the Linux assumption:

/dev - devices
/proc - proc files
/sys - sys files

For crap stuff:

/sucks - stuff that sucks, like ugly gnu library
dependencies, or systemd fake handlers

Можно всю такую иерархию засунуть в sucks - нечего стесняться.

справедливости ради: /bin/true --help

Не учёл :)

должен быть один общий дстронезависимый стандарт пакетов принят

Полностью согласен. И расширение что-то типа lpk(linux package), чтобы его можно было поставить в любом дистрибутиве без конвертаций. По-моему это должно быть очевидно как для мейнтейнеров дистров, так и для девелоперов.

Стандарты необходимы и dependency hell и устаревшая FHS уже всех достали, даже самого Линуса.

Проще пареной репы.

нет, проще станет, когда мэйнстримные пакетные менеджеры научат держать в системе несколько версий.

Эти парни курят реальную дурь, инфа 100%

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

То есть, если у разработчика GIMP одна версия glibc, а у разработчика Inkscape — другая, то в дистре придётся выбирать что-то одно?

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

Мне однажды пришлось слезть с LTS на альфу только из-за того что новый Гимп и VLC требовали новых версий всяких библиотек, которые нельзя было установить в текущую систему, ничего не сломав.Не собирать же все зависимости самому (в /opt, например).

В этом смысле ничего бы не изменилось.

Я хочу иметь возможность ставить параллельно разные версии ПО. Я хочу иметь возможность поставить KDE4 и KDE5 параллельно.

Если у них нет общих файлов, то в чём проблема? А если есть, то вопрос к разработчикам или ставь в /opt. Надеюсь, ты не хочешь поставить параллельно несколько версий coreutils?

Мне однажды пришлось слезть с LTS на альфу только из-за того что новый Гимп и VLC требовали новых версий всяких библиотек

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

В целом они близки по производительности

В мюслях почти всё медленнее в 1.5-2 раза. Близки, ага.

Но скорость работы с utf8 у glibc существенно меленее.

При этом говнософт этих посанов почти никогда вменяемо не поддерживает юникод.

Олсо, какую поддержку utf8 предоставляет libc. Не пытаюсь оспорить, просто интересно.

мэйнстримные пакетные менеджеры научат держать в системе несколько версий

Дело не в пакетных менеджерах, а в FHS и желании разных версий программ иметь одинаковые имена файлов.

Вот прямо так?

А из чего вообще состоят private-данные разделяемых библиотек? .data+.bss, ещё что?

Если больше ничего, то вынужден усомниться в том, что «50% библиотеки = 50% приватной части». .data+.bss — это глобальные переменные и статические переменные, выполняющие роль разных кэшей. По опыту разработки — такие вещи чаще встречаются в кишках библиотек, во внутренних функциях, которые достижимы почти из всех точек входа в библиотеку. Поэтому выкидывание половины текста при статической линковке не приведёт к выкидыванию половины глобальных данных. Даже в том случае, если у нас шибко умный компоновщик, который построит граф достижимости, порежет мёртвый код и так далее.

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

Интересная идея - спаять дистриб на повальной статической линковке с LTO. Впрочем, например, с glibc статическая линковка проигрывает в рзмере. Заменили glibc тормозной маргинальщиной, ок. Но у кого гарантия, что с кучей других нужных библиотек не получится, как с libc?

Олсо, source-based нужен только если всякую блоатварь уже собрали мэйнтейнеры, а если нет - идёт накер, тем более, с пересборкой пакетов на каждый чих из-за статической линковки. Конечно, могут набижать адепты минимализма и кричать, что блоатварь нинужна - тогда жду описания преимуществ tabbed+surf перед любовно настроенной лисой.

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

замена coreutils и util-linux на sbase и ubase собственной разработки;

Смысл?

используется sinit (suckless init).

Чем оно лучше systemd?

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

Вангану - ПО, не являющееся их говноподелками они на stali не тестировали.

В морфеусе хоть пакеты есть. И даже графика.

И всё умерло в далёком 14 году.

В морфеусе хоть пакеты есть. И даже графика.

И всё умерло в далёком 14 году.

Жесть какая-то. Закапывайте.

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

Название дистра и некоторых каталогов нелепое и никто всерьез не полезет это юзать.

Кстати, не понимаю этой фобии по поводу сосания. Я б не отказался если бы у меня отсосали, пусть хоть линукс.