LINUX.ORG.RU
ФорумTalks

Форки как тормоз прогресса


0

0

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

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

Прямо сейчас на работе приходится иметь дело с программой, написанной под Qt 4.3.2, кто не в курсе - эта версия вышла 3 года назад, довольно приличный срок. В своё время бравые разработчики дописали поверх несколько самопальных патчей для собственных целей, тем самым прибив гвоздями программу к конкретно этой версии Qt. Опять же, кто не в курсе - в Qt 4 заявлена обратная бинарная совместимость, это значит, что Троллям нет смысла бекпортировать патчи для старых минорных версий, вместо этого они выпускают новую мажорную, сохраняя при этом обратную совместимость.

Проходит время, разработчики разбежались, программа не развивается, но актуальности не потеряла, поддержка функционирует. И получается такая штука, что Тролли уже выпустили сотни обновлений для Qt, но тем не менее задействовать их нельзя - мешает форк. Итого имеем:
- висящие в воздухе потенциальные ошибки, с помощью которых зная код можно попросту саботировать программу, подсунув ей специально подготовленные файлы;
- в свежих версиях появился функционал, открывающий новые возможности, использовать которые не выйдет;
- проблемы сборки старой версии Qt под OS X 10.6 (Snow Leopard), благодаря которым (сейчас тем кто стоит лучше сесть), программа собирается на OS X 10.5 и тестируется после перезагрузки на 10.6, да это официальный workflow;
- повсеместное использование внутри старой Qt Carbon API, который одной ногой в могиле, ещё чуть-чуть и программа просто перестанет работать на следующей версии OS X;
- закрытая дорога на 64 бита на Маке, опять же из-за Carbon.

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

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

Собственно лично я считаю форки достаточно радикальной мерой. Семь раз отмерь - один форкни.

Мнения приветствуются.

★★★★★

ИМХО ты сделал не совсем правильный вывод из такой ситуации. Проблема не в том, что Qt форкнули под конкретный проект, а в том, что это сделали просто не подумавши. В определённых случаях форки оправданы.

Собственно лично я считаю форки достаточно радикальной мерой. Семь раз отмерь - один форкни.

Как-то так, да.

Deleted
()

Собственно лично я считаю форки достаточно радикальной мерой


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

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

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

Предлагаю начать с закапывания семейства BSD.

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

>Это гораздо менее масштабно...

Это смотря с какой стороны посмотреть…

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

> Я бы убивал за форки. Вместо того чтоб пилить несколько ключевых дистров, люди занимаются идиотией. Вот и имеем в результате кучу неработоспособного говна, но зато с нескучными обоями™.

Дистростроители такие дистростроители.

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

Закопайся сам. Как раз у тебя юзерпик символизирует, что ты зачем то выполз из могилы.

different_thing
()

Подписываюсь.

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

*BSD это отдельные ОС, не надо марать ру^W^Wих трогать.
А вот семейство debian-derived прорядить, кроме специализированных, нужно.

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

> Я бы убивал за форки. Вместо того чтоб пилить несколько ключевых дистров, люди занимаются идиотией. Вот и имеем в результате кучу неработоспособного говна, но зато с нескучными обоями™.

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

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

> Сделай _свой_ дистрибутив, который не будет форкаться и успокойся или найди стену.

Это несложно. Вот сделать дистр, который еще и использовать будут - сложнее. А так составил список бинарников, через ldd список зависимых либ, протестировал в чруте, приклеил загрузчик - дистр гатоф.

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

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

Evgueni ★★★★★
()

- проблемы сборки старой версии Qt под OS X 10.6 (Snow Leopard), благодаря которым (сейчас тем кто стоит лучше сесть), программа собирается на OS X 10.5 и тестируется после перезагрузки на 10.6, да это официальный workflow;

Ты не поверишь, но это проблема дятлов из Apple, которые поломаи нафиг линкер в составе XCode.

Andru ★★★★
()

Вот тут правильно расписано, а у велосипеда с квадратными колёсами — неправильно.

name_no ★★
()

Ты абсолютно прав. Только у вас это не форк, а мертворожденный пасынок.

ttnl ★★★★★
()

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

Даже если дедлайн - уже завтра?

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

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

gods-little-toy ★★★
()

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

upcFrost ★★★★★
()
Ответ на: комментарий от gods-little-toy

> Даже если дедлайн - уже завтра?

Одно другому не мешает. Исправляешь локально, отправляешь патч и следишь за ним. В дистрибутивах накладывают свои патчи, даже КДЕ на постоянном bleeding edge, активно учавствуя в разработке самого Qt - и ничего, справляются.

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

> и если его не принимаю, а говорят it's a feature, то...?

Вменяемые разработчики с moto «Deploy Everywhere» как минимум предложат альтернативу. Иначе - нужно думать.

Вообще я не против включать маленькие редкие библиотеки в продукт, линкуя статически. Также форк оправдан, когда конечная цель - развить его до самостоятельного продукта, однако разрывать рынок выращивая конкурента всегда идея неоднозначная. И совсем другой случай, когда клеят патч «абы побыстрей сдать проект», не думая наперёд, про людей, которым прийдётся спустя годы это исправлять.

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

>Предлагаю начать с закапывания семейства BSD.

Предлагаю перестать его откапывать.

Pavval ★★★★★
()

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

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

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

О каком новом функционале идет речь, если вы занимаетесь поддержкой?

проблемы сборки старой версии Qt под OS X 10.6 (Snow Leopard), благодаря которым (сейчас тем кто стоит лучше сесть), программа собирается на OS X 10.5 и тестируется после перезагрузки на 10.6, да это официальный workflow;

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

повсеместное использование внутри старой Qt Carbon API, который одной ногой в могиле, ещё чуть-чуть и программа просто перестанет работать на следующей версии OS X;

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

закрытая дорога на 64 бита на Маке, опять же из-за Carbon

Вопрос о том, нафиг нужны 64 бита на десктопе, остается открытым.

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

P. S. обычно под форком подразумевают альтернативный публично доступный продукт. То, что какие-то гнусные проприетарщики для своих темных целей пропатчили опенсорснутую либу *без фидбака в апстрим* плохо говорит нам об этих проприетарщиках. Opensource это ведь не только воровство у общественности, но еще и вклад в общее дело. В противном случае это бздунство какое-то.

linuxfan
()

>Тролли уже выпустили сотни обновлений для Qt, но тем не менее задействовать их нельзя - мешает форк

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

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

> Коммерческие ОС крайне неохотно ломают интерфейсы

Поверьте, в Apple их ломают на ура. Не сразу конечно, спустя пару релизов, но таки выкидывают устаревшее API. Три года - достаточный срок, чтобы в OS X что-то отвалилось. А использовать, к примеру, одновременно SDK 10.5 и 10.6 не выйдет, хотите новых плюшек - пишите отдельные версии своей программы под каждую из платформ.

Вопрос о том, нафиг нужны 64 бита на десктопе, остается открытым.


Политика Apple - перевод всех приложений на 64 бита, это часть более глобального плана перевода разработчиков на Cocoa.

берешь исходники Qt 4.3.2, делаешь diff ...


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

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

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

Freiheits-Sender ★★
()
Ответ на: комментарий от Dendy

>Работает - не трогай.

К сожалению, так много где работают. Но ты же в изначальном посте выражал озабоченность тем, что «вот-вот работать перестанет». Вот, на здоровье, предложение по существу: портировать свои наработки в новую версию Qt.

linuxfan
()

а почему ты уверен, что патч на Qt 4.3.2 был бы принят? может это было нужно только для конкретной программы и в mainstream это и ненужно?

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

Он настолько важен, что пилить надо только его

Пилить надо не дистр, а софт. Ванильный.

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

OpenSuSE и Fedora не нужны более чем совсем не нужны

vertexua ★★★★★
()

Зачем в случае Qt может быть патч? И почему нельзя переписать на нормальную версию GT... Qt4? Сделать модульно все наконец?

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

Поломался или XCode или Qt?

Поломался XCode. В сети много разных проблем с конпеляцией в MacOS X 10.6, а недавно и сам столкнулся, когда не смог собрать dylib(тупо крашилось все нафиг на dlopen). Решение правда для себя нашел - использовать no_order_inits и no_order_data в доп. параметрах линковщику.

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

не смог собрать dylib(тупо крашилось все нафиг на dlopen)

не мог собрать работающую dylib(тупо крашилось все нафиг при попытке приложением загрузить её через dlopen)

// fixed

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