Ответ Линуса на пост о мертвейшем линуксе и срач отцов-основателей.

программы от GCC 4.7 несовместимы с GCC 4.5, и желательно всё коммерческое компилировать с GCC 4.1

clang вроде бы решает проблему - сохраняет совместимость с GCC 4.2. Подробностей не знаю.

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

Мне интересно, все описанные тут доводы, в бросили в дискуссию гуру или нет? =))

Что за подростковость - какое-либо отклонение от своих интересов или умений громко называть плохим?

Прочитал статью Мигеля. Полностью с ним согласен.

неуспешный тролль

Гуру в гуглплюсе, тут мы - бравая пионерия

Что за подростковость - считать всех, у кого отличается мнение, троллем, провокатором или врагом народа?

http://ompldr.org/vZmNkbg

Да нет, не RPM, а компилировать программы с минимальным количеством зависимостей. Вот например я покупаю игру Gish и делаю ldd. Зависимостей мало! Компилирую её из открытого исходного кода - и зависимостей много. Как так?!

А просто когда программа открытая, проблемы не существует. Открытое ПО берётся мейнейнерами дистрибутива, и в тот день, когда они решили выпустить новую версию, берётся новый компилятор, последние версии системных библиотек, и прикладное ПО компилируется с ними, намертво привязываясь к 50 библиотекам точно такой, а не предыдущей/следующей, версии. Поэтому для открытого ПО проблемы не существует, на то оно и открытое.

С закрытым ПО стоит поизвращаться. То libboost и libdb прикрепить к программе статически, а остальное - динамически. Но это опасно уязвимостями в библиотеках, которые в последующих минорных версиях закроют, а в программе они останутся навсегда. То с компилятором GCC 4.1 компилировать вместо 4.7, то с Qt 4.3 вместо 4.9. Или класть с программой libgcc и libstdc++, потому что в GCC 4.7 появилась поддержка новых функций или процессорных инструкций, без которых никак. Или положить все библиотеки в каталог lib32 и lib64, и сделать скрипт запуска вроде:

# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"

if [ ! -e properties ] || [ ! -e res ]
then
	echo "Missing properties/ and res/ directories in `pwd`"
	echo "Your installation is incomplete!"
	exit 1
fi

MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
	LIBS=./libs64
	BIN=./WorldOfGoo.bin64
else
	LIBS=./libs32
	BIN=./WorldOfGoo.bin32
fi

# Run the game:
export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@

То делать зависимости не жёсткими, а опциональными, используя библиотеки через dlOpen. Программа с небольшим количеством зависимостей, каждая из которых прописана в стандарте LSB 4, а остальные библиотеки лежат в архиве с программой, и на них указывает скрипт запуска - идеальна. Плюс ещё скомпилировать не в GCC 4.8 из GIT, а в GCC 4.1, и положить значок и ярлык запуска в /usr/share - и вряд ли найдётся такой Linux, соотвествующий стандарту LSB, в котором программа не запустится.

Ну вот например Java от Oracle запустится одинаково хорошо и в системе 2005 года, и в системе 2012 года. Можно играть в Minecraft! Adobe Flash, обновившись с 10 до 11 версии, не выдаст:

/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

А вот Skype 4 теперь требует GCC 4.5, а не 4.3, как Skype 2.1. Зато не привязан намертво к PulseAudio в системе, он использует его только если он есть. dlOpen к libpulse.

Нашёл чем гордиться.

Проблема, о которой говорит Мигель, заключается в том, что многие не соблюдают эти правила, и даже в Humble Bundle многие игры не запускаются, ругаясь на переименовавшиеся или отсутствующие библиотеки. Будет Linux популярнее, будут на слуху эти правила. А пока - запускать свежескачанную программу из консоли и подставлять к ей недостающие библиотеки: libavformat.so.50 (Вагнеры для Linux), libopenal.so.1 (ioquake 1.34 и старше), GCC 4.4 (библиотеки Qt в архиве с игрой Oil Rush). А если код открыт, но на сайте есть готовые бинарники для Linux - пересобирать самостоятельно (TeeWorlds, FileZilla).

Кстати, а на чём он сейчас?

угу, велосипедист со своей агилие-ксилитрой намного умнее

Не в курсе. Тоже любопытно, откуда ждать следующего взрыва :}

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

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

Ненавижу: systemd, policykit, consolekit, и прочую шлабудень.

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

Я посоветую товарищу (врач, между прочим) скомпилировать драйвер самостоятельно. Может, у него получится, да.

сейчас наверное твой оппонент будет кричать «УМВР, чините руки, неосиляторы»

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

плюсую, очень раздражает.

Ещё бы закончился этот срач как с git в своё время.

шоубизнес, что ты хочешь :)

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

т.е. как?

хорошо написал

Я посоветую товарищу (врач, между прочим) скомпилировать драйвер самостоятельно. Может, у него получится, да.

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

И еще раз Мигель прав - пора взять один дистр и сделать его эталоном.

Федора же, ну.

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

Каким чудом дистрибутив, в котором не обновляется софт на новые версии, должен поддерживать видеокарту, которая поступила в продажу после его выхода?

Топикстартер на гуглоплюсе закрыл комментарии, и послал всех на reddit/slashdot/etc, сцука.

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

Взять за нежные филейки всех троих РХ, Канонил и Зузе и заставить их сделать нечто, что станет базисом. А лучше сразу обанкротить святую троицу с последующей передачей всей ИС одному холдеру. На На останках трьох создать ОДНОГО монстрика, который толсто вылезет на рынок и скажет - Я ЛИНУПС ДЛЯ ПК.

Если честно, беглым поиском не нашёл ничего добротного на эту тему. Если в 2х словах: rpm позволяет делать файловые зависимости. В spec`ках рпм есть Requires и Provide. Ну и макросы.

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

т.е. как?

т.е. Линус и компания взяли, и написали ту систему контроля версий, которая была им нужна.

Посмеялся с макфагов — «увидел макось и забросил линукс». Типа аргумент. Я макось более двух лет на работе вижу- использую и что то до сих пор не потянуло перейти. Идеальных систем не бывает. Для меня в линуксе геммороя меньше чем в макосятине и вантузе.

Каким чудом дистрибутив, в котором не обновляется софт на новые версии, должен поддерживать видеокарту, которая поступила в продажу после его выхода?

Ответ на этот вопрос будет таким же, как и на вопрос, как это делала Windows XP, например. Выпущена давно, а новое железо работает. Как так? А вот так же точно и должно быть: путем установки нового драйвера из дистрибутива, а не обновлением всей системы (графической в данном конкретном случае) или ядра. Так, по моему мнению, должно быть.

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

В квотезы

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

как это делала Windows XP, например. Выпущена давно, а новое железо работает. Как так?

Привет из альтернативной реальности. Мне уже не раз приходилось вталкивать хомячкам, что шиндовсхр на ихнее железо не поставится, ибо нет дров. Также есть куча историй успеха, когда под новые ОС нет драйверов для старого железа. А тащить over 15 Гб старых библиотек, как это делает шиндовс7, это путь в никуда.

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

Это далеко не илитарно и не тянет на «продвинутого пользователя».

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

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

Для таких случаев в убунточках есть всяческие ppa.

ppa - это быдлопомойка с пакетов, которые собирают в основном школьники ради понтов.

Не надо несмешной тупняк в квотезы, а то опять JB придётся просить стереть из неподтверждённых.

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

Есть же вроде ппашки, которые поддерживают мейнтейнеры официального дерева.

В spec`ках рпм есть Requires и Provide

КО спешит намекнуть, что в control file дебиан-пакета они тоже есть.

Выйди на площадь возле храма

это где? Возле какого храма? На какую площадь?

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

с ненависти на врагов, с врагов на линуксоидов) Какой ты опытный скакун ;)

никто не заставляет тебя их использовать

и не использую. Теперь что, нельзя их ненавидеть чтоли?

более того, их авторы (как и разработчики твоего дистрибутива) ничем тебе не обязаны.

не повод не ненавидить. ;)

файловые зависимости и ущербность dpkg сцена 100501я ?

Привет из альтернативной реальности. Мне уже не раз приходилось вталкивать хомячкам, что шиндовсхр на ихнее железо не поставится, ибо нет дров.

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

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

Ну, во-первых, пинать никого не получится. Тебя просто пошлют обновлять дистрибутив. Никого не парит. Очень много разработчкиов есть, которые полагаются на самые свежие библиотеки, тем самым отсекая пользователей стабильных дистрибутивов. Даже собрать нельзя. Во-вторых, это совершенно перпендикулярно обсуждаемому вопросу. Пользователю вообще пофиг, собирается ли что-то или нет. Ну, это если мы вообще думаем о пользователе. Можно же проводить такую линию, что тут мы особо пользователей и не ждем, а ориентируем систему на людей, которые умеют решать проблемы вплоть до самостоятельного патчения.

файловые зависимости

Сделай себе плакат «В RPM есть файловые зависимости, а в dpkgнет» и приноси мне на подпись. Я подпишу.

Ты смешиваешь разные вещи. Если каких-то драйверов нет под XP, то это только по причине, что поддержка этой ОС закончилась.

Закончится в 2014 году. «По причине» тут некто распинался выше об обратном.

Если бы до сих пор поддерживалась, то были бы буквально все драйвера. И XP сопровождалась очень много лет.

Не надо писать бредовые «вот если бы», все и так понятно. Шиндовс7 тащит тонны старых библиотек, но далеко не все старые драйверы в ней работают.

Пользователю вообще пофиг, собирается ли что-то или нет.

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

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

Это совершенно естественно, иначе получится регрессия. Дистроклепатели интырпрайза с 5-10 летней поддержкой должны бэкпортировать некоторый софт и латать дыры в безопастности, без этого никак.

неуспешный тролль

Не. Просто толстый. На любителя. :)

Если бы до сих пор поддерживалась, то были бы буквально все драйвера. И XP сопровождалась очень много лет.

И проблемы с драйверами под нее были всё те же много лет, ага.

Не со всеми и не всегда, но были и регулярно. Очень часто все от железа зависело.

И проблемы с драйверами под нее были всё те же много лет, ага.

Ну что же это такое! А у вас в Америке негров линчуют. Это же нерелевантно, что какие-то проблемы у драйверами были. Здесь обсуждается то, что для решения этих проблем не надо было обновлять винды, а надо было обновить драйвер. Если и были проблемы, то их исправляли. Для производителей эти драйвера были приоритетом. А если драйвер не работает в Linux, то что ты можешь сделать? Ты также будешь ждать, когда заработает. Производителю пофиг на Linux, жди, пока кто-то захочет написать.

Вот можешь написать комментарий по поводу того, что тебе больше было бы по душе: обновлять просто драйвер или же ядро, X и даже, если очень захочется, дистрибутив. Об этом и говорим. Как пример был приведен Windows. Не нравится Windows (как красная тряпка действует), тогда давайте возьмем менее популярный пример - Solaris. Там вроде стабильный драйверный API/ABI.

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

Справедливости ради, обычно можно обновить только ядро. Навыки компиляции, конечно, required.

Не нравится Windows (как красная тряпка действует), тогда давайте возьмем менее популярный пример - Solaris. Там вроде стабильный драйверный API/ABI.

В BSD тоже, и BSD тоже красная тряпка :)