[Comm] [JT] [OT] Re: 0install
Michael Shigorin
=?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Пт Мар 11 17:56:02 MSK 2005
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/
Подробная информация о списке рассылки community