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

Может нам Валянского так же выпилить?

> Да, и много еще чего.

и тем не менее твои идеи выглядят как-то наивно

ладно, где можно почитать твое творение?

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

>Слово «стандартизация» тебе о чем-нибудь говорит?

Говорит. Но ты не можешь стандартизировать всё. POSIX - лишь маленькая часть тех API, которые можно использовать, его, вроде бы, не дураки разрабатывали. И всё равно в нём есть противоречия и многого там попросту нет.

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

Это непросто :)

--

Нет, твои цели мне очень даже нравятся. Нет раздутым пакетам, заставить всех разработчиков чётко документировать интерфейсы, разработчики ценят простоту, никто больше не пихает 100+Кб autotools'ов в каждый пакет, а использует системный.

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

K-Lite Mega Codec Pack наше все.

> Что делать, если в этом обновлении (скажем 1.0.11) интерфейс поменялся так, что нарушилась совместимость с 1.0.8? Его мейнтейнер (разработчик) обязан указать Breaks: hooker (1.0.8). Серверная часть пакетного менеджера при регистрации пакета уведомляет по почте мейнтейнеров (разработчиков) всех пакетов, в зависимостях которых есть неограниченный диапазон версий, включающий 1.0.11. Мейнтейнер получает мейл...

Стоп, вы жа сами говорили, что в вашей системе майнтейнеры не нужны.

узнает, что интерфейс теперь ведет себя по другому, и смотрит, не ломает ли это изменение поведение его пакета. Если ломает, то он меняет в зависимостях hooker (>= 1.0.5) на hooker (>= 1.0.5, <= 1.0.10), и перерегистрирует свой пакет.

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

И еще, будет ли ваша система жизнеспособна без сети? Ну, то есть, возможно ли распространиение софта в вашей системе через CD/Flash?

Как будто это не ffmpeg.

>То есть, изменения, по сути, вносятся в уже выпущенный пакет задним числом.

Ну, Breaks, вообще говоря, работают отлично - он описал в точности то, что делается в Debian в таких случаях. Сопровождающими, да. А изменения в уже выпущенный пакет не нужны.

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

OpenOffice будет загружаться полчаса.

> При чём тут POSIX?

При том, что это стандарт _окружения_.

Что такое интероперабельность исходного кода?

Интероперабельность софта, распространяемого в исходном коде.

Как она «обеспечивается», почему этот подход «лучше и красивее»?

Потому что на порядок меньше интерфейсов, которым должен подчиняться пакет (для бинарных пакетов это + архитектура процессора, формат бинарника, ...).

Что значит «пакеты компактны и их удобно собирать»?

Пакеты небольшие и быстро собираются, например.

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

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

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

> ладно, где можно почитать твое творение?

Не хочу это никому показывать. 100 страниц, сделанных из 20. Нормальной реализации нет (забросил по причине бесперспективности). Идеи я изложил.

> Стоп, вы жа сами говорили, что в вашей системе майнтейнеры не нужны.

Разработчики и есть мейнтейнеры.

> узнает, что интерфейс теперь ведет себя по другому, и смотрит, не ломает ли это изменение поведение его пакета. Если ломает, то он меняет в зависимостях hooker (>= 1.0.5) на hooker (>= 1.0.5, <= 1.0.10), и перерегистрирует свой пакет.

То есть, изменения, по сути, вносятся в уже выпущенный пакет задним числом.

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

Что делать людям, у которых установлен этот пакет до внесения информации, ограничивающей верхнюю версию используемой библиотеки (<= 1.0.10)?

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

> И еще, будет ли ваша система жизнеспособна без сети? Ну, то есть, возможно ли распространиение софта в вашей системе через CD/Flash?

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

>> При чём тут POSIX?

При том, что это стандарт _окружения_.

Хорошо. А LSB - стандарт чего?

Что такое интероперабельность исходного кода?

Интероперабельность софта, распространяемого в исходном коде.

Вопрос по-прежнему в силе. В чём отличие распространения софта в коде от распространения в виде собранных бинарников с точки зрения интероперабельности? Всё равно, что спрашивать, какая рука лучше, правая или левая.

Потому что на порядок меньше интерфейсов, которым должен подчиняться пакет (для бинарных пакетов это + архитектура процессора, формат бинарника, ...).

А для исходного кода кода нет таких ограничений? Архитектура процессора, используемый toolchain... Может, приведёте таблицу «интерфейсов» для обоих случаев?

Что значит «пакеты компактны и их удобно собирать»?

Пакеты небольшие и быстро собираются, например.

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

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

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

Остаётся только поверить на слово.

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

Проблема, начинающаяся с разработки - это когда разработчики пихают в тарболл исходники 100500 сторонних библиотек, иногда модифицированных, иногда с изменённым API или ABI. Других проблем я сейчас в упор не вижу. Но это вопрос, гм, профпригодности, и актуален независимо от любых мыслимых «стандартов окружений», репозиториев метаданных и т.п.

> Главное, что такие нарушения будет гораздо проще отслеживать.

1. За счёт чего?
2. Кому жаловаться в случае проблемы?

> > Потому что на порядок меньше интерфейсов, которым должен подчиняться пакет (для бинарных пакетов это + архитектура процессора, формат бинарника, ...).

А для исходного кода кода нет таких ограничений? Архитектура процессора, используемый toolchain... Может, приведёте таблицу «интерфейсов» для обоих случаев?

>> Что значит «пакеты компактны и их удобно собирать»?

> Пакеты небольшие и быстро собираются, например.

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

Ты тупой? (Ничего личного.)

Проблема, начинающаяся с разработки - это когда разработчики пихают в тарболл исходники 100500 сторонних библиотек, иногда модифицированных, иногда с изменённым API или ABI.

Проблема начинается раньше.

Других проблем я сейчас в упор не вижу.

Lucky you.

> Ты тупой? (Ничего личного.)

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

Итак: в сообщении, на которое отвечаю, переформулирую первый вопрос сверху. Для каких архитектур и каким компилятором ты возьмёшься собрать Virtualbox или Google v8? Почему архитектура процессора называется ограничением способа распространения кода именно в виде собранных бинарников?

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

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

Как по мне - каие-то формально проверяемые стандарты на API/ABI (и которые писали бы авторы!) были бы весьма к месту. Проверили - стоят библиотеки нужного ABI - просто компиилируем приложение. Надо перекомпилировать - это хуже, но это уже экзотика, и вполне реально сделать дефолтом компиляцию нужного варианта бибилиотеки - но при этом она должна учитывать такую возможность и не конфликтовать по сохраненным данным и т.п. с уже установленной - и это отсутствие конфликта должно также проверяться автоматом. И так далее - чтобы не форсироватьпользователя на обновление половины системы ради одного нового апплета, если без этого можно обойтись.

>> обеспечиващие установку и работу программы в любом дистрибутиве линукса

Это невозможно, если дистрибутивов больше одного.

Это возможно, если, наконец, перестать дрочить на шареные либы и научиться пользоваться ключиком -static. А если все библиотеки включать в дерево исходников конечной программы, то можно избавиться и от build depend'ов. Немножко лишнего расхода дискового пространства и процессорного времени при сборках - зато целая армия людей вместо пустопорожней борьбы с депендами сможет, наконец, заняться делом.

И при обновление libc обновлять всю систему. Да-да. Удачи.

> Я вижу какую-то невнятную кашу, а идеи, которая была бы лучше того, что работает сейчас, не вижу.

Я в самом начале сказал, что в реальном мире мой подход работать не будет. С тем софтом и стандартами, что мы вынуждены использовать. Проблемы начинаются с глубоких архитектурных вопросов работы софта. Поэтому внимательно смотрим на Plan 9.

Для каких архитектур и каким компилятором ты возьмёшься собрать Virtualbox или Google v8?

Не возьмусь.

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

Потому что они собраны именно под эту архитектуру, не?

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

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

Это прекрасно поддаётся автоматизированному тестированию, и один из мейнтейнеров из quality assurance team этим занимается. Проблема в том, что он делает это на своих личных компьютерах, он единственный вкладывает свои личные деньги в это тестирование, поэтому его ресурсы ограничены.

куча ненужных пересборок софта

Куча? Такая необходимость крайне редко возникает.

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

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

Такое поведение portage появилось не вчера, и ты должен был бы знать об этом, если бы был действительно заинтересован в вопросе.

>> Почему архитектура процессора называется ограничением способа распространения кода именно в виде собранных бинарников?

Потому что они собраны именно под эту архитектуру, не?

Ни Virtualbox, ни Google v8 не соберутся подо что-то отличное от x86 или x86_64 (при этом Virtualbox - с multilib). Ограничение здесь не на уровне бинарников, а уже на уровне исходного кода. Вывод: утверждение ложно, проблема не решена.

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

> Ни Virtualbox, ни Google v8 не соберутся подо что-то отличное от x86 или x86_64 (при этом Virtualbox - с multilib). Вывод: утверждение ложно, проблема не решена.

Какое утверждение? Я где-то писал, что _все_ проекты архитектуро-независимы? Ладно, разжую: _большинство_ проектов архитектуро-независимы.

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

Что значит «полный», ограничений для чего? Традиционное управление пакетами меня не интересует. Ну например так. Исходники: время на сборку, сложнее отслеживать пакеты на уровне файлов. Бинарники: ограничение на архитектуру, ограничение на формат бинаря (=> на используемую ОС), лишняя работа и ресурсы, усложнение пакетной инфраструктуры, несамодостаточность (появляется новая архитектура, а пакета нет => все равно нужны исходники)...

> Какое утверждение? Я где-то писал, что _все_ проекты архитектуро-независимы? Ладно, разжую: _большинство_ проектов архитектуро-независимы.

Ты боролся с «лишними» интерфейсами, которым нужно соответствовать, и это усложняет наш мир. «Лишние» интерфейсы никуда не делись. Мир по-прежнему сложен.

Что значит «полный», ограничений для чего?

Не знаю, для чего. Ты перечислил интерфейсы, которым должен подчиняться пакет (http://www.linux.org.ru/jump-message.jsp?msgid=5812382&cid=5818553). Я всё ещё не вижу проблемы, ну да ладно. Меня интересует: 1) полный перечень интерфейсов, которым вынужден подчиняться бинарный пакет; 2) полный перечень интерфейсов, которым вынужден подчиняться пакет с исходным кодом.

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

Мне всё ещё нужно пояснение.

Бинарники: ограничение на архитектуру, ограничение на формат бинаря

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

лишняя работа и ресурсы

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

усложнение пакетной инфраструктуры

И я снова этого не понимаю.

несамодостаточность

Уже выяснили, что для случая распространения в исходниках это тоже справедливо.

> Ты боролся с «лишними» интерфейсами, которым нужно соответствовать, и это усложняет наш мир. «Лишние» интерфейсы никуда не делись. Мир по-прежнему сложен.

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

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

Цель: это не должно быть работой - одной командой собрать и установить нативный пакет от разработчика, без посредников в виде мейнтейнеров, и чтоб всё заработало, иначе катаем багрепорт.

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

Какое ограничение? Чтоб получить исходник, не нужен бинарник. Чтоб получить бинарник, нужен исходник.

> несамодостаточность

Уже выяснили, что для случая распространения в исходниках это тоже справедливо.

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

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

Не вполне распарсил. Какой еще «нужный нам» формат? Нам нужно, чтоб софт корректно работал.

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

Ты не сосвсем прав. Ядро это фундаментальня штука, но и при этом я тебя уверяю, что если у тебя в компе будет IDE винт и pci видео то есть большая вероятность, что оно заработает. Хотя это и не важно.

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

Так что твоя анология тут не верна.

>«мейнтейнер» — это жаргонное слово, обозначающее «поставщик»

Вообщето переводится как «сопровождающий». Человек решающий какие патчи принимать, какие нет - тоже майнтэйнер. В случае с FFmpeg как раз так и есть.

Дану в жопу. И тудаже ваши десктопы. Линукс это промышленная система.

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

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

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

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

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

Да, просто таки армии борются с депендами.

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

>Да, юзер имеет шанс установить несовместимый пакет, если: а) не обновит вовремя свой кэш метаданных;

Ох**ть!

б) используемый им сервер не успеет синхронизироваться с сервером, на котором мейнтейнер обновил метаданные;

Дважды ох**ть!!!

ЗЫ Ну ты понял?

> И еще, будет ли ваша система жизнеспособна без сети? Ну, то есть, возможно ли распространиение софта в вашей системе через CD/Flash?

Вот у меня система работает в АСУ ТП. Нет никакого интернета из соображений безопастности - как мне установить необходимые приложения и либы?

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

Ещё один не догоняющий. Как ты собрался обновляться? Или разработчик обызан следить за всеми over9000 либ от которых зависит его прога?

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

то апокалипсис наконецто настанет.

>и научиться пользоваться ключиком -static.

А ну ка сделай мне с «ключиком -static» чтоб прога скомпиленая на RHEL5 работала на RedHat9.

>А как насчет испоравления security-багов?

Кстати да, про них я и не вспомнил.

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

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

Очередной фанбой шаред либ. Читать до просветления:
http://sta.li/faq
http://dl.suckless.org/stali/clt2010/stali.html

Настоящая гибкость, масштабируемость и секьюрность обеспечивается файловыми серверами в Plan 9, а не половинчатыми решениями вроде шаред либ.

> >Да, юзер имеет шанс установить несовместимый пакет, если: а) не обновит вовремя свой кэш метаданных;

Ох**ть!

>б) используемый им сервер не успеет синхронизироваться с сервером, на котором мейнтейнер обновил метаданные;

Дважды ох**ть!!!

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

> файловыми серверами в Plan 9

Fix: файловыми серверами 9P.

o_O. А у меня вчера он как раз обновился до ffmpeg-20110121... Что теперь будет?!

>http://sta.li/faq

Охжеж ты, по ссылке наркоманы-гуманитарии, ответа ни на один вопрос нет.

Обоснуй.

Берем первый вопрос

Aren’t statically linked executables huge?

It depends. Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. Linking OpenBSD’s stripped ksh, which will be stali’s default shell, statically against uclibc results in a 170kb binary — linking it dynamically against glibc results in 234kb. Of course this won’t scale with every binary, for example we expect surf being about 5-6MB in size, but the normal Unix userland will be rather small, compared to most popular linux distros.

It depends.

Логично. Только не сказано, от чего зависит.

Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb

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

Linking OpenBSD’s stripped ksh, which will be stali’s default shell, statically against uclibc results in a 170kb binary — linking it dynamically against glibc results in 234kb.

А это вообще к чему? Вопрос был про размер статической линковки, а не про сравнение разных способов линковки с разными libc.

Of course this won’t scale with every binary, for example we expect surf being about 5-6MB in size

5-6М - это вполне даже huge

but the normal Unix userland will be rather small, compared to most popular linux distros.

Цифры, сестра! Кстати, а кто их про какой-то юзерланд спрашивал?

Всё-то надо разжевывать мейнстримным линуксоидам...

Вообще-то это FAQ по их дистрибутиву, вот они и отвечают на вопросы соответственно.

В целом: динамическая линковка бесполезна с вменяемыми либами. Ни glibc, ни webkit сюда не попадают.

Я тут товарищу в приватной переписке указал на отличный source-based пакетный менеджер contrib. Решил и здесь указать публично: многим будет полезно. Лучший пакетный менеджер.

> Ох**ть!

Будто в каком-нибудь yum не надо держать базу пакетов в синхронизированном состоянии.

> Настоящая гибкость, масштабируемость и секьюрность обеспечивается файловыми серверами в Plan 9

Бугага. Plan9 - это та самая операционка, которую понтов ради ставят в виртуалки? Вопросов больше нет...

За именование ОС «операционкой» накладываю на тебя анафему.