LINUX.ORG.RU

Переворот в проекте FFmpeg

 


0

1

Группа разработчиков проекта FFmpeg заявила о том, что у проекта будет новая команда мейнтейнеров. Для нынешнего мейнтейнера проекта (Michael Niedermayer) такая новость стала полной неожиданностью. Несогласная с нынешней ситуаций в проекте основная группа разработчиков перекрыла доступ всем к основному репозиторию исходных кодов, без предварительного обсуждения проблем с текущем мейнтейнером и другими участниками проекта.

>>> Подробности

★★★★★

Проверено: JB ()
Ответ на: комментарий от grusha

>Ну и с чего ох**вать-то? Ты можешь предложить что-то лучше?

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

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

> http://sta.li/faq

Ну и как, приятно работать в ksh? :)

Согласен, если выкинуть всё редко нужное, оверхед будет невелик. Но из-за таких малозаметных удобств предпочитают раздутые решения вроде bash, glibc и GTK :)

От статической линковки чего-либо сложного с GTK, оверхед 20 мегабайт — не предел.

http://dl.suckless.org/stali/clt2010/stali.html

Человек не осилил ./configure и не знает, что на нём свет клином не сошёлся :)

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

> перестать дрочить на шареные либы и научиться пользоваться ключиком -static

Ты готов к увеличению размера всех программ раза в 2? Если не веришь, можешь полазить по сорсфорджу посравнивать размеры динамически и статически собранных пакетов. Увеличится и размер на диске, и потребление RAM.

Если готов, приступай. Поставь LFS. Или Gentoo, прописав -static в /etc/make.conf. О результатах отпишись. Много народу будут тебе благодарны.

А если все библиотеки включать в дерево исходников конечной программы

То получится старый RPM, за который уволили Джеффа Джонсона :) И разработчику программы приходится заодно следить за всеми объявлениями безопасности всех требуемых библиотек, затем всех библиотек, которые требуют они... А ещё можно не мелочиться и ядро прихватить! Создать свой узкоспециализированный статический дистрибутив :)

question4 ★★★★★
()
Ответ на: Слава Мейнтейнерам и Репозиториям! от neurosurgeon

> 1. скачать сорцы 2. распаковать 3. ./configure 4. make 5. sudo make install

До сих пор вычищаю мусор, оставленный мегафоновским драйвером. Функция деинсталляции — главное достоинство пакетных менеджеров :)

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

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

Какое варварство :) Цивилизованные люди записывают в чужой комп педофильские фотографии и стучат в полицию.

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

> Каждая новая версия заканчивается правкой прокладки для ffmpeg к питону

Правкой? Или пересборкой бинарника?

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

> «мейнтейнер» — это жаргонное слово, обозначающее «поставщик» (а уж поставщик .deb-.rpm-пакетиков... или поставщик Кода или Наркотиков — это уже надо из контекста узнавать)

И давно торговец наркотой стал drug maintainer-ом?

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

> Это называется «ABI-совместимость». Понятно, что не 100%, иначе сидели бы с багами 15-летней давности :)

Проигрывание и масштабирование метафайлов, ЕМНИП, за 20 лет так и не починили :)

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

> - вместо репозиториев пакетов - сервера метаданных, где хранится лишь информация о пакетах (зависимости и т.д., а также URL, откуда его скачать)

Gentoo Portage :) В идеальном мире, где пользователи autoconf, cmake и прочих читают документацию на то, чем пользуются :(

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

>В идеальном мире, где пользователи autoconf, cmake и прочих читают документацию на то, чем пользуются

Если бы все было так просто... Гораздо чаще грабли прячутся в несовместимости API разных версий библиотек

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

> Гораздо чаще грабли прячутся в несовместимости API разных версий библиотек

Тогда такая несовместимая пара объявляется неподдерживаемой :)

Чаще несовместимы только бинарные сборки, и проблема решается перекомпиляцией.

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

Пионер всегда готов собирать металлолом

> Ты готов к увеличению размера всех программ раза в 2?

Сделал du -s /usr, мысленно умножил на два. Готов. Даже если в десять раз. Если при этом можно будет не думать о совместимости дистров при установке пакетов: увидел - скачал - поставил. Дисковое пространство нынче дешевле грязи, а жизнь коротка, во всяком случае, у меня есть более интересные занятия, нежели бесконечный, бессмысленный и беспощадный distupgrade (без которого, невзирая на героические усилия армии майнтейнеров, новые версии пакетов всё равно только из сырцов поставить можно).

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

Что до расхода оперативки, то там перерасход будет процентов двадцать, вообще говорить не о чем. Да даже если и тоже вдвое — я сейчас живу на 512 Mb, ну оторву пятую точку от стула и пойду памяти докуплю. Потрачу полчаса. Хотя что-то мне подсказывает, что до этого не дойдёт.

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

>В целом: динамическая линковка бесполезна с вменяемыми либами

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

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

>Тогда такая несовместимая пара объявляется неподдерживаемой :)

Я участвую в опенсорс-проекте, в котором используется SIP. У этой штуки есть весрии API, сильно не совпадающие с «официальной» версией релиза. В результате бывает, что при увеличении минорной версии SIP у мэйнтейнеров федоры (они раньше всех обновляют) ломается компиляция

Думаю, случай не единственный, ибо широко известными такие вещи становятся только для «мэйнстримных» библиотек

Чаще несовместимы только бинарные сборки, и проблема решается перекомпиляцией.

Тоже неприятная штука

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

>А нет, сказано - если линковать с glibc, то выходит больше. Спасибо Капитану, без него кто бы узнал, что библиотека для встраиваемых систем весит меньше.

Да и вообще, glibc (любой версии) - это огромная куча говнокода, способного компилироваться только определенным диапазоном версий GCC

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

>А если все библиотеки включать в дерево исходников конечной программы, то можно избавиться и от build depend'ов.

Мэйнтейнеры Федоры смотрят на тебя как на

annulen ★★★★★
()

Революции ненужны. Ибо слишком много хаоса вносят.

Sergey_T ★★★★★
()
Ответ на: Пионер всегда готов собирать металлолом от Croco

> Готов.

собирать, я не готов

Тогда попробуй убедить авторов часто нужных тебе программ выкладывать статические сборки :)

Что до расхода оперативки, то там перерасход будет процентов двадцать, вообще говорить не о чем.

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

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

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

>До сих пор вычищаю мусор, оставленный мегафоновским драйвером.

Есть же checkinstall. А также возможность запакетить.

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

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

Ты afaik обновиться не сможешь. Если попросишь у репы пакет версии 2.0, а там уже 2.1. Т.е. поломается само обновление.

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

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


До этого верхнего предела, если от реальности плясать, будет, на выбор, как до Луны пешком или как до Китая раком. Из Великой и Ужасной Библиотеки в большинстве случаев берётся десяток функций, суммарный объём которых не составляет и сотой доли общего объёма библиотеки. А шареная либа хоть и декларируется, что не вся пойдёт в память (ибо mmap и всё такое), реально-то в память, во-первых, каждая страничка или идёт, или не идёт, и во-вторых, по закону подлости каждая из нужных функций окажется в своей страничке. А в третьих, шареная либа - это не только функции, это ещё и обвеска, причём как на стороне самой либы, так и на стороне вызывающей программы.

А теперь позвольте фокус. Знаете такую программу true? Ну, которая

int main() { return 0; }

Это она вся, инклудников не требует. Так вот:

crocodil@frock:~$ strace -o XXX true
crocodil@frock:~$ wc -l XXX
104 XXX

(барабанная дробь) СТО ЧЕТЫРЕ СИСТЕМНЫХ ВЫЗОВА!!! bingo! Кто не понял - это она сначала грузит и настраивает либсю. А либся не может жить без того, чтобы не отрюхать для начала, какая у нас там сегодня локаль. Ну вот не может она без этого.

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

> А теперь позвольте фокус. Знаете такую программу true? Ну, которая

...давно уже встроена в shell

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

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

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

> ...давно уже встроена в shell

А что, это обстоятельство как-то что-то меняет в отношении обсуждаемого предмета?

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

> А что, это обстоятельство как-то что-то меняет в отношении обсуждаемого предмета?

Это как бы намекает на то, что нужно выбрать другой пример.

А вопрос о том, как будут «рюхать локаль» статически слинкованные приложения, остался без ответа.

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

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

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

> Есть же checkinstall. А также возможность запакетить.

Но ни Мегавон, ни neurosurgeon этим не озаботились :) Об этом и был пост.

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

вот и внедряй после этого опенсорс-компоненты в бизнес. у вас что-то не работает и бизнес стоит? нам по**й, мы тут делим репозиторий.

долго смеялсо. бизнесмен ты наш!

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

> Это как бы намекает на то, что нужно выбрать другой пример.

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

А вопрос о том, как будут «рюхать локаль» статически слинкованные приложения, остался без ответа.

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

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

>int main() { return 0; }

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

Ты правда не понимаешь почему так происходит, или толсто вбрасываешь?

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

> Ты правда не понимаешь почему так происходит, или толсто вбрасываешь?

Я, разумеется, понимаю, почему так происходит, но, видимо, моё понимание от твоего отличается, ибо следствием моего понимания является классическое утверждение о том, что только массовые расстрелы спасут цивилизацию. А ты, судя по твоей реплике, с текущим положением вещей (glibc, autotools, dependency hell) согласен.

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