LINUX.ORG.RU

Ingo Molnar, разработчик ядра Linux «Нам нужно полностью пересмотреть модель распространения ПО»

 , ,


1

4

Представляю Вашему вниманию мой перевод статьи разработчика ядра Linux Инго Молнара (Ingo Molnar), размещенной в двух частях на его странице в G+. Статья вызвала горячее обсуждение на зарубежных тематических новостных площадках, и, на мой взгляд, заслуживает Вашего внимания.

Удивительно, но главным недостатком дистрибутивов Linux для настольных ПК является их недостаточная свобода.

Помните, сколько уязвимостей и проблем с качеством Linux-систем было найдено в последнее время, в частности моими коллегами Linas Vepstas, Jon Masters, Linus Torvalds и многими другими, и информация, с которая я знакомился в обсуждениях, привела меня к выводу, что разработчики свободного ПО просто не осознают, в какую бездну провалились.

Серьёзные недостатки Linux-систем, с которыми мы постоянно сталкиваемся практически во всех, даже самых популярных дистрибутивах Linux, имеют первопричину в фатальных архитектурных ошибках 10-20-летней давности.

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

А как поступают остальные (большей частью не являющиеся свободными) конкуренты? Они движутся в прямо противоположном направлении: Apple/iOS и Google/Android имеют только около ста тесно интегрированных системных пакетов, которым уделяется огромное внимание и с которым работают как с одним целым проектом. Эти системы документируются и развиваются в десятки раз интенсивнее, чем это происходит с десятками тысяч пакетов в рамках каждого дистрибутива Linux. И гораздо легче задокументировать 10 миллионов строк кода, чем тысячи миллионов.

Для обеспечения должного разнообразия приложений на площадках Apple Store и Google Play сторонним разработчикам открывается полный доступ к внутренней структуре всей платформы и ведётся контроль над внедрением в систему дополнительных приложений. Как результат, большинство новых приложений добавляются с задержкой лишь в несколько дней (в пределе - несколько недель), а их обновления - в несколько часов (в редких случаях - нескольких дней), в общем, весь процесс происходит настолько быстро, насколько быстро над этим сам работает каждый проект. К тому же для iOS/Android нет практически никаких ограничений и препятствий для приложений, стремящихся попасть на официальные площадки по распространению - они попадают туда почти автоматически.

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

В итоге платформы iOS и Android способны поддерживать и управлять десятами тысяч приложений, число которых в перспективе легко может дорасти до миллиона.

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

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

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

Да, я слышу ваш довод «но дистрибутивы Linux - это свободное ПО!». На самом деле, свобода ПО имеет важное значение для разработчиков или организаций, но для обычных пользователей свобода за спиной Linux-систем не имеет никакого смысла, если это свободное ПО не приносит при этом никакой практической пользы, например, настоящей свободы использования.

То есть, для исправления текущей ситуации с Linux-дистрибутивами нам нужно полностью пересмотреть модель распространения ПО: уйти от церковного строя к рыночной системе. Конкретнее, понадобится учесть следующие технологические нюансы:

  • Необходимость принудительного использования безопасной «песочницы» для запуска приложений как на уровне пользователя, так и на уровне ядра. Сегодня установка нового пакета из репозитория - это компромисс и выбор из серии «все или ничего» в плане общей безопасности системы. Пользователи должны быть свободны в своём желании получать и запускать даже непроверенный код.
  • Плоская модель зависимостей пакетов (то есть, обновление одного пакета не должно принудительно заставлять обновлять другие (дублирование содержимого может быть устранено на другом уровне системы, например, на уровне файловой системы).
  • Гарантированная совместимость ABI с новыми версиями основной системы (то есть, при установке пакета он будет гарантированно работать в дальнейшем, не требуя от пользователя обновлений). Пользователи должны быть свободны от пресса необходимости постоянного обновления большей части дистрибутива.
  • Узловая сеть для увеличения пропускной способности каналов. Пользователи должны быть свободными от тяжеловесных и развесистых зависимостей приложений.
  • Криптографическая защищённость данных, а также наличие обзоров и официальных пометок о безопасности и достоверности приложения. Этим достигается важный пункт в системной безопасности: необходимые сертификаты для установки ПО понадобятся для корпоративного сервера так же, как сейчас для обычного пользователя, пожелавшего опробовать новую игру на смартфоне. Такое устройство системы распространения ПО позволит пользователям либо присоединиться к выбору большинства (положившись тем самым на количество установок), либо прислушаться к специалистам (и при выборе пакета исходить из авторитетного мнения экспертов), а также смешивать оба этих подхода.

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

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

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

>>> Источник

★★★★★

Проверено: Shaman007 ()
Последнее исправление: ins3y3d (всего исправлений: 2)
Ответ на: комментарий от geekless

Не нужен никому из тех, кто является пользователями опенсорса в исходном понимании этого слова. Люди при помощи GNU/Linux решают реальные задачи, а не играют на телефоне.

Я самый что ни на есть «пользователь опенсорса в исходном понимании этого слова», как и r, кстати, и мне такая штука нужна. А Инго Молнар , кстати вообще пользователь этого вашего линукса в самом исходном смысле этого слова :D

И подобная технология, а я не столько о линуксмаркете, сократит заметно расходы на поддержку старых инсталляций. Которых энтерпрайз полон. Как пример. Вполне себе стимул двигаться в этом направлении. Затем, опять же, дистрибуторы сократят расходы на поддержку огромных массивов софта. Тоже стимул. И так далее.

По сути - линукс станет лучше. «Быстрее , выше, сильнее»(С) :D

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

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

re

Очень точное замечание.Формулировки полностью определяют истинное положение(состояние) вещей.

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

Всё, что мной было когда-либо поставлено на ведроид - было скачано с сайтов разработчиков при полном отсутствии их присутствия в market/play/store и тому подобных.

Например?

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

В итоге зависимость от libblabla превращается в зависимость от libblabla_2.5-1_+with-cool-feature_+ubuntu-patch-included

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

Что за бред? Не хочешь линковаться с новой версией, сиди со старой.

Неужели уже сейчас в системе можно держать несколько минорных версий одной библиотеки? Тогда о чём речь?

Да нельзя так. Случай когда программ П1 требует библиотеку Б версии x.y.z, а программа П2 требует библиотеку Б версии x.y.z+1 не такая уж редкость. И положить эти библиотеки рядом не получится. Придёт пересобирать программу П1 с библиотекой Б версии x.y.z+1. В противном случае получишь конфликт при установке П1 или П2.

Если в минорной версии ломают API или ABI , то разработчик дурак и не лечится.

API/ABI не ломают, но после сборки с новой версией есть ненулевая вероятность, что в программе что-нибудь перестаёт работать, поэтому потом приходится накладывать патчи. Это обычное дело и есть издержки стремления иметь в системе ровно одну версию библиотеки.

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

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

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

Разработчики Qt при переходе от версии N к версии M полностью сохраняют ABI, но вводят 4 новых свистопердящих виджета.

Вообще говоря такую проблему решают в 0install/autopackage (я же говорю, наработали методик - вагон) тем что вася что бы заявить о том что софтина «для ISV репы» должен и собрать ее соотвественно. Никто же Васе-разрабу не мешает написать в хедерах пакета что пакет для дебьяна, а внутри этому не соотвествовать.
Практический прием для обеспечения этого в том же 0install/autopackage это сборка со специальной девелоперской, референсной версией Qt. В которой естественно, таких виджетов нет.

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

И да - это значит что новая полезная программа Васи не может быть использована на дистрах по стандарту universalrepo-1.3. Это вполне логично. Васе никто не мешает написать программу которая будет не только не совместима с universalrepo-1.3 но и слинуксом вообще. Выбор Васи.

Собственно те кто таки хочет использовать программу васи в universalrepo-1.3, должны будут написать к ней патчи, которые убирают новый виджет. Или там класть в пакет qt новой версии, если ну очень уж нужная программа.

Естественно если речь идет о qt новой версии, то вполне логично оно войдет в стандарт universalrepo-1.4. Который будет перенесен вовсюда где это возможно.

Опять же если у вас новые виджеты, а ABI сохраняется, то такой проект вполне может сделать нормальное API/ABI для плагинов.

То есть программа Васи будет таскать с собой реализацию новых виджетов на старой QT, и использовать их если будет собрана по стандарту universalrepo-1.3

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

Я не пользуюсь deb-дистрибутивами и подозреваю, что мантейнеры таким образом преодолевают какие-то ограничения deb-пакетов

как это вообще относится к формату пакетов?! или у тебя врождённая неприязнь deb'а?!

Но зачем это делать, если гораздо лучше оформить все фичи в виде отдельной библиотеки?

это надо разрабам этой libblabla сказать, а не на формат пакетов пенять.

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

У нас есть AUR (и в том числе прозрачная сборка из репозитория), так что Арчи бОльшая часть сказанного просто не касается.

Нет, касается практически всё. Отсутствие платформы в GNU/Linux достаёт. Недавний пример, комментарий 2 об обновлении зависимости. Скажи, ЧЯДНТ что волшебный аур не спасает меня в условиях вечного bleeding edge?

И да, это не изменение ABI, поскольку петонопроблема. Это изменение API.

x3al ★★★★★
()

ну, не знаю. обновлял на андроиде с маркета Jota text editor и Ted. оба после обновления умирали.

(правда прочитал, что сносить надо Ted перед обновлением. но не проверил, почему это не автоматизированно?)

у меня на gentoo ни разу обновление ЕДИНСТВЕННОГО приложения на приводило к его неработоспособности. (конечно исключая случаи обновления библиотек с последующим ребилдом).

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

как это вообще относится к формату пакетов?! или у тебя врождённая неприязнь deb'а?!

Да, нет, конечно. Это предположение, основанное на том, что в RPM-дистрибутивах я таких хаков не встречал.

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

кстати Jota у меня не вылечилась после сноса и установки. исходников Jota text editor и Ted не нагуглил. понять в чём проблема не могу. так что сомнительно заявление, что лучше.

Гарантированная совместимость ABI с новыми версиями основной системы

ага. и тащить всю совместимость по версиям... вы это Qt-шникам скажите. обновление с 3 н 4, например.

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

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

deb ни при чем, это абстрактный пример.

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

А если разработчик библиотеки этого не сделал?

Неужели уже сейчас в системе можно держать несколько минорных версий одной библиотеки?

А что, когда-то было нельзя?

vadim@host3:~$ pacman -Ql libpng
libpng /usr/
libpng /usr/bin/
libpng /usr/bin/libpng-config
libpng /usr/bin/libpng15-config
libpng /usr/bin/png2pnm
libpng /usr/bin/pnm2png
libpng /usr/include/
libpng /usr/include/libpng15/
libpng /usr/include/libpng15/png.h
libpng /usr/include/libpng15/pngconf.h
libpng /usr/include/libpng15/pnglibconf.h
libpng /usr/include/png.h
libpng /usr/include/pngconf.h
libpng /usr/include/pnglibconf.h
libpng /usr/lib/
libpng /usr/lib/libpng.a
libpng /usr/lib/libpng.so
libpng /usr/lib/libpng15.a
libpng /usr/lib/libpng15.so
libpng /usr/lib/libpng15.so.15
libpng /usr/lib/libpng15.so.15.9.0
libpng /usr/lib/pkgconfig/
libpng /usr/lib/pkgconfig/libpng.pc
libpng /usr/lib/pkgconfig/libpng15.pc
libpng /usr/share/
libpng /usr/share/licenses/
libpng /usr/share/licenses/libpng/
libpng /usr/share/licenses/libpng/LICENSE
libpng /usr/share/man/
libpng /usr/share/man/man3/
libpng /usr/share/man/man3/libpng.3.gz
libpng /usr/share/man/man3/libpngpf.3.gz
libpng /usr/share/man/man5/
libpng /usr/share/man/man5/png.5.gz
vadim@host3:~$ pacman -Ql libpng12
libpng12 /usr/
libpng12 /usr/bin/
libpng12 /usr/bin/libpng12-config
libpng12 /usr/include/
libpng12 /usr/include/libpng12/
libpng12 /usr/include/libpng12/png.h
libpng12 /usr/include/libpng12/pngconf.h
libpng12 /usr/lib/
libpng12 /usr/lib/libpng.so.3
libpng12 /usr/lib/libpng.so.3.46.0
libpng12 /usr/lib/libpng12.a
libpng12 /usr/lib/libpng12.so
libpng12 /usr/lib/libpng12.so.0
libpng12 /usr/lib/libpng12.so.0.46.0
libpng12 /usr/lib/pkgconfig/
libpng12 /usr/lib/pkgconfig/libpng12.pc

Случай когда программ П1 требует библиотеку Б версии x.y.z, а программа П2 требует библиотеку Б версии x.y.z+1 не такая уж редкость. И положить эти библиотеки рядом не получится.

Получится. Один файл пусть зовётся /usr/lib/libblabla-x.y.z.so, а другой /usr/lib/libblabla-x.y.z+1.so. С запуском никаких проблем не будет.

API/ABI не ломают, но после сборки с новой версией есть ненулевая вероятность, что в программе что-нибудь перестаёт работать, поэтому потом приходится накладывать патчи.

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

geekless ★★
()
Ответ на: Итак: от muteki_okami

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

Это уже есть — FreeBSD.

Маркет нам не обязателен, но стремление к созданию подобной структуры и упорядоченности - нужно.

Коллекция портов FreeBSD.

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

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

Другая модель распространения — PBI == «Плоская модель зависимостей пакетов», о которой говорит Молнар. Где сама программа и её зависимости сведены в один пакет, устанавливаются в один каталог и независимы от других таких же программ и пакетов.

iZEN ★★★★★
()

За перевод спасибо, но статья не понравилась.

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

Просигнальте, если Вам интересны мои дальнейшие переводы тематических статей.

Такие переводы всегда и везде интересны.

mr_anonymous
()

Android, разумеется, никак не относится к свободному ПО.

А мужики, то не знают

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

Да, нет, конечно. Это предположение, основанное на том, что в

RPM-дистрибутивах я таких хаков не встречал.

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

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

это надо разрабам этой libblabla сказать, а не на формат пакетов пенять.

Зависимость функционала программ от сборочных зависимостей — неправильный подход. Функционал программы должен быть таким, как его создали разработчики этих программ. Если мантейнер не может собрать, он обрубает зависимости и в программе что-то не работает (порочная практика со ссылкой на занятость). Или, наоборот, он делает какие-то фичи с помощью сборочных хаков. Имеет право, конечно, но не лучше ли усовершенствовать прогу через апстрим? Сейчас понабегут и скажут, что через апстрим тяжело, а у себя велосипед сделать можно за 5 минут и поддерживать его с помощью постоянных переходящих из версию в версию патчей или сборочных хаков.

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

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

Это всё понятно, но речь немного про другое. Наличествуют недовольные необходимостью «обновления половины дистрибутива». Понятно, что для перехода на universalrepo-1.4 им один черт придётся обновить «половину дистрибутива».

Опять же если у вас новые виджеты, а ABI сохраняется, то такой проект вполне может сделать нормальное API/ABI для плагинов. То есть программа Васи будет таскать с собой реализацию новых виджетов на старой QT, и использовать их если будет собрана по стандарту universalrepo-1.3

Если так ставить вопрос, то пакет Васи от universalrepo-1.3 вообще будет прекрасно работать на universalrepo-1.4. Просто в первом случае он ставит в систему «реализацию новых виджетов» отдельной библиотекой, а во втором эта библиотека уже входит в состав universalrepo-1.4.

Это при условии, что мы будем делать по принципу «метапакет с мелкими пакетами внутри».

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

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

Не получится. Каждый считает, что именно его компонент самый важный. Но претендент на такой набор есть: проект GNU.

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

RPM'щики отняли у тебя выбор, а ты ещё и радуешься, дескать так и надо, а DEB неправильный, лол.

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

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

anonymous
()

Самое забавное, что Ingo Molnar не сказал, в общем-то, ничего нового. Но все обсуждают.

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

Ты программы никогда не собирал что ли? «Функционал» программы меняется от параметров сборки, которые созданы самими же разработчиками.

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

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

Спасибо кэп, без тебя ну никак просто. :)

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

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

Или, наоборот, он делает какие-то фичи с помощью сборочных хаков.

И зачастую этот хак есть в апстриме.

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

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

И да - это значит что новая полезная программа Васи не может быть использована на дистрах по стандарту universalrepo-1.3. Это вполне логично. Васе никто не мешает написать программу которая будет не только не совместима с universalrepo-1.3 но и слинуксом вообще. Выбор Васи.

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

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

Это ты так тонко намекнул на то, что надо использовать минимальный набор всего Qt'шного, а все остальные виджеты и прочие возможности велосипедить? :}

Deleted
()
Ответ на: комментарий от Deleted
     Он на вкус не так хорош,
     Но зато сымает дрожь,
     Будешь к завтрему здоровый,
     Если только не помрешь!..
daemonpnz ★★★★★
()
Ответ на: комментарий от vold

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

У меня в системе ровно ДВА приложения, которым требуется gstreamer: pidgin и xneur. И ни в одном из них мне звук не нужен. «Собирайте с полным набором фич», ага.

Тебе не приходило в голову, что ключи --enable-* и --with-* существуют у ./configure как раз для того, чтобы пользователь мог собрать программу так, как подходит для его окружения?

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

Так ведь верно набегут и скажут. Взять тот же pidgin с его долбанутым апстримом, напоминающим объезьяну с гранатой. Или весь проект гном целиком, обвенчанный с HIGом и великой миссией. «В новом релизе мы выпилили 4 опции, встречайте!» Или конфликт Линуса с Коливасом. Или фанатика Аарона. Мало их таких что ли?

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

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

По факту, её придётся переложить не на разработчиков софта, а на других мейнтейнеров. Специальных мейнтейнеров для ЛинуксМаркета, обычных Вась и Петь. Разница только в названии: раньше место, где они могли скоординировать усилия называлось, скажем, «репозиторий [community]», то теперь оно будет называться «ЛинуксМаркет». Что само по себе неплохо, если позволит объединить усилия пользователей разных дистрибутивов, но к разработчикам софта никакого отношения не имеет.

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

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

Это ты так тонко намекнул на то, что надо использовать минимальный набор всего Qt'шного, а все остальные виджеты и прочие возможности велосипедить? :}

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

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

Тебе не приходило в голову, что ключи --enable-* и --with-* существуют у ./configure как раз для того, чтобы пользователь мог собрать программу так, как подходит для его окружения?

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

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

Собственный набор пакетов ? 1001 формат роспространения, который добавит головняка всему миру опенсорс и дистрибутивам ?

Там один формат распространения — tbz.

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

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

А теперь ты расскажешь, как этого добиться.

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

Грузишь либы ручками и работать, работать, работать :)

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

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

Где гарантии, что в любых источниках исходники без внедрённого вредоносного кода?

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

Разве планшеты - это удобно? Тыкать в экран и клавиатуру отдельно таскать, да и экран не защищён никак. Глупость какая-то - эти ваши планшеты.
А андройд - яво-подобная какашка с тёмным будущим в свете истории с моторолой, и вообще.
В убунтах шаттлворт > система > пользователь.
В гентах надо суперкомпутер, чтобы компилить все эти 100500 пакетов багфиксов ради.
Все остальные - минорщина в основном, без критической массы пользовтелей.
join arch

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

гуй не нужен =)

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

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

Вы вообще в курсе что такое подсистема Side-By-Side в Винде?

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

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

Плагины, не?!

Заводить отдельную плагинную архитектуру, под единственный плагин вывода звука? Или под единственный плагин проверки орфографии?

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

Фряха тут ИМХО не лучший пример, так как портами занимаются не разработчики софта.

Лучшим примером будет OpenSolaris/Illumos - есть базовая система, есть реп базовый, а так же есть возможность подключать репы для софта через систему pkg. При этом подключаемые репы могут быть как открытыми, так и защищенными при помощи ssl сертификатов (не передача данных и подпись, а именно подключение к репу, что делает pkg пригодным и для распространения коммерческого ПО). Осталось сделать только централизованный каталог реп.

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

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

По твоему все возможности гуёвин могут реализовываться только через Qt или GTK? Хороший прокачанный интрумент должен быть прослойкой над базовыми линуксовыми либами и не дёргать из системы проблемные функции используя вместо них свои которые имеют ту версию, которую пожелал разработчик. Это вполне реализуемо.

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