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)
Ответ на: комментарий от Softwayer

как-то преподователь ОБЖ байки травил:

на каком то производстве женский коллектив стал не предназначенное для того помещение использовать как сушилку(для одежды).

после того как разрядом убило одну из клуш(при перевешивании сушимого)(сори дарвин)

весь коллектив осознал что за помещение то было

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

А какими путями достигается возможность подмены кусков работающей системы?

меньшей монолитностью процессов

т.е сами проги монолитней за счёт статики но вся система большее разбита на программы взаимодействующие меж а не внутри «процессно»

кста та ще ерланг0идея о том же проще упасть чем рекавери.

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

Хватит пиарить свой говносайт, засовывая ссылки в каждый комментарий.

Хочешь поделиться каким-то текстом — давай ссылки на публичные, широко известные ресурсы, или хотя бы на gist/pastebin.

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

Чтобы меньше пердаков взорвалось. А то и так атмосфера душная.

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

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

Но мне нравится мой сайт, он просто прекрасен.

Кстати, я дополнил статью, собрав разрозненную информацию в одном месте: http://webhamster.ru/mytetrashare/index/mtb0/1459103448okrwleymid

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

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

«И кто ж Вам после этого доктор». Впрочем, я почти уверен, что и емерж не так убог, каким Вы его пытаетесь представить. Однако, заглядывать внутрь лень.

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

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

Правильно. Их не будет много - их будет очень много.

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

Потому что хрен соберёшь все зависимости статик?

Да и днищелинкеры нихрена не убирают - поэтому что статик - что не статик. Срать на это.

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

Библиотека имеет небольшой размер и высокую производительность,

О боже - не смеши мои тапки. Там производительности -1, даже не ноль. Убогая школьная поделка.

полноценную поддержку стандартов

Это никому не интересно. Поддержку стандарта напишет любой школьник за 2дня.

с небольшим размером, низким потреблением ресурсов и высокой производительностью, свойственными специализированным вариантам libc для встраиваемых систем

Нет вася. Для встраиваемых системем как раз-таки и подходят библиотеки с производительностью -1.

Там где «встраиваемое» - там производительности нет по умолчанию. Там где «переносимое» так же.

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

Т.е. чтобы получить вменяемый статик - надо юзать хеадеронли + whole-program. Запилили ли lto для статических библиотек - я не знаю - но без него весь этот балаган смысла не имеет.

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

Динамическая линковка потому и динамическая, что позволяет ЛЕГКО МЕНЯТЬ уязвимые библиотеки без перекомпиляции всего дистра.

Да ну. Поменяй легко glibc 2.5 на glibc 2.7.

Или поставь в одну систему gtk1 и kde4. С динамической линковкой разве что через chroot.

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

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

Можно хоть один конкретный пример, когда в релизном (не в роллинге) дистрибутиве обновление библиотеки что-то сломало? Ну, то есть максимально конкретно — дистрибутив, его версия, версия библиотеки, с которой работало, версия библиотеки в обновлении, с которой сломалось то-то и то-то. А то я прям себя каким-то офигенно удачливым уже чувствую — за много лет все мои десятки линуксов как часы работают (скажем, 12309 я последний раз видел в 2009), а так хоть реальную проблему увижу.

redgremlin ★★★★★
()

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

Депенды — химически чистое зло.

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

Линковка дерьмо и никакой линкер не умеет ничего и никак удалять.

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

Glibc'шники на это давно забили болт по принципу «чего напрягаться, всё равно у нас динамическая сборка». А вот musl'еры изначально ориентировались на статик, и у них всё с этим хорошо. У них вообще всё хорошо, я их maillist читаю, весьма увлекательно.

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

Static linux = Stalin

Дык Stalin Scheme же. Конфликт имён и всё такое, название давно занято.

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

Можно хоть один конкретный пример, когда в релизном (не в роллинге) дистрибутиве обновление библиотеки что-то сломало?

Всё несколько хуже. Common usecase таков: меня перестаёт устраивать некий ОДИН маленький пакетик, потому что, например, в его старой версии слишком мало функционала. Я пакетному манагеру говорю, мол, обнови мне его. Пакетный манагер видит, что новая версия мелкого пакетика зависит от новой версии полудюжины либ, заносит лапу, чтобы их все обновить, за ними тянется весь стафф в системе, который зависит от тех же либ, причём некоторые пакеты зависят ещё от каких-то либ, что тянет кого-то ещё и т.п. В итоге манагер мне заявляет, что скачать нужно пять гигов пакетов и заменить в системе вообще чуть менее чем всё. После чего он получает по сусалам, а я продолжаю использовать старую версию того маленького пакетика, либо качаю его исходники и собираю сам.

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

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

Линковка дерьмо и никакой линкер не умеет ничего и никак удалять.

С выпилом откровенно неиспользуемых функций он справляется вполне успешно.

надо юзать хеадеронли

В смысле, пихать весь код в хедеры? Нафига, если есть LTO?

Запилили ли lto для статических библиотек

Конечно. AFAIK, там всё тривиально запиливается.

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

Но вот что появился, наконец, репозиторий пакетов

Где ты увидел репозиторий и пакеты?

внутренние депенды между отдельными функциями должны быть сведены к минимуму

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

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

Но вот что появился, наконец, репозиторий пакетов

Где ты увидел репозиторий и пакеты?

внутренние депенды между отдельными функциями должны быть сведены к минимуму

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

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

что скачать нужно пять гигов пакетов и заменить в системе вообще чуть менее чем всё

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

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

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

Не разрушай уютный мирок засаленных свитеров, пускай и дальше молятся на священных коров в виде стандарта семидесятых и FHS.

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

Common usecase таков: меня перестаёт устраивать некий ОДИН маленький пакетик, потому что, например, в его старой версии слишком мало функционала

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

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

Роллинг? ССЗБ.

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

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

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

Она не идеальна, но лучше ничего нет. И она работает. В отличие от статической линковки, которая не работает.

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

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

Мне компьютер нужен, чтобы работать, а не играться. Ergo, я совершенно не расположен узнавать про проблемы уже тогда, когда всё случилось. Замена почти всей системы к проблемам приводит практически гарантированно; как следствие, если у меня нет лишнего ненужного дня, чтобы угробить его на пляски с перестановками (а у меня его почти никогда нет), я своему пакетному манагеру ничего подобного сделать не позволю.

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

Она не идеальна, но лучше ничего нет. И она работает. В отличие от статической линковки, которая не работает.

Динамическая сборка как раз не работает, весь имеющийся dependency hell — это не работа, это издевательство. А статическая линковка тупа настолько, что не работать не может, там просто ломаться нечему.

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

Когда ты юзаешь функцию, ты заменяешь ею рукописный кусок кода сходного размера.

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

У авторов glibc, вероятно, проблемы посложней

У них проблемы в ДНК.

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

В нынешней глибсе вызов одной функции из другой — далеко не единственный (и не главный) источник паразитных зависимостей.

А какие там источники?

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

Динамическая линковка потому и динамическая, что позволяет ЛЕГКО МЕНЯТЬ уязвимые библиотеки без перекомпиляции всего дистра

Честно говоря, это заклинание лично мне уже порядком поднадоело. Реальность такова, что этого никогда и нигде не происходит, а обновлять приходится всё и сразу, причём по поводам существенно меньшим, чем уязвимость в безопасности.

Аутотренинг какой-то, ей-богу. «Я самый сильный... я самый сильный... я самый сильный...» Ну бред же.

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

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

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

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

И так далее.

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

Т.е. чтобы получить вменяемый статик - надо юзать хеадеронли + whole-program. Запилили ли lto для статических библиотек - я не знаю - но без него весь этот балаган смысла не имеет.

this

в теории там все пучком

Link-time optimizations do not require the presence of the whole program to operate.  If the program does not require any symbols
to be exported, it is possible to combine -flto and -fwhole-program to allow the interprocedural optimizers to use more aggressive
assumptions which may lead to improved optimization opportunities.  Use of -fwhole-program is not needed when linker plugin is
active (see -fuse-linker-plugin).
но на практике большинство разработчиков тупо забило на систему сборки
и чтоб натравить LTO на их код нужно вычищать захардкоженные флаги, пути к линкеру, и пр. штуки
( http://www.halobates.de/kernel-lto.pdf - попытки сборки ядра с LTO, и список телодвижений )

з.ы. ткчто, грусть-печаль, хоть и есть всякие LTO/PGO/... но они не применимы к реальному миру, нельзя взять и тупо применить на всю (пол) системы
максимум можно «задрочить» какую-то одну приложуху самостоятельно, ито если профит стоит потраченного времени

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

Например, две функции в одном файле, потому что типа родственные.

Я вызываю эту вот другую, но в итоговом бинарнике получаю и их обе

А почему первая не выпиливается -Wl,--gc-sections?

Второй вариант: расширенная функциональность некой функции.

А оно не отключается никакими флагами сборки? А можешь дать примеры?

Третий вариант: подсистемы, требующие инициализации

Например?

А ты не знаешь какую нибудь доку (можно на наглийском), где было бы описано вот это вот всё?

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

Уже обсудили выше.

Я не знаю что ты сам с собой обсуждал.

Всех либ недостаточно. Кому-то повезет, кому-то нет.

Как именно не повезет?

Полюбому дело упирается в системную либу и хидеры ядра.

А что именно меняется если неправильную системную либу с неправильными хидерами ядра прилинковать статически? Ничего не меняется - а значит никакая статическая линковка не поможет.

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

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

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

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

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

Не можешь, если свежий пакет по зависимостям требует свежих библиотек.

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

Ему ничего уметь и не нужно

С какого хрена?

линкер должен быть туп как бревно

Да нет, просто другого не осилилось.

А уметь должен аффффтар библиотеки.

Это каким образом?

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

С какого хрена? Они в отдельном файле просто потому, что так удобно. Ничего за этим не стоит.

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

Ну в мире ламерков - это так. В мире чуть сложнее - за это плюют в рожу.

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

Нет, мистер лс, головной мозг как раз-таки применять тут не надо.

Glibc'шники на это давно забили болт по принципу «чего напрягаться, всё равно у нас динамическая сборка».

Ты нихрена не понимаешь что и почему сделано в глибц - зачем ты кукарекаешь? Причём тут динамическая сборка?

А вот musl'еры изначально ориентировались на статик, и у них всё с этим хорошо.

Хорошо что? Подробнее.

У них вообще всё хорошо, я их maillist читаю, весьма увлекательно.

Ну для лсного адепта с мозгом подобно пакету летящему в ветрах пропаганды.

В целом сборник какой-то неведомой херни. Какие-то файлы, какой-то статик. Ни одного аргумента - какая-то убогая херня. Зачем ты мне это написал?

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

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

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

С выпилом откровенно неиспользуемых функций он справляется вполне успешно.

Нет.

В смысле, пихать весь код в хедеры? Нафига, если есть LTO?

Лто нет. Да и лто кастыль, а пихать не кастыль. Не пихать, чтобы потом запихало лто. Ну отлично.

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

Конечно. AFAIK, там всё тривиально запиливается.

Ну вперёд - я жду хелворда свёрнутого до строки и int80 собранного статик.

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

Имел в виду из родного репозитория.

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

з.ы. ткчто, грусть-печаль, хоть и есть всякие LTO/PGO/... но они не применимы к реальному миру, нельзя взять и тупо применить на всю (пол) системы

максимум можно «задрочить» какую-то одну приложуху самостоятельно, ито если профит стоит потраченного времени Даже этого не выйдет. Нет смысла применять lto на не whole program, если это просто обёртка над тонной либ.

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

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

То что за тебя это дело разруливает сотня мартышек, проблемы не убирает. И беда тут еще в том, что у каждого дистрибутива своя сотня мартышек. Со статической же линковкой проблемы нет.

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

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

Не понял. Любой нормальный линкер линкует только нужные объектные файлы.

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

Ты нихрена не понимаешь что и почему сделано в глибц - зачем ты кукарекаешь? Причём тут динамическая сборка?

1) Не хами. 2) глибц — убогое говно, в котором статическая линковка сломана «by design».

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

Нет.

Доказывать тебе что-то там по сути у меня желания нет, но

никакой линкер не умеет ничего и никак удалять

gcc -O2 -static %f -o hello_no_gc.elf
hello_no_gc.elf                            793 K

gcc -O2 -static -Wl,--gc-sections %f -o hello_gc.elf
hello_gc.elf                               764 K

что-то удалил, так что чисто формально ты всё равно уже неправ.

пихать не кастыль

Пихать не костыль, пихать отстой. Без инкрементальной компиляции в серьёзном проекте - не жизнь.

Да хеадеронли не только пихание, но и подходы к написанию.

Рассказывай свои подходы, или слив.

я жду хелворда свёрнутого до строки

Я тебе не обещал хелвордов. Мой единственный аргумент - описание -flto в мане gcc. Хочешь - опровергай, вскрывай заговор злобных гэсисишников.

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

Не понял. Любой нормальный линкер линкует только нужные объектные файлы.

Ога, а теперь попробуй. Там вон выше пацан попробовал - больше не хочет.

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

2) глибц — убогое говно, в котором статическая линковка сломана «by design».

Это хорошо рассуждать балаболя, но проблема остаётся в том, что аналога так никто и не родил. Убогое? Говно? - сделай хотя-бы так же. Остальные libc дальше поделок первокурсников не ушли. Хотя да - делать сложно, а балаболить просто.

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

Ога, а теперь попробуй. Там вон выше пацан попробовал - больше не хочет.

Что не хочет? Что попробовать? У тебя говно вместо линкера? У всех все работает, поверь.

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

что-то удалил

добавь --print-gc-sections, но подозреваю что что-то из того что чистит strip

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