From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 11 Aug 2004 17:51:37 +0300 From: Michael Shigorin To: community@altlinux.ru Message-ID: <20040811145137.GD6334@osdn.org.ua> Mail-Followup-To: community@altlinux.ru References: <1852459075.20040807182644@post.ural.ru> <4118F9D3.8060305@altlinux.ru> <200408111201.08811.ngrechukh@ua.fm> <4119EF8E.9060603@interlot.ru> <20040811102848.GB11726@ujo.office.sema.ru> <411A05B2.9000601@interlot.ru> <20040811115513.GA6334@osdn.org.ua> <411A1A9B.2010900@interlot.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <411A1A9B.2010900@interlot.ru> User-Agent: Mutt/1.4.2.1i Subject: [Comm] =?koi8-r?b?Is7FINfJzs/XwdTB0SDRISIgKGMpIGFwdCAod2FzOiD+?= =?koi8-r?b?1M8g99kgz8Ig3NTPzSDE1c3BxdTFLik=?= 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: Wed, 11 Aug 2004 14:51:49 -0000 Archived-At: List-Archive: List-Post: On Wed, Aug 11, 2004 at 05:09:47PM +0400, Roman Savelyev wrote: > >В /usr vs /usr/local или /opt > Кто гарантирует, что секурити-фикс в libc или zlib, аль > security-update того ядра (с какой-нибудь гадостью Попробую угадать. security-update не лезет за пределы своего кусочка /etc, /usr, /var (обычно; автоматизируемо) или /boot и /lib/modules (в случае ядра; сами понимаете, без автомата). Далее, Вы не обязаны их прикладывать. А в случае применения -- не вижу, чем отличается ситуация: влияние на базовую систему в sec updates в плане прыжков ABI сведено к минимуму ровно благодаря той самой заморозке версий, которая Вас не устраивает. Соответственно если что-то в /usr/local пользовалось libK, стоящей в /usr/lib -- сломается оно исключительно в том случае, если сек-апдейт libK приведет к ломанию побочного эффекта, на который закладывалось это что-то и получаем трейдофф "безопасность vs работает-это-что-то", который практически неизбежен в любом мыслимом раскладе такого вида. > >Роман, но это неправда. Я бы даже сказал -- типичное > >передергивание в стиле LOR. Зачем это здесь? > Михаил. Я не передёргиваю. Но тогда совсем не понимаю. > Я не скрываю своих мыслей. Я пытаюсь _донести_ до коммунити то, > что думает куча людей, выкидывая дистры в урну. Да понятно, что проблемы есть. Но они -- в совсем другой области: те, что Вы ровно в предыдущем письме привели -- скорее просто нерешаемые на данном этапе развития технологии, культуры, экономики СПО. > Пытаюсь сказать что-то людям, которые начали вариться в > собственном соку - сборка ради Сизифа, Сизиф - ради грядущего > дистро, а по выходу дистро имеет срок годности, дай бог в > квартал, на него все забивают и идёт "развитие" ради сизифа. Ну почему. Живет себе ALM2.2 на серверах и живет, в одном месте даже 2.0 -- лень было обновлять over ssh "по старой памяти", бишь задаром. > Если приглядеться, то никто про updates не сказал _честно_, что > это лишь security-fixes (так по факту обстоит дело). Это как так? Где не сказали? > И никто не подумал, что обновления функциональности и > совместимости нужны не меньше (на самом деле больше), чем > секурити. Это дорого. Ровно как обновление бытовой техники из-за расширения функционала или машины ради увеличения рабочего объема и интеллекта АКПП раз в квартал. Кому надо -- тот и мотивирует, своим временем или оплатой времени тех, кто берется сделать. > >Круг замкнулся. Итак, какие проблемы с RPM, кроме очевидных -- > >обеспеченный внешними факторами дрейф версий и ABI библиотек, на > >которые приходится закладываться зависимостями с целью > >предоставления пакету необходимой функциональности базовой (для > >него) системы? > Да. Что-то не так. РПМ изначально (с аптом или без) был > призван дать свободу пользователю устанавливать требуемый софт. В первый раз слышу. > Минимизировать возможные проблемы, что то сделать с адом > зависимостей... Ну, это CEO-level понятия. На практике он предназначен для автоматизации действий администратора, но никак не для решения проблем сдвига sonames в базовой системе или недостаточной функциональности прошлогодней версии пакета. Это отвертка, а не панацея :) Возможно, Вам просто стоит свалить какие-либо задачи на подчиненных, оставив себе более высокий понятийный уровень их постановки? > Всё идёт по спирали. Пользователь до сих пор в этом аду, но > теперь, с более совершенным apt не может чихнуть без отказа от > какой-никакой целостности дистрибутива. Да ну. Аптом пользоваться никто не заставляет. Для шибко умных в трудные моменты остается --nodeps, если знать, что делаешь. В общем, не вижу смысла тут растекаться мылию по древу. Инструменты могут быть "виноваты" в своей кривости, кривости того, к чему их применяют, или неадекватности применения. Если пеняете на кривизну апта -- она есть, но в других местах. Если пеняете на кривизну подлежащих ему репозиториев -- да, в релизах есть свои проблемы, в unstable -- свои. Приходится выбирать, но всего сразу, нахаляву ($40 -- халява) и без проблем -- пока на планете не наблюдается. Если же вопрос в неадекватности применения -- возможно, действительно осмысленно провести пересмотр инструментов, что, как понимаю, уже и выполнено. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/