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)

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

чтобы зюзеводы пилили дистрибутив а не либреофис - а либреофис напилят либрофисисты

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

1. Зависимости.
2. Зависимости.
3. Зависимости.

Ни одного решения.

geekless ★★
()

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

Всем пользователям обновляться вовремя нереально, селинукс Касперского вас спасёт.

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

Выключи аппарат на полгода а пакеты всё равно за неделю обновятся, до чего техника дошла! С такими технологиями компьютеры превращаются в древние роботроны в которых после суток отключения от питания стиралось ПЗУ и нужно было везти аппараты в сервисный центр для перепрошивки ОС через клизму.

Гарантированная совместимость ABI с новыми версиями основной системы (то есть, при установке пакета он будет гарантированно работать в дальнейшем, не требуя от пользователя обновлений). Пользователи должны быть свободны от пресса необходимости постоянного обновления большей части дистрибутива.

Давно пора.

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

GNU-платформе... не нужны пользователи

fixed

Не ржи, блондинки и идиоты тут действительно не нужны.

У тебя с этим какие-то проблемы? Тебя это напрягает? Ты хочешь об этом поговорить? Просто купи макбук и перестань жрать кактус. Тебя никто не заставляет.

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

> Гарантированная совместимость ABI с новыми версиями основной системы (то есть, при установке пакета он будет гарантированно работать в дальнейшем, не требуя от пользователя обновлений). Пользователи должны быть свободны от пресса необходимости постоянного обновления большей части дистрибутива.

Давно пора.

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

2. Вася — разработчик Крутой Полезной Софтины, не имеющей никакого отношения к базе системы, — решает что новые свистопердящие виджеты как раз то, что нужно и запиливает их в свежий релиз.

3. Пользователь обновляет софтину из этого вашего ЛинуксМаркета.

4. ????

5. Ой.

geekless ★★
()

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

Сначала тебя постоянно предупреждают что это deprecated, но если ты не удосужился поправить на новое - ссзб. Инноваций и новшеств не будет на 100-летней трясине.

Моё виденье этой проблемы - дистрибутивы оставить так, как есть, а всё остальное, что не входит в них, но хочется иметь пользователям просто так, пусть будет статично собрано, в каком-то отдельном аппсторе, и запускается только из под песочницы. Попробовал - понравилось, не хватает скорости - собирай/ищи реп.

Zidane
()

чтобы обеспечить такой уровень безопасности, то нужно запускать каждое приложение и группы приложений в отдельной виртуальной машине и все бинарно линковать ну и прекрутить к этому всему маркет. Получится дикая смесь qubes, pcbsd ну и маркет прикрутить. А учитывая то, что для нормального функционирования нужно 4гб оперативки и нормальный процессор с виртуализацией. То хомячкам это вдвойне не нужно. Им вот вконтакте, фейсбук да аудио/видеоплеер и фоточко просмоторщик - это все.

anonymous_sama ★★★★★
()

Уже предлагали оставить поддержку одного десктопа, одного ноутбука, и переписать все на джаву?

Vit ★★★★★
()

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

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

И какой же из них должен быть в дистрибутиве: libpng1.0, libpng1.2, libpng1.4, libpng1.5?.. Все?

Какой хотят, плюс тот(те) который нужен для совместимости с «ISV-репозиторием».

Грубо говоря как это технически примерно будет осуществлено. Будет «платформа» - некий набор стандартов и подходов, плюс некий набор софта их обеспечивающий. Врапперы к библиотекам, например. Врапперы к apt-get/yum , для установки того что должен дать в систему дистрибутив. Шелл скрипты(генераторы шелл скриптов) вроде фарефоксовского firefox вызывающего firefox-bin. Часть пакетов будут «developer tools» под эту платформу. На сайте autopackage например было полно наработок на эту тему, вроде шелл-враппера к gcc. Которые будут позволять собирать под эту «платформу»(платформу как набор соглашений) бинарные пакеты, максимально легким для девелопера способом.

Соответственно задача дистрибутора будет взять этот проект, собрать его под свой дистрибутив, интегрировать в него, и обеспечить совместимость. Например если libyyy-1 достаточно совместима на уровне libyyy-1.1 , libyyy-1.2 , libyyy-1.3 , дистрибутив может решить предоставлять для обеспечения зависимости libyyy-1 только libyyy-1.3, например. Или вообще, запилить свой враппер libyyy-1 c фиксами.

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

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

можно подтянуть вместе с собой либу Qt. Об дедупликации и прочей экономии жесткого диска позаботится файловая система.

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

И какой же из них должен быть в дистрибутиве: libpng1.0, libpng1.2, libpng1.4, libpng1.5?.. Все?

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

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

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

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

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

ДА мужик, ты прав. Пацаны, все на поддержку ubuntu 12.04!!!

два чая этому господину! даешь USC во все дистры!

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

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

А они и будет фактически. Но для этого единого репозитория.

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

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

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

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

Которые будут позволять собирать под эту «платформу»(платформу как набор соглашений) бинарные пакеты, максимально легким для девелопера способом. Соответственно задача дистрибутора будет взять этот проект, собрать его под свой дистрибутив, интегрировать в него, и обеспечить совместимость.

Так ты предлагаешь соглашения о ПРОЦЕДУРЕ СБОРКИ пакетов или о ABI, позволяющем использовать одни и те же пакеты БЕЗ ПЕРЕСБОРКИ?

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

Я себя не предлагаю помещать в ЛинуксМаркет.

Ты тут бодро размахиваешь саблей на тему нужен-ненужен, забывая добавить что ненужен *тебе*.

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

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

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

Так ты предлагаешь соглашения о ПРОЦЕДУРЕ СБОРКИ пакетов или о ABI, позволяющем использовать одни и те же пакеты БЕЗ ПЕРЕСБОРКИ?

Самый простой способ помочь обеспечению «ABI, позволяющем использовать одни и те же пакеты БЕЗ ПЕРЕСБОРКИ» это ввести соглашения о процедуре сборки.

Грубо говоря описание ABI это огромный талмуд, описание «собирайте gcc с такими то опциями такой то версии» это коротко и этому легко следовать.

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

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

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

Я смотрю ты даже в своем любимом 0install не разбираешся

Зироинсталл в треде ни при чем. Пусть мечтатели опишут технологию, которую хотят применить. Уверен, что половина из радетелей ЛинуксМаркета про зироинсталл слыхом не слыхивала. Это те самые «а ну-ка сделайте мне хорошо, и похрену, каким раком вы для этого встанете»-пользователи. Вот пусть задумаются, о том, каким именно раком надо встать, и кто же именно должен это сделать ради светлого будущего.

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

Делим софт на корневую часть ...

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

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

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

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

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

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

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

и язык один оставить чего уж мелочиться. Желательно завязанный на специальное закрытое API.

qnikst ★★★★★
()
Ответ на: Ура от muteki_okami

Давайте все дружно - заголяем arsch, выходим на улице в костюмах пингвинов, и танцуем под YMCA, который запишем на диктофон!

и правда, ура

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

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

Ещё один голос за. В сложившейся ситуации с новостями это безусловно нужно. Спасибо за перевод.

bloodredfrog ★★
()

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

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

Ни одного решения.

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

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

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

thesis ★★★★★
()

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

Дык! Я ещё с 90-х помню лозунг линуксоидов про «Linux - это система, созданная программистами для программистов!». Он часто цитировался даже в книжках, не говоря уже про инет.

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

1. Бывает, что важны не только библиотеки, но ключи сборки или отдельные патчи. Что делать?

2. В GNU/Linux я тоже могу поставить разные версии бибилиотек и другого ПО (пакеты так и зовутся: gtk2, gtk3, libpng14, libpng15, ruby18, ruby19 — логично, да?). Проблема в том, что нет единого стандарта на всё это.

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

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

2. Вася — разработчик Крутой Полезной Софтины, не имеющей никакого отношения к базе системы, — решает что новые свистопердящие виджеты как раз то, что нужно и запиливает их в свежий релиз.

3. Пользователь обновляет софтину из этого вашего ЛинуксМаркета.

4. ????

5. Ой.

Вот чтобы такого не произошло, Вася послал в /dev/null Qt Designer и слепил гуёвину на лазарусе, программа получилась статичная, ставится простым копированием и в большинстве случаев не тянет никаких зависимостей.

Napilnik ★★★★★
()

Он хочет аля java maven.

vtVitus ★★★★★
()

Не, не нужно. И сейчас всё нормально. Лучше закрытая экосистема, чем открытая помойка.

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

1. Бывает, что важны не только библиотеки, но ключи сборки или отдельные патчи. Что делать?

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

2. В GNU/Linux я тоже могу поставить разные версии бибилиотек и другого ПО (пакеты так и зовутся: gtk2, gtk3, libpng14, libpng15, ruby18, ruby19 — логично, да?). Проблема в том, что нет единого стандарта на всё это.

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

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

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

Такого механизма как в винде нам не надо. А то нас ждёт dll-hell.

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

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

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

пусть флагманы индустрии соберутся и создадут/продвинут

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

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

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

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

Ключи сборки нужны сборщикам.

Ну здрасти. Ключи включают в сборку фичи. Программа может зависеть не только от базовых функций библиотеки, но и от конкретных её фич. В итоге зависимость от libblabla превращается в зависимость от libblabla_2.5-1_+with-cool-feature_+ubuntu-patch-included

А пользователям не помешали бы подписанные пакеты, чтобы их нельзя было подменить.

Это умеет практически любой дистрибутив.

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

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

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

Если в минорной версии ломают API или ABI , то разработчик дурак и не лечится. Увы, дистрибутив тут ничего сделать не может. Решение — либо предоставлять сразу кучу версий минорных в составе репозитория, либо переособирать пакеты. Как пример, недавнее обновление libpng до 1.5 в Арче. Поскольку политика дистрибутива не позволяет держать в основном репозитории несколько минорных версий, то все зависимости от libpng были пересобраны. С другой стороны, libpng 1.4 есть в AUR, и ничто не мешает её установить, если кому-то надо.

И мы возвращаемся к вопросу, как весь этот зоопарк именовать.

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