[Comm] [JT] [OT] Re: 0install

[Michael Shigorin]

PreScriptum: просьба ни в коем разе не воспринимать лично;
подобные рассмотрения пишутся из соображений "слишком много шишек
об это набито будет", но не стоит злоупотреблять -- вещей, об
которые можно успешно набивать шишки, в мире и так многовато.

On Fri, Mar 11, 2005 at 04:53:11PM +0300, Arioch wrote:
> >Потому что вероятность пролома авторской странички и
> >нормальным образом охраняемого репозитория в большинстве
> >случаев несопоставимы.  
> Черт с ним с проломом. При организации этой сети по
> p2p-принципам это будет быстрый пожар, который так же быстро
> будет потущен когда появится флаг типа fake а потом и возвратом
> контроля над страничкой.

Это такая же демагогия, как у автора 0install, уж простите.

> Только загрузка аптового индекса дооолгая, однако :-)

Это зависит от объёма репозитория.  Думаете, все такие
велосипедики не прекращают шустрить, как только задачи начинают
отличаться от "две софтинки, три пользователя в мире"?

> >В таком случае точно так же сломаются как приложения с
> >разделением привилегий и использованием chroot() -- типичные в
> >дистрибутивах, где вообще думают о безопасности, так и
> >suid/sgid -- которые также критичны для выполнения многих
> >задач системного и коллаборативного плана.
> Учитывая, что 0install принципиально не работает от рута, такие
> приложения оно и не сможет поставить.

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

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

Так эти проблемы не решаются 0install.  Зато определённо
создаются.

> >Потому что "without even checking the original sites for
> >updates" гарантирует то, что все дырки -- у пользователя,
> >который не занимается с утра до ночи перекэшированием
> >натянутого и используемого барахла.
> Чем это отличается от,например, Сизифа?

Интегральностью операции обновления и автоматизируемостью
проверки статуса.  См. тж. alt-update или как его теперь зовут.

> Тем более, что настолько общие библиотеки будут в дистре почти
> 100% а вот более разнообразный программы - с ними сложнее.
> Не даром на листе периодически раздается: а почему нет ХХХХ? А
> некому, хотите - займитесь!

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

> >Добавим к этому милую иллюстрацию "софтинка A собирается
> >автором с glibc-2.3 и NPTL, а библиотечка B, которая ей нужна
> >-- в авторской сборке с glibc-2.2". 
> Не факт что это приведет к граблям, все зависит от отношений а и б.

А потом удивляются, почему такие поделки встречают такой приём.
Вы попробуйте на досуге скрестить RH7.3 и RH9, а там продолжим.

> ЗАто можно запустить сейчас и начать неспещно пиать автора
> насчет апгрейда :-)

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

> >Re "What about package conflicts?" -- так убиты не только
> >конфликты, но и совместное использование ресурсов.  Причём вся
> Вот это не так. Не знаю, как насчет ram, но насчет traffic/disc
> это не так.

Да, уже перечитал и ту часть повнимательней.  Стало много
веселее: один пользователь может устроить засаду другому,
поставив заведомо нерабочую версию. :]

Вообще это модель безопасности, напоминающая чем-то /tmp.
А /tmp -- это одна из фундаментальных грабель в UNIX.

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

Да.  А rpm можно проинструктировать не выполнять скрипты и
триггеры.  Ну и?

> Копирование же файлов с кодом формализуется и насчет раздачи
> прав

Положим.

> и насчет кто-куда-зачем

Не обнаружил ничего интересного и _формализованного_.
Граблеобразующего, начиная с вполне легитимных host aliases,
которые технически не отслеживаются -- дофига.

> и насчет зависимостей.

См. выше про версионирование библиотечных символов.

> >>Для юзерских программ типа FireFox, Gaim и т.д. это вполне
> >>себе решение.
> >См. выше про библиотеки.  Интересно, как скоро они аккурат в
> >гномьем хозяйстве с его (неплохой в случае грамотного применения)
> >склонностью к обширной библиотекизации наткнутся на ВИЛЫ.
> Так же часто, как их приходится разруливать в репозиториях.

В репозиториях это автоматизируется и потери времени
централизуются.  Здесь же время теряется распределённо, вот
только скорее не делится, а множится.

> В среднем же все проги будут примерно одновременно плавно
> дрейфовать на новый релизы.

На чём основывается это предположение?

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

Трёп.  Кто этим будет заниматься?

> Опять же, сам вспоминал пример с glibc 2.2 и 2.3

Это не bug compat.  Это slow migration, причём с поводом.

> >>Интересно, зачем он заводил lazyfs? Или тогда еще не
> >>существовало tmpfs?
> >Эти безумные гномятники вечно изобретают велосипеды без
> >остановки на подумать.  Начиная прям с gtk+.  Ну и флаг им в
> >пятку.
> Еще и GTK под раздачу попал :-)

А то надо было придумывать gtkrc :(

> М.б. тогда и D-BUS прибить и udev ? :D

Не знаю, туда практически не лазил.  udev к ним отношения прямого
не имеет AFAIR, вот dbus -- не знаю.

PS: выгоняйте меня в talk-room@ :)

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/