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)

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

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

Это я хелворд с glibc попробовал. А в эмбедщине оно у меня давно работает как надо. Из моих объектников тоже всё, что надо выпиливается, а почему с глибс так плохо - я ХЗ. Блин, всё равно начал спорить(

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

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

Ниже ты уже показал как доказывать умеешь.

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

Ну да, да. Обделай и сделай вид, что это не так.

Во-первых, по дефолту, да и не по дефолту оно никакой код не удаляет.

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

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

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

Опять же - балабольство. Ты ничего в своей жизни больше пары сотни тысяч строк не видел, а их гцц собирает за от силы секунд 10, шланг за секунд 30(ибо быстрее гцц, ну по поверьям адептов).

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

Компилирует 200к строк гцц/шланг с O0 за 1-2секунду. Т.е. это не много времени экономит. Всё это бенчилось на скулайте, где код максимально компактен и вылизан, имеет компактный кодингстайл и сложен. Т.е. это эквивалентно 400к строк среднестатистического проекта.

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

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

Пошли потуги в попытках слиться на «свои» - для начала ты мне покажешь слово «мои» у меня, а потом расскажешь с чего ты приписал им «мои»?

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

Выше ты уже обделался с линковкой. А т.к. ты и сейчас обделался - о чём ещё с тобою разговаривать? Опять какие-то прятанья за кого-то. Убогая попытаться слиться и свичнуть тему на враньё - т.е. попытаться сделать вид, что я спорил с описание lto и прочее.

Ты сказал есть - докажи. Не доказал - балабол.

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

Это я хелворд с glibc попробовал.

Да на любой не хелворде без заранее добавленных кастылей так не будет.

А в эмбедщине оно у меня давно работает как надо.

Это не так как надо - как надо я выше объяснил.

Из моих объектников тоже всё, что надо выпиливается, а почему с глибс так плохо - я ХЗ.

Попробовал я на musl - там выпиливается, но пять же убого и на кастылях.

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

Что не хочет? Что попробовать?

Выпилить линкером.

У тебя говно вместо линкера?

У тебя не говно - вперёд. хелворд и глибц у тебя есть.

У всех все работает, поверь.

Ога, поверил.

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

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

Ну, то есть про «на практике выходит, что после обновления одной библиотеки приходится все к чертям обновлять, ибо сломалось» ты солгал. ОК.
И с логикой ты тоже не дружишь — раз уж «сотня мартышек разруливает проблему», то проблема именно что разруливается и больше не существует. Если ты такой простой вещи не понимаешь, то ты куда как более тупая макака, чем майнтейнеры, которых ты так красиво обозвал.

Со статической же линковкой проблемы нет.

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

redgremlin ★★★★★
()

Почему я его всё время читаю, как Stalin?

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

Покажи мне систему, полностью статически слинкованую

Эх молодёжь. В Linux не сразу появилась динамическая линковка.

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

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

http://linux.bigresource.com/Ubuntu-Audacious-2-5-Updating-Libraries-Broken-G...

https://www.bricsys.com/common/support/forumthread.jsp?id=25166

http://www.jonathanmoeller.com/screed/?p=1190

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

Во-первых, по дефолту

Кто говорил за дефолт? Да и всем пох на дефолт.

оно никакой код не удаляет

Кто где говорил за код?

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

Это удаление секций, к которым нет обращений в коде.

Компилирует 200к строк гцц/шланг с O0

Ясное дело, большая часть времени уходит на оптимизацию. А O0 никому не нужен.

lto есть такая же сборка всего одним куском

Не такая же. Оптимизация всего кода в пределах модуля уже сделана, к этапу линковки одним куском осталась всякое межмодульное IPO, а это <5% времени сборки.

Пошли потуги в попытках слиться на «свои»

Мне плевать, чьи они - либо ты их выкатываешь, либо балаболка.

Ты сказал есть - докажи.

Ну ок. У меня, правда, только эмбещина под рукой:

ololo.c:
#include <stdio.h>

void Ololo(void)
{
    printf("ololo");
}

main.c:
#include "ololo.h"

int main(void)
{
    Ololo();
}

avr-gcc.exe -mmcu=atmega2561 -Os -flto -c ololo.c
gcc-ar rcs libololo.a      ololo.o
avr-gcc.exe -mmcu=atmega2561 -Os main.c -L./  -l ololo -o main.elf
avr-gcc.exe -mmcu=atmega2561 -Os main.c -L./ -flto -l ololo -o main_lto.elf
avr-objdump.exe -h -S "main.elf" > "main.lss"
avr-objdump.exe -h -S "main_lto.elf" > "main_lto.lss"

// Не заинлайнилось
main.lss:
...
00000124 <main>:
 124:	0e 94 89 00 	call	0x112	; 0x112 <Ololo>
 128:	08 95       	ret
...

// Заинлайнилось
main_lto.lss:
...
00000112 <main>:
 112:	80 e0       	ldi	r24, 0x00	; 0
 114:	92 e0       	ldi	r25, 0x02	; 2
 116:	9f 93       	push	r25
 118:	8f 93       	push	r24
 11a:	0e 94 92 00 	call	0x124	; 0x124 <printf>
 11e:	0f 90       	pop	r0
 120:	0f 90       	pop	r0
 122:	08 95       	ret
...

ЧДТ.

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

Да на любой не хелворде без заранее добавленных кастылей так не будет.

Вот только костыли добавлены даже в glibc, на статическую линковку которой вообще всем положить.

как надо я выше объяснил.

Ты не объяснил, а попытался слиться на какие-то костыли и дефолты.

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

http://linux.bigresource.com/Ubuntu-Audacious-2-5-Updating-Libraries-Broken-G...

I was trying to install Audacious 2.5 which required new libraries:gdk-pixbuf-2.22.1
glib-2.28.6
gtk+-2.24.4
libmowgli-60e2589fc14e
pango-1.28.4

I performed the following commands to build them:
Code:
./configure
make
sudo make install

И какое отношение этот самосбор имеет к?

https://www.bricsys.com/common/support/forumthread.jsp?id=25166

Этот BRICSCAD есть в репозиториях Убунты? Как ты собираешься при любом виде линковки гарантировать работоспособность левой проприетарщины? Тут 100% косяк проприетарщиков.

http://www.jonathanmoeller.com/screed/?p=1190

При чём здесь обновление? Handbrake'а в тот момент не было в репозиториях убунты и его разработчики не выпустили совместимой версии.

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

И какое отношение этот самосбор имеет к?

По-другому на дистрибутив с динамической линковкой Audacious 2.5 не ставился. Или «эта программа вам не надо — её нет в дистрибутиве»?

Как ты собираешься при любом виде линковки гарантировать работоспособность левой проприетарщины? Тут 100% косяк проприетарщиков.

При статической линковке libssl, от которого зависит программа внезапно не ломается.

Handbrake'а в тот момент не было в репозиториях убунты и его разработчики не выпустили совместимой версии.

Потому что в репозиториях убунты была неправильная версия libgtk. Опять «эта программа вам не надо»?

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

Покажи мне систему, полностью статически слинкованую, и покажи, как там исправляются уязвимости

http://sabotage.tech/

butch update

False. Либо система не полностью статическая, либо указанная команда не исправляет все уязвимости — судя по сорцам, она не пересобирает пакет, если его хэш не изменился, т.е. при обновлении зависимости она обновится, но сам пакет не пересоберётся с новой версией, пока сам не обновится и всё это время будет уязвим.

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

она не пересобирает пакет, если его хэш не изменился, т.е. при обновлении зависимости она обновится, но сам пакет не пересоберётся с новой версией

Возможно я невнимательно читал. Мне показалось, что все зависимые пакеты также пересобираются. Даже если такой возможности нет, то написать её несложно.

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

Ну, то есть про «на практике выходит, что после обновления одной библиотеки приходится все к чертям обновлять, ибо сломалось» ты солгал. ОК.

Нет, не солгал. У меня генту и у меня есть эта проболема. На арче была та же проблема.

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

У тебя не говно - вперёд. хелворд и глибц у тебя есть.

пф... Ну поехали:

$ cat a.c
 int f(int x){
	return 2*x;
 }

$ cat b.c
 int g(int x){
	return x+666;
 }

$ gcc -c a.c

$ gcc -c b.c

$ ar rcs lib.a a.o b.o

Теперь:

$ cat test1.c 
 #include <stdio.h>
 int f(int x);
 int g(int x);
 int main(){
 	printf("%d\n", f(2));
 }

$ gcc  test1.c lib.a -o test1
 
$ nm test1 | grep " [fg]"
 0000000000400575 T f
 0000000000400583 T g
Против...
$ cat test2.c 
 #include <stdio.h>
 int f(int x);
 int g(int x);
 int main(){
	printf("%d\n", f(2));
 }

$ gcc  test2.c lib.a -o test2

$ nm test2 | grep " [fg]"
000000000040056e T f

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

По-другому на дистрибутив с динамической линковкой Audacious 2.5 не ставился

Ложь. man backports

При статической линковке libssl, от которого зависит программа внезапно не ломается.

Но остаётся уязвимой, глючной, опасной для системы и пользовательских данных и т.д. И ей ничто не помешает сломаться при обновлении вызываемой внешней утилиты или даже библиотеки (библиотека тоже может использовать IPC или некую внешнюю БД, которые при обновлении могут поменяться, что для динамической линковки совершенно не проблема, но смертельно для статической).

Потому что в репозиториях убунты была неправильная версия libgtk

С тем же правом можно сказать, что разработчики использовали неправильную версию. Если программа есть в репозитории — за её работоспособность отвечают майнтейнеры, если нет — то разработчики.

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

Ложь. man backports

В котором есть далеко не всё. http://www.opennet.ru/openforum/vsluhforumID9/3999.html

http://www.softimage.ru/forums/index.php?showtopic=2939

Но остаётся уязвимой, глючной, опасной для системы и пользовательских данных и т.д.

С учётом того, что libssl в этой программе используется только для проверки лицензии, то чем даже уязвимая версия опасна для системы?

библиотека тоже может использовать IPC или некую внешнюю БД, которые при обновлении могут поменяться

Мы всё ещё про libssl? А если программа использует библиотеку доступа к БД для хранения своих данных, то внезапный (для программы) её апгрейд также скорее зло. Например, sqlite может вообще поломаться (http://www.prog.org.ru/index.php?topic=18380.0)

С тем же правом можно сказать, что разработчики использовали неправильную версию.

Какая разница? В конкретной версии дистрибутива программа перестала существовать. В backports тоже нету. Варианты — обновлять целиком дистрибутив или компилировать программу вручную. Вручную, ты сам пишешь, что нельзя (пример про Audacious).

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

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

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

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

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

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

Расскажи о своем опыте решения проблемы «установить новую программу в старый дистр» на Stali.

Если новая программа собирается статически, то просто копированием.

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

Расскажи о своем опыте решения проблемы «установить новую программу в старый дистр» на Stali.

Если новая программа собирается статически, то просто копированием.

Я спрашивал о твоем опыте, а ты рассказываешь о своих представлениях.

tailgunner ★★★★★
()

Всем, кто интересовался сравнением статики/динамики и musl/glibc.

Sabotage linux (static, musl):
root:/src/tarballs$ time sh test.sh > /dev/null
real    3m 58.21s
user    4m 9.90s
sys     0m 2.70s
root:/src/tarballs$ time sh test.sh > /dev/null
real    3m 59.49s
user    4m 10.55s
sys     0m 3.02s

Debian Linux:
serverlinux:/home/sabotage/tarballs# time sh test.sh > /dev/null

real    3m55.062s
user    4m11.912s
sys     0m3.176s
serverlinux:/home/sabotage/tarballs# time sh test.sh > /dev/null

real    3m51.978s
user    4m10.300s
sys     0m2.108s

# cat test.sh
bunzip2 -d < gcc-5.3.0.tar.bz2 | bzip2 -9c

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

Я спрашивал о твоем опыте, а ты рассказываешь о своих представлениях.

Stali без году неделя, какой тут опыт.

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

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

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

как это применяется: можно посмотреть на Rio, Brazil, 8.5 или какой-нибудь acme с виртуальными «логическими» путями, или на скриптоту на rc из пары строчек.

современные понятия: микросервисы, REST-like API (проекция в HTTP протокол 4 действий из файлового протокола open/close/rm/mv и т.п.)

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

в Inferno в Limbo появилась динамическая загрузка модулей.

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

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

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

если эти логические псевдофайлы-объекты в свою очередь, результат файлового сервера-мультиплексора ресурсов (например, как в Rio/Brazil/8.5 у каждого процесса /dev/window -> свой разный симлинк на конкретный /dev/window/1234567, /dev/console -> на свой отдельный терминал и т.п.) => получаем ОС как мультиплексор физических ресурсов в логические, и приложения, работающие с идеально правильными, lock-free логическими ресурсами (ибо это просто отдельный view).

у приложений шизофрения: у разных процессов эти view разные, потому что разные отображения пространств имён, установленные bind (ср. в линуксе mount -o bind ...).

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

симлинков не существует, есть настраиваемые отображения.

развесистого ioctl не существует, есть командные псевдофайлы.

ООП не существует, есть объекты файлы, файлы, файлы... ничего кроме файлов.

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

у линаксов шизофрения только для отдельных LD_PRELOAD

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

Ага, прям все man pages прочитать надо перед тем как работать за компом...

вслух и с выражением

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

В котором есть далеко не всё

Backports это не только репозиторий, но и процесс. Кто мешал этому кадру попытаться сделать правильно — сборкой пакетов по правилам своего дистрибутива?

С учётом того, что libssl в этой программе используется только для проверки лицензии

Во-первых, не факт, что только. Во-вторых, там уже речь не о конкретной библиотеке, а про вопрос статика/динамика.

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

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

А если ты хочешь на дистрибутив пятилетней давности что-то поставить

То, с вероятностью в 99.99999999999999999999%, с тобой что-то не так.

Поэтому обязан жрать что дают (systemd, pulseaudio, ...), всё равно никуда не денешься.

LOL :D Примеры офигенны в своей примерности, я бы лучше против статичной линковки не придумал бы. Ну вот есть у тебя офигенный весь из себя статический линукс пятилетней давности, и хочешь ты поставить на него всю из себя статичную новую прогу. И обламываешься, потому что она требует systemd и pulseaudio, которые суть демоны и класть хотели на твою статичность. Where is your God now?

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

в каких-нибудь других системах с тотальной статической линковкой

Ну вот сейчас в Sabotage собрал часть с musl, который в stage0, часть — с обновлённым из пакета. Всё работает и не глючит при перезапуске.

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

Не уверен, что это ответ на вопрос, который я задал. Скорее даже уверен в обратном.

Почему? Это полная аналогия ситуации http://www.opennet.ru/openforum/vsluhforumID9/3999.html

Часть программ хочет новую библиотеку, часть заведомо правильно работает на старой (и неизвестно как на новой). В Sabotage я просто ставлю новую библиотеку и компилирую те программы, которым она нужна. Был бы бинарный репозиторий, мог бы просто бинарники скопировать. Компоненты системы друг от друга зависят значительно меньше.

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

Не уверен, что это ответ на вопрос, который я задал. Скорее даже уверен в обратном.

Почему?

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

В Sabotage я просто ставлю новую библиотеку и компилирую те программы, которым она нужна.

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

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

Кто мешал этому кадру попытаться сделать правильно — сборкой пакетов по правилам своего дистрибутива?

Бывает и так:

я хочу поставить samba 3 на ASPLinux 7.3 а она  
требует glibc 2.3 и выше, у меня есть  
glibc-2.3.2-27.9.1asp.i386.rpm из ASPLinux 9.0 
хочу обновить коммандой rpm -U glibc-2.3.2-27.9.1asp.i386.rpm , 
не чего не выходит выводит
glibc-common = 2.3.2-27.9.1asp нужен для glibc-2.3.2-27.9.1asp
        glibc > 2.2.5 конфликтует с glibc-common-2.2.5-37asp
        glibc = 2.2.5 нужен для glibc-devel-2.2.5-37asp
Я обновляю glibc-common беру его из ASPLinux 9.0 а он мне выводит

glibc < 2.3.2 конфликтует с glibc-common-2.3.2-27.9.1asp
        glibc-common = 2.2.5-37asp нужен для glibc-2.2.5-37asp
Удалить страй glibc , для установки нового не могу там только зависимостей.
Как мне обновить glibc??? 

И что ему предложишь сделать в его дистрибутиве (Samba 3 использует то, что появилось в glibc 2.3)?

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

И что ему предложишь сделать в его дистрибутиве (Samba 3 использует то, что появилось в glibc 2.3)?

Пересобрать пакет Samba, естественно.

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

программа компилируется ровно по разу на обновление программы, а при обновлениях библиотек не перекомпилируется

Почему же тогда вот этот cmake-3.0.2 требует glibc 2.7, а вот этот — как минимум glibc 2.15? Если остальные дистрибутивы посмотреть, то комбинации требований будут всевозможные.

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

хочешь ты поставить на него всю из себя статичную новую прогу. И обламываешься, потому что она требует systemd и pulseaudio, которые суть демоны и класть хотели на твою статичность. Where is your God now?

Если прога нормальная, то она не будет намертво завязываться на работу на нескольких дистрибутивах линукса (systemd ни в MacOS ни в FreeBSD не встраивают, да и pulseaudio тоже).

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

Пересобрать пакет Samba, естественно.

Он при компиляции требует Glibc >= 2.3. Что дальше?

Но он не требует. Пакеты Samba3 для RedHat 7.3 были.

Или настоящий вопрос звучит как «а вот если бы Samba 3 кровь из носу нужна была бы glibc 2.3, а на старых оно бы не работало совсем вообще»?

Почему же тогда вот этот cmake-3.0.2 требует glibc 2.7, а вот этот — как минимум glibc 2.15?

Потому что в пакет автоматом прописались зависимости со сборочной системы // К.О.

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

без перекомпиляции всего дистра.

А в чём проблема перекомпилировать весь дистр?

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

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

Расскажи это тем инвалидам, которые тут уже 10 страниц ноют на тему «обожемой, это же с обновлением libblah нужно переустановить всё, что её использует».

ugoday ★★★★★
()

К сожалению проблема с подобными дистрами, это то, что они так никогда и не выйдут за рамки proof-of-concept. Пользовательская база слишком мала, а значит количество пакетов и актуальность версий софта будет никакая. Захочешь что поставить (адекватно свежее), придется вкорячивать это ручками и собирать. Это интересно первые пару месяцев, ну или лет (если ты красноглазый гентушник). Но вскоре захочется просто сказать:

aptitude install soft

И тут же получить желаемое стабильного на текущий момент релиза.

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

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

Это интересно первые пару месяцев, ну или лет (если ты красноглазый гентушник).

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

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

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