Исходное сообщение
"Летнее обновление ALT p9 starterkits " Отправлено Michael Shigorin, 15-Июн-20 22:02
>>> чтобы избавить разработку и эксплуатацию пакетного менеджера >>> от необходимости быть специалистом по низкоуровневым >>> базам данных. >> при эксплуатации rpm-alt мне что-то не помню, бывали ли когда нужны db?.?-utils... > Если хотите разобраться с, например, проблемами производительности > или повреждением БД в процессе эксплуатации, нужно быть специалистом > по низкоуровневым БД. Понятно, что при выборе между удобством таких разборок и производительностью/надёжностью в 99,(9)% остальных случаев стоит учитывать и первое.  Вот только ставить его во главу угла -- ну модно, конечно.  Но не работает.  Дальше по этой дорожке -- соседняя новость с post-meritocracy. > Если скажете, что не сталкивались с проблемами с работой БД rpm > в rpm-alt, то не поверю Ну не верьте, но вот как есть.  Один раз как-то давно пришлось выкручиваться из rpmdb, подразваленного чем-то вроде отключения питания при dist-upgrade, но против лома с приёмами у кого хочешь сложно. > в p8 после работы apt-get регулярно в фоне зависала или по очень > долгу весела какая-то операция с БД, кстати, как решили это? > В p9+ не замечал такого. Это стоит в devel@ спросить. > По запросу "rpm rebuild db site:altlinux.org" также нагугливаются > типовые проблемы с БД, корневая причина которых, на мой взгляд, > именно в том, что на пакетный менеджер возложены совсем не > свойственные ему задачи, которые он выполняет плохо. Пробежался по этим вот из попавшихся на первой странице именно гугла: http://forum.altlinux.org/index.php?topic=28293.0 http://forum.altlinux.org/index.php?topic=9405.0 http://forum.altlinux.org/index.php?topic=42874.0 http://forum.altlinux.org/index.php?topic=34644.0 http://lists.altlinux.org/pipermail/devel/2002-April/086943.... -- удивлён Вашим предположением даже в его краткой форме. > Все аргументы против этого, которые слышал, сводились к теоретической > потенциальной потери производительности. Ну пускай какие-то операции > выполняются чуть дольше Это сразу же стукнет и по сборочнице, если что. > на тех машинах, где запускается rpm, это не будет заметно, > на embeded его не запускают. Вообще-то запускают. > Чем еще неправильно? Попыткой "свести всё к javascript", который "зато знакомый". >> неспециалисты по разработке вроде Panu останутся неспециалистами > А какие претензии к Panu? Порой неспособен понять хороший патч, но это полбеды. Он способен _выкинуть_ хороший патч.  На этом фоне наступание на давно известные грабли -- лишь вторые полбеды. Более подробно писал в новости про rpm 4.14, если не ошибаюсь.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>>> чтобы избавить разработку и эксплуатацию пакетного менеджера >>>> от необходимости быть специалистом по низкоуровневым >>>> базам данных. >>> при эксплуатации rpm-alt мне что-то не помню, бывали ли когда нужны db?.?-utils... >> Если хотите разобраться с, например, проблемами производительности >> или повреждением БД в процессе эксплуатации, нужно быть специалистом >> по низкоуровневым БД. > Понятно, что при выборе между удобством таких разборок и производительностью/надёжностью > в 99,(9)% остальных случаев стоит учитывать и первое. Вот только > ставить его во главу угла -- ну модно, конечно. Но > не работает. Дальше по этой дорожке -- соседняя новость с > post-meritocracy. >> Если скажете, что не сталкивались с проблемами с работой БД rpm >> в rpm-alt, то не поверю > Ну не верьте, но вот как есть. Один раз как-то давно > пришлось выкручиваться из rpmdb, подразваленного чем-то вроде отключения питания при dist-upgrade, > но против лома с приёмами у кого хочешь сложно. >> в p8 после работы apt-get регулярно в фоне зависала или по очень >> долгу весела какая-то операция с БД, кстати, как решили это? >> В p9+ не замечал такого. > Это стоит в devel@ спросить. >> По запросу "rpm rebuild db site:altlinux.org" также нагугливаются >> типовые проблемы с БД, корневая причина которых, на мой взгляд, >> именно в том, что на пакетный менеджер возложены совсем не >> свойственные ему задачи, которые он выполняет плохо. > Пробежался по этим вот из попавшихся на первой странице именно гугла: > http://forum.altlinux.org/index.php?topic=28293.0 > http://forum.altlinux.org/index.php?topic=9405.0 > http://forum.altlinux.org/index.php?topic=42874.0 > http://forum.altlinux.org/index.php?topic=34644.0 > http://lists.altlinux.org/pipermail/devel/2002-April/086943.html > -- удивлён Вашим предположением даже в его краткой форме. >> Все аргументы против этого, которые слышал, сводились к теоретической >> потенциальной потери производительности. Ну пускай какие-то операции >> выполняются чуть дольше > Это сразу же стукнет и по сборочнице, если что. >> на тех машинах, где запускается rpm, это не будет заметно, >> на embeded его не запускают. > Вообще-то запускают. >> Чем еще неправильно? > Попыткой "свести всё к javascript", который "зато знакомый". >>> неспециалисты по разработке вроде Panu останутся неспециалистами >> А какие претензии к Panu? > Порой неспособен понять хороший патч, но это полбеды. > Он способен _выкинуть_ хороший патч. На этом фоне наступание на давно > известные грабли -- лишь вторые полбеды. > Более подробно писал в новости про rpm 4.14, если не ошибаюсь.
	Введите код, изображенный на картинке: