From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 11 Mar 2005 16:56:02 +0200 From: Michael Shigorin To: community@altlinux.ru Message-ID: <20050311145602.GS7719@osdn.org.ua> Mail-Followup-To: community@altlinux.ru References: <4230372A.3010806@list.ru> <085c01c5256b$90d713f0$8fa4210a@ksf720> <20050310190759.GL7719@osdn.org.ua> <20050311120347.GE7719@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: [Comm] [JT] [OT] Re: 0install X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 14:56:08 -0000 Archived-At: List-Archive: List-Post: 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 ------ Linux.Kiev http://www.linux.kiev.ua/