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)
Ответ на: комментарий от Napilnik

Если бы так всё просто. Вася тыкнул на красивую кнопку в кутекреаторе, ...

Ну так и в результате новая прога васи не встанет на «все линупсы», и ей никто не сможет воспользоваться. Тут ничего не поделать, если ситуация зашла так далеко.

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

Но поначалу конечно, будет плохо. Но надо понимать трезво, юзеры qtcreator такую кнопку очень даже захотят. «Что бы нажал - и сразу подовселинуксы один красивый пакет111». Мы как бы говорим (я по крайней мере) про ситуацию когда редхаты+дебьян+сузе будут выносить «некритичный» софт в этот universalrepo и будут этот самый репо поддерживать в своих дистрах.

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

Ну так и в результате новая прога васи не встанет на «все линупсы», и ей никто не сможет воспользоваться. Тут ничего не поделать, если ситуация зашла так далеко.

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

В реальности же, в qtcreatore быстро сделают кнопки-галочки, «проект под universalrepo-1.3». И при попытке собрать с данной галкой ему напишет «обломись вася, нету в 1.3 таких виджетов».

Это если universalrepo появится, а пока проще использовать статичные бинарники.

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

Откуда «никто», разве сейчас любая прога для дебиана или бубунты собирается во «всех линупсах»?

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

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

Тем не менее появление «нового qt» это штатная ситуация. Собственно как мы обсуждали qt в пакете понадобится только для u...-1.3 , в u...-1.4 уже будет новый qt и ничего класть не придется.

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

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

Это если universalrepo появится, а пока проще использовать статичные бинарники.

Мы и обсуждаем что будет когда universalrepo в той или иной форме появится. Статичные бинарники это гораздо более грубое решение. Даже проприетарщики предпочитают грузить нужные библиотеки динамически чем делать статику.

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

подовселинуксы один красивый пакет

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

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

Ага, очердной повторяющий «ненужнатор». Если мейнтейнеру не нужно, то это не значит, что не нужно пользователям. Кончайте уже за всех говорить.

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

А нахрена это нужно? Из тарболов и так на любом линуксе собирается.

Прочитате дискуссию с начала. Нужно что бы не собирать на каждом линуксе с тарболов.

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

А тут патчи наложат ментейнеры этого самого universalrepo для всех дистрибутивов сразу.

А там рассматривается ситуация когда собирает автор, но не в коня корм.

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

universalrepo

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

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

Статичные бинарники это гораздо более грубое решение. Даже проприетарщики предпочитают грузить нужные библиотеки динамически чем делать статику.

Качаешь демку использующую visual c++, пытаешься запустить в хрени со вторым сервиспаком но она падает потому что, скорее всего, собрана в системе с третьим. Но зато удивительно маленький исполняемый файлик, без статики, им можно любоваться и восхищаться.

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

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

Они постоянно договариваются об общих стандартах, ващето :D

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

Ну так у них продолжится свое видение на тему того какой должен быть дистрибутив. А вот грубо говоря «сторонние пакеты», не-дистрибутивные будут такие, по новому стандарту.

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

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

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

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

Собственно почему вы считаете что пакетная система в системе должна быть одна? У нас уже расширения firefox или там pear какой нибудь - отдельные пакетные системы.

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

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

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

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

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

Я кратко описывал выше, отвечая geekless. Вкратце - посмотрите как это делают для autopackage со стороны «клиента». Со стороны сервера посмотрите на то как устроен LSB как стандарт. Дистрибуторы предоставят более широкий аналог LSB и тулчейн для сборки пакетов под universalrepo(tm), разработчики будут собирать пакеты под universalrepo(tm) тулчейном, придерживаясь определенных соглашений.

Естественно для конкретных библиотеки будут возникать свои возможные фиксы и варианты достижения совместимости, врапперы в том числе. А сам проекта universalrepo(tm) будет площадкой на которой и будут догавариватся как именно решить проблемы с той или иной библиотекой.

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

Собственно почему вы считаете что пакетная система в системе должна быть одна?

[понимаю, что отвечаю на вопрос, адресованный не мне]

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

На работе одному из коллег пришла в голову ставить на Debian Stable свежие питонные модули из pip, а не из пакетов. Вот он и поставил PIL из pip. Результат: PIL без поддержки JPEG, поскольку pip (как-бы пакетный менеджер для питонных модулей) не знает, как заставить APT (пакетный менеджер для всего остального) поставить libjpeg.

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

т.к. есть межпакетные зависимости, пересекающие границу раздела зон ответственности.

Есть такие зависимости.

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

А вот это не совсем так.

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

В вашем случае pip должен уметь запрашивать некий враппер, типа xdg-open, пусть например xdg-package, который поставит ему нужный пакет из системного репа спросив пользователя.

Собственно если копать глубже, это должно быть в настройках pip - «вышестоящий» пакетный манагер, по дефолту системный.

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

Собственно если копать глубже, это должно быть в настройках pip - «вышестоящий» пакетный манагер, по дефолту системный.

если это вдруг заработает, т.е. для внешнего наблюдателя (например, операционной системы, которая должна запускать весь установленный хлам) пакетные менеджеры будут не различимы, то согласно liskov substitution principle , pip и «вышестоящий» пакетный манагер - однотипны. в таком случае возникает вопрос: зачем нужны два пакетных менеджера, если они делают абсолютно одно и то же?

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

боюсь, что на таком уровне, с задачей справится лишь человеческий интеллект. :)

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

если это вдруг заработает, т.е. для внешнего наблюдателя (например, операционной системы, которая должна запускать весь установленный хлам) пакетные менеджеры будут не различимы, то согласно liskov substitution principle , pip и «вышестоящий» пакетный манагер - однотипны. в таком случае возникает вопрос: зачем нужны два пакетных менеджера, если они делают абсолютно одно и то же?

Когда дело касается системы, то два и не нужны. Например, у нас есть общесистемный пакетный менеджер и менеджер gem от Ruby. Существует куча пакетов для gem, но мы хотим ставить их как обычные системные пакеты. Задача решается созданием враппера, который будет конвертировать gem-пакеты в системные. При этом такой установленный пакет присутствует в обоих пакетных менеджерах.

Другое дело, когда надо выйти за пределы области компетенции системного ПМ. gem-пакеты могут стоять не только в /usr, но и в $HOME, здесь-то он нам и пригодится.

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

Задача решается созданием враппера, который будет конвертировать gem-пакеты в системные.

по сути, это совсем другая задача) и так-и - да, она худо-бедно решается. с одной стороны, есть fpm, который старается уметь конвертировать пакеты gem в во все популярные системные форматы. получается, но сами знаете как и сами знаете почему. с другой стороны, есть адаптеры внутри самих систем - cdbs, ebuild classes и т.п. - с помощью которых из gem удаётся собрать изумительные системные пакеты, правда поддержкой таких штуковин собственно и занимаются мейнтейнеры на протяжении всего своего рабочего времени, между релизами)

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

Будет ли такой сферический universalrepo подразумевать возможность выбора префикса на этапе установки пакета?

Мне кажется что было бы разумней выбирать префикс на этапе настройки инстанса этого universalrepo .

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

Мне кажется что было бы разумней выбирать префикс на этапе настройки инстанса этого universalrepo .

Ну или так. Суть однако ж в том, что пакету придётся быть перемещабельным.

Я тут подумал-подумал, и всё же реализация пакетов в зироинсталл мне кажется более удачной. Общий кэш пакетов в /var/cache/0install.net/implementations и конфигурация «установленных» пакетов в хомяке конкретного пользователя.

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

Такая организация позволяет сделать полноценный централизованный «ЛинуксМаркет» (как конкретный сервис на конкретном домене) со всеми ништяками, и в то же время даёт возможность ставить софт с любых url при необходимости.

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

Такая организация позволяет сделать полноценный централизованный «ЛинуксМаркет»

Вот скажите, почему вы считаете что «ЛинуксМаркет» должен быть обязательно централизованный? :D

(Вообще конечно что меня в этом всем веселит, так это попытка трактовать слова Инго в рамках собственных пещеных представлений в голове, и страхов. Ужас прямо какой то. Один Айлавмикрософтчик чего стоит.)

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

Централизация маркета в случае яббла (и частично гугла) это исключительно банальное следствие контроля ключевых точек одной компанией которая за всем этим стоит. То есть следствие логики развития, была компания Х, которая сначала контролировала все, потом она «отдала» все(или многое) кроме определенных ключевых точек.

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

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

Более того как вы хотите в 0install - это *неотрываемая* завязка на энторнет. Репозиторий в отличие от 0install распределенной помойки можно закешировать локально. Собственно у федор-редхатов даже разбиение на диски их этих соображений сделано, сколько раз замечал и радовался. Обычно если вы ставите внешние пакеты то чаще всего библиотеки к этим пакетам уже давно лежат в основном первом диске дистрибутива. И чаще всего если вы принесли «на дискетке» на ситсему без интернета некий софт, то он чаще всего прекрасно ставится yum localinstall, разрешая зависимости из хзакешированного репозитория дистрибутива.

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

Я не «считаю, что „ЛинуксМаркет“ должен быть обязательно централизованный» и не «трактую слова Инго в рамках собственных пещеных представлений в голове, и страхов». Я рассматриваю ситуацию с точки зрения разработчика/мейнтейнера программы и с точки зрения пользователя.

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

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

2. Пусть я разработчик. Я прихожу на «ЛинуксМаркет» и регистрирую там свой продукт. И, в зависимости от продвинутости сервиса, получаю определенный набор возможностей: от возможности дать 100500 пользователям трёх разных систем устанавливать мой пакет в простом случае, до автоматических сборок релизов или даже текстовых ночных пересборок в случае продвинутого сервиса. Удобно? Удобно.

3. Пусть я разработчик. Я в гробу видал маркет по каким-нибудь своим соображениям. Я выкладываю на своем домене xml-интерфейс пакета, и любой зашедший пользователь может установить мою программу всё тем же одним кликом. Удобно? Удобно.

На что ты так возбудился, я не понимаю. Это всё ровно то, о чем говорил Инго.

Это же очевидно, что каждый пилит пакеты для community-репозитория своего дистрибутива только в силу несовместимости дистрибутивов. Если Вася уже опакетировал точно такой же софт, то зачем напрягаться. Поэтому из условий задачи создание такого маркета вполне неизбежно.

Я вам привел аргумент почему распространять библиотеки во внешних пакетах universalrepo это плохо: сразу расплодятся либо стопистот дублирующих библиотек либо расплодятся глюки.

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

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

Более того как вы хотите в 0install - это *неотрываемая* завязка на энторнет.

Ты не прав. Щас объясню, почему.

Репозиторий в отличие от 0install распределенной помойки можно закешировать локально.

Понятие репозитория исчезает на «линукс маркете», потому что закешировать весь объём софта с него — надорвёшься. Зато появляются частные репозитории: «группы», «избранные пакеты», «30 лучших приложений на gtk», «все почтовые клиенты, умеющие $coolfeaturename», «всё, что нужно дизайнеру» и т.п. Тот самый юзер-генерейтид контент, да. Пользователи сами его сделают, это то место, где граница между пользователем и мейнтейнером исчезает. Если тебе надо закешировать какой-то набор пакетов а ля «куча приложений на kde для типичного десктопа», просто даёшь команду 0store http://адресфида и ждёшь полчаса, пока всё скачается вместе с зависимостями. После чего достаешь пакеты из хранилища, из другого каталога достаешь кэш закачанных фидов, нарезаешь всё это на болванку и получаешь тот самый «репозиторий на диске». Переопределить правила ПМ так, чтобы он сначала смотрел в отдельный «внешний» кэш пакетов, а уже потом лез в инет — это вообще простейшая вещь — даже если сейчас не реализована в зироинстале, допиливается за пару вечеров.

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

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

s/не модераторы пропустят/модераторы не пропустят/

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

Я не «считаю, что „ЛинуксМаркет“ должен быть обязательно централизованный»

Замечательно считаешь... якобы. А теперь читаем:

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

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

То есть вот он, централизованный линксмаркет, кушать подано :trollface:

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

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

Просто потому что структура линукса - распределенная. Любые совместные действия это договор равноправных субъектов.

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

Предметом договора по факту будет слой совместимости (ABI) и стандарты на «единый пакет». При этом метод реализации - это область ответственности дистрибуторов. Вплоть до наличия реализаций universalrepo для дистрибутива X не от дистрибутора - в связи с тем что дистрибутор «жистоко нинавидит» universalrepo.

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

Субъектами договора будут флагманы-дистрибуторы и коммунити - поставщики типа( libreoffice). Арчик не пригласят, гентушечку тоже.

И все. Вот слой совместимости, вот единая таксиномия пакетов (pidgin это и тут и там pidgin), вот общие соглашения по поиску, что бы на вопрос «хочу пидгин» гугл выдавал разные, но universalrepo пидгины. Все остальное - от лукавого.

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

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

А вот договариваться на тему каждого пакета в этом универсальном репозитории - нереально. И не будет этого.

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

Если следовать твоей логике, то и AUR-а не существует, потому что «договариваться на тему каждого пакета в этом универсальном репозитории - нереально».

До тебя никак не дойдёт, что ты используешь неправильную модель. С точки зрения участия в проекте, проект децентрализован: захотел добавить пакет, добавил. Всё.

От AUR-а в плане установки пакетов он отличается только тем, что:

1) совместимость гарантирована на уровне ABI, а не API, поэтому не нужно собирать пакеты на целевой машине.

и

2) совместимость не привязана к конкретному дистрибутиву.

Если угодно, «одобрение модератором» — это переход из AUR в community, в «доверенную зону».

[code]pacman -Sl community | wc -l 2397 [/code]

Ты хочешь сказать мне, что эти 2 тыщи пакетов — «в моих влажных мечтах»? Заметь, это всего лишь дистрибутив-конструктор для гиков, а не платформа для дистрибьюции софта на весь гнулипус. Даже сравнивать нечего — если будет такая платформа, туда сразу влетят 10000 пакетов, а не 2000.

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

Именно. Предмет договора максимально узкий: спецификация ABI (подмножество LSB) + zeroinstall-injector. ВСЁ. Сравни со своими влажными фантазиями про систему сборки, позволяющую собирать 100500 «разных, но одинаковых» пакетов под 100500 дистрибутивов. Как, еще один autotools? На этот раз совмещенный с пакетным менеджером? «Нахер нужно скажем дружно» — подумают в каком-нибудь дебиане, и весь твой unirepo отправится на юх.

При этом метод реализации - это область ответственности дистрибуторов. Вплоть до наличия реализаций universalrepo для дистрибутива X не от дистрибутора - в связи с тем что дистрибутор «жистоко нинавидит» universalrepo.

Именно. Если какой-нибудь абстрактный Школололинукс «жистоко нинавидит» наш проект, то всё равно находится какой-нибудь энтузиаст, который собирает все нужные для обеспечения совместимости с LSB пакеты + пакетирует zeroinstall-injector. И опять: ВСЁ! На Школололинукс стало можно ставить наши пакеты, пойте и пляшите!

Замечательно считаешь... якобы. А теперь читаем:

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

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

Ты хочешь сказать мне, что эти 2 тыщи пакетов — «в моих влажных мечтах»?

Ага. Более того - ты сам это говоришь.

(А приводить в пример дистрибутив - бред. Дистрибутив - «кафедральный собор». Там есть иерархия и нет договора ранвоправных субъектов )

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

Вот тут ты это говоришь, что «влажные мечты» сплошные. Потому что «это всего лишь конструктор для гиков» это и есть - ниочем.

Именно. Предмет договора максимально узкий: спецификация ABI (подмножество LSB) + zeroinstall-injector. ВСЁ.

Кого пускать в доверенные а кого нет - вот и место где не договорятся. Возникнет куча «доверенных» иерархий.

Сравни со своими влажными фантазиями про систему сборки, позволяющую собирать 100500 «разных, но одинаковых» пакетов под 100500 дистрибутивов.

Ну и где я такое предлагал? :D

Именно. Если какой-нибудь абстрактный Школололинукс «жистоко нинавидит» наш проект, то всё равно находится какой-нибудь энтузиаст, который собирает все нужные для обеспечения совместимости с LSB пакеты + пакетирует zeroinstall-injector. И опять: ВСЁ! На Школололинукс стало можно ставить наши пакеты, пойте и пляшите!

Вот если вкратце относительно твоей схемы я «предлагаю» (а точнее считаю более разумным, так сам пока ничего не предлагаю - слишком сложная задача. А вот 0install я считаю школьной игрушкой для школьников с энторнетами :D ) :

а) будет расширение базы LSB на тему стабильного ABI. Именно это я называю условным universalrepo 1.3 и из за чего возникает путаница.

б) Это расширение базы LSB будет по репозиторному принципу. К этому будет стандартный интерфейс, шелл в том числе. Будет стандартизированная таксиномия пакетов/фич для этого «репозитория» ABI. То есть да, это по репозиторий. Но никакого прикладного софта там не будет. Только библиотеки. Назовем этот репозиторий universalrepo-system

в) внутри будет сильно стандартизированная таксиномия пакетов. То есть(пример) universalrepo-1.3::libcoollib-1 - это тег ABI.

То есть некий пакет сможет «сказать» universalrepo-feature libcoollib-1 и дистрибутив ему его предоставит. Как это сделает дистрибутив не важно - это дело дистрибутива. Он может например предоставить враппер который уже и будет напрямую слинкован с дистрибутивной реализацией libcoollib-5.2.34, но которая бинарную совместимость не держит.

г) задача подбора софта в universalrepo-system - это обеспечить максимальное удовлетворение зависимостей прикладного софта.

Грубо говоря - расширенное LSB , у которого вместо одного LSB-1.1 некий внутренний репозиторий. Который обеспечивает дистрибутив. Федора(и вообще редхаты) кстати примерно так внутри и построена.

«Клиентская часть»

Есть «пакеты», сборки, бинари в архиве собранные с тегом совместимости universalrepo 1.3 . Или , действительно, пакеты в некоем условно новом формате с новым расширением.

Множество этих пакетов - ДРУГОЙ репозиторий, а точнее вообще НЕ РЕПОЗИТОРИЙ. Тут никаких зависимостей. Никаких идиотских плясок с 0install в случае отсутствия интернета. Просто некие пакеты... в принципе в любом пакетном формате. Все дополнительные библиотеки таскают с собой.

И та же схема как и у тебя - собирают под дистрибутив universalrepo-system , и можн оставить universalrepo-x.x пакеты под дистр. Пакеты совместимые с тегом universalrepo-x.x собирают один раз, один пакет с бинарями под все дистры.

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

И данная схема НЕ ПРЕДНАЗНАЧЕНА для решения всех мировых проблем линукса с точки зрения вендошкольника узнавшего про линукс, как пытается сделать школоло-0install. Она предназначена для того, что бы софт вроде инксейпа или там другой прикладной софтины, не имеющей в зависимостях стопитсот пакетов, можно было просто поставить и она бы просто заработало.

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

То есть нах** не нужен этот самый «общий случай» никому кроме фанатов 0install.

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

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

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

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

ты предлагаешь путь в никуда.

Я предлагаю решать проблемы одну за другой, а не методом «сразувсепорешаем».

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

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

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

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

а нужна именно помойка.

Ну это вам же нужна помойка.

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

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

При этом вы вообще ничего не предлагаете кроме лозунгов про то что «надо двигаться в сторону 0install» которым по факту никто кроме 2.5 гиков не пользуется.

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

Кого пускать в доверенные а кого нет - вот и место где не договорятся. Возникнет куча «доверенных» иерархий.

Пусть будут. В том и плюс, что данная система как целое абсолютно не страдает от того, будет одно уважаемое всеми место, или нет.

[много букв о universalrepo]

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

1. Как идентифицировать пакеты и как их обновлять. Система-то децентрализована, ага. Тебе ВСЁ РАВНО придётся при каждом пакету указывать url, с которого он обновляется. Так может проще сразу связать эти понятия: имя пакета и url — и не парить мозг?

2. Что делать, когда таких пакетов в системе будет не 5, а 55? Пользователи начнут задаваться справедливым вопросом «а где мои гигабайты, бро?», и это проблему тоже всё равно придётся решать.

3. Но еще раньше чем пользователи, спохватятся админы. Ты ведь все компоненты ПО по сути разделил на «граждан» первого и второго сорта. Видишь ли, раньше админ мог заменить проблемную библиотеку, и проблема исчезала во всех приложениях. А теперь ему предётся ручками пересобрать неизвестное число пакетов. (Предварительно теми же ручками выяснив, в какие вообще пакеты входит эта библиотека.) «Отсутствие зависимостей — очень удобная штука для вендошкольника», — скажет тебе админ, — «но не могли бы вы со своими вендоидеями пойти отсюда нахрен?» Добро пожаловать обратно, наш старый друг "./confugure && make && sudo make install".
И эту проблему — удивительно — всё равно придётся решать.

А беря твою систему и прибавляя к ней эти два требования, мы получаем, внезапно, систему эквивалентную — по функциям и архитектуре — 0install-у. Ну просто таково направление внутренного развития такой системы.

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

И данная схема НЕ ПРЕДНАЗНАЧЕНА для решения всех мировых проблем линукса с точки зрения вендошкольника узнавшего про линукс, как пытается сделать школоло-0install.

Да ты что? Перечисли, пожалуйста, КАКИЕ ИМЕННО проблемы школолоника решает 0install, помимо тех, которые мы тут с тобой мусолим?

То есть гипотетический случай софта который требует орду зависимостей которую потом будет использовать какая другая программа - так вот этот случай идет лесом.

Ага. Очень гипотетический случай.

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

Я тебе страшную вещь скажу: в 0install ВСЁ ЕЩЕ ПРОЩЕ. Там софт даже ставить не надо.

Ну и что касается энторнетов, ты пытаешься решать проблему, которая вот уже несколько лет как не актуальна. Отсутствие энторнетов это настолько маргинальный случай, что на него можно просто забить. Тем более, что «репозиторий на диске» для 0install архитектурно вообще ничем не отличается от аналогичного репозитория для deb. Так что проблема изначалаьно полностью высосана из пальца.

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

за абсолютной помойкой скрывается жесткое ABI

«жесткое ABI» как бы само собой подразумевающаяся вещь к подобной системе пакетирования.

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

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

Я такие речи слышу с 90-х. После каждого нового всплеска развития технологий связи. Старое доброе «проблему ОЗУ мы решили^W^W^W 640 кб хватит всем»

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

Вот и я и говорю - школьники с энторнетами. Типичный их образ мыслей. Просто иллюстрация. Как и пример такого образа мыслей ниже.

Тем более, что «репозиторий на диске» для 0install архитектурно вообще ничем не отличается от аналогичного репозитория для deb.

Ну и реально, часто ты чтото там для 0install кешировал ... ах да - ты же уже написал что во первых «если этого нет то можно доработать», то есть ты даже не знаешь есть ли это кеширование хоть во сколько то годном формате. А во вторых это «не нужно так как несколько лет это уже не проблема». Какое то сплошное «Мы теоретики считаем что наша теория ничем не отличается от практики».

Ты хоть понимаешь насколько это по идиотски звучит для всякого кто не является этим самым школьником с энторнетом?

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

Ты долго говорил но опять пришел к «Так что проблема изначалаьно полностью высосана из пальца.» При этом, ИЧСХ, тот же редхат об этой проблеме думает, например.

Я тебе страшную вещь скажу: в 0install ВСЁ ЕЩЕ ПРОЩЕ. Там софт даже ставить не надо.

Фейспалм. Только пользоваться вундервафлей никто не хочет :D

PS

И случай энторнета дорогого тоже не рассматриваем? Спутниковый там? :D Ты расценки на спутниковые линки видел, не те которые длябыдлоса+, а двунаправленные? :D А gprsы всякие, 3g хреновые, с ними что делать? Пропадание основного канала? :D

А *медленный* энторнет тоже не рассматриваем? :D Так как везде быстрый есть? :D

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

«жесткое ABI» как бы само собой подразумевающаяся вещь к подобной системе пакетирования.

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

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

Если это очевидно, тогда в чем пафос?

Если же он предлагает перейти к 0install'ам и от любого рабства, в том числе дистрибутивного, отказатся, тогда как будет поддерживатся это самое «жесткое ABI»? А никак - умалчивает онон этот момент.

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

У тебя очередное обострение школолоболезни, выпей таблетку.

Старое доброе «проблему ОЗУ мы решили^W^W^W 640 кб хватит всем»

Если для тебя не очевидно, чем ресурс ОЗУ отличается от ресурса доступа в интернет, тут даже разговаривать не о чем. Впрочем, ты ж не тупой, ты просто придуриваешься.

Ты хоть понимаешь насколько это по идиотски звучит для всякого кто не является этим самым школьником с энторнетом?

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

то есть ты даже не знаешь есть ли это кеширование

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

Фейспалм. Только пользоваться вундервафлей никто не хочет :D

Твоей воображаемой системой тоже никто пользоваться не хочет. Знаешь, в чем отличие? Зироинстал кто-то хотя бы реализовал.

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

Лол, ты бы еще ABI ядра рабством назвал. А уж про спецификацию системы команд процессора и вообще страшно вспоминать — натуральное рабство!

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

В том и плюс, что данная система как целое абсолютно не страдает от того, будет одно уважаемое всеми место, или нет.

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

Т.е. по сути ты предлагаешь то же самое, вид сбоку.

Я по сути предлагаю решать проблемы по одной. И из этого исходить.

А ты (и прочие борцы за счастье всего человечества) предлагают решить все разном, «и чтобы никто не ушел обиженным».

1. Как идентифицировать пакеты и как их обновлять. Система-то децентрализована, ага. Тебе ВСЁ РАВНО придётся при каждом пакету указывать url, с которого он обновляется. Так может проще сразу связать эти понятия: имя пакета и url — и не парить мозг?

А может когда решим проблему ABI, и таксиномии пакетов, вы, фонаты 0intstall поконкурируете с другими решениями на общих основаниях?

Я например считаю что гораздо больше не хватает нормальной мультидеревности пакетов и дистрибутивов нескольких уровней. Что бы были например дистрибутивы 1 уровня - федоры/дебьяны/сузе/убунту, а были *поверх* них, дистрибутивы второго уровня, прикладные. Например, условно, дистрибутив «художников». Который бы я мог поставить на дебьян/федору/убунту.

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

2. Что делать, когда таких пакетов в системе будет не 5, а 55? Пользователи начнут задаваться справедливым вопросом «а где мои гигабайты, бро?», и это проблему тоже всё равно придётся решать.

И пусть задаются. И пусть будет конкуренция за решения.

3. Но еще раньше чем пользователи, спохватятся админы. Ты ведь все компоненты ПО по сути разделил на «граждан» первого и второго сорта.

А это не я разделил - они всегда были разделенные. Просто одни были в FOSS организационно оформленны (дистрибутивы), а другие - нет. И это была в FOSS проблема - ISV сектор был абсолютно незначителен. В отличие от проприетарщиков где это основная масса софта.

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

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

Ну то есть мы уже говорим об проблемах одмина гентушечки на локалхостике и прочих «i like to move it, move it»^W^W^W"i like to make compile, make compile"?

«Отсутствие зависимостей — очень удобная штука для вендошкольника», — скажет тебе админ, — «но не могли бы вы со

Речь идет, как я понимаю, об плюшевом одмине сурового арчика? :D

своими вендоидеями пойти отсюда нахрен?» Добро пожаловать обратно, наш старый друг "./confugure && make && sudo make install".

И эту проблему — удивительно — всё равно придётся решать.

А тут мы внезапно вспоминаем крайне веселую вещь сказанную Инго... «да, для корпоратива текущая схема в линуксе неплоха» :D

Я тебе даже еще одну замечательную вещь скажу, никто же не мешает дистрибутору засунуть в свои каналы обновления, О УЖАС, бинарные пакеты собранные не ими... И в этих обновлениях, делтарпм'ами юзеры все обновления и придут.

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

А беря твою систему и прибавляя к ней эти два требования, мы получаем, внезапно, систему эквивалентную — по функциям и архитектуре — 0install-у.

Дадада. Именно по этому форсишь 0intall на ЛОР только ты, при чем узнал ты о нем относительно недавно :D Даже емнип я твой комент видел, «о какая классная система 0install, не знал».

Ну просто таково направление внутренного развития такой системы.

Это твое мнение.

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

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

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

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

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

Мечтали о децентрализованности? Получите, распишитесь.

Хотя ты конечно можешь дальше делать вид, что я «праигнариравал» и тэпэ.

Я по сути предлагаю решать проблемы по одной. И из этого исходить.

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

А ты (и прочие борцы за счастье всего человечества) предлагают решить все разном, «и чтобы никто не ушел обиженным».

Лично меня вообще не колышет счастье всем даром и прочий бред а ля «вендоюзер не нашел setup.exe в злом линуксе». Есть интересная техническая задача — я её рассматриваю. Считай это таким упражнением для ума.

А может когда решим проблему ABI, и таксиномии пакетов,

О, а вы желаете всерьёз её порешать? Ссылку на сайт проекта, сестра!
Нет, серьёзно. Вопрос ABI — это интересно. Где?

вы, фонаты 0intstall поконкурируете с другими решениями на общих основаниях?

Синтаксис и логику ты нарушаешь столь же целеустремленно, как и арфаграфею? «Фонаты покункурируют с решениями»? А инженеры с холодильниками у тебя не конкурируют?

Бред какой. «админ мог заменить библиотеку» это к суровым админам локалхоста и прочим школьникам. О корпоративе заботятится его платный апстрим с суппортом, который делает ему апдейты. Ну то есть мы уже говорим об проблемах одмина гентушечки на локалхостике и прочих «i like to move it, move it»^W^W^W"i like to make compile, make compile"?

Картина маслом: суровый админ локалхоста впервые в жизни услышал про обновления безопасности. Ты наверное и софт при помощи make install ставишь на боевой редхат? Если да, то скажи название конторы, чтобы не связываться с вами никогда.

Дадада. Именно по этому форсишь 0intall на ЛОР только ты, при чем узнал ты о нем относительно недавно :D Даже емнип я твой комент видел, «о какая классная система 0install, не знал».

Догадываюсь, что ты кроме варианта развития событий «ознакомился и офонател», с прочими не знаком. Вынужден тебя разочаровать, есть люди, которые рассуждают не в категориях «$productname хароший», а в категориях «вот список требований, какие из продуктов ему соответствуют?»

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

Если для тебя не очевидно, чем ресурс ОЗУ отличается от ресурса доступа в интернет, тут даже разговаривать не о чем. Впрочем, ты ж не тупой, ты просто придуриваешься.

Я тебя внимательно слушаю - чем конкретно?

Что я слышу — неужели баттхерт школьника без интернета?

...

То есть то что за исключением узкой полосы цивилизации рядом с кабелем энторнеты доступны далеко не всем до тебя таки не доходит.... понемаю. Это поколение ЛОРовцев второй половины двухтысячных такое забавное.

Твоей воображаемой системой тоже никто пользоваться не хочет. Знаешь, в чем отличие? Зироинстал кто-то хотя бы реализовал.

«И обида чувствовалась в его голосе ...»

«Моя» система не моя - это некий минимум для стандартного ABI. Будет ли вообще этот ABI - не моя забота, это там дистрибуторы будут пилить или не пилить. Пока они пилят .desktop файл для таксиномии пакетов, плевать хотели на твой 0install .

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

Лол, ты бы еще ABI ядра рабством назвал.

Это к онониму, на пост которого я отвечал.

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

Хотя ты конечно можешь дальше делать вид, что я «праигнариравал» и тэпэ.

Ты упорно игнорируешь тот факт что «два класса пакетов» это реальность. Есть пакеты на которые все завязано, которые используют «все». И есть пакеты используемые узким кругом лиц в своих условиях, всякие прикладные.

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


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

Фейспалм. Вот от таких чотких дерзких заявлений у меня наступает приступ ололошкололобоязни - я вижу в собеседниках безумное школоло. Впрочем средний админ хостинга например, от этого не лечится и лет в 25 ... просто ЧСВ растет. :D

В данном случае, и готовое решение уже есть, и проблемы вполне очевидны.

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

Поэтому нормальный человек в такой ситуации просто берёт готовый инструмент и не страдает NIH-синдромом.

Судя по распространенности «нормального» инструмента - NIH синдром всех победил.

Лично меня вообще не колышет счастье всем даром

Имелось в виду что желание порешать все и сразу это оно и есть «счастье всем и даром»

О, а вы желаете всерьёз её порешать? Ссылку на сайт проекта, сестра! Нет, серьёзно. Вопрос ABI — это интересно. Где?

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

Синтаксис и логику ты нарушаешь столь же целеустремленно, как и арфаграфею? «Фонаты покункурируют с решениями»? А инженеры с холодильниками у тебя не конкурируют?

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

Картина маслом: суровый админ локалхоста впервые в жизни услышал про обновления безопасности. Ты наверное и софт при помощи make install ставишь на боевой редхат? Если да, то скажи

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

Дадада, а в контору где «админ мог заменить библиотеку» ты конечно обратишься. :D Нуну. Кстате по поводу перекомпиляций было в твоей мессаге, ага? Проецируем на меня свои страхи, вдруг кто о твоем make install узнает? :D

Догадываюсь, что ты кроме варианта развития событий «ознакомился и офонател», с прочими не знаком.

Ну в твоем случае это так и выглядит.

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

У нас спор по поводу списка требований. Он у тебя вытекает из твоей уверенности (в том числе) что энторнеты есть везде. О том что их на серваке может не быть потому что в организации в этом месте энторнет не предусмотрен например, ты не задумываешься.... что о тебе многое говорит :D

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

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

Т.е. нигде. Что и требовалось доказать. Не воспринимай слишком серьёзно болтологию на ЛОРе, ага?

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

У нас спор по поводу списка требований. Он у тебя вытекает из твоей уверенности (в том числе) что энторнеты есть везде. О том что их на серваке может не быть потому что в организации в этом месте энторнет не предусмотрен например, ты не задумываешься.... что о тебе многое говорит :D

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

Но если до тебя не дошло дважды, повторю уж в третий, может дойдёт:

Для любой системы пакетной системы с зависимостями процесс оффлайнового обновления выглядит совершенно одинаково. Поэтому будет там зироинсталл, или rpm, или черт с копытами, для «сервака без энторнета» не меняется ровным счётом ничего.

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

Т.е. нигде. Что и требовалось доказать. Не воспринимай слишком серьёзно болтологию на ЛОРе, ага?

Если чо, LSB уже есть :D

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

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

Это вы тут говорите про другую вещь. Мы же говорим что эта вещь затронет и этих самых «нещастных админов» и это надо понимать. И кстате тот же редхат, например, это прекрасно понимает.

Для любой системы пакетной системы с зависимостями процесс оффлайнового обновления выглядит совершенно одинаково. Поэтому будет там зироинсталл, или rpm, или черт с копытами, для «сервака без энторнета» не меняется ровным счётом ничего.

Очередной разговор безумного теоретика с практиком. Я в отличие от тебя имел возможность сравнивать с autopackage, например. Которой работает примерно так же в области «все выкачаем» как и 0install. Решил посмотреть как оно будет в эксплуатации, что бы составить свое мнение не на основе влажных фантази о «протестированном решении 0install» а на основании своего непосредственного опыта. И для себя сделал вывод что использовать это не буду. И никто кто решает схожие задачи - не будет.

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

Но если до тебя не дошло дважды, повторю уж в третий, может дойдёт:

Ты бы лучше не повторял три раза, а слушал бы три раза. Может быть что нибудь дошло.

0install не теоретически а практически демонстрирует вполне определенный менталитет разработчиков, и их пользователей. Менталитет далекий от любого реально использования линукса кроме как «поигратся»(ну или как r упоминал - «безумных улутшаторов»)

При чем ты мне, самое что смешное, пытаешься доказать что это не так, используя сугубо теоретические аргументы из набора этого образа мышления. Вроде «уже пару лет проблем с интернетом нету».

При чем ситуация с энторнетом, в «последнюю пару лет» изменилась только на территории РФ(точнее части постСССР) при чем только для физлиц.... Изменение в том что xDSL добрался таки до масс в городах РФ, не только в мск плюс 3g стал хоть как то заметен. А в мировом масштабе все осталось ровно как и было. :D

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

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

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

разговор безумного теоретика с практиком

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

И кстате тот же редхат, например, это прекрасно понимает.

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

Для справки: я никогда не призывал и не призываю завязываться на конкретную реализацию, т.е. на 0install. Как я уже говорил, есть список требований, и есть софт, которые ему соответствует. Если у этого софта имеются серьёзные недостатки, отличные от «его придумали не в редхат!!!1111», которые невозможно пофиксить в разумные сроки, я их с интересом выслушаю.

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

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

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

Когда ты троллил на тему makeinstall это было не высасывание из пальца, нет-нет ...

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

Что тебя тут удивляет? Ваш полет мысли «жутко бесит...»(С)

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

То есть что, 0install никто " реальных условиях никто не применял, не применяет и в обозримом будущем применять не собирается"? Тогда зачем столько пафоса? А как же твой риторический вопрос «почему же не применяют?»

За пределы потока сознания про «демонстрирует вполне определенный менталитет разработчиков» ты выйти не способен?

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

То же самое в случае autopackage моментально упирается в то, что теперь у нас любой поставленный «пакет» тянет кучу дополнительных пакетов плюс это еще и меняется. И каждый сборщик естественно тянет использовать «свую теплую, ламповую» сборку библиотеки. Далее, сборщиков много, политики дистрибутива над ними не довлеют - на случай «не инета/есть gprs» им плевать.


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

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

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

PS
А вообще да, спор идет «не о том». Тут проблема лежит в социально-экономической плоскости.

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

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

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

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

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

Да и черт с ними. Вот у тебя машина с толстым каналом и есть машина вообще без интернета за тридевять земель. Что ты сделаешь, чтобы притащить туда обновления пакетов unirepo? В случае с твоим вариантом, ты скачиваешь пакеты, едешь, обновляешь. В случае с моим вариантом, ты... скачиваешь пакеты, едешь, обновляешь. Какая разница? Никакой разницы. Тебе будет вообще не важно, 1 там архив на одну «программу» или несколько, если тебе не приходится их руками все выкачивать.

У тебя будет, допустим, одна команда вида cachepkg -o /some/path package1 package2 package3 package4 для для создания локального репозитория и еще одна вида mergepkg -o /var/cache/pkg /some/path для переноса его «с флешки на целевую машину». Где в этом сложность, объясни?

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

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