>Получается я наивно верю

Получается, так :)

ради удовольствия и фана

Там много гитик. Начиная с того, что в мире СПО крутятся гигабаксы, кончая тем, что для многих удовольствие и фан - это построить других :)

>для многих удовольствие и фан - это построить других

Что-то я об этом и не подумал... Довольно очевидно. Но ведь всё равно в мире СПО ситуация лучше, чем у проприетарщиков, правда?

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

>Но ведь всё равно в мире СПО ситуация лучше, чем у проприетарщиков, правда?

Не знаю. Я в проприетарной команде последний раз работал 16 лет назад :) И это была классная команда. Народ не за деньги работал, а за интерес.

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

Беллард Вернись И Программируй!

>Товарищ командир всех достал.
Так это же самое интересное. :-) Чем достал то?

Но зачем?

Правильно веришь, так оно и есть. Я пишу for fun на, для двух - трёх юзеров.

отличные два письма: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/103733.html http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/103734.html

>Чем достал то?

1. «спец ты крутой, но командовать не умеешь (you aren't suitable as leader since you lack the social skills needed)»
2. «нужно больше оверлордов»
3. «чувак, ты походу забыл, что ffmpeg - это не mplayer»

исходники Дальнобойщиков-2, кстати, частично открывались. если мне память не изменяет, на сайте govnokod.ru =) знакомый хороший в Софтлабе работал, доставлял иногда полёт мысли физиков-программистов.

сомневаюсь
вот типа доказательства неадекватности основного ментейнера (с 2006) проекта FFmpeg:
http://ikaruga.co.uk/~snacky/mn.html

Насколько я понял, Michael Niedermayer вел проект FFmpeg с 2004 (начатый Fabrice Bellard, это также и автор qemu).
Т.е., если вы что-то сделали, то есть хороший шанс, что из вас могут сделать идиота (на бесплатной основе) заклятые друзья по работе.
Наверное, это и им как-то вернется потом.

Вот интересно:
http://bellard.org/
the Open Source Multimedia System. I launched this project in year 2000 and led it during several years.

мнение этого человека (типа как автора) учитывали ?
Или gpl лишает совести напрочь в таких делах ? ))

Зачем они не ставят проверки? Видимо лениво им. Причем от версии к версии проверки то появляются то изчезают в разных местах, поэтому падает оно всегда по разному.

Зачем они не ставят проверки? Видимо лениво им.

От большого кол-ва проверок снижается производительность. Ваш К.О.

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

Как раз написал диплом на эту тему. Придумал альтернативный подход к управлению пакетами. Основные принципы:

- мейнтейнеры - сами разработчики
- вместо репозиториев пакетов - сервера метаданных, где хранится лишь информация о пакетах (зависимости и т.д., а также URL, откуда его скачать)
- разработчики выкладывают где-либо свои пакеты и регистрируют их на серверах метаданных
- пакет - частный случай интерфейса; интерфейс, не являющийся пакетом, не имеет URL откуда его скачать для установки: по сути, это спецификация без реализации, например какой-нибудь стандарт (а пакет - спецификация с реализацией)
- пакет (более общо - интерфейс) зависит от набора интерфейсов и предоставляет набор интерфейсов (поля Depends и Provides в метаданных); чтобы установить интерфейс, не являющийся пакетом, нужно установить пакет, его предоставляющий
- еще у меня там явный контроль совместимости версий (поле Breaks для явного указания, что интерфейс в новой версии несовместимо поменялся) и много еще чего
- коренное отличие идеологии: внимание уделяется не корректной работе пакета в конкретном окружении, а корректному использованию хорошо определенных интерфейсов; если и пакеты, и окружение работают в соответствии со спеками, то всё должно правильно работать везде.

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

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

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

А что, по-другому в принципе нельзя? Дистров хоть миллион (ядер, libc'ов, coreutils'ов, ...), но они соответствуют спекам, пакеты соответствуют спекам, пакетный менеджер знает, кто какие спеки реализует и кто на какие спеки полагается (для всех версий), сами спеки непротиворечивы и отвечают реальности, а если что-то не работает, то этот баг, который надо зафиксить, и он зафиксится сразу везде? Речь не о том, что это невозможно сейчас, в 2011 году, а о том, что тебе это даже в голову не пришло.

а до того времени мы будем продолжать свою работу, хоть мы и не нужны :)

«Если бы Эдисон побольше думал, ему бы не пришлось столько потеть» (Тесла, цитата приблизительная)

Эх, ностальгия... Когда-то мне тоже было 12 лет, мир для меня был простым, а голова полна идеалов...

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

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

)) как забавно ...
А если баг ходит на двух ногах и зовут его Гвидо ?
Как фиксить собираетесь это ?

Ещё под горячую руку поддержку APE выпилят...

> Как раз написал диплом на эту тему.

Я прочитал что ты предлагаешь.

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

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

Но дело в том, что новая подверсия программы или библиотеки может оказаться (и часто оказывается) с такими багами, что для нормальной работы непригодна. А откатиться невозможно. В Debian вместо решения этой проблемы нагородили три слоя «стабильности». Но это не решение проблемы. Она как была, так и осталась.

Если бы была обязательная совместимость снизу-вверх, то есть разработчик _обязан_ поддержать первоначальный интерфейс в неизменном виде, только расширяя его, но не убавляя/переименовывая/меняя концапцию инициализации, это и называлось бы совместимостью снизу-вверх. И жить было бы гораздо легче. Кто-то скажет, что это затормозит разработку - да, вместо заплаточного метода работы и постоянного перпроектирования интерфеса, программист должен трижды подумать что он делает, ведь он должен создавать базу на длительный период, а потом её ещё и сопровождать.

Кстати, почему-то в интерфейсах упускают, что клиент _должен_ сообщать используемому коду, какой он есть версии. Чтобы код при необходимости знал, как подстроиться под клиента. Этакое обратное информирование. Тогда разработчики библиотек могут более гибко менять внутренности библиотеки, и перекидывать обработку клиентского кода в соответсвии с историческими особенностями. Например, если клиент требует версию 1.22, а текущая версия библиотеки 1.35, причем крупная переделка была в районе версии 1.29, то код библиотеки 1.29 можно выделить, например, в скрытую за интерфейсом и выделенную в отдельное пространство имен область.

Или, если так не геморроиться (а в MS как раз так и делали при переходе с W95 на W98 - для того, чтобы все программы из 95 работали в 98), то нужно делать возможность иметь в системе параллельно нестолько версий одной и той же библиотеки. Сейчас это очень затруднительно - пакетный менеджер сносит старую и устанавливает новую. А должен в идеале пробежаться по зависимостям, и если хоть одна программа требует старую версию, то при обновлении оставить её и рядом поставить новую версию либы. Только так.

Слава Мейнтейнерам и Репозиториям!

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

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

Ваш К.О.

А если считаете, что это сложно, или «красноглазо», то скажите спасибо тем самым мейнтенерам, что мы можем обойтись pacman (yaourt), apt-get и иже с ними.

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

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

И вообще, как вспомню этот глючный зоопарк инсталляторов в ОС имя которой мы не произносим, так вздрагиваю. Репозитории - это наше всё!

Постоянно вплывает одна и та же тема.

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

Это одна из тысяч _возможных_ проблем.

Если бы была обязательная совместимость снизу-вверх, то есть разработчик _обязан_ поддержать первоначальный интерфейс в неизменном виде

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

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

Вы вообще когда нибудь занимались программированием? Вы представляете в какой Ц это превращается?

---

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

>Я в проприетарной команде последний раз работал 16 лет назад :) И это была классная команда. Народ не за деньги работал, а за интерес.

Вполне возможно: для кого-то еда - интерес

>Например, если клиент требует версию 1.22, а текущая версия библиотеки 1.35, причем крупная переделка была в районе версии 1.29, то код библиотеки 1.29 можно выделить, например, в скрытую за интерфейсом и выделенную в отдельное пространство имен область.

Хороший, годный путь прямо в ад.

>Вполне возможно: для кого-то еда - интерес

Денег итак платили раза в два больше, чем другим программистам по стране тогда в среднем. Так что о деньгах просто не думали :)

>разработчик _обязан_

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

Или, если так не геморроиться

Капитан Очевиднность спасает: s/так не //

а в MS как раз так и делали при переходе с W95 на W98

В MS так не делали при переходе с W95 на W98. SxS появилось в XP.

для того, чтобы все программы из 95 работали в 98

Они внутри почти не отличались. А вот сколько программ для 9x не работало в XP... А в семерочку вообще пришлось виртуалку встроить для запуска XP-прог.

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

Прохладная история, брат. А ошибки/уязвимости фиксить кто будет для всех 9000 версий 100500 либ? А так в чем проблема -
трать память, не обновляйся
@
собирай статически.

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

1. это не будет результатом внутренних разборок, а в ffmpeg разборки именно внутренние

2. вообще-то с точки зрения закона (даже _до_ суда) кое-какие популярные опен-соурс проекты в принципе незаконны. :-)

на практике раздел/слияние коммерческого проекта блокирует его развитие на срок от полугода до полутора.

Смотря какой проект, смотря какое руководство. Про «от полугода» - глупости. Зависит от того, как именно проводится раздел/слияние и кем.

Чучело, а тестировать взаимодействие тоже ты будешь? Со ВСЕМИ дистрибутивами.

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

Он уже есть. Называется source.tar.gz.

Fedora и Debian это разные системы. Предложи ещё, чтобы этот дистрибутив сам учитывал все нюансы взаимодействия со всеми такими системами, умел сам интегрироваться во всё (в убунте сам бы прописывал себе индикаторы, в debian собирался бы под все платформы, а также под gnu/kfreebsd и gnu/hurd и так далее), работал бы на linux, freebsd, haiku, macosx, macos, os/2, dr.dos и cr/m.


Или ты такой вид дурачка, который считает, что в жизни есть только десктоп, его десктоп, только amd64 и i386, а ос существуют только windows и linux?

Хреновенько. Линукс сообщество напоминает порой индейские племена, порой враждующие и кажое гребёт под себя.

Кстати, http://rutube.ru/tracks/1001480.html

> отличные два письма

Хе-хе, да уж.

>Дистров хоть миллион (ядер, libc'ов, coreutils'ов, ...), но они соответствуют спекам

Чьим? Дистрибутивы потому и разные, что у них принципы и способы построения системы разные. Разные наборы патчей, параметры сборки, разные префиксы, разное разбиение на бинарные пакеты.

Так что одним «спекам» может отвечать только один дистрибутив. Т.е. вернулись к тому же, только ещё «спеки» добавили.

Да, проблема есть. Попробуйте впилить в ядро Линукса драйвер железки какой-нибудь новой. Можно, но в отношении написанного с нуля драйвера шансы нулевые. С одной стороны это можно понять. С другой...

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

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

Меня смущает пункт 3. Autotools это настолько жуткий костыль, что и думать об этом не хочется.

«There are toolchains like the BSD ones and they proof pretty much that the „everything is a Makefile approach“ is the most portable and sustainable one. Running a configure script from 10 years ago will fail immediately.»

http://lists.suckless.org/dev/1001/3059.html

И вообще, как вспомню этот глючный зоопарк инсталляторов в ОС имя которой мы не произносим, так вздрагиваю. Репозитории - это наше всё!

Ну если в сравнении, то да.

За что стоит ненавидеть винду, так за то, что люди не стремятся сделать Юникс лучше - мол, радуйтесь, что не как в винде.

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

В моей системе нет понятия основного номера версии. Разработчики нумеруют версии как хотят, но в поле Upgrades явно задают список версий, обновляемых данной. Получается явный граф обновлений для всех существующих пакетов/интерфейсов.

Вообще, интерфейс у меня идентифицируется парой <имя, версия>. Версии по сути нужны лишь для возможности задания диапазонов версий. Depends: hooker (>= 1.0.5) означает все пакеты, до которых в графе обновлений есть путь от hooker 1.0.5. Этот диапазон неограничен: может появиться новое обновление.

Что делать, если в этом обновлении (скажем 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), и перерегистрирует свой пакет. При перегегистрации опять-таки все зависящие от него мейнтейнеры на всякий случай уведомляются.

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

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

Поздравляю, ты изобрёл Gentoo.

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

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

Кстати, почему-то в интерфейсах упускают, что клиент _должен_ сообщать используемому коду, какой он есть версии. Чтобы код при необходимости знал, как подстроиться под клиента. Этакое обратное информирование. Тогда разработчики библиотек могут более гибко менять внутренности библиотеки, и перекидывать обработку клиентского кода в соответсвии с историческими особенностями. Например, если клиент требует версию 1.22, а текущая версия библиотеки 1.35, причем крупная переделка была в районе версии 1.29, то код библиотеки 1.29 можно выделить, например, в скрытую за интерфейсом и выделенную в отдельное пространство имен область.

OMG Нафиг надо такое, настолько усложнять код. Пусть пакетный менеджер всё разруливает.

> А разработчик занимается своим делом, он разрабатывает, а как его разработку будут внедрять это не его дело.

А должно быть его дело.

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

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

Он уже есть. Называется source.tar.gz.

И в нем угребищный configure скрипт, да.

патчи посыпались, как горячие пирожки в ffmpeg-devel list - как и обещано - 2 разработчика их одобряют

«Ни в одной коммерческой разработке такого бешенного срача не было бы. А в Open Source можно все. Даже заживо похоронить полезный проект, нассавши на голову его мейнтейнеру. »

Ну за это люди и любят опен сорц-чистое творчество! :)

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

> Он уже есть. Называется source.tar.gz.

И в нем угребищный configure скрипт, да.

Что, в каждом первом?

> >Дистров хоть миллион (ядер, libc'ов, coreutils'ов, ...), но они соответствуют спекам

Чьим? Дистрибутивы потому и разные, что у них принципы и способы построения системы разные. Разные наборы патчей, параметры сборки, разные префиксы, разное разбиение на бинарные пакеты.

Так что одним «спекам» может отвечать только один дистрибутив. Т.е. вернулись к тому же, только ещё «спеки» добавили.

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

Забыл добавить: моя вымышленная инфраструктура предполагает именно использование пакетов исходников: интероперабельность исходного кода обеспечивается гораздо проще и красивее. Но это предполагает, что разработчики ценят простоту, пакеты компактны и их удобно собирать. Мы же живем в мире bloatware. Сам я юзаю бинарный дистр, ибо нет желания тратить время на сборку какого-нибудь gcc или иксов.

>> а до того времени мы будем продолжать свою работу, хоть мы и не нужны :)

«Если бы Эдисон побольше думал, ему бы не пришлось столько потеть» (Тесла, цитата приблизительная)

там проблема похоже не в этом

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

* экстрагировала

а ты изучил пакетные менеджеры хотя бы дебиана и ред хат?

> Получается я наивно верю, что в мире СПО люди работают ради удовольствия и фана (даже для других людей иногда) с хорошим настроением и располагающим отношением к окружающим, а не грызутся друг с другом за тёплые местечки и прочие «нужные» штуки, свойственные рабам в загнивающих корпорациях?

загнивающих

вспоминая советский анекдот про духи шанель — да, загнивающих, но зато с каким запахом!

насчет опенсорса: все не так драматично; вон товарищ в теме запостил ссылку:

I think you aren't suitable as leader since you lack the social skills needed yet I trust your technical competence

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

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

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

Вот и я о том же.

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

Не надо, автоконфом уже наелись.

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

Забыл добавить: моя вымышленная инфраструктура предполагает именно использование пакетов исходников: интероперабельность исходного кода обеспечивается гораздо проще и красивее. Но это предполагает, что разработчики ценят простоту, пакеты компактны и их удобно собирать. Мы же живем в мире bloatware. Сам я юзаю бинарный дистр, ибо нет желания тратить время на сборку какого-нибудь gcc или иксов.

Это всё херня какая-то.

Ты сейчас не диплом защищаешь, расслабься. Здесь не надо грузить комиссию заумными, но ничего не означающими фразами.

При чём тут POSIX? Это во-первых.

Что такое интероперабельность исходного кода? Как она «обеспечивается», почему этот подход «лучше и красивее»? Это во-вторых. Нужны конкретные примеры.

Что значит «пакеты компактны и их удобно собирать»? Покажи пакет, который «неудобно собирать», и как это «удобство» соотносится со «стандартизацией» дистрибутивов? Это в-третьих.

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

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